Project Honeynet - Scan of the Month - April 2001 Analysis and Answers Submitted by: Tom.Vandepoel@ubizen.com ------------------------------------------------- The answers to the analysis questions are further below. First some general explanation on how I came to these conclusions. I first took a quick look at the raw dumpfile. Skimming through the readable text I could already reconstruct most of the attack's progress, one which is very typical for NT IIS intrusions and which I myself have also used during pentests. Next, I ran the file through snort's decode mode and made it write its output to a log directory, which means it produces an output of sorted decodes per originating IP address. This makes it real easy to eliminate some of less interesting traffic I concentrated on traffic between the attacker's host, the target and the FTP server that was initially included in the attack. Using these decoded dumps, I started composing a timeline, which is included further below. This method allowed me to follow most of what was going on at HTTP level, but analyzing the netcat sessions was a bit cumbersome. Instead, I fired up ethereal and opened up the dump file. Using the "follow TCP stream" plugin I managed to save a clean readable dump of each of the netcat sessions. I then cross referenced these readable dumps with the snort decodes, to know the exact time occurence of each interesting command, so I could further complete the timeline. I also used ethereal in the manner described above to reconstruct copies of files transferred by the intruder: - The SAM._ registry dump. - The downloaded '0-day' whisker.tar.gz archive. I ran the SAM file through l0phtcrack, which found the Administrator password to be '50uthP'. Answers: 1) Which exploit(s) were used to attack the system? Two very prominent IIS vulnerabilities were used: - IIS MDAC RDS Vulnerability, which allows remote command execution as "SYSTEM The dumps show that, ironically, RFP's own "msadc.pl" perl script was used. - IIS Unicode Vulnerability, which allows to request files outside the document root through directory traversal and as a side-effect allows remote command execution as IUSR. This was done through a regular browser, by crafting URL's. 2) How were the exploits used to access and control the system? Both IIS vulnerabilties were used in combination with each other, although this is not strictly necessary. As shown in more detail in timeline.txt, this is what happened: - Both vulnerabilities are 'tested': - The intruder tries to view c:\boot.ini through Unicode directory traversal, which succeeds. - The intruder creates a file via the RDS vulnerability and is able to view it through Unicode directory traversal. - Tools are downloaded to the target: - The intruder creates an FTP script (via MDAC, line-by-line) and executes it through "ftp -s". The intruder is quite clumsy, so (s)he has to repeat this a few times. - Initially, (s)he tries to use an account on ftp.nether.net, which is a public-access system, but this fails. (S)he switches over to using an FTP server on what I suspect is his/her own system and eventually (s)he succeeds in uploading netcat and pwdump. - The intruder also thinks the MDAC exploit isn't working properly, and switched to the Unicode vulnerability. - The intruder establishes interactive control by forking a netcat listener on TCP port 6969, which spawns a cmd.exe. This command shell runs as IUSR, because the Unicode exploit was used to spawn the shell. 3) What was done once access was gained? Using the interactive shell, the intruder scouts around, getting a better 'feel' of the system. (S)he tries to elevate privileges of the IUSR, which (s)he is logged in as, which appears to succeed. Strangely, these gained privileges aren't really used afterwards. A copy of the system's user database is transferred off the system and presumably run through l0phtcrack. The 'administrator' password is quite weak and can be found fairly quickly, so we presume the intruder also managed to extract it. Next, the intruder appears to show off the 'hack' to other people. We assume this is the case because of the various HTTP requests for a very specific file (/test.txt) from different locations. Also, two messages are left for RFP (in 2 seperate files): First: 'Hi, i know that this is a lab server, but patch the holes!' And later: 'best honeypot i've seen till now :)' 4) How could this attack been prevented? Various measures could have been taken: - First, simply applying the latest IIS patches would have eliminated the 2 holes that were used. - Second, doing some more proactive IIS stripping would provide even better protection. The 'if you don't use it, disable it' principle should be applied. More specifically: -> stripping default mappings like /msadc -> removing unneeded application mappings like .htr,.htw,... -> keeping web directories on seperate logical drive as system (eg. D) would help a lot against generic directory traversal exploits. -> Making the web directories non writable for IUSR - Third, a better level of host security would make the intruder's life a pain. Especially the filesystem permissions are too lax by default and make it too easy for an intruder to access most files on the system. - Finally, have a firewall filtering device in between the web server and the outside world. This will thwart those rogue netcat cmd.exe sessions. Ofcourse, don't forget to restrict *outgoing* traffic as well, cause it's just as easy to have netcat connect back to a listener on an outside box. 5) How much time did you spend on this analysis and writeup? Spread over a number of days, I guess this adds up to about 12 hours of analysis and writeup work. Bonus Question: Do you feel that the attacker in question knew if this was a honeypot? If so, why or why not? Absolutely: - (S)he left a clear message for RFP, stating "best honeypot ever seen". - lab.wiretrip.net was revealed as honeypot on the CanSecWest conference, a few days just before the intrusion. - The attacker doesn't really use the gained privileges. No attempt is made to look for other systems on the same segment. Thus the intruder probably knew or assumed that there would be nothing of further interest to look for. - Anyone with half a brain would find it quite strange that RFP himself would leave these holes in his own webserver, holes he himself wrote advisories about.