Vulnerabilities Abound in 2010

Volume 16 of the Symantec Internet Security Threat Report covers trends in the Internet security threat landscape during 2010. It has been an interesting year, to say the least. We saw vulnerabilities implicated in major events such as the Trojan.Hydra…

Volume 16 of the Symantec Internet Security Threat Report covers trends in the Internet security threat landscape during 2010. It has been an interesting year, to say the least. We saw vulnerabilities implicated in major events such as the Trojan.Hydraq Incident, the Stuxnet attacks, and numerous zero-day attacks.

Here are some highlights:

-          In terms of the sheer number of new vulnerabilities discovered, 2010 was a record year. At the time of writing, we documented 6,253 new vulnerabilities over the year.

-          The rise in vulnerabilities was influenced by an increase in the number of new vendors that were affected by vulnerabilities in 2010. In 2010, Symantec documented 1,914 new vendors that were impacted by vulnerabilities, compared to 734 new vendors in 2009.

-          This also means that the total number of vendors reporting vulnerabilities has increased, along with the number of security researchers reporting vulnerabilities.

-          Vulnerabilities affecting new vendors are a growth area for high severity vulnerabilities. Symantec documented a 591 percent increase in high severity vulnerabilities affecting new vendors in 2010 over the previous year. This is likely due to the combination of efforts from security researchers and new vendors to identify high severity vulnerabilities.

-          “Bug bounty” and vulnerability acquisition programs also likely influenced the rise of vulnerabilities. In 2010, Google started its own bug bounty program to reward security researchers for discovering vulnerabilities, following the approach used by Mozilla with its own bug bounty program that started back in 2004. These types of programs collectively released 338 new advisories in 2010, an increase over the 180 such advisories in 2009.

For more vulnerability highlights and other insights into the threat landscape in 2010, check out the latest Symantec Internet Security Threat Report.

The Hype Surrounding “Massive” Malware SQL Injections

Every so often there is another round of a fairly unsophisticated SQL injection that places malware scripts into poorly coded websites occurs and then there is a enviably a security company that hypes the infections and flood of new stories … Continue reading

Every so often there is another round of a fairly unsophisticated SQL injection that places malware scripts into poorly coded websites occurs and then there is a enviably a security company that hypes the infections and flood of new stories about it.  Another round of the infection occurred in the last week, dubbed Lizamoon by Websense who is the company to hype this round (we previously discussed Websense’s false claims of WordPress security issues). From what we have seen dealing with malware infected websites and other data confirms is that these “massive” infections are not massive as they are claimed to be each time, in fact they are of average size for a malware infection of websites. Most of those average size malware infections never receive any press coverage. The reason these attacks seems to receive the coverage is because of the use of Google search results to provide a large but highly inaccurate measure of the size of the infection.

The most important thing to understand about these infections, and this often not mentioned, is that they are completely preventable by properly sanitizing user input data that will be sent to a database. Anyone coding should be well aware of this the possibility of a SQL injection , these specific attacks have been occurring for years, and take the necessary precautions. Prevent SQL injections is one of key things mentioned in our article on securing your website from hackers. Widely used software like WordPress, Drupal, and Joomla are not susceptible to such a basic SQL injection. Unfortunately, even websites that get hit often don’t bother to take the necessary precautions to prevent these SQL injections. Instead, they often just remove the code from the database. There are also unethical website malware removal companies that will remove the infection from the database without insuring the SQL injection vulnerability has been fixed.

Normally you cannot search for a malware using Google’s search engine. This is due the fact Google only makes a web page’s text content searchable and not the HTML code that makes up the page. The malware either consists of a script of iframe tag, both of with are HTML code that would not be searchable. What happens with these injections is that they get placed throughout out the database, in some instances they are placed in a location where the code from the database is escaped while the web page is being generated. So in the source code it would look like

<script src=http://lizamoon.com/ur.php></script>

instead of

<script src=http://lizamoon.com/ur.php></script>

.Because the code has been escaped it will appear as text in the pages and therefore be searchable. When the code is placed into the website in escaped form it is not infectious.

There are several problems with trying to use Google search results to measure the size infection:

  • The number that Google provides in an estimate, it’s not all clear how accurate it is. If you include duplicate pages currently you can only see 604 results for the search “<script src=http://lizamoon.com/ur.php></script>” despite there being “about 1,470,000 results”.
  • The number includes any page, like this one, that mentions the code.
  • Not all pages that have the code are actually infection, because the code only searchable if it escaped. So it would require that another instance that is not escaped be one the page for it to be infectious. We checked the first 10 results for the search “<script src=http://lizamoon.com/ur.php></script>” which were still injected and found that only four of them were infectious.
  • Most malware infections are not measurable using search results making a comparison with them impossible using the metric.
  • Web pages are not a good measure of the reach of a malware infection. A page could be accessed millions of times a day or never.

The ideal way to measure the size of a malware infection would be to determine how many times each pages with the malware would be accessed. There is not a tool able to do this and there is unlikely to be one.  What we have found to best indicator available to measure the size of a malware infection size is Google Safe Browsing system. This system scans web pages from across the Internet for malware. This data is used to block infected websites in Google’s search results and is also used for malware protection in the FireFox, Chrome, and Safari web browsers.  It does not scan all websites and does not scan all of the websites it does scan equally, so the number won’t include every infected website. Google doesn’t indicate what criteria it uses to determine how often it scan various, but in general it scans more popular website more often so it should provide a good measure of how many website that people are likely to access were infected. At the moment the system reports that lizamoon.com has infected 1436 domains. That is far lower than the nearly 4 million websites claimed to have been infected according to one source, far lower than the 1,470,000 reported for a search on “<script src=http://lizamoon.com/ur.php></script>”, and far lower than “hundreds of thousands of domains” claimed by Websense. By comparison, the IP address 86.55.140.203 that is called by a infection that has recently been hitting many osCommerce based websites is reported to have acted as an intermediary for 2957 sites.

LizaMoon the Latest SQL-Injection Attack

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 Read more…

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.

The Symantec Internet Security Threat Report (ISTR) Volume 16 Is Here!

We are pleased to announce that Volume 16 of the Symantec Internet Security Threat Report (ISTR) is now available. There are some significant changes to the report this year, including several new metrics, a revamping of existing metrics, and a revised…

We are pleased to announce that Volume 16 of the Symantec Internet Security Threat Report (ISTR) is now available. There are some significant changes to the report this year, including several new metrics, a revamping of existing metrics, and a revised format. Aspects of the new format were first seen in the Report on Attack Kits and Malicious Websites, which was released earlier this year.

One point of interest in this most recent report is the continued prevalence of malicious code propagation through the sharing of malicious executables on removable media. This propagation mechanism has been ranked at the top for quite some time now, with no signs of coming down. However, in February 2011, right in midst of writing the report, we read an announcement by Microsoft that AutoPlay functionality (used extensively for this propagation mechanism) was getting an update that would significantly restrict its use. The update limits AutoPlay to CD and DVD media only, and as users adopt the update, we may see a substantial decline in the success rates of malicious code that makes use of it, such as SillyFDC and Sality.AE.

During 2010, much while working on the Report on Attack Kits and Malicious Websites, we noticed that the increase in Web-based attacks exploiting Java vulnerabilities was being discussed by various sources, so we were interested to see the results of our Web-based attack activity metric in this volume of the ISTR. As we had expected, many of the top attacks we saw employed exploits against Java—the results of which are increasingly being touted by attack kit developers. Java attacks that were not kit specific were also notably observed, suggesting that the use and volume of Java-related attacks will likely increase in the future. In the same vein, Adobe Reader continued to be an often-exploited technology by attack kits. These types of attacks have accounted for a large percentage of activity during the past few years, so it’s  not surprising that they continue to be so prevalent. Should attackers experience more success with attacks on Java-based technology in the coming years, we may begin to see a lower percentage of activity targeting Reader; however, it seems likely to continue to be a high-level target for some attackers.

For a complete analysis of propagation mechanisms and Web-based attack activity observed in 2010, as well discussion on other aspects of the Internet threat landscape, please download the recently released Symantec Internet Security Threat Report, vol. 16.