m4d H4X

For two years I was a UTA for our department's Introduction to Security course, and my current roommate is the current Head TA. So when a friend was looking for someone to perform a security audit on his web application, he called my roommate, who called me in as his surgeon's assistant. Here's what we found:

Dictionary Attack

Anytime you have a problem in computing, there's always a 'dumb way to do it,' which normally involves checking every possibility. Remember being a kid and asking someone to guess your birthday? The first thing they ask is 'What month is it in?' Suppose you say 'August.'

A dictionary attack is the kid who closes his eyes and says "August 1st August 2nd August 3rd August 4th August 5th..." (and ruins the game).

The idea is this: if you want to guess someone's password, try every value it could be. You do this by trying to log in as them with every password, and you stop when one of them works.

Sounds dumb? It is, but never underestimate a fast, dumb computer. After all, it worked against Twitter.

The attack is called a Dictionary attack because the idea is that you try someone's e-mail address with every word in the dictionary. A simple dictionary (one I used for this) consists of the 500 most common passwords, a couple hundred first names, and an actual dictionary (the puzzle links to a text file). Since most people use real words as their passwords, there's a good chance you'll stumble upon the correct one.

To stop this, you have a few options:

• Create a delay after some failed attempts, and report the behavior to an admin. So if someone messes up their password 3 times, make them wait 15 minutes. Another 3, make them wait an hour, etc. This slows down your opponent, and makes you aware of suspicious activity.


• Demand strong passwords. We all get annoyed having to mix numbers and letters (one of the most common passwords is 'password1', the most common is '123456'), but it helps your security, since you won't find 'h4ll0MRP3ANut' in a dictionary.


• Keep track of your requests, and stop trolls. This is a similar tactic to a DoS, but keep track of where people are logging in from. If you have 100 failed logins in 1 minute from IP Address 113.154.2.110, stop letting them try to connect (again, at least for a day or two).

File Upload

Most web applications let you upload files to share, or view online. There was once an artist who bound his book with sandpaper so that shelving and re-shelving it would destroy the books next to it. That bookshelf is your application, and that book is the other exploit we found.

The site in question had a file upload feature, so we uploaded an executable file that would run whatever command we fed it on the computer where it resided (in this case, the company server). As soon as we 'viewed' the document, it would execute. So a command like

find ../../ -name "config.rb" -exec grep password '{}' \;

Will find a configuration file, and find all the passwords in it (most web frameworks have contain a file).

The fix to this one is simple: don't let users upload any type of file your server might execute (unless, of course, you're a code hosting site, in which case you don't need to be told about this).

----

Security isn't the way movies make it out to be: most hacks aren't mathematical or cryptographic breaks, and they're never as dramatic. The brilliance in the best ones is that they're so simple. Most security holes are little leaks in the way software gets written, or more usually (like weak passwords) flaws in predictable human behavior.