SQL Injection

There's a 'bug' going around.  You might have heard of it- it infected more than 1/2 million sites.  I actually saw this particular attack before it hit the press, as one of the effected admins was posting questions about it on a tech support forum I frequent.  It's really just a run of the mill SQL injection attack and I've seen the raw SQL code.  While I'm not impressed with it's quality it was certainly effective enough.  At the time I just didn't realize the significance.  I want to make a few comments on the attack, and then I'm done.

The attack targets Microsoft's IIS+ASP+SQL Server combination, but it's not taking advantage of any specific security vulnerability in Microsoft's software.  It's really not Microsoft's fault.  I've seen a few people scoff at that, but it's true.  The attack could just as easily have targeted Apache+PHP+MySQL, and some 'experts' are expecting a MySQL enabled version of the attack to go out soon.  If you run a web site, the good news is that if you're doing even the most basic field validation you'll be fine.  The only thing to blame here is bad coding in the web sites.  To be fair I suppose there are some sites that have been running for longer than SQL injection has been a problem, but they'll be a very small minority.  The moral of the story here is always sanitize your database inputs!  This is database programming 101.  You shouldn't be able to get a programming job if you don't know how to do that, and I mean it.  If you already have a programming job and don't know how to filter your inputs for SQL injection, STOP RIGHT NOW, GO CHECK GOOGLE, AND FIND OUT!  Yes, that's right;  I'm yelling at you; you deserve it.  This is kindergarten stuff (obligatory xkcd reference).

Since I called out the quality of the code for an obviously very successful attack I need to back that up, so here's my analysis.  When you look at the code, everything is scrunched up on one line.  The author uses single letter variables and other tricks to minimize the size of the code.  That's not the bad part.  There's a good reason for this: the code has to be passed in through form fields, and form fields are often validated first by the length of the text passed.  Even if you don't validate anything else (and the attack relies on that completely, as I've explained), you might do this.  By reducing the size of the code the author increases the potential number of vulnerable sites.  Unfortunately, he uses a long name for one important variable, resulting in extra bytes that are repeated several times.  He also misses an easy trick to reduce his code size and takes the time to close and deallocate a cursor.  By fixing these issues he could have saved more than 100 bytes, or reduced his code size by more than 20 percent.  Finally, in closing the cursor he made his code less successful and more open to detection.  If he leaves the cursor open subsequent calls to his same procedure would fail.  Because he closes it, they succeed.  I know that several sites were only aware of the breach because of the load this procedure placed on their system when running repeatedly.  Leaving the cursor open, while normally poor practice, would have been the better choice here.  Not only that, but the attacker's system was unprepared for the resulting load.  The javascript target of the attack was unavailable for several days because so many sites were hit it couldn't keep up.

Moving on.  As I've already said, this attack succeeded at more than 1/2 million web sites.  Nearly all of these sites are perfectly legitimate, and odds are you visited one or know someone else who has.  That's where the problem comes in.  See, while the attack initially targets web sites those sites are only a means to an end.  The real target here is you.  When you visit any of these sites code will run that will try to install bad things on your computer.  Your anti-virus software might stop it, but then again it might not.  Are you sure it's up to date?  Are you sure it knows to check for this particular set of malware?  You might only get a pop-up asking if you really want to continue before installing something bad.  And this is a legitimate site.  It might even belong to a church, government, or charitable organization.  So of course you trust the site?  Or maybe you've already trusted the site by accepting a 'certificate'. 

In any of these cases your computer is turned into what is known as as zombie, and that means several things.  It means the attacker can come back at his leisure and try to copy passwords, bank account information, identity information and other things from your computer.  It also means your computer is now part of an invisible army the attacker can use to conduct denial of service attacks, send spam, crack captchas, or crack encrypted data.  Your computer doesn't fully belong to just you any more, and you didn't even do anything wrong.

That's bad enough it has me re-thinking my previous decision to run without virus protection, which I finally put into practice when I re-installed my operating system last week.  Even if you follow good computer practices, only visit reputable web sites, and have your system fully patched, you could be vulnerable to this attack.  Currenly, my only layer of defense is the built-in Windows Defender, and that's not much.  As weak as many current anti-virus programs are, at least it's something.  I also typically use Firefox with the NoScript extension, but I don't always have the luxury of surfing in Firefox.