Never give up ! Don't throw away your lemon of a computer even if it's been around since the cavemen era. There is always
a use for a computer, like turning it to a hub, flie sharing, firewall.javascript:doSubmit()
Done

<DIV><!--StartFragment -->&nbsp;
<P><B>Web Servers</B> </P>
<P>&nbsp;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&nbsp;you can test attacks against both encrypted and unencrypted servers. </P>
<P><B>Hex Encoding</B> </P>
<P>One of the easiest ways to disguise attacks is through changing the URL request. As administrators,&nbsp;you
generally search&nbsp;your 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&nbsp;you see the following in our IIS log,&nbsp;you
know that someone is looking for the presence of the MDAC remote vulnerability in IIS: </P>
<P>06:45:25 10.0.2.79 GET /msadc/ 302 </P>
<P>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: </P>
<P>[root@localhost /root]# nc -n 10.0.2.55 80
GET /msadc HTTP/1.0 </P>
<P>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: </P>
<P>[root@localhost]# nc -n 10.0.2.55 80
GET /%6D%73%61%64%63 HTTP/1.0 </P>
<P>The log file for IIS shows: </P>
<P>07:10:39 10.0.2.31 GET /msadc/ 302 </P>
<P>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: </P>
<P>[root@localhost]# nc -n 10.0.0.2 80
HEAD /cgi-bin/test-cgi HTTP/1.0 </P>
<P>[root@localhost]# nc -n 10.0.0.2 80
HEAD /%63%67%69-bin/test-%63%67%69 HTTP/1.0 </P>
<P>Now let's take a look at the access_log file: </P>
<P>10.10.10.10 - - [18/Oct/2000:08:22:47 -0700] "HEAD /cgi-bin/test-cgi HTTP/1.0" 200 0 </P>
<P>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 </P>
<P>Note that in both cases the 200 status code tells&nbsp;you that the command completed successfully. However,
in the second case, the hex values rather than the plaintext values appear. If&nbsp;you were relying on pattern matching
to detect this attack,&nbsp;you 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. </P>
<P><B>Proxy Servers</B> </P>
<P>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. </P>
<P>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. </P>
<P>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.
</P>
<P>In the attack/log file combo below, we see the attacker request information, and&nbsp;you see the request
appear in the log file: </P>
<P><B>Attacker</B>
[root@10.1.1.1 /]# nc -v 10.8.8.8 80
HEAD / HTTP/1.0 </P>
<P><B>Log file</B>
10.1.1.1 - - [18/Oct/2000:03:31:58 -0700] "HEAD / HTTP/1.0" 200 0 </P>
<P>In the following attack/log file combination, we see the attacker achieve the same goal, except that the attacker
uses a proxy server. </P>
<P><B>Attacker</B> [root@10.1.1.1 /]# nc -v 216.234.161.83 80
HEAD http://10.8.8.8/ HTTP/1.0 </P>
<P><B>Log file</B>
216.234.161.83 - - [18/Oct/2000:03:39:29 -0700] "HEAD / HTTP/1.1" 200 0 </P>
<P>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. </P>
<P><B>SSL</B> </P>
<P>I&nbsp;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. </P>
<P><B>Summary</B> </P>
<P>I&nbsp;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. </P>
<P>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 . </P>
<P>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. </P></DIV>