Retina vs. IIS4, Round 2, KO (fwd)

[Brian Behlendorf <br...@hyperreal.org>]

Ouch!  KO, indeed.

---------- Forwarded message ----------
Date: Tue, 15 Jun 1999 12:18:16 -0000
From: eEye - Digital Security Team <ee...@EEYE.COM>
To: BUGTRAQ@NETSPACE.ORG
Subject: Retina vs. IIS4, Round 2, KO

Retina vs. IIS4, Round 2

Systems Affected:

Internet Information Server 4.0 (IIS4)
Microsoft Windows NT 4.0 SP3 Option Pack 4
Microsoft Windows NT 4.0 SP4 Option Pack 4
Microsoft Windows NT 4.0 SP5 Option Pack 4

Release Date:

June 8, 1999

Advisory Code:

AD06081999

Description:

We have been debating how to start out this advisory. How do you explain
that 90% or so of the Windows NT web servers on the Internet are open to a
hole that lets an attacker execute arbitrary code on the remote web server?
So the story starts...

The Goal:

Find a buffer overflow that will affect 90% of the Windows NT web servers on
the Internet. Exploit this buffer overflow.

The Theory:

There will be overflows in at least one of the default IIS filtered
extensions (i.e. .ASP, .IDC, .HTR).  The way we think the exploit will take
place is that IIS will pass the full URL to the DLL that handles the
extension. Therefore if the ISAPI DLL does not do proper bounds checking it
will overflow a buffer taking IIS (inetinfo.exe) with it and allow us to
execute arbitrary code on the remote server.

Entrance Retina:

At the same time of working on this advisory we have been working on the AI
mining logic for Retina's HTTP module. What better test scenario than this?
We gave Retina a list of 10 or so extensions common to IIS and instructed it
to find any possible holes relating to these extensions.

The Grind:

After about an hour Retina found what appeared to be a hole. It displayed
that after sending "GET /[overflow].htr HTTP/1.0" it had crashed the server.
We all crossed our fingers, started up the good ol' debugger and had Retina
hit the server again.

Note: [overflow] is 3k or so characters... but we will not get into the
string lengths and such here. View the debug info and have a look for
yourself.

The Registers:

 EAX = 00F7FCC8 EBX = 00F41130
 ECX = 41414141 EDX = 77F9485A
 ESI = 00F7FCC0 EDI = 00F7FCC0
 EIP = 41414141 ESP = 00F4106C
 EBP = 00F4108C EFL = 00000246

Note: Retina was using "A" (0x41 in hex) for the character to overflow with.
If you're not familiar with buffer overflows a quick note would be that
getting our bytes into any of the registers is a good sign, and directly
into EIP makes it even easier :)

Explain This:

The overflow is in relation to the .HTR extensions. IIS includes the
capability to allow Windows NT users to change their password via the web
directory /iisadmpwd/. This feature is implemented as a set of .HTR files
and the ISAPI extension file ISM.DLL. So somewhere along the line when the
URL is passed through to ISM.DLL, proper bounds checking is not done and our
overflow takes place. The .HTR/ISM.DLL ISAPI filter is installed by default
on IIS4 servers. Looks like we got our 90% of the Windows NT web servers
part down. However, can we exploit this?

The Exploit:

Yes. We can definitely exploit this and we have. We will not go into much
detail here about how the buffer is exploited and such. Read the comments in
the asm file for more information. However, one nice thing to note is that
the exploit has been crafted in such a way to work on SP4 and SP5 machines,
therefore there is no guessing of offsets and possible accidental crashing
of the remote server. We have not tested the exploit on SP3 and would love
to know if it works or not. eMail alert@eEye.com if you've successfully
exploited this hole on SP3.

For more details about the exploit visit the eEye web site at www.eEye.com

The Fallout:

Almost 90% of the Windows NT web servers on the Internet are affected by
this hole. Everyone from NASDAQ to the U.S. Army to Microsoft themselves.
No, we did not try it on the above mentioned. But it is easy to verify if a
web server is exploitable without using the exploit. Even a server that's
locked in a guarded room behind a Cisco Pix can be broken into with this
hole. This is a reminder to all software vendors that testing for common
security holes in your software is a must. Demand more from your software
vendors.

The Request. (Well one anyway.)

Dear Microsoft,

One of the things that we found out is that IIS did not log any trace of our
attempted hack. We recommend that you pass all server requests to the
logging service before passing it to any ISAPI filters etc...The logging
service should be, as named, an actual service running in a separate memory
space so that when inetinfo goes down intrusion signatures are still logged.

Retina vs. IIS4, Round 2. KO.

Fixes:

1. Remove the extension .HTR from the ISAPI DLL list. Microsoft has just
updated their checklist to include this interim fix.
   http://microsoft.com/security/products/iis/CheckList.asp
2. Apply the patch supplied by Microsoft when available.
   http://microsoft.com/security

Vendor Status:

We contacted Microsoft on June 8th 1999, eEye Digital Security Team provided
all information needed to reproduce the exploit. and how to fix it.
Microsoft security team did confirm the exploit and are releasing a patch
for IIS.

Related Links

Advisory - On our web site
http://www.eEye.com/database/advisories/ad06081999/ad06081999.html

Advisory - Retina Brain File used to uncover the hole
http://www.eEye.com/database/advisories/ad06081999/ad06081999-brain.html

Retina - The Network Security Scanner
http://www.eEye.com/retina/


Greetings go out to:

The former Secure Networks Inc., L0pht, Phrack, ADM, Rhino9, Attrition, HNN
and any other security company or organization that believes in full
disclosure.

Copyright (c) 1999 eEye Digital Security Team

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.

Please send suggestions, updates, and comments to:

eEye Digital Security Team

info@eEye.com
www.eEye.com