Skeleton key unlocks Microsoft SQL servers in latest Web attack

Last week on my Security Bites podcast I talked with Jeremiah Grossman, CTO of WhiteHat Security, about the recent spate of SQL injections affecting Microsoft SQL.

Grossman said that if users surf to an SQL-injected site, their browsers will attempt to download a variety of exploits, not all of which are Microsoft-based. One site from the Shadowserver Foundation lists exploits affecting Real and other vendors alongside various Microsoft Security bulletins. Grossman also said that just turning off Javascript won't necessarily protect end users from this latest round of attacks since the attackers can use traditional HTML as well.

Below is a transcript of part of my interview. The entire podcast can be heard here.

Me: Why don't you walk me through what a traditional SQL attack looks like.

Jeremiah Grossman: A traditional SQL injection usually starts off with a bad guy looking at your Web site (and) finding a spot in the Web site like a URL parameter that takes in some user supply data and constructs the database statement out of it. So a login form, user name and password fields, search fields are all possible. What a bad guy will do to test the vulnerability is to throw in some meta characters like a single tag or a semicolon into the input of the Web site. If the Web site doesn't properly handle these characters you'll get a database exception error message and they'll say things like ODBC error messages and some weird error codes and this...gives an indication of that the site is vulnerable to SQL injection.

Now what the bad guy can do is take the next step. Since this data is going in and becoming part of an SQL statement they could add additional characters, additional statements and try to construct a database statement that's different than what the Web developer intended to maybe pull data out of the database, instead of, "Log this user in," it's "Get all credit card numbers from the database or drop table" and things like that. So usually in SQL injection the attack is for this particular Web site, for that particular vulnerability; each one is custom.

Me: So they're using the browser. We're not talking about a command line attack. We're talking about using any browser to go in and modify a vulnerable Web site.

Grossman: That's correct. Usually vulnerabilities are found and often exploited, you know, using a browser. There are some good attack tools out there...that will aid a penetration tester or a bad guy to extract large volumes of data out of the database. But if you're just looking to exploit one Web site, one at a time, you don't really care about all the data. You just want to put something in there. A browser will do just fine.

Me: Now what is different about this SQL injection attack? We have had them before, but this one is getting a lot of press.

Grossman: There are two things that are pretty interesting about this one. It's the size of the incident, like how many sites have been infected with this exploit, and two it's the sophistication level of it. So like before, each Web site with an SQL injection vulnerability was usually custom. They're exploited in a custom way, so there's really no way to create a massive Web attack.

In this case what the bad guys did is figure out a way to target MS SQL server specifically on creating a generic type of SQL injection exploit that they fire off against, well that's probably millions of Web sites at this point and they've actually been able to get a pretty high success rate on sites that they've SQL injected. So the way they work is they send their exploit code into a parameter field just like in a normal SQL injection and they load the Web site out with some JavaScript malware. They then get the skeleton key to an SQL injection exploit that will compromise all these Web sites.

I think the numbers are usually in the hundreds of thousands of infected pages now. Should a user come across these infected Web pages their browser can and has been and will be exploited with Trojan horses and other malicious codes like that.

Me: Microsoft is denying that there are any new vulnerabilities. Any truth to that?

Grossman: I agree, this actually is not a clinical vulnerability in MS SQL server, but it is directly targeted at MS SQL server. So the way this exploit works...it sends multiple commands to the database as a single statement. So they'll tell the database to do several things in order with one request. If you try to send the same command to other databases like MySQL, it won't work. So the bad guys are leveraging a feature of the database, not necessarily the vulnerability. So they're right, it's not a new vulnerability, but it is a feature that the bad guys are leveraging.

Me: Is there any evidence that there is definitely a tool kit that's doing this? Obviously it is automated since it infects a million sites in a very short period of time?

Grossman: No, I've not seen a tool kit. We've only been able to look at the gravity of the attack by actually measuring the number of affected pages using search engines like Google and Yahoo that are indexing these sites. It's yeah, it's definitely obvious that they're using tools to infect all these Web sites, you couldn't do it all by hand. Is the tool kit is publicly available? Probably not. They'll probably keep it to themselves.

Me: I've heard this attack described as severe. How dangerous is this attack to the end user?

Grossman: It's really, really dangerous to the end user because we're talking about legitimate Web sites hosting malicious content that will impact their users. We're talking the sites by the Department of Homeland Security, by the United Nations, and many, many other legitimate Web sites. These are phishing clone look-alike Web sites that the users have to watch out for. Now these are real live legitimate Web sites that can infect your browser so it's really bad.

Where it gets worse is it's going to be the cleanup effort. The cleanup after this compromise it's going to require database administrators going back to their database and manually pulling out the infected database tables or reverting to a back up. Either way it's going to take days, weeks, and possibly months to actually clean up the code.

Me: Is there anything preventative that database administrators can do? Microsoft's recommending a series of best practices such as validated user input and restricting account permissions to the database.

Grossman: That's correct. That's actually probably the best approach. That's not a database security precaution, that's a programmatic database precaution, something the developer must do and that's actually the challenge in our industry. There is actually so many vulnerabilities across the range in Web sites now. White Hat releases reports on these every quarter, but there are so many vulnerabilities now that we have to start looking in the code. So, you know, we recommended a two-pronged plan. One is, take those recommendations that Microsoft and many others have put out and say, "We're going to start writing code now that is secure or more secure than it was before."

From White Hat's perspective, the Web sites are already out there. It's going to be very difficult to go back in these millions and millions of Web sites to find the vulnerabilities and fix them. That's why we're actually partnering up with Web applications firewall vendors. So when vulnerabilities are found through our service, what we call Sentinel, they can be put into a Web application firewall that's specially built to look at these types of attacks and block those attacks to the site that's known to be vulnerable, a virtual patch if you will.

[Pete Bardo]

Typical Microsoft response to a problem, "That's not a bug, it's a feature!" They've been saying this for a few decades now--before internet, even before Windows!

But, really, web developers have to take some of the blame here. Saving data from an unknown source without validating or scrubbing? Who does that and why? Lazy programmers do it because, well, they're lazy. I happen to be one of the laziest programmers I know, but even I validate user input before saving it. I remove any and all javascript and in most cases remove all html code that could be harmful.

Oh, btw, I stopped using MS SQL several years back when mySql became a reasonable alternative. It may not be vulnerable to the same kind of injection, but I still validate and scrub all data before saving it to a database.

[Pete Bardo]

Typical Microsoft response to a problem, "That's not a bug, it's a feature!" They've been saying this for a few decades now--before internet, even before Windows!

But, really, web developers have to take some of the blame here. Saving data from an unknown source without validating or scrubbing? Who does that and why? Lazy programmers do it because, well, they're lazy. I happen to be one of the laziest programmers I know, but even I validate user input before saving it. I remove any and all javascript and in most cases remove all html code that could be harmful.

Oh, btw, I stopped using MS SQL several years back when mySql became a reasonable alternative. It may not be vulnerable to the same kind of injection, but I still validate and scrub all data before saving it to a database.

[Pixelslave]

I am continuously amazed by comments like the one above. After reading the whole comment and the article, it's fair to say that MS bashing in this case is just ... MS bashing. Even WhiteHat's CTO agreed that it's a feature -- what's the point of saying "Typical Microsoft response to a problem, 'That's not a bug, it's a feature!'"?

[gbrayjr]

Yeah, let's blame it all on Microsoft!!! Does the author and the rest of the world realize that half-decent entry-level coding practices can completely prevent this? Hmm.. probably. But that would mean passing on an opportunity to bash Microsoft and actually show some objectivity. Oh wait a minute... this is CNet... Yeah, it's an extra step to write sensible secure code. But let's just keep blindly blame Microsoft while we don't bother to validate our input before passing it off to our database. People get the internet they deserve...

[mighty_max_3]

also javascript and html are used in xss attacks and not sql inject attacks as the syntax is completely different for these attacks. Also no db software is inheriently secure. This attack may not work in MySql but that's not to say that MySql can't be sql injected as this comes from user commands originating from the code the programmer wrote.