|
Scan 31 Writeup by: Doug Brown and Eric Clore. 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. 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
Download the Image (25 MB) Questions
Bonus Question:
Question 1 How do you think the attackers found the honeyproxy? Answer Typically, open proxy servers are discovered by scanners and posted to web pages that serve lists of open proxy servers. A majority of our attackers likely came from these lists. In this case, the proxy may have been sent to these sites in order for attackers to quickly locate the honeyproxy. Additionally, there are many utilities out there to scan a range of IP addresses in an attempt to retrieve a page. One such utility is called Proxy Hunter and traces of such utilities can be found in the audit logs:
Request: 219.151.209.144 - - [Fri Mar 12 09:23:17 2004] "GET http://www.sciencedirect.com/ HTTP/1.1" 200 34827
Handler: proxy-server ---------------------------------------- GET http://www.sciencedirect.com/ HTTP/1.1 Accept: */* Host: www.sciencedirect.com Pragma: no-cache User-Agent: ProxyHunter HTTP/1.1 200 OK Last-Modified: Fri, 12 Mar 2004 14:23:18 GMT Set-Cookie: EUID=cf038b64-7430-11d8-9aca-8a0c593caa77; expires=Thu, 07-Mar-2024 14:23:18 GMT; Set-Cookie: MIAMISESSION=cf0381b4-7430-11d8-9aca-8a0c593caa77:3256554198; path=/; domain=.sciencedirect.com; Set-Cookie: ATHENS_TARGET=http://www.sciencedirect.com/science; path=/; Content-Type: text/html Expires: Tue, 01 Jan 1980 05:00:00 GMT X-Cache: MISS from www.testproxy.net Transfer-Encoding: chunked
Question 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 The Nessus attacks comprised of 733 seperate attack scripts. These may have been performed by the system administrator to check the honeyproxy's integrity. The attacks consist of the following plugin families:
567 CGI Abuse Attacks 82 Misc Attacks 54 Remote File Access Attacks 21 Firewall Attacks 7 CISCO Attacks 2 Netware Attacks The Nessus scripts contain CVE/CERT/Bugtraq/Anti-Virus Id numbers for the information they are trying to determine. The configuration script allows the user to specify which families are executed in the probe and we have determined that these families were run by finding fingerprints of one or more family scans. These are the majority of the attacks on the server, all other attacks are either contained in this scan or a subgroup of one of these families.
CGI Abuse Proof:
Request: 217.160.165.173 - - [Fri Mar 12 22:45:41 2004] "GET %00%00.box/../../../../../lotus/domino/notes.ini HTTP/1.1" 404 279 Handler: (null) ---------------------------------------- GET %00%00.box/../../../../../lotus/domino/notes.ini HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Charset: iso-8859-1,*,utf-8 Accept-Language: en Connection: Keep-Alive Host: www.testproxy.net Pragma: no-cache User-Agent: Mozilla/4.75 [en] (X11, U; Nessus) HTTP/1.1 404 Not Found Keep-Alive: timeout=15, max=98 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 This attack was performed by the domino_traversal.nasl script.
script_id(11344); script_version ("$Revision: 1.4 $"); script_cve_id("CVE-2001-0009"); script_bugtraq_id(2173); family["english"] = "CGI abuses"; name["english"] = "Domino traversal";
MISC:
Request: 217.160.165.173 - - [Fri Mar 12 22:38:38 2004] "GET /caucho-status HTTP/1.1" 404 293 Handler: (null) Error: File does not exist: /usr/local/apache/htdocs/caucho-status ---------------------------------------- GET /caucho-status HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Charset: iso-8859-1,*,utf-8 Accept-Language: en Connection: Keep-Alive Host: www.testproxy.net Pragma: no-cache User-Agent: Mozilla/4.75 [en] (X11, U; Nessus) HTTP/1.1 404 Not Found Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 This attack was performed by the resin_server_status.nasl script.
script_id(11930); script_version ("$Revision: 1.2 $"); name["english"] = "Resin /caucho-status accessible"; family["english"] = "Misc.";
Remote File Access:
Request: 217.160.165.173 - - [Fri Mar 12 22:45:41 2004] "GET /ifx/?LO=../../../../../etc/passwd HTTP/1.1" 403 288 Handler: (null) Error: client denied by server configuration: /usr/local/apache/htdocs/ifx ---------------------------------------- GET /ifx/?LO=../../../../../etc/passwd HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Charset: iso-8859-1,*,utf-8 Accept-Language: en Connection: Keep-Alive Host: www.testproxy.net Pragma: no-cache User-Agent: Mozilla/4.75 [en] (X11, U; Nessus) HTTP/1.1 403 Forbidden Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 This attack was performed by the informix_traversal.nasl script
script_id(10805); script_cve_id("CAN-2001-0924"); script_bugtraq_id(3575); script_version ("$Revision: 1.9 $"); family["english"] = "Remote file access"; name["english"] = "Informix traversal";
Firewall:
Request: 217.160.165.173 - - [Fri Mar 12 22:31:11 2004] "CONNECT www.testproxy.net:1234 HTTP/1.0" 403 314 Handler: proxy-server ---------------------------------------- CONNECT www.testproxy.net:1234 HTTP/1.0 HTTP/1.0 403 Forbidden Connection: close Content-Type: text/html; charset=iso-8859-1 This attack was performed by the proxy_connect.nasl
script_id(10192); script_version ("$Revision: 1.12 $"); family["english"] = "Firewalls"; name["english"] = "Proxy accepts CONNECT requests";
CISCO:
Request: 217.160.165.173 - - [Fri Mar 12 22:31:32 2004] "GET /level/17/exec/show/config/cr HTTP/1.1" 200 578 Handler: (null) Error: mod_security: pausing [/level/17/exec/show/config/cr] for 50000 ms ---------------------------------------- GET /level/17/exec/show/config/cr HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Charset: iso-8859-1,*,utf-8 Accept-Language: en Connection: Keep-Alive Host: www.testproxy.net Pragma: no-cache User-Agent: Mozilla/4.75 [en] (X11, U; Nessus) mod_security-message: Access denied with code 200. Pattern match "/exec/" at THE_REQUEST. mod_security-action: 200 HTTP/1.1 200 OK Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 This attack was performed by the cisco_http_admin_access.nasl script.
script_id(10700); script_cve_id("CVE-2001-0537"); script_bugtraq_id(2936); family["english"] = "CISCO"; script_version ("$Revision: 1.16 $"); name["english"] = "Cisco IOS HTTP Configuration Arbitrary Administrative Access";
Netware:
Request: 217.160.165.173 - - [Fri Mar 12 22:39:36 2004] "GET /lcgi/sewse.nlm?sys:/novonyx/suitespot/docs/sewse/misc/allfield.jse HTTP/1.1" 403 298 Handler: (null) Error: client denied by server configuration: /usr/local/apache/htdocs/lcgi ---------------------------------------- GET /lcgi/sewse.nlm?sys:/novonyx/suitespot/docs/sewse/misc/allfield.jse HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Charset: iso-8859-1,*,utf-8 Accept-Language: en Connection: Keep-Alive Host: www.testproxy.net Pragma: no-cache User-Agent: Mozilla/4.75 [en] (X11, U; Nessus) HTTP/1.1 403 Forbidden Keep-Alive: timeout=15, max=99 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 This attack was performed by the novell_novonyx_default_files.nasl script
script_id(12049); script_version ("$Revision: 1.4 $"); script_bugtraq_id(4874); family["english"] = "Netware"; name["english"] = "Default Novonyx Web Server Files ";
Question 3 Do attackers target Secure Socket Layer (SSL) enabled web servers as their targets? Did they target SSL on our honeyproxy? Why would they want to use SSL? Why didn't they use SSL exclusively? Answer Attackers have been known to target Secure Socket Layer (SSL) enabled web servers as targets. Several examples came from CERTŪ Advisory CA-2002-23 Multiple Vulnerabilities In OpenSSL. These attacks tried to exploit buffer overflows and ASN.1 encoding errors which could allow the attacker to execute arbitrary code on the target system or could be used to control the server in order to direct denial of service attacks. SSL is not exclusively used because most of the vulnerabilities are well known and have been patched. SSL was targeted on our honeyproxy by the following ip addresses (from the ssl_access_log): 217.107.218.126 217.160.165.173 217.162.108.28 62.58.50.219 65.161.65.104 66.36.242.145 69.57.146.21 80.196.149.199
Question 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 are indications of attackers chaining through other proxy servers. The proxy servers were identified by the X-Cache: line in the audit log. That line identifies cache hits and misses from our server (scrubbed to www.testproxy.net), and when proxy chaining is being used, other server names appear on that line as well.
Request: 218.218.20.193 - - [Sat Mar 13 00:38:40 2004] "POST http://hapi.comiu.com/login .cgi HTTP/1.0" 200 1167 Handler: proxy-server ---------------------------------------- POST http://hapi.comiu.com/login.cgi HTTP/1.0 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/x-shockwave-flash, */* Accept-Language: ja Content-Length: 56 Content-Type: application/x-www-form-urlencoded Cookie: comiuusermode=0; comiucomsession=; 0105706NQ=1dmtfyxqdmvllxxaaac&00aaac Host: hapi.comiu.com Pragma: no-cache Proxy-Connection: Keep-Alive Referer: http://www.hapitan.com/ User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; MSN 6.1; MSNbMSFT; MSNmja-jp; MSNc00; v5m) id=reolovi&password=cpmuya&imageField.x=0&imageField.y=0 HTTP/1.0 200 OK Warning: Subject to Monitoring Set-Cookie: comiuusermode=0; domain=.comiu.com; path=/; expires=Fri, 11-Jun-2004 05:38:43 GMT Set-Cookie: comiucomsession=5pRu004N3PQulO8jTeRYBSEQK6GvfFWT%2Chapi%2C%A1%B3%28%2A%A1%AE%A7%A5%A1%AD%29%A5%CEnatuko; domain=.comiu.com; path=/ Expires: Sat, 13 Mar 2004 05:38:43 GMT Cache-Control: no-cache Pragma: no-cache Content-Type: text/html; charset=EUC-JP X-Cache: MISS from cs1.comiu.com, MISS from www.testproxy.net Connection: close The proxy chainers used our honeyproxy in a chain to other proxies to provide more anonymity. The evidence of proxy chaining we found shows our proxy server as the first proxy used in the chain. Since our proxy does not cache pages, all request result in a cache MISS: X-Cache: MISS from www.testproxy.netThe request will go down the proxy chain looking for cached pages, and in some cases, the request will result in a cache HIT:
Request: 220.248.145.3 - - [Sun Mar 14 10:37:30 2004] "GET http://www.163.com/ HTTP/1.1" 200 20118 Handler: proxy-server ---------------------------------------- GET http://www.163.com/ HTTP/1.1 Accept: */* Host: www.163.com Pragma: no-cache User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows 98) HTTP/1.1 200 OK Warning: Subject to Monitoring Last-Modified: Sun, 14 Mar 2004 15:36:01 GMT ETag: "2b1c02-11ce9-40547be1" Accept-Ranges: bytes Content-Length: 72937 Content-Type: text/html Age: 9 X-Cache: HIT from bjc196, MISS from www.testproxy.net X-Cache-Lookup: HIT from bjc196:80 In addition to using X-Cache to look for signs of proxies, we used the Via header field as well. The Via field is used by gateways and proxies to indicate intermediate protocols and recipients between the user agent and the server on requests, and between the origin server and the client on responses.
Request: 212.160.136.163 - - [Wed Mar 10 01:58:22 2004] "GET http://www.bizrate.com/mkt.xpml?mkt_id=960409 HTTP/1.0" 302 0 Handler: proxy-server ---------------------------------------- GET http://www.bizrate.com/mkt.xpml?mkt_id=960409 HTTP/1.0 Accept: */* Accept-Language: fr Host: www.bizrate.com Pragma: no-cache Referer: http://www.searcheaven.net/cgi-bin/smartsearch/smartsearch.cgi?username=bmocking&keywords=scrabble User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows 98) HTTP/1.0 302 Moved Set-Cookie: sessionid=82704260242; domain=.bizrate.com; path=/; expires=Thu, 11-Mar-2004 06:58:24 GMT Set-Cookie: br=107890190426017846; domain=.bizrate.com; path=/; expires=Sat, 08-Mar-2014 06:58:24 GMT Set-Cookie: user_key=_HASH&e6c7472089a4d03823a563033c8ae8f3&_TIME&1078901904&_BR&107890190426017846&_EXPIRES&%2B10y; domain=.bizrate.com; path=/; expires=Sat, 08-Mar-2014 06:58:24 GMT Pragma: no-cache Cache-control: no-cache location: /mkt_int.xpml?mkt_id=960409&url_id=83372&rf=ldi&lp=6 Content-Type: text/html Expires: Wed, 10 Mar 2004 06:58:24 GMT Via: 1.1 redline04 (Redline Networks Accelerator 2.3.8 0) X-Cache: MISS from www.testproxy.net Connection: close All of the proxies discovered could be anything from open proxies to private proxies hidden behind firewalls. We parsed the audit_log for signs of other proxies and this list (proxy_list) was discovered (note that multiple similarly named servers were replaced with a single line with a string of ?'s replacing the different part of the string) These proxies were then scanned (using nmap) on known proxy ports (80,81,8000,8080,1080,3128,6588) using the following command: nmap -p 80,81,8000,8080,1080,3128,6588 -oN proxy_report -iL proxy_listThe results can be found in the proxy_report file. From the report file, we can check the servers with open ports to see if they are valid proxy servers. Several of the proxy servers were tested using IE6 and Mozilla FireFox 0.8 and were confirmed to be proxy servers.
Question 5 Identify the different Brute Force Authentication attack methods. Can you obtain the clear text username/password credentials? Describe your methods. Answer The audit_log has many examples of some sort of brute force attack. There seemed to be three main methods for the brute force attacks. The first one being a POST method where the username and password are in the POST variables. The second method is using Basic HTTP Authorization using cleatext passwords that have been base64 encoded. The final method is with plaintext passwords in a simple GET request. This attacker tried to brute force his way into several websites by using the POST method. The POST style attacks were also not stopped by the proxy until SecFilter was added for "password\=" on the March 14th restart at 11:08.
Request: 196.39.125.7 - - [Sat Mar 13 01:20:08 2004] "POST http://www.pixandvideo.com/ HTTP/1.1" 200 6609 username=artymann&password=drbob username=andibusz1&password=andi03 username=woodboy&password=wahoo2 username=87654321&password=12345678 username=abcjww&password=13971397 username=jer7149&password=macadoo username=sting1&password=dragon username=DEDE31&password=EXUPERY username=director&password=3light username=bigcat&password=101660 username=Elmarce&password=Siemens1 username=callie&password=boots username=highrune&password=bouncer username=YANKEE&password=miranda username=brantodd&password=sniper username=bradmars&password=pencil username=chadas&password=danielle username=Guy249&password=fct4cz username=roberto&password=dustin username=olebrumm&password=oa427unt username=qqqsss&password=wwwxxx username=rpurdy&password=josalyn username=abcdefg&password=12345678 username=uweral&password=xyzzzz username=rkramon&password=totally username=craigmcl&password=cwm1959 username=cwhite&password=blue4711 This attacker hit easynews 827 times from 9:24-9:30 and 10:31-11:11 without being hindered by the proxy:
Request: 217.162.108.28 - - [Sat Mar 13 09:24:22 2004] "POST http://www.easynews.com/login/ Request: 217.162.108.28 - - [Sat Mar 13 11:11:42 2004] "POST http://www.easynews.com/login/index.phtml This attacker tried to brute force his way into the following site using Basic Authorization but was foiled by the "Basic" match set up for the HEADER. There were 30 attempts at this site, all of which were rejected by the testproxy.
Request: 217.123.173.207 - - [Sat Mar 13 06:57:56 2004] "HEAD http://www.earlmiller.com/members/frameindex.html HTTP/1.0" 200 0 Handler: proxy-server Error: mod_security: pausing [http://www.earlmiller.com/members/frameindex.html] for 50000 ms ---------------------------------------- HEAD http://www.earlmiller.com/members/frameindex.html HTTP/1.0 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* Authorization: Basic cTJidTlpbTM6bmx5bHQwM3I= Host: www.earlmiller.com Pragma: no-cache User-Agent: Mozilla/4.0 (compatible; ICS) 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 Basic Authorization string can easily be turned into a plain text password by the following php code: <?The following type of log also occured a large number of times. This particular log contains the username and password in the request URL. Yahoo was target of a lot of attacks this way and they seemed to be directed at all countries. All of these attacks were stopped at the proxy.
Request: 24.168.72.174 - - [Tue Mar 9 22:27:46 2004] "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=HELLHTTP/1.0" 200 566 Handler: proxy-server Error: mod_security: pausing [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] for 50000 ms ---------------------------------------- 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 Accept: */* Accept-Language: en Connection: Keep-Alive mod_security-message: Access denied with code 200. Pattern match "passwd=" at THE_REQUEST. mod_security-action: 200 HTTP/1.0 200 OK Connection: close Content-Type: text/html; charset=iso-8859-1 The attacker with the IP 68.82.249.118 hit these random yahoo sites 43 times with various passwords.
http://e1.member.ukl.yahoo.com/config/login? http://e1.member.vip.ukl.yahoo.com/config/login?. http://e1.tpe.yahoo.com/config/login? http://e2.edit.cnb.yahoo.com/config/login? http://e2.member.ukl.yahoo.com/config/login? http://e2.tpe.yahoo.com/config/login? http://e2.yahoo.co.kr/config/login? http://e3.edit.cnb.yahoo.com/config/login? http://e3.member.ukl.yahoo.com/config/login? http://e3.tpe.yahoo.com/config/login? http://e3.yahoo.co.kr/config/login? http://e4.edit.cnb.yahoo.com/config/login? http://e4.member.ukl.yahoo.com/config/login? http://e4.tpe.yahoo.com/config/login? http://e5.member.ukl.yahoo.com/config/login? http://e5.tpe.yahoo.com/config/login? http://e6.member.ukl.yahoo.com/config/login? http://edit.vip.tpe.yahoo.com/config/login? http://l1.login.dcn.yahoo.com/config/login? http://l2.login.dcn.yahoo.com/config/login? http://l3.login.dcn.yahoo.com/config/login? http://l4.login.dcn.yahoo.com/config/login? http://l5.login.dcn.yahoo.com/config/login? http://sbc1.login.dcn.yahoo.com/config/login?
Question 6 What does the Mod_Security error message "Invalid Character Detected" mean? What were the attackers trying to accomplish? Answer "Invalid Character Detected" means that Apache received a character that is not deemed appropriate by mod_security. In the case of our honeyproxy, our character range is described by the following rule in httpd.conf: SecFilterForceByteRange 32 126This filters out control characters that can be used for a buffer overflow attack on the server, which is probably what our attackers were attempting. Method First, we noted that in the audit_log, all "Invalid Character Detected" messages were preceded by a mod_security tag. By reading the document linked in the challenge (Open Proxy Honeypot), we found configuration settings for mod_security that would only allow characters within a certain range. All of the Invalid Character messages give information about which character was received and classified as invalid: Error: mod_security: Invalid character detected [205]In this case, ASCII character 205 was received and logged.
Question 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 A partial translation of the webpage attached to the spam can be found here. This webpage appears to be a newsletter entitled "The Pale Tea Room." The subject matter appears to center around a religious sect called 'Falungong.' The full list of recipients that were listed in the To: field of the email can be found below (sorted alphabetically). In addition, all of the recipients listed in the CC: field can be found here.
To:
ai_nei06@163.com botaizao489@163.com caogaijiang31@163.com ganyaoke9@163.com ganzuluo07@163.com huangliedao3742@163.com huansongzun12@163.com kangzhuae1879@163.com kouyantou4131@163.com liuyecu63@163.com ouchen334@163.com pangrengye4@163.com shaodancuan60@163.com shengfiaopa07@163.com xuepiaosai117@163.com zongzefeng8@163.com Method The HTML attachments found in the /upload directory are all the same (verified by a diff on all the files), and after opening one, we noted that it was written in Chinese. We utilized a free machine translation tool (at WorldLingo) to translate a good amount of the page. We thought about breaking it apart into chunks to translate seperately, but the first translation we obtained through WorldLingo was enough to deduce what the attachment was about. In order to obtain the recipient information, we utilized Apache's audit logs. We searched for logs including the string "mail.sina.com.cn" and found several entries that look like the following:
Request: 128.211.247.199 - - [Wed Mar 10 11:10:17 2004] "POST http://mail.sina.com.cn/cgi-bin/sendmsg.cgi HTTP/1.0" 200 566 Handler: proxy-server Error: mod_security: multipart_process_data_chunk: Failed to create file "/usr/local/apache/upload/20040310-111017-128.211.247.199-GoodMorening.htm_KJleFR" ---------------------------------------- POST http://mail.sina.com.cn/cgi-bin/sendmsg.cgi HTTP/1.0 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, */* Accept-Encoding: deflate, gzip Content-Length: 52896 Content-Type: multipart/form-data; boundary=---------------------------7002449c63fa4 Cookie: ads=ABCEADADBAAO; nick=xiahuo6(1448381950); SINA_NU=2:xiahuo6:; SINA_USER=BSH707pvFblnyCR7sr8jvruNcc5toDOc5qNzRcPnfc0c; SID=BXJ81qTb802mkd1T0E2G6EhMq81GETGE8w8q2q660760G2G70r70018Ty8G2nG0cry6c/8TyKCE0; gender=1; appmask=00000000000000000000000000000004; SINAPRO=SHj7fccc%26ohjz0rcT%3DoNqP%2FbR55szrcl078zO0qhpDCzR0Z%3Dn%3Dzt%3DFBv7oyj%26vN%26; SINAPROC=1; SINA-AVATAR=; UNIPROTM=1078934999; UNIPROU=2:xiahuo6 Cookie2: $Version=1 Host: mail.sina.com.cn Pragma: no-cache Referer: http://mail.sina.com.cn/cgi-bin/sendmsg.cgi User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98) mod_security-action: 200 -----------------------------7002449c63fa4 Content-Disposition: form-data; name="youxj" 3 -----------------------------7002449c63fa4 Content-Disposition: form-data; name="sendok" 1 -----------------------------7002449c63fa4 Content-Disposition: form-data; name="atth2" -----------------------------7002449c63fa4 Content-Disposition: form-data; name="atth3" ... -----------------------------7002449c63fa4 Content-Disposition: form-data; name="to" ai_nei06@163.com -----------------------------7002449c63fa4 Content-Disposition: form-data; name="cc" kjonny@sina.com,kjp14.student@sina.com,kjp1969@sina.com,kjp2000@sina.com,kjp_1000@sina.com,,... -----------------------------7002449c63fa4 Content-Disposition: form-data; name="bcc" ... We extracted the To: and CC: information from all of the entries, sorted them, and removed duplicates.
Question 8 Provide some high level statistics on attackers such as: - Top Ten Attackers - Top Ten Targets - Top User-Agents (Any weird/fake agent strings?) - Attacker correlation from DShield and other sources? Answer Top Ten Attackers:
Top Ten Targets:
Top User-Agents:
Weird/fake agent strings:
Clicking Agent fork() ProxyChains 1.8 ProxyExpert ProxyHunter pxyscand/2.0 Sleipnir Version 1.42 -->Web Browser Shell Space Bison/0.02 [fu] (Win67; X; SK) This host can be open proxy - please investigate. This host is open proxy - please investigate. You lose ! rank* -->Lots of random numbers after rank Attacker correlation from DShield We first checked our top 10 attackers against the DShield database. Only 2 of those attackers had a record with DShield:
After checking our top 10 attackers, we checked all of our attackers against DShield's published block list. None of our attackers' IP addresses matched the network blocks that DShield suggests blocking. We also ran a quick script against DShield's IP checking page [http://dshield.org/ipinfo.php] with the query string ?ip=IP_ADDRESS&summary=Y to get a report on a given IP_ADDRESS. The script timed out on several requests, and the results we received were inconclusive at best. Method We utilized the beautiful text import features of Microsoft Access to put all of the access_logs into a database. To simplify our import, all of the fields were imported with type Text except for the Request and Referer strings which were imported as type Memo (they were too long to be supported by type Text). In order to count the number of duplicates (to learn interesting information about attackers, targets, etc.), we ran the Find Duplicates Wizard Query, chose the appropriate field. Memo fields could not be counted this way, however, so we imported the log to another table with the desired fields as type Text (length 255). We could still retrieve the rest of the string from the log file or the other table. This could also be done with an SQL statement: SELECT DISTINCTROW First(Access_log.user_agent) AS [user_agent Field], Count(Access_log.user_agent) AS NumberOfDups FROM Access_log GROUP BY Access_log.user_agent HAVING (((Count(Access_log.user_agent))>0));
Bonus Question 1 Why do you think the attackers were targeting pornography websites for brute force attacks? (Besides the obvious physical gratification scenarios :) Answer Attackers target pornography websites for a number of reasons. Possible reasons could include bumping hit counters, selling login information on the internet, or to gain information about users such as credit cards. Method
Bonus Question 2 Even though the proxypot's IP/Hostname was obfuscated from the logs, can you still determine the probable network block owner? Answer Having looked through the logs, we believe it is possible to determine the network block owner. We examined two possible methods that we took in route to making this decision. We will first discuss how we came up with these methods. We examined the log and came across the following two pieces of information from the audit_log:
Request: 68.48.142.117 - - [Tue Mar 9 22:22:07 2004] "GET /MSADC/httpodbc.dll HTTP/1.0" 404 286 Handler: (null) Error: File does not exist: /usr/local/apache/htdocs/MSADC/httpodbc.dll ---------------------------------------- GET /MSADC/httpodbc.dll HTTP/1.0 Connnection: close Host: www HTTP/1.0 404 Not Found Connection: close Content-Type: text/html; charset=iso-8859-1 At a later time in the audit_log, the same request was made, but a different response:
Request: 68.48.142.117 - - [Sat Mar 13 22:56:06 2004] "GET /MSADC/httpodbc.dll HTTP/1.0" 200 566 Handler: (null) Error: mod_security: pausing [/MSADC/httpodbc.dll] for 50000 ms ---------------------------------------- GET /MSADC/httpodbc.dll HTTP/1.0 Connnection: close Host: www mod_security-message: Access denied with code 200. Pattern match "/msadc/httpodbc\.dll" at THE_REQUEST. mod_security-action: 200 HTTP/1.0 200 OK Connection: close Content-Type: text/html; charset=iso-8859-1 These events hint that the honeyproxy is being monitored and the security is being updated as is seen fit. If this was the case, then the server administrator would probably be among the first IP addresses to connect to the server after the proxy services were restarted. We examined all the logs to determine if we could find when the proxy was restarted. The error_log contains the information we were looking for. Server restarts look like this: [Wed Mar 10 21:03:15 2004] [notice] SIGHUP received. Attempting to restartWe checked audit_log and access_log for ip addresses right after server restarts and shut downs. We were looking for requests from the same ip address right after the server came back up, as a check for any security fixes that may have gone in. This task was time consuming and did not give us any conclusive results. Since we knew someone was fixing security holes because of logs similar to the one above, we kept looking down that road, figuring that if we knew who was patching the holes, we could determine a probable block that the server resided. One thing that struck us from the log files was the Nessus attack. At first, we figured it was a script kiddy, but there was a direct correlation from the last logged server restart in the ssl_engine_log (12/Mar/2004 22:26:35) and the timing of the first Nessus attack:
Request: 217.160.165.173 - - [Fri Mar 12 22:30:15 2004] "GET / HTTP/1.0" 200 4301 Handler: (null) ---------------------------------------- GET / HTTP/1.0 HTTP/1.0 200 OK Warning: Subject to Monitoring Connection: close Content-Type: text/html The times are very close together and this leads us to believe the Nessus attacker is probably the system administrator and likely on the same block as the honeyproxy. Further analysis of the Nessus scripts [homepage] led us to research the attack categories launched against the server (CGI Abuses, Gain root remotely, Firewalls, General, Misc, Netware, CISCO, and Remote File Access). We noted several fixes that fell under these categories, and several that actually broke the proxy: mod_security-message: Access denied with code 200. Pattern match "GET" at THE_REQUEST.Under the assumption that the administrator is running Nessus and has an IP on the same block as the honeyproxy, the following whois query would return our honeyproxy's network block:
$ whois 217.160.165.173
Request: 217.160.165.173 connected to whois.arin.net [192.149.252.43:43] ... connected to whois.ripe.net [193.0.0.135:43] ... % This is the RIPE Whois server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html inetnum: 217.160.160.0 - 217.160.175.255 <-------------- probable testproxy block netname: SCHLUND-CUSTOMERS descr: Schlund + Partner AG descr: NCC#1999110113 country: DE admin-c: JH1220-RIPE tech-c: SPAG-RIPE remarks: INFRA-AW remarks: in case of abuse or spam, please mailto: abuse@schlund.de rev-srv: nsa.schlund.de rev-srv: ns.schlund.de rev-srv: ns2.schlund.de status: ASSIGNED PA mnt-by: SCHLUND-MNT mnt-by: SCHLUND-P changed: manfred@schlund.de 20030128 source: RIPE route: 217.160.0.0/16 descr: SCHLUND-PA-3 origin: AS8560 notify: guardian@schlund.net mnt-by: SCHLUND-MNT changed: mink@schlund.net 20010308 source: RIPE role: Hostmaster SCHLUND address: Schlund + Partner AG address: Erbprinzenstr. 1 address: D-76133 Karlsruhe address: Germany phone: +49 721 91374 50 fax-no: +49 721 91374 20 e-mail: hostmaster@schlund.de remarks: For abuse issues, please use only abuse@schlund.de trouble: Information: http://www.schlund.de trouble: Questions: mailto:hostmaster@schlund.de trouble: For fastest response, please use only hostmaster@schlund.de admin-c: ES-RIPE tech-c: ES-RIPE nic-hdl: SPAG-RIPE remarks: Role Account for the "Hostmaster of the Day" remarks: for Domains managed by Schlund + Partner AG, Germany notify: hostmaster@schlund.de mnt-by: SCHLUND-P changed: hostmaster@schlund.de 19990412 changed: hostmaster@schlund.de 20000120 changed: manfred@schlund.de 20021125 source: RIPE person: Joerg Hennig address: Schlund + Partner AG address: Erbprinzenstr. 4-12 address: D-76133 Karlsruhe address: Germany remarks: For abuse issues, please use only abuse@schlund.de phone: +49 721 91374 0 fax-no: +49 721 91374 20 e-mail: hennig@schlund.net nic-hdl: JH1220-RIPE notify: hennig@schlund.net mnt-by: SCHLUND-P changed: hennig@schlund.de 19971021 changed: hennig@schlund.net 19980907 changed: manfred@schlund.de 20021125 source: RIPE |