13th Jun 2002 [SBWID-5429]
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
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2025 AOH