Wednesday, November 22, 2000
Chris Prosise and Saumil Udayan Shah
Hackers are not only clever in how they invade
servers; they are also devious in how they disguise their attacks. Malicious
attackers use a variety of evasive techniques, which we will examine in this
column so that we, as administrators, can be better prepared to detect and
respond to them.
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.
Hex Encoding
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.
Proxy Servers
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:
Attacker
[root@10.1.1.1 /]# nc -v 10.8.8.8 80
HEAD / HTTP/1.0
Log file
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 [root@10.1.1.1 /]# nc -v 216.234.161.83 80
HEAD http://10.8.8.8/ HTTP/1.0
Log file
216.234.161.83 - - [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
(216.234.161.83, 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.
SSL
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.
Summary
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).