Massive SQL injection attack making the rounds—694K URLs so far

Hundreds of thousands of pages have been modified to include malicious …

Hundreds of thousands of URLs have been compromised—at the time of writing, 694,000—in an enormous and indiscriminate SQL injection attack. The attack has modified text stored in databases, with the result that pages served up by the attacked systems include within each page one or more references to a particular JavaScript file.

The attack appears to be indiscriminate in its targets, with compromised machines running ASP, ASP.NET, ColdFusion, JSP, and PHP, and no doubt others. SQL injection attacks, which exploit badly-written Web applications to directly perform actions against databases, are largely independent of the technology used to develop the applications themselves: the programming errors that allow SQL injection can be made in virtually any language. The underlying cause is a programmer trusting input that comes from a Web page—either a value from a form, or a parameter in a URL—and passing this input directly into the database. If the input is malformed in a particular way, the result is that the database will run code of the attacker's choosing.

In this case, the injected SQL is simply updating text fields within the database, to make them include an extra fragment of HTML. This HTML in turn loads a JavaScript from a remote server, typically "http://lizamoon.com/ur.php" or more recently, "http://alisa-carter.com/ur.php." Both domain names resolve to the same IP address, and presently that server is not functional, leaving browsers unable to load the malicious script when they visit infected pages. Previously, it contained a simple script to redirect users to a fake anti-virus site.

The massive scale of these attacks (and the rapidly growing number of affected URLs) was first noticed by Websense Security Labs. On Tuesday, around 28,000 URLs were compromised; now more than 20 times more URLs are infected, and the numbers are still growing.

The injected code is also found on a number of product pages on Apple's iTunes Store. Apple fetches RSS feeds from podcasters that broadcast using iTunes, and in a number of cases these broadcasters have been compromised by the SQL injection attack. As a result, the malicious code has made its way into Apple's system. However, due to the way Apple processes the RSS feeds, there appears to be no exploitation vector; the injected HTML is safely nullified.

SQL injections following this pattern appear to have been happening off and on for six or more months now. The domain name hosting the JavaScript changes each time, but the file name—ur.php—and the style of injection remain consistent. The actions of the scripts have been similar too; pop-up windows and malware downloads. Previous efforts were on a much smaller scale, however: hundreds of compromised URLs instead of hundreds of thousands. In these earlier cases, the attacks originated from IP addresses in eastern Europe and Russia.

It's been a busy week for SQL injection; at the weekend, MySQL.com, the website of Oracle-owned open source database MySQL, was hacked, again using SQL injection. A little embarrassing for a database vendor to be unable to use its own database securely.

While I generally understand the article, I'm not sure I get what this means for end users. Are passwords/personal information compromised? If so, is there a list of sites effected? Should I panic and run screaming up and down the hallway of my apartment building?

While I generally understand the article, I'm not sure I get what this means for end users. Are passwords/personal information compromised? If so, is there a list of sites effected? Should I panic and run screaming up and down the hallway of my apartment building?

It's most likely small sites, though 694,000 URLs is a lot. It looks like they weren't after usernames /passwords.

The article sounds rather incomplete frankly. SQL injection requires some assumption of field names, or db schema. How did they nail so many sites indiscriminately without targeting a particular framework?

While I generally understand the article, I'm not sure I get what this means for end users. Are passwords/personal information compromised? If so, is there a list of sites effected? Should I panic and run screaming up and down the hallway of my apartment building?

To be honest, with the site hosting the malicious script down, it's a bit hard to say. It would be very possible for that site to host a browser-based exploit, for example, which would mean that there's a hell of a lot of Web pages that would become malicious. But at the moment, it's effectively harmless.

Yet another reason why having SQL statements anywhere but in the DB is a Bad Idea.

While not bulletproof, parameterized stored procedures eliminate much of this threat. (And they usually perform better!)

Schools (and tutorials and such) shouldn't even bother showing how to construct the full statement yourself, parameterized should be the way people are shown (it's better for a large number of reasons, including avoiding a lot of cases of string manipulation).

As far as I know, that'd completely kill off this class of attack. You'd still need to sanitize your inputs, but just to avoid users inputting HTML/javascript code... which, at the very least, won't leave the DB itself vulnerable.

The article sounds rather incomplete frankly. SQL injection requires some assumption of field names, or db schema. How did they nail so many sites indiscriminately without targeting a particular framework?

What he said. Peter, go back and finish the article.

In order for this story to be true, the affected sites must all be running the same underlying application. The real story here is 'Which common framework has such a vulnerability?'

The article sounds rather incomplete frankly. SQL injection requires some assumption of field names, or db schema. How did they nail so many sites indiscriminately without targeting a particular framework?

Not this class of attack - all that is needed is for a site to not properly santize the database inputs - then the URL of the Javascript will be passed into the database by the site's own scripts, and happily pull it out again for display without ever realising there's a problem.

this is why all database calls should rely on at the very least a POST variable...otherwise Bobby wins

Obscuring query string values behind a POST when you should simply be GET'ing only complicates your website architecture and adds absolutely no security. Sniffing and sending arbitrary POST values is trivial.

The article sounds rather incomplete frankly. SQL injection requires some assumption of field names, or db schema. How did they nail so many sites indiscriminately without targeting a particular framework?

SQL injection doesn't require that kind of a priori knowledge; see INFORMATION_SCHEMA for details. It's possible that there's a database (and hence an SQL variant) in common, but even that isn't always necessary.

"While not bulletproof, parameterized stored procedures eliminate much of this threat. (And they usually perform better!)"

Drive-by security / performance advice is responsible for much of the conventional wisdom that characterizes poor web and database programming.

While neither of your statements are flat out wrong, they also don't say very much. Sure, if you make a call a stored procedure properly, you avoid SQL injection. If, of course, your stored procedure isn't vulnerable itself. And, of course, if you parameterize a regular query you also avoid injection.

But stored procedures aren't always practical, and that comes back to a basic tenet of security: you need a damned plan. If you haven't got a plan and you don't stick to it, you've got no security. One-liners do not a plan make.

And, performance-wise, you don't go into why or how. Just "this might be faster!" You're perpetuating the mythology of performance, giving novice designers yet another distraction from logical correctness and usability.

Premature optimization is the root of all evil. Every time you optimize prematurely, god rips off an angel's wings, a baby is born with AIDS and the terrorists win. Closer to home, *you* will be wondering why the hell Conglomerated Corp screwed up your billing again or why Joe's Online Crap can't get a shopping cart right.

Test and profile, test and profile. If it really is faster, prove it. And if you can't be bothered to profile, you don't care so much about performance that you need to be making your design needlessly opaque or possibly buggier by using wonky performance tips you read online.

And, performance-wise, you don't go into why or how. Just "this might be faster!" You're perpetuating the mythology of performance, giving novice designers yet another distraction from logical correctness and usability.

In order for this story to be true, the affected sites must all be running the same underlying application. The real story here is 'Which common framework has such a vulnerability?'

I'm not aware of a common framework that would affect ASP, ASP.NET, JSP, and PHP. I'm not sure why one would be necessary, either: there's no indication that this was blind injection, so the initial probe for each affected site could well be something simply to generate an error message that discloses the identity of the underlying RDBMS. Just brute force query/POST parameters until you generate a useful error message, and work from there.

Q: How do you know it's using SQL Injection?A: We have been contacted by people who have seen the code in their Microsoft SQL databases. So far we have only had reports of Microsoft SQL Server 2003 and 2005 being affected, so if you have any information that says that 2008 has been hit as well, we'd like to know about it.

Q: Could this mean that there's a vulnerability in Microsoft SQL Server 2003 and 2005?A: We don't know, but we don't think so. Most likely there are vulnerabilities in the Web systems used by these sites, such as outdated CMS and blog systems.

Q: How do you know it's using SQL Injection?A: We have been contacted by people who have seen the code in their Microsoft SQL databases. So far we have only had reports of Microsoft SQL Server 2003 and 2005 being affected, so if you have any information that says that 2008 has been hit as well, we'd like to know about it.

Q: Could this mean that there's a vulnerability in Microsoft SQL Server 2003 and 2005?A: We don't know, but we don't think so. Most likely there are vulnerabilities in the Web systems used by these sites, such as outdated CMS and blog systems.

Yeah, they're still waiting to see logs though. There are portions of logs from earlier variants of what appears to be the same activity floating around the Internet, but I've not come across anything current.

Once someone has some complete logs from an attacked site, it should be possible to narrow down the vulnerability quite a bit, I think.

Yeah, they're still waiting to see logs though. There are portions of logs from earlier variants of what appears to be the same activity floating around the Internet, but I've not come across anything current.

Yeah, they're still waiting to see logs though. There are portions of logs from earlier variants of what appears to be the same activity floating around the Internet, but I've not come across anything current.

I read this immediately after getting off the phone with a friend who called for help on how to remove the 11 viruses from their computer. Turns out it was a website telling them they had 11 viruses, which was nice enough to automatically send them the download containing a spyware/virus fixup/removal tool. Thank god Firefox didn't have them run it directly, and they just saved it to their Downloads folder.

I essentially explain to "never ever ever download and run any software from an untrusted website". The bigger problem is that most users today don't really understand the line between the internet and their computer. I take issue with Microsoft, as Windows Update is training them to be worse in this regard - this user doesn't really see a difference between a Windows Update popup taking them to the Windows Update website and offering to download Windows Defender updates, versus this attack site popping up and doing the same thing. Frankly, with web apps running in the "cloud" launching from desktop icons, web integrated widgets, etc, this situation is going to get a whole lot worse before it gets better.