From Eddi@blenkers.net Wed Feb 14 19:14:12 2001 Date: Sun, 11 Feb 2001 12:41:13 +0100 From: Eddi To: project@honeynet.org Subject: Scan of the month Dear honeynet! As I am still massaging our management into buying an IDS system, I am happy to use the opportunity for a paper & pen exercise. 1. What is the operating system of the honeypot, how do you know? ----------------------------------------------------------------- The session breakout hints to a Windows NT system, version 4.0 that is. Lacking the equipment to check sequence numbers from the handshake, I have to deduct the OS from session breakout. a) the directory listing provided shows a WINNT directory b) the directory structure matches NT 4.0 c) For Win2k I would expect to see a "Documents and Settings" directory d) As the system was installed in 12/00 it would be real suprise to find version 3.51 or even 3.1 As I am not too deep in reading IP traces and NT history, I can not deduct any service pack from the trivial increase in sequence numbers. 2. What is the name of this attack? ----------------------------------- The CERT Vulnerability Note VU#111677 names this attack as the "Web Server Folder Directory Traversal" vulnerability. 3. What is the attack attempting to accomplish? ----------------------------------------------- This attack would start an executable on the target system. The simple request of a directory listing (as seen in the scan) would be a proof of concept, that this system is vulnerable. The attackers hope is to run the executable under the privilege level of the webserver (in this case: hopefully the administrators account) 4. How does the attack work? ---------------------------- The url starts cmd.exe using a relative path. This is discussed in bugtraq ID #968. Another useful explanation can be found in the Network ICE database on http://advice.networkice.com/advice/Intrusions/2000603/ The presented system here is a smart variation of this bug: As several intrusion detection systems trigger on the relative path traversal (i. e. the string ../..) the slash is hidden in an overlong unicode presentation of the slash: %C0%AF On an unpatched system, the unicode replacement would happen after the file specification has been parsed. This would a) trick the IIS into thinking, it's an innocent URL and b) dodge some IDS triggers. Rain forest puppy gives a good explanation of unicode in URLs in http://packetstorm.securify.com/0010-exploits/iis-unicode.txt Oh, I guess, he _is_ somewhat linked to the honeynet project, isn't he? Bonus Question: Is it possible to gain remote control of the system using this technqiue? If so, how? ------------------------------------------------------------------------------------- I don't know too much about IIS internals, so my answer is from an OS point of view: Yes, a poorly configured system might be vulnerable. Instead of requesting a directory listing, the echo command could be used to append autoexec.bat. echo >> autoexec.bat net share winnt echo >> autoexec.bat net user malicious_intent /add Starting services to allow remote control of the registry might be another idea. As both the CERT note and rfp point out, the programs are run in the context of the IUSR_machinename account. It might be noteworthy, that a number of scripts are floating around to exploit this bug. One of them is at http://packetstorm.securify.com/0011-exploits/iis-unicode-exploit.pl Unsolicited question: What do we learn from this exercise? ------------------------------------ a) There is a vulnerability in msadc, but it's not the one we are looking for. b) Don't think straight. Keep on looking c) Banning linux from your net won't keep "adventurous" users at bay: Any Win* system in a default configuration will do. d) There is always another vulnerability. That's it. I enjoyed walking through the questions. Kind regards, yours electronically /Eddi Blenkers