If you’re doing any wireless penetration testing these days, odds are you have a WiFi Pineapple Mark IV from Hak5 in your toolkit. If you’re not a professional penetration tester or are just starting out with wireless hacking, the Pineapple is a device that will save you a considerable amount of headaches and is easily the best “all-in-one” tool for the job. This first article in a series of three tutorials is all about walking you through those first baby steps of configuration to get your new toy up and running. Part 1 starts with the Mark IV since many shops have this device already. Part 2 of this series covers the new Mark V, and Part 3 will show the device in action on a real pen test.
The first step to being successful in any endeavor is preparation, and the pineapple is no different. This tool packs a considerable amount of options into a small frame, and getting your new device up and running prior to “game time” is critical. We’ll show you how to set up your host computer’s network interfaces, the communication options to talk to the device, installing and configuring modules (known as Infusions), and more. So let’s get to it.
WordPress is by far the most popular Content Management System (CMS) in the world today. According to W3 Techs, “WordPress is used by 58.2% of all the websites whose content management system we know. This is 18.6% of all websites.” As with most modern, popular CMSs, the WordPress application itself is hardened and secure out of the box. But to get all of the cool ‘stuff’ to make your site memorable and engaging, WordPress site owners often use 10 – 20 plugins for each installation. As of July 2013, WordPress.org lists 25,700 plugins with more than 475 million downloads, and that doesn’t include those outside of the WordPress repository. It’s these third party plugins that leave a tight framework vulnerable to exploitation and attempts at hacking WordPress common. Many installed plugins remain unpatched or overlooked, and even those not activated through the WordPress Dashboard provide an excellent attack surface. With shared hosting plans and consolidated corporate data centers, it is more often than not that your instance of WordPress is not the only web application residing on your server.
For the sake of brevity, I won’t “beat a dead horse” and talk about why Cross-Site Scripting (XSS) is dangerous. There still is some confusion surrounding XSS and its role in network breaches, how it is used, and how it can be utilized over and over to do the same thing. An attacker cannot leverage an XSS flaw to directly “hack” into a server. Instead, by chaining vulnerabilities together and socially engineering personnel, an attacker can move from XSS to an internal compromise fairly quickly. This tutorial shows how hacking WordPress with a simple XSS flaw can be crafted into a vehicle to intrude on internal networks.
By Todd Kendall
Security professionals are often tasked with the unenviable position of wading through millions of bits of data, the review of thousands of systems, or the evaluation of hundreds of applications. At the end of the day it is their job to provide the ten thousand foot view of an organization and the highest rated findings that put it at risk. Information overload is a common theme in today’s society, and management requires the presentation of this material in a digestible manner of typically one page or less. The ability to provide this service requires what is often referred to as “seeing the forest for the trees.” In other words, don’t get distracted or bogged down by the minutiae of your discoveries at the risk of overlooking the big picture.
When it comes to computer forensics, however, the tables are flipped. When an event turns into an incident and management must answer to a board or the company’s shareholders, the ten thousand foot level is no longer adequate. At this point, every packet that ever crossed your company’s domain becomes suspect, and expectations are set whereby the answers to the questions such as, how did it happen, what damage did it do, where did it come from, when exactly did it occur, and who did it, requires the puzzle to be unraveled and presented in such excruciating detail it would make Melville take up skim-reading.
By Thomas Wilhelm
I had a question the other day from a student at the Hacking Dojo who was interested in accessing a Windows system remotely through SMB. My initial response was to tell the student that it was similar to FTP, and they should conduct the same type of enumeration against SMB as they do anything else open on the system. Unfortunately, this did not help the student, because their hands-on experience on Windows file sharing was all done using GUI. It then dawned on me that, since I came from a Solaris background, I had a different experience. I would simply map the drives at the command line as a system / network administrator. Because of this, I decided to put together a quick tutorial for my students. Since there might be some additional confusion in the general populace of the security community, I thought getting it published on The Ethical Hacker Network would be beneficial. In a world where security awareness is rapidly increasing and your grandmother even has a secure wireless access point, one might imagine that admins without command line experience and open, anonymous SMB shares are a thing of the past… think again!
During a penetration test (pentest), it is natural to investigate FTP services within a network that allow anonymous access. It is possible that sensitive data is unintentionally placed on an FTP server by non-IT employees (for the sake of convenience) without knowing who else can access the material. During a pentest, I find these anonymous FTP systems quite frequently, and in some cases they serve up useful information. Now, if we compare FTP with system shares, we find that employees are quicker to allow anonymous access to their own files – all it takes is someone wanting access to some document another employee has on their system. In fact, sharing a single file makes it easier to maintain revisions than copying a file back and forth between an FTP server. While that is certainly convenient for the employees, it is obviously quite devastating for the organization’s security posture. So let’s take a look at SMB shares and how we can take advantage of them.
Keyloggers are usually one of the top picks for a hacker or a spy’s best friend. They basically serve as the eyes and ears of the attacker. They can be based on software or hardware and send detailed reports including the user’s passwords, chat logs, all typed text, launched applications and visited websites. They can even send screenshots to visually show what the user was viewing as well as any webcam and microphone activity. Most laptops today come with a built-in webcam and microphone and don’t usually give any signal that they have been enabled. Any person who uses that computer will have all their activities monitored and recorded in an encrypted log which only the attacker can access.
In this video, I will present the basics of keyloggers and also demonstrate a couple of my favorite keyloggers, their features, how hidden they are and how to prevent and detect keyloggers in general. At the end of this primer, the viewer should be able to fully understand where keyloggers fit into both sides of the equation.
By Thomas Wilhelm, ISSMP, CISSP, SCSECA, SCNA
Many people are familiar with John the Ripper (JTR), a tool used to conduct brute force attacks against local passwords. The application itself is not difficult to understand or run… it is as simple as pointing JTR to a file containing encrypted hashes and leave it alone. In a professional penetration test, we don’t always have the time to allow JTR to run to completion, and we must rely on some additional techniques to speed things up including the use of wordlists or dictionaries. JTR comes with its own wordlist containing supposedly common passwords, and we can use that dictionary to identify some low-hanging fruit. However, in most cases, the supplied JTR wordlist is woefully inadequate in identifying a wide-range of commonly-used passwords, especially when people prefer to select passwords that have some meaning to them (e.g. hobbies, partner names, child names, and pet names). So how can we improve our use of JTR to catch passwords that have relevancy to the users of our target system? It may be a bit more complicated than it seems.
The Information Systems Security Assessment Framework (ISSAF) provides an adequate methodology when focusing on password attacks and includes the suggestion of using dictionaries. For those who conduct penetration testing, the use of dictionaries is only one of two prongs used in attacking a local, encrypted password list; brute force attacks are conducted after we have attempted to break passwords using dictionaries. In this fashion, we can (hopefully) obtain weak passwords to work against during the pentest; anything discovered during the brute force attack (assuming it is too late in our pentest to use then) can simply be added to our wordlist for future penetration test projects.
Rainbow tables reduce the difficulty in brute force cracking a single password by creating a large pre-generated data set of hashes from nearly every possible password. Rainbow Tables and RainbowCrack come from the work and subsequent paper by Philippe Oechslin . The method, known as the Faster Time-Memory Trade-Off Technique, is based on research by Martin Hellman & Ronald Rivest done in the early 1980’s on the performance trade-offs between processing time and the memory needed for cryptanalysis. In his paper published in 2003, Oechslin refined the techniques and showed that the attack could reduce the time to attack 99.9% of Microsoft’s LAN Manager passwords (alpha characters only) to 13.6 seconds from 101 seconds. Further algorithm refinements also reduced the number of false positives produced by the system.
Caution: With tools such as these, we do not condone their use for anything but testing networks for which you have the authority and for implementing defensive measures. Have fun!