Techgage logo

SysAdmin Corner: Introduction to Pentesting and the Pwn Plug – Part 1

Date: December 20, 2012
Author(s): Brett Thomas

Many sysadmins understand how to set up and maintain a network, but the concept of auditing is an entirely different world. In the first part of a series on auditing and penetration testing (pentesting), we introduce the concepts and tools for putting all that security to the test. We’ll also talk about our pentest platform of choice, the Pwn Plug.

Introduction; Understanding Vulnerabilities

When we build networks – particularly small ones – it can be easy to “set it and forget it” by plugging everything into the router and clicking “Deny All” incoming and “Allow All” outgoing. While, indeed, this can be an effective start to small business security (many consumer routers that are not wireless-enabled can be an effective front-line of protection this way), it’s only one point among many that needs to be considered. 

To effectively protect a network, particularly in an ongoing fashion, there are three things required:  proper setup, proper monitoring, and proper auditing.  Setup involves things like user accounts, firewall rules, domain policy and software upgrades/patches.  Monitoring involves maintaining and examining logs, analyzing traffic through things like Wireshark, and the installation/maintenance of an Intrusion Detection System (IDS) such as Snort.  Auditing, which is the aspect we will begin to look at today, involves putting the network security through its paces – learning what vulnerabilities exist and how they can be used by an unauthorized party to gain access, maintain access, and perform reconnaissance about your deeper network. 

In other words, auditing is about hacking your own network in a controlled and documented manner.  We call it penetration testing, or “Pentesting” for short.  In the IT world, there are numerous tools designed for the security-minded to help them test their networks – from the extremely expensive commercial products like those from CORE Security to the freebie open-source Backtrack Linux distribution.  Some offer one-click tests, others rely on you to understand the intricacies of what you are working with – which probably means you already vetted your setup, software and services carefully to begin with and are just making sure all is right with the world.

Pentesting is not a process that’s learned in a day or a week or even a series of tutorials as we’ll write here, but there are basics that can help you get familiar with the process.  The purpose of this series will be to use what I feel is an excellent platform of pentesting tools contained in a handy little box – the PwnPlug by Pwnie Express.  It’s well-balanced between price, performance, and ease-of-use, and is something that I feel should be in every true sysadmin’s toolbox if setting up or protecting the network is in his or her job description.  Though the tools available on it are open source (and thus available without cost), there is no place you can get so many things in one small, mobile package. 

This particular article is aimed at the novice in security (who understands basic networking principles and may have some minor programming experience), introducing you to the terms, concepts and goals of both a successful pentest and a well-thought-out attack (which are really the two sides of the same game of chess), and introduce you to the PwnPlug and its tool suite.  Part two and beyond of this series will get into using the individual tools to examine your network for vulnerabilities and learn what can and can’t be monitored through open-source tools.

Vulnerabilities – What they are and how we get them

Before we go further into the tools of exploitation, it’s important to understand a bit about vulnerabilities, which come in two flavors:  holes and bugs.  Holes are an easy concept, and are usually the result of us as sysadmins configuring our networks improperly.  A hole can be anything from leaving ports open to not enforcing good domain policy to misconfigured services (I once audited a network where the external-facing DNS server spit out an entire map of the internal network due to an error in the BIND 9 config).

Bugs, on the other hand, are somewhat out of a sysadmin’s control.  Bugs are flaws in a currently running program or service that the programmer did not intend to be there. They are a natural byproduct of the complex programming required by modern systems, and largely arise from the fact that programming is actually the exact opposing concept (and school of thought) from true hacking.  Programmers, as a stereotype, are methodical people creating things from the ground up.   Contrary to popular belief (especially as jokes amongst the technically intelligent against companies like Microsoft and Cisco), these people take their roles very seriously and work as quickly as they can to patch flaws in their products once discovered. The problem is, when you are building something up, you often don’t have the ability to think of how the not-even-existing-yet final product could or would be taken apart.

Most bugs come from new feature sets that are introduced on a tight schedule that demands a product be released as soon as it’s functional, which is a different concept altogether from secure.  After all, end users usually compare the feature-list (not the security patches) when they are making buying decisions.  The developers then have to go back and fix what’s found afterward as it’s disclosed, having likely already been moved on to another project.  Most of the bugs are byproducts that simply can’t be detected in the short amount of time before a feature goes live or in a small testing environment, as different usage scenarios influence vulnerabilities tremendously. 

Bugs come in all shapes and sizes – from critical vulnerabilities like SQL injection on a webserver to “harmless” ones like Denial-Of-Service (DOS) weaknesses. They can cause anything from a crashed process to the theft of information.  The more dangerous a bug is, the less you will hear about it (even if it’s being used on you!) until it’s patched – the best exploits leave the process that they hijack running normally, while inserting themselves into other areas of the system. 

The most dangerous kinds of bugs are ones that are made inadvertently by incorrectly parsing a variable.  The most common type of this is the “Buffer Overflow”, which takes a program that’s waiting for input and crams a response that’s too long into it, causing it to actually execute part of that response as if it was the program’s own code.  Though operating systems across the board have made steps to secure this (the biggest ones being ASLR and DEP), they have started a cat-and-mouse game that provides security for only a short time.  Both technologies have seen multiple revisions through each OS, and both technologies are routinely broken or bypassed shortly thereafter. 

Web technologies have made the list of vulnerabilities that much larger,  as we build software that runs within its own Java VM or interfaces that use a scripting language like PHP, Perl or Python.  For instance, if a Tomcat Web service ties into your database and the attacker wants the database, s/he can get that access through multiple points – breaking into your server’s OS remotely (often difficult), breaking into the network from another entry point and then connecting to the DB port directly (much easier), or breaking into the Web service sufficiently to make it display the results of rogue queries (entirely dependent on the software in question).

Understanding the Battlefield

Who are we really defending from?

In all of technology, I don’t think that there is a field more misunderstood than hacking.  To most, even the very word conjures up images of pimple-covered geeks with buck-teeth, staring at a bright green cursor on a black console and wielding black magic at the digital gates of a target.  Some think of the modern “hactivism” movements of Anonymous and the likes, others think of stolen credit cards and breached e-commerce servers.  Though these things are certainly what the media wants to portray of hacking, the reality is far, far different.  I would even dare say that most of those who perform these actions aren’t even hackers – simply script-kiddies using the tools created by the best and the brightest. 

So then, what is hacking?  Hacking is the art of reverse-engineering protection.  It is the art of gaining access.  The true hackers that I have met over the years (the ones who further the art, attend the conferences, publish the exploits, etc) are puzzle-solvers, looking at firewalls and protocols as a Rubik’s Cube.  There is no “evil” or “good” hacking, it’s a pursuit of knowledge – not knowledge of what your credit card number is or email account holds, but knowledge of the systems you used to secure your information.  These people publish their work for the community at large, and hope that the systems they identify will be updated and provide new challenges and puzzles.  Smarter mice require better mousetraps, and it is the end consumer who truly benefits. 

Yes, I just said that true hackers are not a threat to, but a benefit to end-user security.  And odds are, unless you’re a major multinational corporation that somehow became an interesting target for political purposes, you’ll probably never encounter one trying to break into your network.

The problem is, the tools and the whitepapers and the exploits then filter down to those less-skilled and less well-intentioned… the script-kiddies.  Knowledgeable enough to be dangerous but motivated by other concepts than academic knowledge and understanding, these people wreak havoc on networks… and are usually there for one purpose – to steal your stuff.  We can’t ever assume that they don’t know what they are doing, but we can assume that they will pursue any target not bolted down tight, small or large.  We can also assume that they will go about their task using a variety of already-available tools that perform pre-defined actions.

This concept becomes their weakness – the things they are using against us are already existing, already accessible and will eventually be obsolete, leading them to need to find new tools and methods.  If we know the tools, we can know what weaknesses we have to look out for.  And if we can USE the tools… we can make sure we aren’t susceptible.

Tools of the Trade

As I mentioned before, there are numerous tools at your disposal for pentesting.  The cheapest and most powerful tool is absolutely free – Backtrack Linux.  Backtrack is pre-packaged to do one thing and do it well – audit networks.  It comes pre-loaded with all the tools you could need, is updated routinely and runs like a champ.  I love BT and have used it since v2.  There’s only one problem with it:  For someone learning the process or who will not use all of the tools on it, Backtrack is an overwhelming [email protected]#! of options with little to clarify how to even begin.  

This is further compounded by the hardware limitations of Linux, particularly with wireless.  Assuming you can get everything to work on whatever laptop you have available, you may still need a new wireless card, a second Ethernet card, and a variety of other bits and bobs to truly make an effective pentesting platform.  It’s met with further limitations because that machine cannot be easily dedicated to stay on the network as an access point long-term, which is often necessary to test other important (more human) failings.

At the other end of the spectrum are the huge platforms designed by a security company for other security/auditing/pentesting companies, like CORE Impact and Metasploit Pro/Express.  But these come with their own set of limitations – they run the tools that are programmed into them – often many at once – and routinely require that you disable certain network conditions in order to “properly” test.  The “instant dump” of exploits can overwhelm IDSs and logging, so those routinely need to be turned off, which disables one of the key points of auditing – knowing how a problem will show up in your logs.  Further adjustments to test for specific vulnerabilities prevent you from being able to audit the network that is actually running. 

Of course, you get what you pay for as far as ease of use.  Things like CORE Impact run thousands of dollars per license, but require little more than clicking a button to accomplish a wide array of tests.  Though I agree with these methods as a convenience for those truly knowledgeable, I feel that they run afoul of the true goal – understanding why things are vulnerable, or how they are attacked.  These products tell you simply “Yes, no, fix…”, which leads to a lack of understanding about what is actually going on.  For all that money, you get to learn all about bugs… but nothing about exposure or how to better protect your network.

This set of circumstances means that it is very hard – particularly in smaller businesses – to find the tools necessary to properly and effectively audit.  On one hand, we have an expensive vulnerability scan that’s so easy a monkey could do it, but it tells us nothing about how an attacker can get in or what they may actually accomplish once within the systems.  On the other hand we have a free suite of bona fide hacking tools, but they are useless without both carefully selected hardware and the hacker that would run them. 

The middle ground in this is my preferred solution, the Pwn Plug.  It’s not free, but for $500 and up you get a pocket-sized powerhouse – an entire Debian Linux system in a little headless box with a network port, USB port, and all the options you need to test a network – and nothing more.  Configure it, plug it into the wall, plug it into the network you’re auditing, and you’re off to the races.

Where we begin in a pentest (and valuable lessons from the RMS Titanic)

If you’ve been reading carefully so far, you’ll notice that all of the solutions listed above have a very important common point, leading to what might just be the most often heard question when introducing sysadmins to pentesting:

“All the pentesting platforms start from already being inside of the network.  I’d never give some stranger a plug to go jack into my network, so why on earth would we start from there?”

It’s a perfectly rational question.  If your outer perimeter is strong enough, it would be very, very hard to get into your network in the first place.  Therefore, it seems like we’re skipping past the bulk of the security right off the bat – the most important security, in fact, which seems like it should be tested more thoroughly than anything else!

However, if we start from the idea that the outer layer is never breached, then there really is no point to testing anything inside the network. The guys who developed the hull of the RMS Titanic felt similarly. We all know that’s not how things work in the real world – we have to start with the assumption that our very first layer of protection (however good) has failed, and there is now someone on our network just past the router.  In fact, it’s important to test at each layer of security present on the network and never, ever think your ship is unsinkable.

Pentesting tools can certainly help test your outermost layer of protection, but the reality for that outermost layer is that there are only two real-world outcomes – you either have a breach, or you don’t.  If you don’t, there’s nothing to worry about.  If you do, and you wasted all your time testing that and assuming it secure, you will have absolutely no clue as to what the attacker could have gained access to or how. 

Most of the time, the outer layer is breached by an internal vulnerability anyway.  Pretty much all of the major hacks of the past couple years have been started by “spear phishing”, using targeted emails to make employees run malicious code that sends out the first foothold for the attacker.  These types of attacks are hard to prevent because they rely on the weakest link of all – reckless users.  Even the best ship sinks when the user doesn’t read the warning and steers right into icebergs.  No candy-coating necessary – users sometimes suck.

Just think of some of the dumb calls received by Tech Support, and ask yourself, “Can I really prevent them ALL from doing stupid things?” 

Our Pentest Platform: The Pwn Plug

Introducing the Pwn Plug

As mentioned when discussing tools, the Pwn Plug is designed to sit squarely in the middle of the industrial vulnerability scans and the built-by-hand pentest system.    It’s designed from the ground up to be everything that a pentester needs in a small, polished package.  Configure it, plug it into the wall, plug it into the network, and instantly, you have many of the same pentesting powers available in Backtrack Linux and a couple of the most amazing abilities ever – easy setup, and a host of “outbound” communication methods that will leave your IDS bewildered beyond belief. 

Pwnie Express has packed a lot into a little package – we’re using the PwnPlug Elite for our articles, but even the cheapest of the bunch (the Mini) has access to all but a couple of the features we’ll cover here in our tutorials.  The most important features included on the Elite version are advanced security bypassing on wired networks and the ability to actually not even use the target network to “phone home,” instead using a 3G/4G cellular connection that receives inputs by SMS.  The SMS feature in particular is more for advanced long-term testing and monitoring and, though a huge selling point for a person who needs to monitor several complex networks, is well beyond the scope of anyone needing this primer.  The security bypass, however, is a pretty major feature even for a beginner, as it allows you to test a few things on more secure networks that you couldn’t easily do without it.

The PwnPlug strikes a perfect balance between cost and function – unlike products such as Metasploit Pro and CORE Impact, it’s a one-time entry fee of between $500-$1,000 (depending on model) with no future costs.  Unlike Backtrack, it doesn’t require any separate hardware to make it work.  Thanks to its easy setup, it’s the perfect tool for someone who isn’t entirely familiar with the intricacies of the security field to keep themselves up-to-date with the same tools that an attacker would use… but provides a full pentesting platform for those who are already knowledgeable and are looking for something efficient and easy to deploy.

This cannot – CANNOT – be understated:  The tools that are on a PwnPlug are the tools used against many networks.

This leads to one of the greatest misconceptions about the Pwn Plug, including an entire article in Wired magazine that completely misstated the device’s purpose:  Is the PwnPlug is a hacking tool?  No – it could be, but most script-kiddies are cheap, want bigger antennas and a screen for war-driving, don’t want to leave $1,000 systems unattended (even if they ARE discreet), and (if they’re any good) are probably using the tools already on the laptop they’re trying to break in with.  It is a tool designed by hackers for pentesters.  The point of the Pwn Plug is so that WE, who need to be aware of the tools, techniques and technology used against us, can effectively audit our networks in the same way that an attacker would attempt to attack it.

One of my favorite parts of the Pwn Plug is its simplified configuration.  All of the plug’s network settings can be controlled via a Web-based UI (called, unoriginally, PlugUI), allowing you to make changes quickly and easily.  Arguably the most important of these configuration options is the way the device interfaces with you, the pentester – setting up complex options that can be difficult to get working via individual commands are nothing more than a checkbox away.   Once configured, it can simply be taken to the site, plugged in the wall and the network, and left to do it’s thing.  If all goes well (or poorly, depending on your network setup), it will let you know via your chosen method that it’s ready to roll, and is awaiting your command.

Having the more common tools for pentesting built in the PlugUI would be a nice touch, because most all of the setup options just deal with how the Pwn Plug connects to the world around it.  The proper auditing still begins from the command line on the device, same as on Backtrack.  However, most of the tools we’ll be covering can be taught effectively even if you don’t have a lot of Linux CLI experience.  Pwnie Express has talked about a massive update to the PlugUI that will allow much more Web-based functionality, which is a concept I do hope that it can implement.  Though many tools are better with a host of options more suited for a command line, there are quite a few things that are basic pentest concepts that can be automated by scripts and run through the Web interface, saving their results for more complex command-line functions later on.  The unit already does one of these right now with a “Passive Recon” mode, which turns the box into a stealthy little information gatherer by analyzing the network traffic passed and obtaining things like IPs, OS guesses, open/used ports, and clear-text passwords.

Each model in the series comes with a lot of testing firepower, including Wi-Fi by default and Bluetooth as an option (standard on Elite models).  This, on its own, is a huge selling feature for me – matching up Wi-Fi cards that have the proper chipset to go into Passive/Monitor mode can be a giant pain.  It also means that for the price of entry, you aren’t having to spend extra money finding a way to test your mobile systems or wireless network.  Also optional on the lower models is an extra USB-Ethernet adapter to let the Pwn Plug function as a completely pass-through appliance, allowing it to function transparently on switched networks.  On the Elite model, this is upgraded further to allow the advanced one-click Network Access Control (NAC) bypass, which is a huge bonus for testing Active Directory, Kerberos or other protected networks. 

It’s this versatility that makes the Pwn Plug such a good platform.   In a flash, we can put it inside or outside of the NAC controls or Wi-Fi network.  We can stealth it to be un-ping-able and virtually undetectable, or treat it like a system already on the network.  We can contact it in a variety of ways. We can position it at nearly every layer of network security as if we had breached that particular layer.  And at each layer, we still have the full suite of tools at our disposal, instead of being limited to certain ones based on our own attacking skills.  This is a vital benefit to this particular platform – it assumes we aren’t an elite hacker that knows everything about breaking and entering, and therefore gives us the access a more skilled attacker might get that maybe we wouldn’t if we were trying to break through the layers ourselves.

If there is one complaint to the Pwn Plug, it’s that of limited memory and processing firepower.  You can’t expect a device that is the size of a large power adapter to be a computational powerhouse, but certain intensive tasks do take a while.  The memory hampers it more, especially since some programs (like the Metasploit Framework) are already needing to be “shaped” by Pwnie Express to run within the 512MB of RAM and storage.  Though the SD card slot built into the higher-end devices helps, that doesn’t assist with the actual program/OS storage.  The device works wonderfully for its target purposes, but it takes some patience with parts of the toolset. 

Before we get too far into discussing the tools provided in the Pwn Plug, however, we still have a bit more very important theory to cover – how an attack actually happens. 

Understanding an Attack

How an intelligent attack really happens

Hacking and Information Security are, as I mentioned, two sides of the same game of chess.  In order to play one side effectively, you must understand the moves available to the other side and anticipate them.  A successful attack is usually a well-planned attack, because entering a network is not usually a simple process unless it’s set up very poorly (such as in the case of our Seven Network F-Ups Small Businesses Make).

We discussed at the start of this article that there are really three general phases to administrating a network – setup, monitoring and auditing.  Likewise, there are three general phases to an attack on a network – reconnaissance, exploitation, and maintenance. Each of these phases can be broken down into subsections, but the general process usually goes:

  1. Research what vectors of attack you have available to you;
  2. Scan for vulnerabilities, starting with the most promising ones;
  3. Exploit found vulnerabilities;
  4. Create new or maintain current access routes;
  5. Remove tracks;
  6. Repeat.

The recon phase is parts 1 and 2.  Notice that the actual “hacking” is only one step out of the sequence, and is (believe it or not) the most trivial.  Maintenance, which we’ll cover in depth in just a moment, involves parts 4 and 5.  

Any good attack starts with the basics:  research, followed by more research, followed by more research.  Systems are scanned, the potential OS fingerprinted, the most vulnerable of those is scanned in detail, services are examined, versions checked and researched, and then – finally – an attack is performed.  Even with the advent of Metasploit, which is the crux of every “hack-in-the-box” that a script-kiddie can use, intelligent attacks still follow this pattern.

The most important of the three phases to the attacker, believe it or not, is the maintenance of access.  A wise attacker will do a lot of reconnaissance on your network before trying to move another layer into it, and a true data thief may want to do little more than set up camp to listen for traffic, decrypt SSL certificates, and harvest internal e-mail/sip/other communication.  In order to do this, the attacker needs time and, quite often, numerous re-entries. 

How many times the attacker repeats these phases will depend on how many different protections that you have put in place.  If all you’ve done is fenced the perimeter (which is one of the seven F-ups), very little time will required to harvest large amounts of information. On the other hand, if gaining entry leaves the attacker looking at a Kerberos or ActiveDirectory protected domain and properly protected database connections, s/he has just barely opened the door and there is a lot of work ahead indeed. 

Each protection needs to be peeled back like layers of an onion, and in order to keep those layers from snapping back into place (and thus having to do it all over again), one needs to establish a foothold.  The absolute best foothold is, of course, the login/password/token/etc. that would allow you to enter and leave the network as a privileged user at your convenience, without having to use further exploits.  However, since good network design should make that as absolutely difficult to obtain as possible, we are stuck with our tools and hopefully the ability to get what a login would have yielded – a command line, or shell.

The Shell (and why reversing it is such a big deal)

The Shell, or command prompt, is the holy grail of access. Even an unprivileged user account can do a very large amount of digging and recon work with a basic shell.  This is compounded by the fact that prior to Windows 7, most users had to be privileged at least on their local machine (though not the network at large), meaning full access to a variety of components that can allow for deeper exploration/exploitation.

However, even if an attacker could get one easily enough, making use of it from afar is a tricky ordeal.  Shells are usually a “by request” action – you ask, the machine checks if you have the right to have one, and then it accepts or rejects.  Forgive the remedial reminder here, but with Network Address Translation (NAT) present in IPv4, this is an important concept.  An internal network is just one IP to the outside world, even if it has 200 machines behind the router.  If the firewall is configured to block incoming requests (or forwards them to specific machines), those on the outside can’t get to any specifically vulnerable computer within the network to request the shell – the router wouldn’t know where to send it, and will just drop the packets with no response. 

That means your firewall’s “Block all incoming, allow all outgoing” seems quite effective, as even that unpatched Windows XP system behind a cheap-o router is useless to me as an attacker… unless I can get it to initiate the connection.  This is called a reverse shell, because the target contacts the attacker and offers a shell, instead of the attacker logging into the target and requesting it.  The shell will have whatever privileges that the user whose process created it has.  Reverse shells are nothing new to attackers – they’re how you get a computer that is inside a closed network to communicate with your computer outside of that network.  Consider it “phoning home.”  There are many ways to do it, and we’ll cover a few of them in these tutorials.

Now, depending on the network setup, you may have been wise and blocked a few outbound ports, too – things like port 22, the common SSH port.  But all Web traffic needs port 80 – and you may not have known that one can funnel the SSH traffic right through that.  Just because a port is “meant” for one kind of traffic doesn’t mean you can’t run different traffic through it as well.  If that’s still too obvious, then how about port 443 (SSL)?  The traffic would look almost identical to what should already be going through there (encrypted websites).  Maybe you were one of those particularly tricky admins, though, who filters or blocks unauthorized Web access from your naughty employees.  That’s ok – you can’t block DNS or ICMP traffic nearly so easily, as otherwise you couldn’t even resolve the acceptable sites.  We can use those ports, too… or countless others (well, maybe not countless… there are only 65,535 choices). 

The Pwn Plug makes it easy to test these different types of connections without needing to know the intricate details of how to set them up, which puts it miles beyond any other pentest platform in ease-of-use.  By simply clicking on some checkboxes in the setup and running PuTTY or SSH set up to listen on a computer outside of the target network, you can see whether your traffic rules and firewall are prepared to detect or prevent this type of communication. 

So we’ve covered the anatomy of an attack and chosen our platform.  It’s on your network, it’s armed to the teeth, and it just phoned home… now, what can we do with it?

The Toolset Intro: Recon

Scanning with NMap

The tool of choice for basic network reconnaissance has been and continues to be (and will likely be until the end of time) the port scanner, NMap.  Port scanning tells you everything you can learn about a target before you start taking shots at it – it tells you what’s open, what’s closed, what’s filtered, what (likely) services and even what OS the target may be running.   That immediately gives you an idea of which machines are likely to yield some fruit and which are likely hardened off against your attacks.

Though its basic premise is simple, using NMap properly can be a tricky thing.   Incorrectly performed port scanning is one of the fastest ways to alert the world to your presence on a network.  Fortunately, NMap comes with a variety of features to help it “blend in” to regular network traffic in order to avoid being picked up by an IDS, and can be quite stealthy indeed if used right.  We will be covering NMap usage in-depth (along with other network topography tools) in Part 2 of this series.

Stumbling with Netdiscover

If using NMap to find active systems is likely to alert the authorities, there is the (less powerful) Netdiscover.  What’s brilliant about Netdiscover is that it can be completely passive, meaning that it will do nothing but sit and watch a network’s traffic for a certain behavior (the ARP request by default).  From these requests, it builds a table of IPs, MAC addresses, and adapter types.   This has the added bonus of helping you quickly sort out which machines might be Wi-Fi connected vs. wired, static IPs that don’t utilize DHCP, or network appliances like copiers/printers.  Netdiscover can also be run in active mode, where it sends out ARP requests and functions much like NMap’s ARP scan, but for the most part I’d rather use NMap in that case.

Sniffing with Ettercap and the dSniff suite

Ettercap is the beautifully malicious packet sniffer.  It is designed through-and-through to function in the role of Man-in-the-Middle (MITM), examining the packets and subsequently forwarding them on to their original destination.  Before sending it on, it can manipulate the packets in any way that you tell it to, including (but certainly not limited to): appending malicious links to HTML or email, changing the content of HTML, e-mail or IM content, stripping SSL off of encrypted communications (if the handshake was captured), snooping through SSH1 connections, blocking a host, hijacking DNS to send a user to unintended targets, and myriad other little nasty tricks. 

It accomplishes this through ARP spoofing/poisoning, thus telling the router that this machine is the target system and telling the target system that it is the router.   The very, very important and handy byproduct of this technique is that Ettercap can be made to sniff all traffic on switched networks, making it invaluable in an attacker’s toolbox.

If you don’t need all of the ridiculous power/complexity of Ettercap, there is the much more individualized toolset of the dSniff suite.  Ettercap can be set to do many things at once, but can be unwieldy and is often overkill.  On the other hand, the dSniff suite comes with a bunch of specific tools to accomplish many of the same goals – think of it as the “All I really am looking for is “.  Its specialty is grabbing passwords for a variety of services (both plaintext and SSL-encrypted, under certain conditions), but it can also track a user’s browsing history (and show you the same thing they are on your screen), log IM conversations, hijack new browsing sessions or restart existing sessions, and spoof DNS responses. 

We will be looking at Ettercap and dSniff in detail in Part 3 of this series, as well as how to detect and defend against them.  ARP poisoning leaves a particular signature on the network which can be picked up by a properly configured IDS or even prevented by specific tools, but be warned – that’s about the only opportunity you get to detect it. 

Sniffing Wireless with Aircrack-ng and Kismet

As mentioned in my seven F-ups article, providing Wi-Fi creates an extra degree of vulnerability to any network.  If configured properly, Wi-Fi simply creates an extra method for harvesting a bunch of junky encrypted data for an attacker.  If configured incorrectly, it opens the door for an entirely malicious system as if it was always supposed to be there.

The crux of the Aircrack-ng suite is Airodump-ng, which kicks the wireless card into passive mode and grabs every bit of traffic sent between all access points and all attached devices, saving it as a capture file.  This file can then be analyzed by Aircrack-ng, which uses a dictionary attack on the handshake packets (in the case of WPA/WPA2) or IVs (if you’re foolish enough to use WEP).   If you’ve captured the handshake for a client and cracked the pre-shared key (in the case of WPA/WPA2) you can decrypt the entire session afterwards using Airdecap-ng or Wireshark.  No handshake or not enough IVs?  Don’t worry about it, just start using Aireplay-ng to deauthorize current clients or inject yourself onto the network (depending on the protection). 

Though Airodump is a beautiful quick-and-dirty capture, some people would like a little more “full-service” software – and that’s where Kismet comes in.  Kismet is part packet sniffer, part analyzer, and part IDS for wireless networks.  Best of all, Kismet functions in a server/client/drone aspect, allowing captured traffic to be streamed to a waiting server rather than remaining on the drone device. This is extremely important for devices with limited space like the Pwn Plug, as it prevents the need to store and analyze the capture file locally.  The file can then be analyzed on a more powerful machine to attack WPA/WPA2 keys using more effective software (oclHashcat, for instance) and decrypt the sessions. 

The Toolset Intro: Exploitation Frameworks

Metasploit Community Framework

All of the bells, whistles and graphs provided by the very expensive pentesting platform Metasploit Pro are actually window dressing for the completely free Metasploit Community Framework, which is easily one of the most powerful, overused and poorly understood tools that exists in security.  The framework is huge – and there is simply no way to cover it effectively even if I wrote a hundred tutorials on it… so when we do cover it later in this series, plan on it barely scratching the surface. 

Metasploit contains an utterly ridiculous amount of software vulnerabilities for nearly every type of OS and service combination that you are likely to encounter in the wild, and is updated religiously by hackers everywhere.  Along with the vulnerabilities themselves, the framework provides built-in code (called payloads) that work with the different types of vulnerabilities (they’re sorted for you, so you don’t need to worry about what won’t work with a chosen exploit).  Hardcore pentesters can even roll their own, and useful ones are encouraged to be submitted to the framework.

The framework is self-updating and self-contained, with a vast array of tools built in (including a comprehensive database interface to track results of each stage of the process).  Because of the regular updates and the newer commercial version (the Metasploit Express license), the Community Framework has changed and likely will change again.  The biggest change in recent memory is the loss of the “Autopwn” functionality, which expedited testing across a wide variety of hosts.  However, Fast-track, which we’ll cover in a moment, helps to bring that back.

On the Pwn Plug in particular, it’s important to note that Metasploit has been pared down to specific functionality for pentesters, instead of being the complete “hack-in-the-box” that it’s come to be known for.  Those who are familiar with certain features will likely find them needing to be separately installed, but for most people that are trying to genuinely test (instead of just break) networks, the changes won’t be very noticeable. 


Metasploit is a great test of a network’s exposed services, but it ignores two of the most powerful exploits known to the industry – users, and browsers (Metasploit’s Browser Autopwn is part of the community framework, but it doesn’t provide any direct method for getting someone to go to the attack site).  And as we have covered earlier, users suck.  The Social Engineering Toolkit, or SET, is pure proof of that concept – it’s designed to create phishing mails and tie them to well-dressed autopwn websites that exploit a user’s browser upon opening and (upon success) phoning home with a Meterpreter shell. 

Any good pentest should test more than just the systems, and SET is a perfect example of how to go about that.  Not only do you learn which systems are running highly exploitable browsers, you also get to see who in the office either clicks through every warning as if it’s gibberish or has their security settings largely disabled.  The benefits of this should already be so obvious to you that I don’t need to spell them out here. 

Speeding up the process with Fast-track

Fast-track is, in a way, the “poor man’s Metasploit Pro.”  It’s an open-source wrapper to the Metasploit framework that is designed to speed up pentesting by automating common but advanced tasks.  Now, based on my entire argument with things like CORE Impact and Metasploit Pro, you would think that I would find a tremendous amount of issue with this – and indeed, there’s a reason why it’s being included last on my highlights reel.  

Fast-track is just that – it relieves the pentester of quite a lot of work that could have yielded additional information if each test was performed by hand.  However, what differs about it is its purpose – Fast-track is not meant to scan for everything, it’s meant to scan for what vulnerabilities are well-documented, quickly repairable and come up again and again in pentests.  Most of these vulnerabilities are widely discussed and the technique for using them has become obsolete by newer versions, so there is little to gain by wasting time learning about them.  This time is much better spent going out and downloading the patches or updates that will make them obsolete on your system, as well. 

Testing passwords with Hydra

We all know that “12345” is the same password that an idiot would have on his luggage, but what about on your database?  Many users’ internal passwords are not very secure and many common “group” ones are even less than that.  How many SQL users are there with no password, or “hello”?  How many routers sit at the default password?

Hydra makes finding this information much easier, offering a fast and effective brute-force for both username and passwords on a variety of different protocols including MySQL/MSSQL/Oracle, Cisco setups, IMAP/POP3 email, HTTP/HTTPS, and a bunch more. 

The W3AF framework

Some sysadmins get the extra joy of having to worry about a large majority of webapps on their systems, which can be tricky to test.  On the next page, we’ll highlight some extra tools that are specific to webapps.  However, since we’re covering frameworks now, it’s a perfect time to bring up W3AF. 

The W3AF framework is, in essense, the Metasploit of webapps.  The framework functions very similarly to Metasploit, has a very large number of features and exploits, and is used in much the same way.  It isn’t updated nearly as consistently (it’s a much smaller team), so it’s possible to miss some of the newest issues.  Therefore, if webapps are a big part of your business, it’s worth keeping an eye out elsewhere and counting on W3AF to make sure that you don’t accidentally fall prey to some of the established vulnerabilities or recent trends.  However, it’s a well-built toolset and one that we’ll be looking into in detail as we examine webapps in future tutorials. 

The Toolset Intro: Webapps; Final Thoughts

Web Service Testing

What you should use for the backend of a webservice can be a hotly contested topic.  Everyone seems to have his or her individual favorite backend, and each has a reason for it.  From databases to CMS software to webservers, everyone has an opinion.  

Though W3AF covers a lot of vulnerabilities that can exist in webapps, there are a few other gems hidden in the Pwn Plug’s toolbox that you should familiarize yourself with.


In the process of truly understanding and examining Web services, it’s important to get a good idea of what you have publicly available.  There are two important tools for this purpose that we will touch on in-depth in later articles.

The first of these tools is great for general reconnaissance, called theHarvester.  This uses publicly available information to give you a “map” of what’s registered to the outside world, including email addresses, Web addresses, IP addresses, server enumeration and a variety of other useful bits and bobs that would clue you in on where an attacker may begin the push through your outermost perimeter.  

The second is particularly useful for website owners who publish through CMS services like WordPress, Joomla or Drupal.  Each of these has become a common backend that is widely extensible with plugins (read: points of vulnerability).  For this, cms-explorer spiders through the service and identifies the currently active CMS, its plugins and themes.  Knowing what versions of the main service and what plugins are running can give you a great insight into potential vulnerabilities.  

SQL Injection

For each of the different DB flavors, there is a tool designed to break it. For MySQL, there’s DarkMySQLi.   SQLBrute is designed to attack either an Oracle or MSSQL backend, while SQLNinja is very specifically designed to be the last thing an MS-SQL admin wants to see.  SQLNinja is even integrated into the Metasploit framework, and (when coupled with a VNC-server injection) is even capable of phoning home with a complete GUI access to the server. 

Of course, for those who want to test a variety of vulnerabilities on a variety of platforms, there is the well-loved sqlmap.   sqlmap contains features to poke at just about every commercial and open-source database that is commonly used, in a variety of ways.  From “blind injection” (where the true results of the query are never shown to the attacker) to table dumping to shell-spawning to password cracking, it covers it all.  We’ll be taking a look at it in detail nearer to the end of our series of tutorials.  

File Inclusion

File inclusion bugs can be just as dangerous as, if not more than, SQL injection in webapps.  As the app calls up files to display or parse through the include statement in PHP, it is possible to elicit a number of nasty effects.  The tricky part is, these bugs (Called LFI and RFI bugs, for “local file” and “remote file” inclusion) are getting harder and harder to find.  Because of their severity, however, they are worth scouring your webapps (both internal and external) for!  

The program fimap (named in honor of sqlmap) aims to automate this process by going through your webapp link-by-visible-link and attempting a variety of techniques against them, in hopes of making your webapp accept/load an incorrect file and thus spawn a shell or upload/execute a more complex (and permanent) payload. 

Final Thoughts

Though pentesting is often considered a “dark art,” it has an important place in the role of any well-trained sysadmin.  It is the only way to actually understand which vulnerabilities can lead to what levels of access, and to prepare and protect your systems accordingly.  If you don’t understand the process of or tools used in an attack, how can you reasonably expect to be secured against one? 

Some may look at the choice of the Pwn Plug as a platform and shy away or argue for whatever platform they use.  However, I have simply not found a platform that is as thorough and well-designed when it comes to actually using it day-to-day, especially for longer-term testing.  The amount of features you can test and the time it will save you once you’ve become familiar with the tools is well worth the cost.   

I would like to remind you that all of these tools are open-source and can be installed independently on your system of choice (many are even available for Windows!) if you would like to follow along with our future tutorials, though some features or output may be different on your platform. 

For those interested in dipping a toe into the water of security auditing, I hope that this article has been a good primer on the theory and some of the tools we’ll see.  As we move forward into the tutorials, the articles will offer a brief intro on the basic networking theory (which you may or may not already know), how to use the tools themselves (as well as how not to) and how you should expect to see those tools in your network monitoring setup.  

Part 2 of this series will revisit some of our basic networking theory as we explore basic reconnaissance techniques and how they interact with common internal protections like the Snort IDS.   We’ll see you then! 

Copyright © 2005-2019 Techgage Networks Inc. - All Rights Reserved.