Slashdot Mirror
Viral Scareware Infects Four Million Websites
oxide7 writes "A fast-spreading SQL injection attack that illegally peddles a bogus scareware has been breaking anti-virus barriers and compromising millions of websites, besides defrauding unsuspecting victims. The news of this attack was brought out by Websense Security Labs in its blog last week. Websense said its Threatseeker Network identified a new malicious mass-injection campaign which it named LizaMoon."
http://community.websense.com/blogs/securitylabs/archive/2011/03/31/update-on-lizamoon-mass-injection.aspx
Only people who've been thoroughly windows-indoctrinated could use terminology like that -- it actually means nothing at all, except "we don't know what we're doing here".
Caveat Utilitor
Anyways, as said before, there's plenty of guides (including by the NSA) on how to not suffer cross-scripting attacks. That anyone still suffers from them is not through a lack of resources.
SQL injections and XSS attacks aren't necessarily related.
XSS attacks require you to push the parameters in the URL itself. If an attacker modifies the SQL, they don't need to change anything, you just visit the site, and they'd change it 'server side' instead. So its much more dangerous, and there's no real way for the user to avoid it - except of course turning off scripts I would assume. And being careful about links.
"This latest viruses attack your computer's humours, exchanging it's good aire for foul and musty spirits, thus disrupting the subtle fires necessary to process your data. Most inauspicious. That's why you need Semantec's Miracle Oil, the Ninth Wonder of the Worlde!"
Caveat Utilitor
which sites are vulnerable? are there any more precise information than "outdated CMS and blog systems" ??
As others have noted, the original article is much more informative.
First, only MS SQL Server seems to be affected. This isn't because of a flaw in SQL Server, but because the injection seems only to work on a web app that's designed to run this DBMS in the back end, The article authors note that they don't know which application this is, however. This seems a little surprising, given that they should be able to spot the commonality between all the infected sites.
Second, to determine whether your server is affected, just check to see whether your site now has an URL like http://domainname/ur.php. If it does, you're infected. If you run on Linux and Apache, it looks like you're safe from this particular attack.
Crumb's Corollary: Never bring a knife to a bun fight.
First, only MS SQL Server seems to be affected. This isn't because of a flaw in SQL Server
Strictly speaking, that is true. However, SQL Server supports a multiple statement binding syntax that makes it uniquely vulnerable to these kinds of injections in poorly written programs - i.e. you can start a new SQL statement anywhere simply by injecting a semicolon followed by whatever SQL you like.
That is why if a SQL injection attack ever affects tens of thousands of sites, it is inevitably a poorly written SQL Server application. If I were Microsoft, I would add an option to turn the traditional syntax off, deprecate it for future use, and require block syntax to process multiple statements. That doesn't eliminate the problem, but it greatly reduces the possible attack surface, and the severity of the attacks that do get through.
Actually I'd say the problem isn't Windows, it is PEBKAC which NO OS will solve or they would have done so by now. I just got finished cleaning one of these scareware infections where the user uninstalled their working AV to install the malware. Now why would they do that you say? Simple, they saw the number of "infections" reported on the fake scareware page and decided their good AV must not be working (since it wasn't reporting the non existent viruses) and therefor " must have gone bad" like cheese in the fridge and tossed it to install the malware.
Now show me ANY OS that would protect the system from that level of stupid, I dare you. You can't because idiot proofing will always be defeated by the bigger idiot. For Linux here is a nice trick, how to write a Linux virus in 5 easy steps that uses nothing but bog standard social engineering. hell it doesn't even need root to be able to do all the things your average malware writer wants to accomplish. And we know this works because they used similar methods in the KDELook attack, where thousands of KDE users were infected by fake screensavers that were actually malware. Sound familiar?
So it is real simple folks, if the user has install rights then they have the ability to screw themselves, full stop. You can try education, making them jump through hoops like UAC or root prompts, it doesn't matter. it is the classic dancing bunnies problem where if the user WANTS the malware (and that is what it all boils down to, the malware uses fear or social engineering to convince the user they want to install the malware, a classic con game) then by God they're gonna get that malware whether you like it or not!
So in the end you do what you can, make sure they have a backup solution, and be ready to clean up the messes when they happen. it reminds me of how an old Linux admin of mine ended up being threatened with firing and had to show up before the head of the regional office because the PHB over him was demanding he allow the PHB's emails from Melissa without interference. In the end there is only so much you can do, you just can't knock the stupid out of some folks.
ACs don't waste your time replying, your posts are never seen by me.