A SQL Injection attack that may have added malware links to more than 500,000 pages compromised hundreds of thousands of sites, but appears to have had relatively few victims, at least according to the security companies who claim credit for having stopped it.
The attack called LizaMoon -- after the first fake Website link it added to targeted sites – showed as many as four million pages infected by April 3 with links to 28 URLs redirecting victims to scareware sites warning their computers could be in danger if they refused a free PC scan.
The infected sites were relatively low profile, so the attack's breadth wasn't great, according to Reuters interviews with Trend Micro and other security companies. Trend Micro added filters to block the LizaMoon sites, but intercepted only about 2,000 attempts to reach them, the story said.
Many were hoping at first the attacks, first detected March 29 but only hitting their real stride April 1, were an April Fool's trick (The scareware in the fake links was called the Windows Stability Center, which I'd normally think was as clear an indication of satire as InfoWorld's annual story about Microsoft adopting Linux.)
In the wake of high-profile attacks everyone screams for better security, which usually means buying more antivirus software and keeping it updated.
LizaMoon and other SQL injection attacks argue for different application design, though, especially for sites or applications based on cloud, virtual-server or web platforms that may be more vulnerable to bogus SQL commands embedded in otherwise standard requests.
“SQL injection has been the primary way that databases have been attacked for years," Josh Shaul, CTO of Application Security, Inc. told the WSJ. "What’s different here is that people are putting the code that runs their Web sites in the database itself. And that’s what’s so troubling. Effectively you’ve exposed your code to an attacker so they can go modify it.”
That argues for the same kind of n-tier design for web applications as for more secure apps designed with web front ends for corporate apps.
Simply put, add a layer of middleware or secure filtering app between the web front end and the database to identify and strip out bogus SQL code.
Worried it will have an impact on performance?
Run it on a high-performance security appliance that sits in the same spot, acting as a firewall and security gateway for your other apps; or stick it in front of the web server so it can filter bogus requests before they hit the server at all.
Bonus benefit: it will also reduce your risk of DDOS attacks by sloughing off most of the fake queries without having to pass them to the web server to think about first.
Check that you've already taken the most basic precautions,, though, like the one SQLSecurity.com uses as the tagline on its home-page introduction: "Have you blocked access to TCP 1433 and UDP 1434 from all un-trusted clients? No? Then get to it!"
Although it's not clear if that's the site slogan, its most-obvious advice, or a follow up to its real slogan: "There is not patch for stupidity."