An article appeared in Phrack magazine 11 years ago that discussed a problem that remains a security headache to this day — SQL injection.
That article, which came out on Christmas Day 1998, is believed to have been the first publicized mention of SQL injection. It is fitting, then, that as Christmas approaches we take time out to look at how the attack has evolved over the years. I discussed the topic today with Tom Cross, manager of IBM X-Force Research, and couldn’t help but walk away with the thought that Web application security needs to be at the forefront of more people’s minds as we enter 2010.
“This vulnerability has been around for 11 years now,” Cross said. “[But] it’s been in the last year, year and a half … [that] computer criminals have figured out how to leverage it broadly to essentially steal money. We’ve seen this massive increase in SQL injection as an attack technique during that time.”
By massive, here is what he means: This past summer, IBM X-Force was seeing 600,000 SQL injection events per day. In May 2008, that number was 5,000.
“What’s happened is that there is a bunch of attackers using automated tools … to do SQL injection on a broad basis across any Website they can find that’s vulnerable,” he explained. “What they want to do is they want to inject HTML that will redirect users of that Web page … to an exploit tool kit. Basically these guys are running exploit tool kits and they want to direct traffic to it and they want to leverage the traffic that’s coming to legitimate Websites and they use SQL injection to do it.”
SQL injection has also been at the center of some of the most well-publicized data breaches, including the one at Heartland Payment Systems. Recently, I did a short list of tips for avoiding SQL injection vulnerabilities. But many organizations, Cross pointed out, have trouble addressing vulnerabilities in their code.
The reason why is not especially shocking. For one thing, many Web app developers are focused first on making sure the applications provide a good user experience, he said. In addition, vulnerabilities slip through even at the largest, most sophisticated organizations, so it shouldn’t be surprising that organizations with fewer resources have vulnerabilities in their custom applications, he said.
There is some good news, though. According to Cross, while the volume of SQL injection attacks went up, the overall number of SQL injection vulnerabilities declined in the first half of 2009 — suggesting that organizations are taking the problem seriously.
Solving these problems depends on a layered approach, a combination of making sure Web applications go through a sound quality assurance process and monitoring Web app traffic for malicious activity. Also, give the database administrator a seat at the table, Cross said.
“There are a lot of features in most modern database software products that either A) can be abused to potentially get remote code execution on the underlying database or B) can be used to protect the database for that kind of attack, and it’s all about how well the database is configured,” he noted.
“So ask your DBA, What security features does he have in place? Has he disabled some of these code execution stored procedures? How well patched [and] up-to-date is your database software? … Really, the right prescription for locking a database down is heavily dependent upon the database software in question. It’s really a matter of what database you’re using, what features it has, and how well you are using those features and how tight your processes are in terms of managing that database.”
