Working in the security industry brings about a myriad of challenges. This is especially true for vendors. We must do our best to educate and inform. At the same time, we want to avoid laying on the FUD–or scaring customers into making poorly educated security decisions.
Which brings us to the recent LizaMoon attacks. There is an incredible amount of highly generic and vague information floating around. The fact of the matter is on-going SQL-injection attacks are a fact of life. They are not the only ones, either; every day there are mass spammings of new pieces of malware. Every week we see thousands of new “fake-alert” Trojans (a.k.a. rogue or bogus AV/security products and scams). And fake-alert is just one of the millions of static malware examples that we deal with on a constant basis.
So how should we respond? Do we toot our own horn and blast everyone with a gargantuan list of countermeasures for any and all threats? Do we wait and see how the industry reacts and then do what everyone else does?
Without getting too philosophical, I’ll cut to the chase.
What’s In a Name?
The LizaMoon attack is named after one of the domains referenced in the script code that gets injected into compromised pages.
Example: <script src=http://lizamoon[dot] com /ur[dot] php >
Lizamoon.com is not the only domain associated in this way. In the days since we started tracking this event, we have added many others. As of this writing we know of around 40 (give or take a few). If you are looking to block traffic to the malicious domains, this is where you want to focus your efforts. We have seen some recommendations to block all associated domains–even those that have been compromised (the valid sites that were victimized by the attack). This step may be overly paranoid. We do not necessarily need to block traffic to all these legitimate and well-meaning sites (by some estimates the count is up to 1.5 million) to protect against this and similar threats.
Make Me Feel Secure !
The injected scripts redirect clients to sites that are known to host fake/rogue/bogus security software. There are tens of thousands of write-ups on this fake-alert family on our Threat Intelligence site, and it’s one of the most prevalent families of static malware that we deal with.
The particular package associated with this attack is detected as follows:
Name: FakeAlert-PJ.gen.c
DAT: 6304
Release Date: April 2, 2011
Info: http://vil.nai.com/vil/content/v_348729.htm
Malicious hosts associated with this attack (for example, lizamoon.com) are categorized as malicious by our Web Reputation Service (http://mcaf.ee/92e06). Multiple McAfee products, at various layers of defense, use this intelligence to block traffic or filter out the bad stuff. McAfee Firewall Enterprise and McAfee Host Intrusion Prevention are just a few examples. More details on McAfee GTI Reputation and Categorization Services can be found here: http://mcaf.ee/92e06
The network side of the SQL-injection attack is detected through the McAfee Network Security Platform. The signatures that pick up this particular attack are approaching one year old (sig: HTTP: SQL Injection – evasion III in Releases 4.1.74, 5.1.44, and 6.1.11).
Where’s the Beef?
This is a SQL-injection attack. Before any of us blow our IT budgets on database security goodies, we must all take the basic first steps. Simple and core techniques, such as constraining user input, validating user input, limiting types of input, encrypting sensitive data, and designing accounts with the principle of least privilege will go a long, long way.