In our last column, we discussed some of the most common types of attacks against Web servers, and the evidence they leave in Web server logs. In this column, rather than initiating new attacks, we will demonstrate some dirty tricks hackers use to avoid detection, and the evidence they leave behind. These techniques are an added twist to the attacks we examined last time, making those attacks more difficult to detect.
The Web Servers
Our test environment uses two of the most common Web servers, Apache and Microsoft's Internet Information Server (IIS). We run Apache 1.3.9 on Red Hat Linux, and IIS 4.0 on Windows NT 4.0. Furthermore, both servers have normal and SSL-enabled versions, so we can test attacks against both encrypted and unencrypted servers.
One of the easiest ways to disguise attacks is through changing the URL request. As administrators, we generally search our log files looking for certain strings, or collections of plaintext characters. We look in resource requests for strings that match known vulnerabilities. For example, when we see the following in our IIS log, we know that someone is looking for the presence of the MDAC remote vulnerability in IIS:
06:45:25 10.0.2.79 GET /msadc/ 302
To see how attackers attempt to circumvent pattern matching, let's examine the request from the malicious attacker's perspective. To determine whether or not the msadc directory exists, an attacker might type the following:
[root@localhost /root]# nc -n 10.0.2.55 80
GET /msadc HTTP/1.0
This would yield the log file we saw above. The attacker can change the request by encoding it as hexadecimal ASCII characters. In the above example, the string msadc would become 6D 73 61 64 63 using hexadecimal ASCII encoding. You can use the Windows Charmap program to do a quick ASCII-to-hex encoding of characters. The above HTTP request, rewritten with the string msadc encoded in hexadecimal, appears as follows:
[root@localhost]# nc -n 10.0.2.55 80
GET /%6D%73%61%64%63 HTTP/1.0
The log file for IIS shows:
07:10:39 10.0.2.31 GET /msadc/ 302
Note that this is exactly the same log that is created when the URL is not encoded in hexadecimal. So in this case, encoding did not help the attacker. However, a look at the Apache logs for a similar attack tells a different story. The command an attacker would use to check for the existence of a particular CGI script is listed below, followed by the same command with hexadecimal encoding:
[root@localhost]# nc -n 10.0.0.2 80
HEAD /cgi-bin/test-cgi HTTP/1.0
[root@localhost]# nc -n 10.0.0.2 80
HEAD /%63%67%69-bin/test-%63%67%69 HTTP/1.0
Now let's take a look at the access_log file:
10.10.10.10 - - [18/Oct/2000:08:22:47 -0700] "HEAD /cgi-bin/test-cgi HTTP/1.0" 200 0
10.10.10.10 - - [18/Oct/2000:08:23:47 -0700] "HEAD /%63%67%69-bin/test-%63%67%69 HTTP/1.0" 200 0
Note that in both cases the 200 status code tells us that the command completed successfully. However, in the second case, the hex values rather than the plaintext values appear. If we were relying on pattern matching to detect this attack, we would likely fail. Many intrusion detection systems also use unintelligent pattern-matching capability, and some do not convert the hex-encoded URLs in order to perform the pattern matching. All administrators should be aware of this well-known dirty trick, and of whether their intrusion detection software is smart enough to convert hexadecimal code.
While concealing an attack may be crucial to an attacker, obfuscating the source of the attack is just as important. If an attacker can mask the source IP address, she or he can hack without worrying about legal repercussions. One way for attackers to mask their source address is through the use of proxy servers.
Proxies are used legitimately to funnel various protocols through a single access point. Typically, internal users are forced to go through a proxy server to access the Internet, allowing network administrators to be more restrictive with filtering rules for inbound and outbound access. A user connects to the proxy server, which then forwards the connection request to the intended destination. The destination server records the address of the proxy server as the source address of the connection, rather than recording the address of the system that originated the request.
Unfortunately, proxy servers are sometimes inadvertently placed on the Internet. (Check out Proxys-4-All for a list of these misconfigured servers.) These servers are sometimes misconfigured so that any Internet user can connect to the proxy server. When an Internet user connects to a server via the proxy, the proxy's source address, rather than the address of the Internet user, is recorded in the server logs. A malicious attacker may appear in a victim server's log files with a source address belonging to an "innocent" proxy rather than with the attacker's actual address. Let's take a look.
In the attack/log file combo below, we see the attacker request information, and we see the request appear in the log file:
[email@example.com /]# nc -v 10.8.8.8 80
HEAD / HTTP/1.0
10.1.1.1 - - [18/Oct/2000:03:31:58 -0700] "HEAD / HTTP/1.0" 200 0
In the following attack/log file combination, we see the attacker achieve the same goal, except that the attacker uses a proxy server.
Attacker [firstname.lastname@example.org /]# nc -v 184.108.40.206 80
HEAD http://10.8.8.8/ HTTP/1.0
220.127.116.11 - - [18/Oct/2000:03:39:29 -0700] "HEAD / HTTP/1.1" 200 0
Note that in this example, the source address that appears in the Web server log file is that of the proxy server (18.104.22.168, proxy.proxyspace.com), not the attacker (10.1.1.1). In this case, the attacker has successfully hidden the IP address of the source of the attack from the victim. The network administrator can track down the ultimate source of the attack if the administrator of the proxy server cooperates. Most proxy servers keep very detailed logs, so the source address of the attacker should appear in the log files of the proxy server. Unfortunately, here's where the dirty trick gets even dirtier: attackers can "chain" proxy servers so that the attack is propagated through multiple proxy servers. In order to determine the source address of the attacker, administrators or law enforcement officers need the cooperation of the administrators of every intermediate proxy server, sequentially. The process of chaining proxy servers is well known in the hacker community, and an automated software tool that performs this process is SocksChain for Windows.
We've said it before, but it is worth mentioning again: SSL-enabled servers are not monitored by network intrusion detection systems. Give an attacker a choice between port 80 (HTTP) and port 443 (HTTPS), and the attacker will choose 443 every time. This is not really a dirty trick, just a side effect of using encrypted communications. You can use the Web server log files to monitor requests to port 443.
We have shown you a few common deceits used by Web hackers. Needless to say, this list of tricks is limited only by hackers' creativity and imagination. Techniques such as hexadecimal encoding are not only used for deceptive log file entries; they can also deceive a Web server's URL parsing mechanism, which may lead to vulnerabilities such as source code disclosure. Attackers sometimes use multiple proxy servers for scanning and attacking, making it very difficult for administrators to trace the real source of attacks. And of course, SSL sometimes paves the way for "secure hacking," as we have seen in this and in past articles.
Chris Prosise is the vice president of consulting at Foundstone, a network security firm specializing in consulting and training. Formerly a U.S. Air Force officer and "Big 5" consultant, Prosise has led dozens of security penetrations and incident response engagements on government and Fortune 500 networks. Prosise holds a B.S. in electrical engineering from Duke University and is a Certified Information Systems Security Professional (CISSP).
Saumil Udayan Shah, principal consultant for Foundstone, provides information security consulting services to Foundstone clients. Shah specializes in ethical hacking and security architecture. He holds an M.S. in computer science from Purdue University and is a Certified Information Systems Security Professional (CISSP).