Michael Howard on SQL Injection and my concerns on the most recent attacks

So, in catching up with blogs after vacation, I went and had a peak at Michael Howard's web log, and was glad to see another post from him.  His posts are very insightful (I just wish he would post more).  So, way back on May 16th (old news now, but still interesting) Michael commented on the recent rash of SQL Injections, and he made some excellent points, especially about how to prevent these types of issues.  Michael mentioned: 

You may have read recently about a large number of Web serversthat were compromised through a SQL injection attack. The malicious SQL payload is very well designed, somewhat database schema agnostic and generic  so it could compromise as many database servers as possible. While the attack was a SQL injection attack that attacked and compromised back-end databases courtesy of vulnerable Web pages, from a user's perspective the real attack was compromised Web pages that serve up malware to attack user's through their browsers. In essence, there were two sets of victims: the Web site operators and the users who visited the affected Web sites. In this post, I want to focus on what the first set of users, the Web site operators, can do to protect themselves.

The fact that the malicious payload was so generic shows that the science of SQL injection has not taken a back seat to research in other vulnerability types, such as buffer overflows or cross-site scripting issues.

I think the first lesson from this attack is this:

If you have a Web server (doesn't matter what type), and it's hooked up to a database (doesn't matter what type) you need to go in and review your code that performs the database work.

This is a great point which may have been missed.  While this attack was targeted at IIS and Microsoft SQL server databases, SQL injections are an issue on all platforms.  Michael has some great steps on how to shore this up:

So now that you've determined the database access code, now what? The SDL is very specific about what do here, there are three requirements - they are requirements not recommendations, which means you must do the following coding requirements and defenses

• Use SQL Parameterized Queries
• Use Stored Procedures
• Use SQL Execute-only Permission

I'll link to his blog for the detailed breakdown of all of those defenses, it's a nice reference.

What concerns me most about this attack is that everyone is talking about the proliferation of malware through this attack, through the use of UPDATE commands, but I haven't seen much discussion about exfiltration of the data on these database servers, which almost certainly would've been possible for these attackers.  Further, they could've selectively been stealing this data and using the malware as a smoke screen for that activity.  If you were hacked by this attack, I think you need to assume your data was exfiltrated unless you have logs supporting that it was not (even then I'd be cautious).

-Nate

[poll id=5]

[poll id=6]