Defense in Depth

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.

Progress was made Monday in mitigating thousands of SQL-based Web sites injected with malicious Javascript code. However, one security expert says we can expect more such attacks in the near future.

A traditional SQL injection attack allows malicious attackers to execute commands on an application's database by injecting executable code. "What's different about this latest attack is the size and the level of sophistication," said Jeremiah Grossman, CTO of WhiteHat Security.

On Monday, CNET found a few sites still infected with the latest SQL-injection attack.

In the past, attackers have gone after a small niche of the Internet--say travel sites or sports sites--but with this latest attack, attackers have a generic way to blast the Internet, and they've chosen to attack sites running MS-SQL.

On Friday, Microsoft denied that new vulnerabilities within Internet Information Services are to blame for a rash of Web site defacements. Microsoft insists it's the application developer's responsibility to follow the company's best practices. These include constraining and sanitizing input data, using type-safe SQL parameters for data access, and restricting account permissions in the database.

Grossman agreed it's not Microsoft's fault, and said the attacks could have easily targeted another vendor's software. If users surf to an SQL-injected site, their browser 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 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.

"It's said that the attacks never get worse, they only get better," Grossman said. But in terms of the good guys closing the gap with the attackers, he remains optimistic. He said with more diligence and more care, we can protect Web sites from these attacks.

Want to cause trouble at RSA? Register with any of a number of special characters in your name or business name and watch the badge printer issue blanks. That's what happened to me.

Monday morning when I registered for RSA 2008 (where I'll be speaking with Chris Boyd of FaceTime), I thought maybe I'd get a little VIP service. (Our talk on "How to Adapt to the Echo Generation's Social Media Hacking Game" is at 9:10 a.m. PDT on Thursday.) Instead, I was stuck in various registration lines for more than half an hour until the lone IT guy realized the system wasn't handling special characters in my company's name. In other words, the registration at RSA could be vulnerable to SQL injections, where special characters cause the database system to behave differently.

After typing in my name and confirming my registration at the little kiosk near the door, I walked over to the printer desk, where I should have had my badge waiting. Instead, the first badge came out blank. As did the next, and the next after that. For the next 20 minutes, as different desk clerks tried to help me, there were about a dozen attempts to print out my badge--all blank. Apparently there's only one IT guy and he immediately realized that whoever registered me as a speaker used the pipe character in CNET, a style we stopped using years ago. The pipe character in most SQL systems is used to indicate a concatenation.

But I'm not alone. Security researcher Adam J. O'Donnell reports that even the apostrophe in his last name caused the system to bonk. O'Donnell humorously (or maybe not) adds that "RSA is attempting to segregate out the Irish without posting an 'Irish Need Not Apply' sign."

Are there any other special character examples from RSA 2008 attendees? Post a note below.

On Monday, Adobe Systems rolled out its new Web 2.0 development tool, Adobe Integrated Runtime, or AIR. Following its release were some concerns from the security community.

Adobe CEO Shantanu Narayen talks up AIR at a San Francisco event.

(Credit: Charles Cooper/CNET News.com)

AIR, formerly Adobe Apollo, is a runtime environment that allows developers use HTML, Flash, AJAX, Flex, and other Web 2.0 tools to create desktop applications. One such application built using Adobe AIR comes from Nickelodeon Online.

But some security experts are concerned about local file access by AIR applications. Recently, Firefox experienced a vulnerability that could have allowed remote attackers to access a targeted file system. To mitigate this, Adobe says it implemented a sandboxing environment, however, Adobe's documentation suggests that the sandboxes are less secure than a Web browser's sandbox.

Additionally, Adobe says that AIR applications need to be digitally signed, however, these certificates can be self-signed. And many users will ignore the warnings and run untrusted applications.

Finally, there is the potential for Cross-Site Scripting (XSS), SQL injection, and local link injection. While these threats are not limited to Adobe AIR, developers could gain a false sense of security by relying only on AIR's weaker sandbox protection.

Adobe has also provided the following: an informative article titled "Introduction to AIR security" and a white paper, "AIR Security" (PDF). But Lenny Zeltser, writing on the Sans Internet Storm Center site, notes that "many developers will be unaware of Adobe AIR security best practices or will knowingly take shortcuts that expose end users to attacks."

On Wednesday, the SANS Internet Storm Center and others published details about the massive SQL-based Web attack that occurred over the weekend. The attack, says SANS, is similar to a smaller SQL-injection attack seen in November. At least 70,000 sites were compromised in a short period of time, leading some to speculate this was an automated attack.

From logs files, the attack code appears to exploit a variety of SQL injection vulnerabilities existing on Web sites using Microsoft SQL or Microsoft IIS. On the vulnerable sites, malicious JavaScript is injected into all variable character fields and text fields in the SQL database such that when visitors hit the site, their browsers, if vulnerable, are then redirected to another domain--in this case, us8010.com.

Roger Thompson, chief research officer at Grisoft, identified one of the exploits served at the malicious server as taking advantage of MS06-014, a Microsoft Data Access Components vulnerability that Microsoft patched in September 2006. He also noted that "this domain uc8010(dot)com was registered just a few days ago (Dec 28), and yet, at one point Google showed script injections pointing to it were showing up on over 70k domains." Yet by January 5, most of these domains had already been cleaned.

What's interesting about this attack, aside from its automation, is that the SQL injection script is given in terms of a CAST statement, code that converts one data type to another. Ryan Barnett has provided a decoded version of this attack.

Barnett suggests that to protect against this attack a Web site should be front-ended by an Apache proxy and then back-ended by ISS or MS-SQL. SANS says other methods, such as blocking CAST statements, would also be effective.