|
COMMAND IIS .HTR Remote Buffer Overflow SYSTEMS AFFECTED Microsoft Windows NT 4.0 Internet Information Services 4.0 Microsoft Windows 2000 Internet Information Services 5.0 PROBLEM In eEye Digital Security Advisory AD20020612 [http://www.eEye.com]: A vulnerability in transfer chunking, in combination with the processing of HTR request sessions can be exploited to remotely execute code of an attackers choice on the vulnerable machine. By sending a carefully crafted session, an attacker can overwrite a section of the heap. Data structures in the overwritten heap can be manipulated to move attacker-supplied data to attacker supplied memory addresses, thereby altering the flow of execution into an attacker supplied payload. This is a very serious vulnerability and eEye suggests that administrators install the Microsoft supplied patch as soon as possible. The following example will show the vulnerable condition. The dllhost.exe child process will silently die because the developers have replaced the default exception filter. So if you want to examine this closer, load a debugger up on the dllhost child process before you send this example session over the wire. **************Begin Session**************** POST /EEYE.htr HTTP/1.1 Host: 0day.big5.com Transfer-Encoding: chunked 20 XXXXXXXXXXXXXXXXXXXXXXXXEEYE2002 0 [enter] [enter] **************End Session****************** Technical Description: The example session above overwrites a section of the heap that contains data structures related to the memory management system. By manipulating the content of these structures we can overwrite an arbitrary 4 bytes of memory with an attacker supplied address. While many may believe that the risk for these types of vulnerabilities is fairly low due to the fact that addressing is dynamic and brute force techniques would need to be use in an attack, eEye strongly disagrees. This premise is false as successful exploitation can be made with one attempt, across dll versions. An attacker can overwrite static global variables, stored function pointers, process management structures, memory management structures, or any number of data types that will allow him to gain control of the target application in one session. SecureIIS(tm) Application Firewall for Microsoft IIS It should be noted that clients using any version of SecureIIS from eEye Digital Security are secure from this vulnerability. This vulnerability was discovered by the eEye team while testing a new version of SecureIIS to help further its protection abilities from similar classes of attack. To learn more visit http://www.eeye.com/SecureIIS Vendor Status: Microsoft has released a security bulletin and patch: http://www.microsoft.com/technet/security/ Beyond installing the Microsoft security patch it is also recommend to disable the .htr ISAPI filter if you have not already done so. Microsoft’s security advisory references more information on the steps of how to disable the .htr ISAPI filter. Credit: Riley Hassell Greetings: Caesar, K2, Dark Spyrit, Solar Designer, Joey, Halvar, Gera, Scut, Ilfak Guilfanov. And last but not least, Kasia and Jenn ;) and as always, www.securityfocus.com. Copyright (c) 1998-2002 eEye Digital Security Permission is hereby granted for the redistribution of this alert electronically. It is not to be edited in any way without express consent of eEye. If you wish to reprint the whole or any part of this alert in any other medium excluding electronic medium, please e-mail alert@eEye.com for permission. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user\'s own risk. Feedback Please send suggestions, updates, and comments to: eEye Digital Security http://www.eEye.com info@eEye.com Update (18 June 2002) ====== Brett Moore adds : This following applies to the recent .asp and .htr Buffer Overflows for IIS and possibly other similar vulnerabilities. From the eEye Advisory: \"By manipulating the content of these structures we can overwrite an arbitrary 4 bytes of memory with an attacker supplied address.\" This statement is misleading and should read similar to: \"we can overwrite multiple memory addresses with attacker supplied data\" So what is the difference? From the Eeye Advisory: \"While many may believe that the risk for these types of vulnerabilities is fairly low due to the fact that addressing is dynamic and brute force techniques would need to be used in an attack, eEye strongly disagrees. This premise is false as successful exploitation can be made with one attempt, across dll versions.\" The recent .asp exploits that I have seen all work in a similar way. They overwrite the exception handler, which is a static memory address with the address of the payload. Then when the execption happens code execution jumps to this address. This address is dynamic, so to reach this address exploits can 1) Hard code the address as in; IIS5.0 .asp overrun remote exploit Programmed by hsj : 02.04.14 #define RET 0x0045C560 /* our payload. ugh, direct 2) Brute force the address as in; IIS5.0 .asp overrun remote brute force exploit by isno(isno@xfocus.org) #define RET 0x00450000 /* brute force addr */ #define STEP 2000 /* brute force step */ 3) Find a static address that has the required code to do a relative jump as in * the address of our payload is at [esp+xx] * we find a static location with the instuctions for jmp [esp+xx]. While #3 is obviously the best way, it is not always possible to find the instructions required. But because we can write to multiple addresses an exploit can work like this, * locate the static memory address for the exception handler * locate another static memory address * overwrite the exception handler with the second address * overwrite the second address with the required instructions for our relative jmp * cause an exception The result? A security vulnerability is always a serious issue. The fact that there are not always exploits created and made available to the public, should in no way suggest that the risk is lower. Where did I find this? It was there inside my computer just waiting for me. And I could almost say 100% that \"I\'m not the only one to know this\". But it is not something that I have seen on any resource for IT Security and as such the general impression has been that vulnerabilities of this type are \"Low Risk because of the dynamic address issue\". So either only the true underground know about this or perhaps the professional IT security industry is somewhat like the NSA,FBI,CIA and doesn\'t like to share information. Microsoft Resources ----------------------------------------------------------------------- Title: Heap Overrun in HTR Chunked Encoding Could Enable Web Server Compromise (Q321599) Date: 12 June 2002 Max Risk: Moderate Bulletin: MS02-028 Mitigating Factors: ==================== - On default installations of IIS 5.0, exploiting the vulnerability to run code would grant the attacker the privileges of the IWAM_computername account, which has only the privileges commensurate with those of an interactively logged-on unprivileged user. ----------------------------------------------------------------------- Title: Unchecked Buffer in Remote Access Service Phonebook Could Lead to Code Execution (Q318138) Date: 12 June 2002 Impact: Local Privilege Escalation Max Risk: Critical Bulletin: MS02-029 Mitigating Factors: ==================== - The vulnerability could only be exploited by an attacker who had the appropriate credentials to log onto an affected system. - Best practices suggests that unprivileged users not be allowed to interactively log onto business-critical servers. If this recommendation has been followed machines such as domain controllers, ERP servers, print and file servers, database servers, and others would not be at risk from this vulnerability. So put the together the two vulnerabilities that were released on the same day, and we have a remote system level exploit for IIS? Yet the HTR Buffer Overflow only has a Max Risk: Moderate. SOLUTION Apply Microsoft patch: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS02-028.asp