Vulnerability
IIS
Affected
IIS 4, 5, 6beta
Description
Marc Maiffret found following. 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.
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.
eEye 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.
eEye got lucky using this method. They were basically limited to
a very very small range of memory in which to find jump bytes.
They thought they were losing the battle until we realized that
IIS/ISAPI uses 0x00aabbcc as its memory range for allocated heap.
They 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, eEye noticed that
they had request bytes at around 0x0042deaa. Since the closest
they could get to this was 0x00430001 (by overflowing with C%01
at the end of our overflow string. This offered 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.
With this technique of forceful heap violation, everything is
relative to what is there to begin with. eEye 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; eEye 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 internal tests, eEye 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, Windows 2000 and Windows XP systems.
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.
Discovery credit goes to Riley Hassell and Ryan Permeh for
exploit.
Solution
Check out Microsoft Security Bulletin:
http://www.microsoft.com/technet/security/bulletin/MS01-033.asp