Looking back at 2009 through SQL Injection goggles

The earliest public mention I could find of SQL Injection (‘piggybacking SQL statements’ as the author put it) was from someone who called himself Rain Forest Puppy (RFP). In 1998 RFP wrote an article for Phrack Magazine (Volume 9, Issue 54) in which he talks about ‘NT Web Technology Vulnerabilities’. However I suspect the vulnerability had existed long before then.

More than a decade has passed since ‘RFP’ wrote his article for Phrack Magazine, and still today fortune 500 companies are having trouble protecting themselves against SQL Injection attacks. In this article we are going to look at some high profile SQL Injection attacks which hit the news this year.

As you can see from the chart below, SQL Injection was the third most widespread web vulnerability in 2008, according to The Web Application Security Consortium (WASC).

In February a group of Romanian hackers in separate incidents allegedly broke into Kaspersky, F-Secure, and Bit-Defender.pt websites by use of SQL Injection attacks. All three companies are major brands in the security and antivirus market. All three attacks were relatively trivial to carry out, however gave the hacker known as ‘unu’ access to F-Secure’s virus statistics, Kaspersky’s entire database which consisted of users, activation codes, a list of bugs and Bit-Defender’s thousands of user email addresses, admin login credentials and customers personal information.

The Kaspersky SQL Injection attack URL would have looked something like this:

http://usa.kaspersky.com/support/home/208280433/?UniOn%20SelECT%201,concat_ws(0x3a,version(),host,user),3,4 ; —

As we can see from the above (guess-estimation) ‘unu’ used a mixture of upper case and lower case characters in order to circumvent any blacklist keyword filtering and he also used the concat_ws() MySQL 5.0 string function to concatenate (with a separator) his query. The above query output the MySQL version, the server hostname and the SA username.

After looking at screenshots of all three alleged security breaches, the attacks were trivial and could have been circumvented by simple input sanitisation on variables which were passed to the back end database. The Romanian hacker ‘unu’ went on to allegedly hacking many other high profile websites such as RBS WorldPay, CNET.com, BT.com, Tiscali.co.uk, national-lottery.co.uk and others. I tried to contact ‘unu’ to ask him some questions for this article, but I never heard anything back from him.  He has now shut down his personal blog (paranoid? understandable).

Ever signed up to a jobs web site in the expectation of landing that dream job and then being contacted by the site to say that all your personal information including, job applications, CV’s and covering letters have fallen into the hands of a malicious user? If so, then you must be one of Guardian Job’s half a million users who received that very email just a few weeks ago. The Guardian Jobs website uses a third party (Madgex) to store their job seekers data. Apparently the website was compromised due to a ‘sophisticated’ and targeted attack (SQL Injection suspected) on the 23^rd of October. We would love to talk about the nitty gritty of how this attack happened however according to the Guardian “The police remain anxious to keep information about the apparent theft to a minimum”. I speculate (which one should never do) that simple input sanitisation could have avoided it, yet again.

Jon Hickman a user of the Guardian Jobs website says:

“I was surprised that this incident has passed with so little comment. Guardian Jobs must have many thousands of members, and this security breach could be effecting them all in a very real way, yet I haven’t seen much in the way of a backlash.” http://jonhickman.posterous.com/we-work-for-them

PayChoice Inc., one of America’s largest payroll organisations with 125,000 business customers relying on their payroll services, were the victim of two separate SQL Injection attacks in a short period of time. PayChoice have subsequently shut down their online portal all together because of the attacks. The SQL Injection vulnerability itself was in the password reset function on one of their login pages. It is quite common for developers to go all out in securing their main login functionality and forgetting all about the “forgot/change password” functionality.

If we take look at the following example:

SELECT *

FROM users

WHERE email = ‘1’ OR name LIKE ‘%John%’;

The above SQL Injection attack acts like a mini search engine, looking for a user in the database with the name field LIKE ‘John’. If the above SQL Injection attack was used in a change password function on a login page and the database contained a user called John the website would output a successful message, something along the lines of “Your password has been sent to john@john.com” giving us a valid user and their email address to carry out further injections or other attacks.

SQL Injection has been a big headache to many organisations throughout 2009, and will likely still be a headache for the foreseeable future. The countermeasures are out there, use them!