Photo Album

BorgMatrix System Shock

page1

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> 
Web Servers 
 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 you 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, you generally search 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 you see the following in our IIS log, you 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 you that the command completed successfully. However, in the second case, the hex values rather than the plaintext values appear. If you were relying on pattern matching to detect this attack, 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. 
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 you 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 
I 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 
I 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 . 
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. </DIV>

Know your computer as you know yourself.