|
Release Date:
June 18, 2001
Severity:
High (Remote SYSTEM level code execution)
Systems Affected:
Microsoft Windows NT 4.0 Internet Information Services 4.0
Microsoft Windows 2000 Internet Information Services 5.0
Microsoft Windows XP beta Internet Information Services 6.0
beta
Description:
There exists a remote buffer overflow vulnerability in all
versions of Microsoft Internet Information Services (IIS)
Web server software.
The vulnerability lies within the code that allows a Web
server to interact with Microsoft Indexing Service
functionality. The vulnerable Indexing Service ISAPI filter
is installed by default on all versions of IIS.
The problem lies in the fact that the .ida (Indexing
Service) ISAPI filter does not perform proper "bounds
checking" on user inputted buffers and therefore is
susceptible to a buffer overflow attack.
Attackers that leverage the vulnerability can, from a
remote location, gain full SYSTEM level access to any server
that is running a default installation of Windows NT 4.0,
Windows 2000, or Windows XP and using Microsoft’s IIS Web
server software. With system-level access, an attacker can
perform any desired action, including installing and running
programs, manipulating Web server databases, adding,
changing or deleting files and Web pages, and more.
The
Discovery:
Riley Hassell was at it again one day working to further
advance eEye's CHAM (Common Hacking Attack Methods)
technology so that Retina could better search for unknown
vulnerabilities in software and so that SecureIIS could
better protect from unknown IIS vulnerabilities.
After a few hours of running some custom CHAM auditing code
one of our Web servers in our lab eventually came to a halt
as the IIS Web server process had suddenly died.
We investigated the vulnerability further and found that
the .ida ISAPI filter was susceptible to a typical buffer
overflow attack.
Example:
GET /NULL.ida?[buffer]=X HTTP/1.1
Host: werd
Where [buffer] is aprox. 240 bytes.
The Exploit, as taught by Ryan "Overflow Ninja" Permeh:
This buffer overflows in a wide character transformation
operation. It takes the ASCII (1 byte per char) input buffer
and turns it into a wide char/unicode string (2 bytes per
char) byte string. For instance, a string like AAAA gets
transformed into \0A\0A\0A\0A. In this transformation,
buffer lengths are not checked and this can be used to cause
EIP to be overwritten.
This sounds like any normal overflow to date, however there
are a few sticking points in doing anything useful with
this. First, you transform 2 bytes into 4, 2 of which you
have no control over. This would be a bad situation, but not
impossible to exploit. However, the 2 bytes that you do not
have control over happen to be nulls. Basically, we need to
take this 2 byte string and somehow get it to point to our
code. Traditionally, we use our overwritten EIP to jump to a
call esp, or jmp esp, jumping back to code we have
positioned on the stack to implement whatever it is our
shellcode would like to do. In this case, however, there is
a problem.
GET /a.ida?[Ax240]=x HTTP/1.0
The above example overwrites EIP with 0x00410041. Again,
traditionally, we insert our shellcode in the same buffer we
overflow, however we run into the problem that then our code
would also face the same expansion that our EIP bytes face.
This makes writing shellcode a horrible pain. There are two
methods of doing this:
1. custom shellcode: It might be possible to write
shellcode that works fine with NULL byes every other byte.
It would probably have to be very simple, but this could be
possible.
2. encode: You could probably write a decoder that takes a
string of 0x0041 and rewrites it on the stack into actual
single byte code. This would have to be written completely
in 0x00bb opcodes, most likely a challenge in itself
(similar to the above custom shellcode, but only a decoder
would need to be written).
This would, of course only be possible if we could find a
point in memory that we could reach using only 0x00aa00bb.
This gives us only about 65k spots in memory to look for
jump bytes, a pretty dismal situation.
Exploiting Wide Char Strings In Practice
We got lucky using this method. We were basically limited
to a very very small range of memory in which to find jump
bytes. We thought we were losing the battle until we
realized that IIS/ISAPI uses 0x00aabbcc as its memory range
for allocated heap. We developed a spray technique in an
attempt to push enough data into the heap so that the bytes
we require will be there when we need to jump to them.
For instance, in Windows 2000 Service Pack 1, we noticed
that we had request bytes at around 0x0042deaa. Since the
closest we could get to this was 0x00430001 (by overflowing
with C%01 at the end of our overflow string. This offered us
an intriguing possibility -- perhaps we could push more
stuff into a request, causing more heap memory to be used,
pushing our request closer to where we want to be.
GET /a.ida?[Cx240]=x HTTP/1.1
Host: the.victim.com
eEye: [Cx10,000][shellcode]
Now, we overflow the EIP with 0x00430043. With our new much
larger request, 0x00430043 happens to be inside the large C
buffer we setup. This acts as a slide in our code, executing
down to our shellcode.
The
Warning
Now for the warning. With this technique of forceful heap
violation, everything is relative to what is there to begin
with. We noticed that in any situation, we found 4-5
different copies of our requests in the 0x00aabbcc memory
range. This means that perhaps 0x430043 is not the best spot
in memory, however it is the one we chose in our forthcoming
sample exploit (the exploit we will provide only executes
file writing; we provided Microsoft with shell-binding code
but will not publicly release this code). The other
potential problem with this attack is that different systems
may have different heap usages. In our internal tests, we
noticed that heap usage differed depending on which ISAPI
extensions were enabled at any time. Also, requests that
cause faults handled by exception handlers that do not free
their heaps may cause certain parts of the heap to become
unusable, causing those spots to not be reused. This is not
a problem for Windows 2000 because it is nice enough to
restart itself (giving us a nice clean heap to work with).
Windows XP appears to act similarly, however we did not
focus our research with this beta OS. This is, however,
potentially a problem with NT 4, which will crash if
exploited incorrectly. Again, like all other IIS overflows,
this attack is not logged, causing only a fault in IIS and
crashing it.
All of the technical talk aside, we do have working
exploits for Windows NT 4.0 and Windows 2000 systems.
Proof-Of-Concept Exploit
We will be posting a proof-of-concept (file writing)
exploit to our Web site within the next few days.
The
Fallout
According to Netcraft (www.netcraft.com), there are roughly
5.9 Million Web servers running IIS; however, the true
number of IIS Web servers is much larger when you count
internal network servers. Any of these Web servers that have
the default .ida ISAPI filter installed are most likely
vulnerable.
Note
on Windows XP beta:
As stated earlier, all versions of Microsoft’s IIS Web
server software are vulnerable to this flaw. This includes
Windows XP beta, Microsoft’s next-generation Operating
System and the version of IIS that is included with it.
Microsoft is taking the necessary steps to patch Windows XP
before the final version ships to customers.
Funny:
Some people might wonder why this advisory does not contain
the typical eEye humor like most of our other advisories.
Basically, the reason is that this is our 4th remote SYSTEM
level IIS vulnerability and well...we've run out of jokes.
eEye
Note:
Those eEye customers who are using the latest version of
SecureIIS are already protected from this vulnerability.
SecureIIS is able to stop known and unknown IIS
vulnerabilities by looking for classes of attacks instead of
specific attack signatures.
Also, Retina 4.02, The Network Security Scanner, will be
posted to our Web site shortly. It includes many new
features and functionalities and also remotely checks for
this latest Microsoft IIS vulnerability.
Vendor
Status:
Microsoft has released a patch for this vulnerability that
can be downloaded from:
http://www.microsoft.com/technet/security/bulletin/MS01-033.asp
Also eEye Digital Security recommends removing the .ida
ISAPI filter from your Web server if it does not provide
your Web server with any _needed_ functionality.
Copyright (c) 1998-2001 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.
Hyperlinks
SecureIIS: stop known and unknown IIS Web server
vulnerabilities Retina, The Network Security Scanner
http://www.microsoft.com/technet/security/bulletin/MS01-033.asp
Credits
Discovery: Riley Hassell, Exploit: Ryan Permeh
eEye Digital Security
http://www.eEye.com |