SQL Injection attacks now on industrial scale

SQL Injection attacks are old school and well known. How well known? Well, check out popular web comic xkcd http://xkcd.com/327/

So, if they are that well known, there can’t be a problem with them any more because people will have protected themselves against them, yes? Uh, not so much. The pace is increasing but the patterns are changing. Let us look at an old school SQL injection attack and a currently popular one. Oh, I will be discusses some specifics of how they are done because the information is already widely known and it would be shutting the stable door after the horse has bolted if I skipped those.

Old School

A hacker injects some SQL into a text field on a website – or sometimes into the URL. You don’t see websites that pass the SQL as part of the URL any more but it was very obvious that they would be subject to abuse. There were a number of quick and dirty solutions to this. Some were better than others. One cheap technique was to put the whole site in a frame so that the user doesn’t get to see the URL. That works fine for an average user but when there are tools like the excellent Fiddler (http://www.fiddlertool.com/Fiddler/help/hookup.asp) about, that won’t help. A lot of sites use hidden text fields – these show up just fine as well. Anyway, there are a number of ways of spying on the HTTP traffic. Most of the time, this is necessary and you can just type the SQL directly into a text field on the form and that is what the old school script kiddie did.

They would then tag (deface) the web pages it they were doing it for bragging rights or if they were looking to steal, they would either write SQL to dump out tables full of valuable data or sometimes they would look for a helpful stored procedure to get them to a command shell. Once you had a command shell, a remote admin tool would be uploaded to the site and the hacker would have a nice high rights account to play with. Data theft was the most common motivation.

New School

In the classic old school approach, the hackers would find individual sites and pick away at them. It was craftsmanship in a way. Ok, a grotty and illegal way but craftsmanship all the same. When organised crime got in on the act, they didn’t like the slow, handpicked approach. They embraced new tools such as Goolag scanner (http://www.goolag.org/) There isn’t actually all that much to the Goolag scanner. All it does is perform custom searches on Google for vulnerable versions of software running on servers. You could do the same thing from a browser window but the scanner automates the process and saves a lot of time when looking for websites to hit. This tool was brought to the world by the Cult of the dead cow, a very well known group that did some seminal work on breaking the codes that protect nominally secure transactions on the web. Anyhow, the Goolag tool gives an automated way of finding sites to attack. Point it at a top level domain, tell it what sort of vulnerability to look for and let it run.

So, this gives the hacker a slowly growing list of websites that will be vulnerable. Only it isn’t “the hacker” any more. 16 year old script kiddies are the exception rather than the rule these days. There are a few lone wolves out there but more commonly, there will be a team of moderately skilled individuals working for a technical lead of some sort. They seem to mainly work from a set of written instructions and don’t show a great deal of variance form a standard procedure. That said, you do sometimes find a bright one and I suspect that is when their technical lead has become involved.
These commercial hackers want to find the vulnerable servers for a different reason to the average script kiddie. They want to change the content of your website to run exploits against your clients to install malware on their PCs. This generally works well if your customers are often unpatched – and in real life, that is the most normal case. What if they are patched? Your user knows your web site and trusts your company. If they can’t be exploited because they are well patched, they are still likely to install a component if your company’s website asks them to.

So, if you don’t protect against SQL injection attacks, are you putting your customers at risk? Yes, you surely are. Does that mean that your own servers are not at risk? Nope, far from it. There is nothing to stop the server being a host for malware while its data is harvested. They can get you coming and going. Why do they do it? Because it is their job.

Can you protect against this? Well, yes you can. I will be talking about how in my next blog entry.

By the way, when this particular xkcd comic came out, a lot of people sent it to me unbidden: http://www.xkcd.com/350/ I had to smile

Signing off

Mark Long, Digital Looking Glass