[ISN] All versions of Microsoft Internet Information Services, Remote buffer overflow (SYSTEM Level Access)

From: Marc Maiffret (marcat_private)
Date: Mon Jun 18 2001 - 16:50:11 PDT

  • Next message: InfoSec News: "[ISN] TVA workers reprimanded for alien search"

    All versions of Microsoft Internet Information Services, Remote buffer
    overflow (SYSTEM Level Access)
    
    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
    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, Windows 2000 and Windows XP 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.
    
    Credit:
    Discovery: Riley Hassell
    Exploit: Ryan Permeh
    
    Related Links:
    SecureIIS: stop known and unknown IIS Web server vulnerabilities
    
    Retina, The Network Security Scanner
    
    Greetings:
    James, Delsea, Rachael, Steve, and Code Red Mountain Dew.
    
    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 alertat_private 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
    infoat_private
    
    
    ISN is hosted by SecurityFocus.com
    ---
    To unsubscribe email isn-unsubscribeat_private
    



    This archive was generated by hypermail 2b30 : Tue Jun 19 2001 - 02:01:56 PDT