It never stays quiet on the internet: The Lizamoon attack, the update problem?

It never stays quiet on the internet and new attacks or malware are seen every day. The last week however we saw an interesting mass SQL injection attack, referred to as Lizamoon, which was spreading and has infected several millions of URLs last week (March 29 until April 4). Even after a week, thousands of comprised websites don’t seem to be cleaned up, yet.

What are we talking about?
The mentioned attack uses SQL injection techniques to insert rogue code into the databases of websites. SQL injection is a code injection technique that misuses available functionality that is not filtered away properly. In other words: The vulnerability is present when user input is not correctly filtered for escape characters embedded in SQL statements or if the input is not strongly typed and by this unexpectedly executed (cf.: Wikipedia).

The following code was injected into a large number of websites:
<script src=hxxp://lizamoon . com / ur . php >

According to our colleagues from Websense, there are also other injected strings. Have a look at their initial blog entry plus the update.

If you do a Google search with:
“<script src=http://*/ur.php”

you can still find infected websites but note that not all of these websites with that search string were/are infected of course. And of course it is not only the lizamoon.com domain (hence the name of the attack) which has been used in the attack, but many other domains were involved as well. 

It wants your money?
The injected code was redirecting the visiting users to several fake antivirus sites. Several distribution sites end in .cc or .in. These sites then display fake alerts to persuade people to download some rogue application(s).
In case people download these, the malware will display some fake security alerts and advise users to buy a license to fix the problems the fake antivirus allegedly found. Of course, the aim is to steal the user’s credit card details during the buying process.
You can see a very similar FakeAV behaviour in two of G Data’s videos about “Win HDD”: Video 1 and Video 2

Why was the attack successful?
It is most likely that out-dated Content Management Systems (CMS) and blog systems were the basic cause of the problem, as no real vulnerability was used in Microsoft SQL 2003 and 2005. MS SQL based webpages were the target in this attack. SQL injections are a prominent attack vector, especially for web applications. If user input is not filtered properly or one of the many obfuscation techniques for SQL injection can evade the filtering, then it is in most cases, possible to manipulate the content of the website.
Was it successful all the way?
We don’t think so. The number of affected customers is quite low. Only about 1 out of 2,000 incidents is related to Lizamoon-domains – and for several of the observed days this number is even lower. The estimation is that the attack was not that successful, as fast actions by some security companies were in effect after the launch of the attack. By shutting down the distribution domains, cleaning up the infected websites and upgrading / updating the CMS software or other software on the webservers, the number of victims should have been limited.

Advice for users
The good news is that the G Data SecurityLabs were monitoring the attacks all the time. G Data’s customers were protected from the very beginning by the built-in scanner and web-protection technologies, which are standard features in all our products. We recommend that you read the related G Data whitepaper “Attacks from the web”, written by Ralf Benzmueller, head of G Data’s SecurityLabs, if you are interested in this whole matter. The whitepaper provides an in-depth look into most web security problems and is provided as a PDF at the bottom of this article. 

Advice for webmasters
In most cases, very easy and basic steps are sufficient to prevent this described attack on the websites itself:

• Use an updated CMS system or update it when released
• Keep all software and the operating system updated on the webserver
• Restrict and validate user input thoroughly
• Encrypt sensitive data
• Restrict the privileges of user accounts and database users
• Consider using a web application firewall

You can find more at the original blog post of G Data’s Security Blog.