From canacar@eee.metu.edu.tr Fri Apr 20 20:33:10 2001 Date: Fri, 20 Apr 2001 20:21:50 +0300 From: Can Erkin Acar To: project@honeynet.org Subject: Scan of the Month #14 submission The answers: 1. Which exploit(s) were used to attack the system? ISS/UNICODE and IIS/RDS vulnerabilities were used [1,2]. The RDS exploit uses the exact command patterns used by RFP's msadc.pl (v1 or v2) script so it is possibly the same script. The unicode exploit strings were typed from the Internet Explorer commandline. 2. How were the exploits used to access and control the system? two tools, pwdump2 and netcat were uploaded to the honeypot [3,4]. (the md5 sums of the reconstructed ftp data streams match the tools) using a combination of RDS and unicode exploits to run ftp on the honeypot. dumping of password hashes is attempted using pwdump2 failing that, the SAM is backed up using rdisk command is downloaded from the honeypot. Three interactive sessions were initiated by running netcat through the unicode exploit. 3. What was done once access was gained? Some experimentation, looking around, attempts to gather information (net session, users, SAM dump) attempts to add IWAM_KENNY and IUSR_KENNY users to the Administrator group. A file called README.NOW.Hax0r is created containing the text: "Hi, i know that this is a lab server, but patch the holes! :-)" The attacker notified a friend who connected through an nc connection created by the attacker. He examined the machine contents and created rfp.txt containing text: "best honeypot i've seen till now :)" The second attacker also appended a '.' to the default.htm file and created a test.txt file at the web root containing text "this can't be true". They announced the exploit to others (persumably through irc). Others connected to read the 'test.txt' file. If the above description makes the attack appear professional, it is not. The attacker is not familiar with NT and the workings of the exploits. There are many errors and retries throughout the attack. 4. How could this attack been prevented? Apply the latest NT/IIS updates. Remove\disable unused components (in this case, the sample database files) These fixes were extensively discussed in Bugtraq and NTBugtraq forums. 5. How much time did you spend on this analysis and writeup? About 4 hours initial analysis, including downloading latest version of snort/Win32 and coaxing it to work without installing the packet drivers. After understanding what is going on, the detailed analysis and writing is stretched over four days (working on my spare times). I started by documenting every step of the attack but it is taking too long. So this is a short version giving the basic ideas. Bonus Question: Do you feel that the attacker in question knew if this was a honeypot? No, but he has some smart friends. I believe that there are two people involved. The attacker is the one who did the initial exploiting. He then called a friend, who connected through a NetCat connection left open by the initial attack and decided that it is a honeypot. I believe his reasoning was: 'RFP wont leave his machines vulnerable to the exploits he developed' which, I think would be an obvious conclusion. Now the analysis: After downloading the snort dump, I ran it through snort and tcpflow [5,6]: snort -de -h 172.16.1.106/32 -l log -r hnet.dmp to create a directory structure, one per host that contains files for each 'connection' between that host and the honeypot. A typical file, log/204.42.253.18/TCP_42288-113.ids contains: 02/04-15:34:29.867335 8:0:20:9C:6B:2D -> 0:E0:1E:60:70:40 type:0x800 len:0x3A 204.42.253.18:42647 -> 172.16.1.106:113 TCP TTL:242 TOS:0x0 ID:44719 IpLen:20 DgmLen:44 DF ******S* Seq: 0x17E40A1 Ack: 0x0 Win: 0x832C TcpLen: 24 TCP Options (1) => MSS: 1460 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 02/04-15:34:29.868850 0:E0:1E:60:70:40 -> 8:0:20:9C:6B:2D type:0x800 len:0x3C 172.16.1.106:113 -> 204.42.253.18:42647 TCP TTL:127 TOS:0x0 ID:49015 IpLen:20 DgmLen:40 ***A*R** Seq: 0x0 Ack: 0x17E40A2 Win: 0x0 TcpLen: 20 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Which is an ident request from 204.42.253.18 port 42288 that is rejected by the honeypot (since there is no ident deamon) The next step was creating an alert.ids file using snort -c snort.conf -r hnet.dmp -de The alert.ids file lists the alerts snort generated while processing the hnet.dmp file. Sample alerts look like: ... [**] spp_http_decode: IIS Unicode attack detected [**] 02/04-15:25:22.525676 8:0:20:9C:6B:2D -> 0:E0:1E:60:70:40 type:0x800 len:0x1FE 213.116.251.162:1765 -> 172.16.1.106:80 TCP TTL:111 TOS:0x0 ID:11031 IpLen:20 DgmLen:496 DF ***AP*** Seq: 0x8E406992 Ack: 0x2CAE9E9B Win: 0x2238 TcpLen: 20 [**] WEB-MISC http directory traversal [**] 02/04-15:25:22.525676 8:0:20:9C:6B:2D -> 0:E0:1E:60:70:40 type:0x800 len:0x1FE 213.116.251.162:1765 -> 172.16.1.106:80 TCP TTL:111 TOS:0x0 ID:11031 IpLen:20 DgmLen:496 DF ***AP*** Seq: 0x8E406992 Ack: 0x2CAE9E9B Win: 0x2238 TcpLen: 20 ... The file contains 6 distinct alerts: Some initial tests by the attacker triggered forbidden responses. [**] WEB-MISC 403 Forbidden [**] These three are triggered by unicode exploits [**] WEB-MISC http directory traversal [**] [**] spp_http_decode: IIS Unicode attack detected [**] This is triggered for RDS and Unicode exploits [**] WEB-IIS msadc/msadcs.dll access [**] There are some ICMP ping echo requests as deteccted by below alerts [**] ICMP L3retriever Ping [**] [**] ICMP PING Windows [**] The frequency of alerts are as follows: 2x ICMP L3retriever Ping 2x WEB-MISC 403 Forbidden 7x ICMP PING Windows 104x WEB-MISC http directory traversal 252x spp_http_decode: IIS Unicode attack detected 256x WEB-IIS msadc/msadcs.dll access a single exploit attempt raises multiple alerts. Actually there are about 29 Unicode attempts and 64 RDS attempts. Although snort data has all the packet and timing information, it is very cumbersome for analysis. This problem is solved by using tcpflow to assemble tcp streams. Two files (one for each direction)are created for each connection. For instance, tcp flow for one of the unicode exploit attempts is in file 213.116.251.162.01876-172.016.001.106.00080: GET /msadc/..À¯../..À¯../..À¯../program files/common files/system/msadc/cmd1.exe?/c+echo+johna2k+>>ftpcom HTTP/1.1 Accept: */* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0; Hotbar 2.0) Host: lab.wiretrip.net Connection: Keep-Alive : Keep-Alive and the reply is in file 172.016.001.106.00080-213.116.251.162.01876 There are 492 streams, about 369 of which are directly related to the attack session. The exploit commands (unicode and rds), complete files transferred through ftp and netcat command-line sessions are directly recoverable from these files. The attack progresses as follows: - The attacker browses the web pages of the honeypot. Finds the guestbook and successfully retrieves /boot.ini using unicode exploit. - He now tries the RDS exploit and retrieves the result using unicode. This is also success. - There are four attempts to upload (by running ftp on the honeypot) three files (pdump.exe, samdump.dll, nc.exe) using RDS. First the attacker failes to login to his warez site, so he uses an ftp server on his machine. But mistypes the commands three times. - Finally, the attacker manages to upload the files to the honeypot this time using unicode (and typing the commands right). - He runs two netcat command sessions. The interactive sessions are coupled with RDS commands. Since the attacker ran nc.exe using the unicode exploit, he uses rds to execute commands with Administrator rights. - The first session (port 6969) lasts 18 minutes. The attacker tries to obtain SAM hashes using pdump.exe but fails (why? perhaps admin does not have debug privs in the honeypot?). He also adds IWAM_KENNY and IUSR_KENNY users to local administrators group. He tries rdisk /s through rds and saves this to a file (har.txt) he also creates README.NOW.Hax0r file. typing this file corrupts his terminal so he creates another nc command session on port 6968. - During The second session he tries to clean up the files he created and looks around some. He also downloads the har.txt using http. The source port numbers have large gaps, which means he is active elsewhere during this session that lasts 6 minutes. - He apperantly does some web searches, since the referrer header of his HTTP connections shows references to www.google.com and linux.unix.or.kr. So, he has found links to (possibly) www.wiretrip.net which referred him back to the honeypot. - He contacts some friends. And places an nc backdoor for one of them - The friend investigates the honeypot. Decides that it is a honeypot and leaves the rfp.txt file. He also creates the test.txt file and probably announces the hack on IRC. Right after the creation of the test.txt file, 14 distinct ip addresses fetch this file one of which is the original attacker. 10 connections occur in first 10 minutes, other 3 in next 20 minutes and last one 20 minutes later. - The session stays open for 32 minutes most of which is idle. During that time, the attacker moves around examining some files on the honeypot. - One final activity is the of unicode exploit to run an ftp command that puts whisker.tar.gz from the honeypot to the attacker ip. Results: There are 15 distinct ip addresses related with the exploit. Plus two possible warez site ips. Most connect using internet explorer or netscape, and some connect through proxy servers (that gives us a few open proxy addresses). The skill level of the attack is low. It attack could have been prevented by keeping up-to date with patches, and not installing (removing/disabling) unused services and modules. References: 1. Microsoft IIS and PWS Extended Unicode Directory Traversal Vulnerability http://www.securityfocus.com/bid/1806 2. NT IIS MDAC RDS Vulnerability http://www.securityfocus.com/bid/529 3. pwdump2 by Todd Sabin. http://www.webspan.net/~tas/pwdump2/ 4. Netcat 1.1 for Win 95/98/NT/2000 http://www.atstake.com/research/tools/nc11nt.zip 5. Snort homepage: http://www.snort.org/ 6. tcpflow homepage: http://www.circlemud.org/~jelson/software/tcpflow/