I got a first hand taste of some of the new “mass infection” SQL injectors that have been running around since April of this year, when I was asked to do an incident response for a friend of mine today. The funny thing is that the injector tool is seeding links to hostile code at a web site that has been taken down a long time ago — more of the automated zombies on the internet continuing to spew long after their venom has been removed.
The really interesting part about this beastie is the “trick” used to encode the SQL query here. There is a T-SQL function (at least in MS SQL, can’t speak to the others out there) called CAST — and it is specifically used to convert a wide variety of characters into long integers or hex. This is a good argument for never trying to black list, as the entirety of the query is hidden from anything that might be looking for “<script>” or the like.
The quick fix here is parameterized queries, or not letting the semicolon through — this exploit only works on sites that do dynamic SQL, and does the traditional trick of appending additional commands at the end of the legitimate SQL. However, if you do have dynamic SQL, and you are not blocking very tightly on your input validation, this puppy is going to slide right on through. I believe the site in question may have actually allowed for appended queries, though I am not sure, as the developers said they had an input validation filter appropriate to the application in place (I didn’t get to see enough of it to confirm it was working right though).
Johannes Ullrich of SANS explains it far better than I ever could in a recent ISC post here. But if you want to read on of my own bumblings:
(more…)