Hacking: how to read any file on a server

Posted by Nancy Wyatt (Penetration Testing), 16 Jan 2012
Hello world! I am Conseal's new leader of penetration testing - meaning I am paid to deliberately break our products and web sites. This is even more fun than it sounds. Recently I have had the pleasure of trying to rip into the new version (currently in beta) of Conseal Server.

Having only recently joined Conseal, I was essentially trying to break into a product whose internal machinations I knew nothing about. This is much harder than hacking products that I'm familiar with or which I've had a hand in developing, because I don't know the mechanisms involved. For example, I don't know what happens internally when a client authenticates itself - knowledge of which I would otherwise use to develop specific attacks.

So when working from cold I can only guess. It's a case of thinking carefully about how a product may have been written, and what security mistakes a programmer may therefore have made. For example, are a users' permissions checked correctly for every action they may take - or can I get into somewhere I'm not supposed to, simply because there's no bouncer on the door?

One of the most common mistakes I find allows me to read any file on a server's hard disk including system settings or password hashes. Even more significantly, it even allows me to read (and potentially reverse-engineer) the server's executable code - meaning I no longer have to work "from cold". Jackpot!

Here's how to protect yourself from an evil-minded version of me reading anything I want off your server's hard disk.

The problem occurs whenever a server takes a user's input and uses it to read a file (perhaps a template for example) from the disk.

Take a web server for example, and say it's used to display information on products. Let's say there's a URL like this:

http://www.my-parrot-shop.com/products?name=norwegian-blue

So there is a script called 'products' which is used to display a product named 'norwegian-blue'. The same script could be used to display any other parrot by replacing 'norwegian-blue' in the above with the parrot's name.

A common way of writing the 'products' script is:

1. Read the contents of a file called 'norwegian-blue'
2. Paste this into a template web page and display it to the customer.

So in step 1, we are taking the user's input and using it to form the filename. Can you see the security flaw yet? Let's ask this question... What happens if I request the following:

.../products?name=/etc/passwd

That would cause the script to serve me the contents of /etc/passwd as part of a web page! (A file which, under Unix, typically contains users' password hashes).

In fact, I could use the name of any file. This is known as a directory traversal vulnerability.

Scary? You'd be surprised how often this kind of hack works. Whenever you see a web page which takes a parameter which just might be a filename, try this out.*

It's such a great hack because it's so obvious, and so easy for programmers to get wrong. The solution is, of course, equally simple. If the file name you're reading from is based on a user's input, make sure it only consists of letters, numbers and dashes!

...So, most importantly, is this a hack that would work against your own website?

PS: You'll be pleased (or maybe disappointed as I was) to know that Conseal Server wasn't subject to any directory traversal vulnerability. Ah well. Next!

* Okay, perhaps check you're allowed to first.

0 comments:

Post a Comment