Anti-virus Vendors Succumbing to SQL Injection

Posted by Gunter Ollmann on February 12, 2009 at 11:51 AM EST.

It’s been an interesting week for anti-virus software vendors. Over the weekend both Kaspersky and BitDefender had Web sites attacked and successfully compromised through SQL Injection, and yesterday F-Secure fell to the same vector.

I posted a couple of short blogs about the Kaspersky and BitDefender attacks earlier this week with my original thoughts, but figured it would be valuable to readers to follow up here on the Frequency-X blog following yesterdays F-Secure attack.

While there’s been a fair amount of press and blogging about the topic of SQL Injection attacks – it’s interesting to me the general attitude of those commenting. In general the attitudes can be divided in to two types:

1. "This is an old threat, and these security vendors should know better"
2. "SQL Injection is impossible to protect against"

Yes, SQL Injection is an old attack vector, but it’s also a very difficult threat to protect against in reality. Sure, if you have a “dumb” brochure-ware Web site, you’re unlikely to be relying upon interactive backend systems and databases - but practically every interactive site on the Web today ceased to function that way quite a few years back.

Ideally all data is sanitized before being passed from the Web application to the backend database, but in practice it’s not as easy as it sounds. Today’s Web applications are increasingly complex – particularly the commercial sites of software vendors that have to deal with purchases, updates, helpdesk, bug submissions, data streaming, etc. – and the actual code powering the Web application can best be summarized as “federated”. It’s actually more of an art form than a consistent methodology in securing sites against SQL Injection – and it’s further complicated by the ongoing changes to the federated code.

On the other hand, if you want to, you can stop SQL Injection attacks dead. The technology exists to do that – however, it does have ramifications for Web application design which most Web design and usability teams are unwilling to concede. Perhaps high-profile attacks like the three this week will have other executive teams reevaluating the costs to brand and consumer trust.

As a consequence, SQL Injection attacks have become a preferred vector for attack. The recently released X-Force 2008 Threat Report has tracked these attack trends, and you’ll see a depiction below:

There are a couple of major reasons for why I believe SQL Injection has been on the rise:

1. While Cross-site Scripting (XSS) is much easier to conduct and more common within Web applications, it is not as valuable to criminal attackers. SQL Injection can allow data retrieval and modification at the server-side, while XSS is largely bothersome to the client-side. As such SQL Injection can be used by criminals to propagate other more lucrative attacks (e.g. drive-by-downloads) or extract value directly from the saleable data pilfered from the vulnerable Web site.
2. A new generation of automated tools have appeared over the last 2 years that specialized in SQL Injection. They are capable of performing thousands of attacks per minute and some make use of popular search engines to identify likely vulnerable sites before they even start (thereby reducing “lost time” trying to crack sites and pages not supported by backend databases).

To get a better feel for the scope of the attack vector, below is another graph taken from the recent report depicting the volumes of SQL Injection attacks observed by IBM’s Managed Security Services teams:

Will other security vendor Web sites get compromised through SQL Injection in the future even after learning of these recent attacks? Yes, more than likely. It’s the nature of the world we now live in.

With that in mind though, what I’ve found amusing with some of the vendor responses to the attacks has been the way that – even after admitting that the SQL Injection attacks had been successful, and the public availability of screenshots – they claim that system integrity wasn’t breached, no confidential information would have been leaked, and no consumer was at risk. What a load of rubbish. Sure, they’re trying to restore confidence to their customers, but frankly I think they’d regain customer confidence faster if they were more truthful and helped educate their customers about the evolving threat.

Could one of IBM’s Web sites be vulnerable to SQL Injection? I have very little doubt that there are more than several similar vulnerabilities awaiting discovery. IBM literally has thousands of public facing Internet sites – running more code developed by internal resources and third-parties than you can probably imagine. It is inevitable that such flaws exist within some of the code pushed out daily and, for precisely the same reasons I mentioned before, they’ll likely reappear time and again even after detection and remediation by our internal QA and pentest teams. My hope is that IBM internal teams discover and remediate them faster than external “bedroom security warriors” stagger across them and that we’re a little more honest about the reality of the threat.

If you’re interested in more information about the attacks and viewing a handful of screenshots depicting the outcome of the SQL Injection attacks this week, evidence can be found over at Hackersblog.