This article is not intended to show you how to hack something, but rather to show how attackers can take advantage of your mistakes. This will enable you to avoid the common pitfalls that criminal hackers exploit.
Most networks today are built on what is called the eggshell principle: hard on the outside and soft on the inside. This means that if an attacker can gain a foothold onto the network, the rest of the network will usually fall like dominoes. Once inside, the most difficult part is often to figure out what to attack next and where to go for the really juicy bits of information. It does not have to be this way. With the proper techniques, we as network administrators can achieve two crucial objectives: to make it much more difficult to gain a foothold in the first place and to make it much more difficult to use that foothold to get anywhere else on the network.
Network Address Ranges and Host Names
Say I'm performing a penetration test of solidstore.co.uk. I would start out by looking up what networks are registered to solidstore.co.uk. Perhaps even more interesting than the publicly registered address ranges for solidstore.co.uk is any information on networks connected to the target network, such as an extranet or a business partner. It's often easier to attack poorsecurity.co.uk and take over that domain before jumping from there to solidstore.co.uk. Like links in a chain, a network is only as secure as the least secure network connected to it (including all the VPN users connecting into it).
The next thing the attacker needs is host names. In some cases, it is possible to perform nslookup requests on large swaths of the network and it may even be possible to perform something called a zone transfer. A zone transfer is simply a request to a DNS server to send back a copy of an entire DMZ zone (a listing of all the registered names in the network). While host names are not critically important to most attacks, they can make an attack much simpler. For example, if you have the hostname of a Web server running IIS, you can deduce the anonymous IIS account for that host, since it is usually called IUSR_hostname. Now let's assume that the administrator has configured account lockout on that system. All an attacker has to do to take down that Web server is to send a large number of requests to the server asking it to authenticate you as IUSR_hostname. In short order the attacker can send enough bad passwords to lock out the anonymous user account. Once that account is locked out, the attacker can just keep sending enough bad requests to keep it that way and this Web server will no longer serve anything to anyone.
Exposed Hosts and Exposed Applications
More interesting than host names are the hosts that are actually exposed. In this phase of the attack, I am trying to locate easy targets. Doing so may be absolutely trivial. You may not even need any hacking tools, as long as Internet Control Message Protocol (ICMP) traffic is not blocked at the border.
In the vast majority of cases, ICMP traffic should be sent to /dev/null at the border. Even a half decent firewall should block ICMP, but it is surprising how often administrators forget to ensure that it is actually disabled. No response should even be sent. While this does not really stop enumeration, it makes it marginally more difficult since the attacker needs to rely on custom tools, such as port scanners.
A port scanner is simply a tool that attempts to connect to a target and report whether it was successful or not. A successful connection means the host is listening. An unsuccessful connection usually means it is not. The most common type of port scan is known as a SYN scan, where the attacker attempts to establish an ordinary connection to the target. If a host is listening, the connection will be successful and the port scanner will notify the attacker that a port is open. You can port scan an entire network in short order. Doing so on a range of well-chosen ports can give you a tremendous amount of information about what is available on the network.
Port scanning is the way to determine what applications are exposed on a host. This allows us to get information on possible vectors for attack. Some of the applications commonly looked for include the FTP clients and servers, Telnet, mail servers, and HTTP Web servers.
Version Info and Patch State
If you can, it is very useful to get information on the version of the applications that we find running on a target machine. For example, many applications have some kind of banner that is sent as soon as someone connects. Most SMTP and POP servers as well as many Web servers are configured to do this.
It is also very interesting to an attacker to find out what patch state the exposed servers are in. This information can be found in a variety of ways. In some cases, the banners presented by the applications will tell you all you need to know. For example, sendmail banners usually tell you the version number of the daemon. If you know which version of sendmail still exposes certain vulnerabilities, you have all the information you need. In other cases, you can figure out whether it has a particular patch or not from the responses the system is giving you. This is essentially the technique used in good vulnerability scanners and in OS fingerprinting tools. As a last resort, you can always fire off an exploit against a system and see what happens. This is often how vulnerability scanners look for denial of service attacks. If the system still responds after the attack it was most likely not vulnerable!
Structure of the Apps and Back-End Servers
It is often very helpful to get information about the structure of the application and back-end server(s), if any. This is usually very difficult, but in some cases you luck out. For example, let's assume you have a target network that uses a particular third-party Web application with very distinct file names and page designs. In this case, it is often obvious to the attacker which application you are using. If the attacker is familiar with the application, she may know how to exploit it. For instance, the application may use a configuration file called %webroot%\system.config. If files with the .config extension are not parsed by the Web server, the attacker can simply request this file in a Web browser. In a best-case scenario, that file will only give her information such as the names of the back-end servers and databases. In the worst-case scenario, that file will contain the user name and password used to actually establish the connection between the Web server and a database server.
Do not dismiss this as a contrived example. I encountered this exact situation just a few months ago. A very large number of commercial Web applications are extremely poorly written, essentially turning them into backdoors into the network.
At this point, I have just about all the information I need to start hacking. The first step is to establish an initial foothold into the network, to pierce the eggshell, if you will.
Initial Compromise
Let's assume I've done some initial probing and know that the target network is fully patched and that there is a really tight firewall in front, only allowing traffic on ports 80 and 443 (the defaults for HTTP and HTTPS); where do I go from here? Remember what I said about backdoors. Where could the backdoor be? What am I up against? The first step is to look at what is exposed to me: a Web application.
From this screen, I can tell that this is obviously an ordering site of some kind. Let's use a legitimate account to find out more about it.
The next page shows the Pubs bookstore and lists books for sale. They display my username on the page. This could come in handy if they are not careful, because I can use it to validate certain other techniques. For example, I have a hunch that this site uses a pretty poor algorithm for checking whether users have entered the right username or password (pretty shrewd, considering I wrote the algorithm!). I am also curious whether they are properly validating the input from the username fields. To find out for sure, I'm going to use a technique called SQL injection. Using a SQL injection attack, I pass the following string in the username field.
foo' OR 1=1;--
You can see that not only do I get logged on, but the application also displayed the fake username I sent it on the homepage. This latter artifact is actually a separate type of vulnerability known as a cross-site scripting (CSS) vulnerability, where the user input is echoed directly to the screen without sanitizing it first.
So how was I logged on? There obviously isn't a user called foo' OR 1=1;--. The application is very poorly written. It assumes that if any results come back from the database when it asks for a user with a particular password, then the username and password combination is obviously valid, and therefore it should log on this user. The SQL injection attack effectively rewrote the database query to include the statement OR 1=1. Since 1 is always equal to 1, this evaluates to true, which means the entire query evaluates to true for all records in the database. This will return every user account in the database, which means the application thought I was logged on.
I can now send arbitrary commands to the back-end database server. I am going to use that capability in an elevation of privilege attack to get the database server to run commands for me.
Elevating Privileges
As you saw earlier, the database server is not directly accessible from the Internet, and the front-end Web server is fully patched and not vulnerable to any known attacks. The objective at this point is to elevate my privileges so that I become an internal user, preferably a highly privileged one, on one of the systems in the target network. To do that, I'll use SQL injection to send commands to the database server and ask it to do things for us. Note that I cannot connect directly to the database server, so instead I will ask it to make a connection to me. I'll begin by setting up a listener on the external network, and then I will make the database server connect to me.
Before I can command the database server, I need to get some tools onto the Web server to further the attack. This is important because, generally speaking, hacking tools are not installed on the operating system by default. To get them up there you can use Trivial File Transfer Protocol (TFTP), a connectionless protocol used primarily for booting diskless workstations. The client application for TFTP is installed on all Windows systems by default (with the exception of Windows Server 2003 Service Pack 1 and later), so unless you have removed it, it is still there and available. Since I have a SQL injection vulnerability, I can use it to command the database server to use TFTP to download netcat to the database server. Netcat is a network tool somewhat like telnet, except that it is unauthenticated and much more versatile. It is freely available on the Internet and even comes standard on many UNIX and Linux distributions. It is pretty much universally used by attackers, however, and should never be left on a system where it is not absolutely needed.
The attack works by calling the xp_cmdshell stored procedure. Installed by default on SQL Server, xp_cmdshell is used to execute commands on the underlying operating system.
I will simply use this procedure to run TFTP and upload my tools to the database. xp_cmdshell is rarely needed in most deployments and can be disabled in several ways to protect against exactly this kind of attack. Once I've uploaded netcat, I tell netcat to create a socket, and then I pass that socket as stdin, stdout, and stderr in a call to cmd.exe. This sounds complicated, but it works reliably. The result is an outbound connection where I pipe a command shell over a socket. I now have my remote command line:
c:\>nc -l -p 12345
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.
C:\WINNT\system32>hostname
hostname
PYN-SQL
At this point, I have established my first foothold and am well on the way to taking over the network. I have escalated privileges from a remote anonymous user to an inside user. To find out what kind of user, I need to first get the rest of my tools onto the system. Those tools will be used to escalate local privileges if needed as well as to hack the rest of the systems on the network. I can transfer those, too, using tftp.exe. Once I've done that, I can verify my credentials on the host:
C:\warez>whoami
whoami
NT AUTHORITY\SYSTEM
Bingo! I'm already LocalSystem. That must certainly mean that SQL Server ran xp_cmdshell as LocalSystem, and that I have completely compromised the back-end database server. I can now proceed to hacking other machines on the network.
More in next article.