Friday, April 20, 2007

White Hat Hacking for Rainy Day Fun: Weak search forms still revealing too much data

What better way to spend a rainy April day than white hat hacking? Experience the thrill of hacking with none of the guilt. I highly recommend this for anyone who has difficulty understanding why hackers do what they do (and you are NEVER going to be a really good information security professional unless you DO understand what hacking is about).

Allow me to swap my white hat for my linguist cap for a moment (B.A. Honours, School of English, University of Leeds--one year behind guitar virtuoso Mark Knopler but way ahead of the wonderfully talented Corinne Bailey Rae--and would you believe I can't even carry a tune, but I digress). It has to be said that hacking is one of the most hotly contested words of the information age. In justifiable homage to the original good-hearted hackers many infosec professionals use the qualifier "criminal hackers" to distinguish the bad guys from the good guys (that's gender-neutral colloquial 'guys' by-the-way). The good guys, who don't break laws, can be referred to as white-hat hackers, the bad guys being black hat. I am actually leaning towards 'bad actors' as a preferred term for the bad guys (with apologies to my thespian readers).

So, one rainy April afternoon I was wearing "my film producer hat" and working the web to promote the film's appearance at two overlapping film festivals, one in Winston-Salem and the other in Columbus, Ohio. Neither the director nor myself could afford to attend these events in person and we were worried that turnout would be low. I decided to surf the web sites of colleges in the target areas and to identify faculty with an academic interest in civil rights history (and thereby interested in the film enough to tell their students about it). In the process I found a classic example of weak web design that was hackable.

After using standard search tools to identify the people I wanted to contact, I looked for their email addresses. Many organizations like schools and hospitals have a directory of staff phone numbers and email addresses. However, to prevent a variety of problems, such as spam, these and other details are not displayed wholesale in a list, but one at a time in response to a name search. In other words, a form on a web page enables users to search a database of people (in infosec terms, this database can be referred to as an asset). The premise is that you have to know the person's name to find their information.

I used this sort of directory to email several professors at several schools. However, I also found something interesting. These forms usually consist of two fields, for Last Name and First name, together with a Submit button. The way it's supposed to work is that you, perhaps an aspiring Physics major, enter Einstein in one field, Albert in the other, click Submit, and get the phone number and email address for Prof. Einstein. However, such forms can be a pain for users who can't recall the professor's full name, so the form might allow you to enter Einstein for the last name and the letter 'A' for the first name. And herein lies a dilemma that can become a problem. How 'vague' to make the search. For example, if I can enter 'D' in the last name field and 'J' in the first name field, I can all Jane and John Does in the database. What you need is a fairly clever set of rules built into the form to control the results of any conceivable form input.

You see, in terms of information security, one can reliably predict that someone (referred to as an agent) will at some point click the Submit button without entering any characters at all in either field. If the result of this action is to reveal all of the records in the database (what we might call a means), one can reliably predict, based on past history, that this method will eventually be used to make a copy of all the records in the database (asset).

Thus, by failing to properly code the handling of form input from this search page, the folks who put up the page have created a vulnerability. This becomes a means of attack and a threat exists if someone figures out how to exploit it to gain unauthorized access to the asset. (This same problem crops up with student directories as well, where you are even less likely to want to grant access to the full list.)

This example nicely displays all of the elements of an information security threat (asset, agent, means). I have seen this type of problem on local government web sites where the effect was enable the attacker to find all the data required to steal a person's identity, or even find all of the special training taken by former military personnel in the area.

As a white hat hacker it is your responsibility to inform the site manager of the problem. You avoid, as I have here, revealing specifics of the problem (e.g. the address of web site where I found this example). Hopefully, they will correct the problem. As for me, I will admit that, wearing my producer hat, I did use some of the email addresses that I found. I did not spam anyone. I sent them personal notes. And maybe it worked. At the Ohio festival Dare Not Walk Alone won the audience award for best film.
.

No comments: