Latest News Posts

Social
Latest Forum Posts

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

Pentesting_PwnPlug_Thumb
Print
by Brett Thomas on December 20, 2012 in Editorials, Security

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.

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?