UW Computer Security Research and Course Blog

This post documents an actual vulnerability exploit I recently witnessed. Details have been changed to protect the stupid.

I happened to be loafing around on IRC yesterday, when an unusual opportunity to observe some pointless cybercrime in action presented itself. One user on a channel I occasionally visit brought the channel’s attention to the website of a state government agency. Because this blog is open to the public and this post concerns a currently extant vulnerability in a public website, I will not identify the particular agency, but I will say that it is an Internet crime database for an entire state, including information about missing children, parole and probation supervision, and a sex offender registry.

This individual apparently ran a search for some name in the sex offender database, and examined the HTML source code of the output. There, among other things, he discovered that the photographs of the offenders matching the query were referenced in the following fashion:

    <img src='../reqsql?query=EXEC+SP_SOR_IMAGE+"SO001337">

Yep, this is exactly what it looks like: the image is retrieved by running an SQL command on a database, and the specific query to be executed is specified entirely in the URL. Normally, SQL injection attacks rely on poorly-checked input to slip additional statements into places where they wouldn’t be expected. In this case, however, the system was specifically designed to accept entire queries directly from the client application! One could enter a URL like the following:

Which would return a list of all the tables existing in the database. Through repeated queries of a similar nature, the hacker was able to obtain a comprehensive map of the entire database used by the website, and to download from it whatever information he pleased, including a comprehensive list of information on more than 100,000 registered sex offenders.

Things took a turn for the more sinister when our cracker, drunk with the sweet, sweet nectar of illicit success (and probably some libations of the more mundane sort as well) announced his intention to exploit this vulnerability to add a friend of his to the state’s sex offender registry. I, being the paragon of hacker virtue that I am, advised him that this action was certainly extremely illegal and unethical, not to mention an astonishingly effective way of converting a friend into an ex-friend.

Indeed, had he actually done this, I would have been obligated to alert the relevant authorities myself, but here the story takes an unexpected turn: as soon as he tried to run a query that would actually modify the database, he was rebuffed by a permission error. The designer of the site, while committing the grievous error of allowing arbitrary queries to be run by clients, had at least had the foresight to assign the minimum necessary database permissions to the webserver account. It could read from the database, but not write to it.

Just goes to show that sensible assignment of permissions can limit the potential damage from sloppy program code. This isn’t always the case, however.

Another time, in another place in IRC-land, I saw a successful “attack” against the website of the Entertainment Software Rating Board (http://www.esrb.org), which contains a searchable database of all PC and video games that have been rated by the organization. Another fellow had discovered that the input to one of the search forms was unchecked, which means that input similar to “123; DROP TABLE games” could potentially wreak havoc on the system. He thoughtfully pointed this out to the ESRB, but they declined his suggestion, insisting that their website was perfectly secure.

At this point, unfortunately, he turned toward the dark side and mentioned his findings on an IRC channel full of the least scrupulous human beings on the planet: bored teenagers. One of them surreptitiously added a game of his own creation to the ESRB database, giving it a rating of “AO” (for “Adults Only”). It remained in the database for a short while, before the cracker removed it himself. Had the attacker been of a mind to cause more mischief, he might have changed the rating of Grand Theft Auto: San Andreas to “E” for “Everyone”…

This is a clear example of excessive permissions: the ESRB website is supposed to provide a way to search the database, not modify it, so why give the publicly accessible program write permissions? Stupidity, that’s why. Fortunately, the ESRB’s website has since been overhauled, and that vulnerability no longer exists. The guy who exploited the vulnerability has probably been  kidnapped by Jack Thompson.

Well, in closing, I suppose this just goes a little way towards explaining why SQL injection attacks are some of the most common exploits found on the web. When one is found, it is often almost trivial to take advantage of. Such vulnerabilities are also very easy to avoid, but there are more than enough sloppy implementations and knuckle-headed security policies out there to ensure a steady supply of script-kiddie fodder for years to come.