• Search Blog Archives

Follow us: 
Like us on Facebook Follow us on Twitter Visit us on YouTube Follow us on LinkedIn

March 2010 Posts

Malicious Code Evolution from IE Zero-Day Exploit Code
Posted: 19 Mar 2010 03:44 AM

Internet Explorer zero-day exploits are not new to the world: we have been suffering from them since the beginning of IE. This latest IE zero-day exploit, known as CVE-2010-0806, as usual is no surprise, but we can't help noticing that something behind it has changed. Just a week after the exploit code was exposed to the world we have seen many variants come out. Based on the records from the Websense® Security Labs™ ThreatSeeker™ Network, we are setting out the evolution history of the exploit code.

We know that every security company tries to detect exploits, and malware authors try their best to avoid it. Code evasion is the key point in this endless war, and the following 3 aspects are what hackers like most and are still focused on:

 

Core Code Obfuscation
Core code is the core of the malicious code, where the main purpose of the attack resides. Typically it is a piece of shellcode which will download and execute remote files after successful exploitation. By obfuscating core code, the real intent of hackers is hidden right in front of your face.

 

Algorithm Code Obfuscation
Algorithm code is the helper part to ensure that core code executes. Actually algorithm code is the pick of the basket in the whole exploit code and people will pay large amounts to get it. Normally it is some JavaScript code to set up the exploitable environments. Hackers may encrypt this part to make their code less fingerprinted and hence avoid detection.

 

Code Position Obfuscation
When checking for malicious code, people often first try searching the code in script and iframe tags, which is where malicious code usually resides. However, other HTML tags are also a good place to embed bad code. Typically hackers choose P and DIV tags as their first choices; sometimes they change their taste to use INPUT and TEXTAREA tags. Another common way to hide code is code fragmentation, which is putting the malcode in separate files; of course the reason for this is to avoid detection.

In this latest IE zero-day attack, malware authors have so far made many different versions based on the original one. Let's take a look at them, from easy to difficult. The first snapshot below shows literal core code and algorithm in normal script tags. 

 

The code above is very easy to read and understand, so some people might not be satisfied with this. Hence they obfuscate the core code a little bit and the algorithm code slightly, but it is still readable. You may or may not be familiar with this trick, but we have come across it a lot - refer to Gumblar for more details. This kind of obfuscation could be done in various ways and we have quite a few examples; this blog includes 2 easy cases so you can see what they look like. 

Up to now, we can easily understand what the core code will do, but some hide-and-seek-loving people have introduced a new way to make things more complicated. They put the malcode in a separate file or even many files, so people might not notice it at all, let alone read or understand it. 

The next snapshot shows that hackers are still using the hide-and-seek tricks, but moving the obfuscated core code to HTML tags. 

Some very simple tricks are applied in the following case: all function and variable names are randomized, making the whole code appear unreadable. 

Finally, in this example the algorithm is obfuscated which makes it even harder to read. It looks complicated, right? You will never know what the real content is unless you decode it completely. However, this is still not the worst case we have encountered. The Beladen attack that happened last June has shown us how this kind of trick could be improved, and a multilayer obfuscation we have found almost brought despair to people who love manual deobfuscation. 

 

So we have seen many obfuscation techniques so far, but it is not a problem to us since we luckily have our super tool Gustav to help. Gustav simulates the execution of inputted HTML and JavaScript code and outputs the final code to us, saving a lot of time in the process. We will introduce more details about Gustav later.

Security Researcher: Tim Xia

Filed under: ,

WebsenseSecurityLabs

How To Speak Malicious
Posted: 16 Mar 2010 02:52 PM

In this blog post, I want to cover a specific type of code obfuscation and then demonstrate how to manually, step-by-step deobfuscate the code. There are many automated tools and methods for performing deobfuscation, but I feel it's important to get down to the attacker's level to gain a more intimate understanding of attackers and obfuscation algorithms. This understanding helps us create better signatures to identify malicious content with our Threatseeker Network. After all, the best way to protect yourself and others from attack is to understand your attacker so that you have a better chance at proactive protection. Now, on to an example of obfuscated attack code. 

It's important to note that sites that have this code are most likely legitimate sites that have fallen prey to malicious code injection. This means that the site has been compromised by an attacker. The attacker inserts malicious code onto the compromised site and the injected malicious code executes when visitors visit the site. The attack code can either be on the compromised site or on another site to which the injected code redirects the visitor. We can think of the injected site as a vehicle for getting the attack code to run on victim computers. Below is a screenshot of the injected code that we're going to study. 

Injected code on an innocent site: 

For most people who see this malicious code, their eyes go crossed and they have no idea what they are looking at. This is the attacker's intent. Attackers don't want anybody viewing the source of the page to recognize that their injected code is doing something bad. So our first step is to format this script code so that it's easier for our eyes and brains to handle. You'll want to grab the code, put it into your favorite text editor and format it so that it looks like actual code. When that's done, you should feel that the code is easier to read and much less intimidating to review. 

Here is the code copied from the source of the page and formatted: 

Now that the code is nicely formatted, we can see that there are a number of function definitions in the script. In each of the function definitions we can see a variable declared with a peculiar string of numbers in a specific pattern. We can also see that this variable seems to be followed by a for loop. The for loop attracts my eyes straight away. Typically, a for loop that follows a peculiar variable definition is a red flag for a deobfuscation routine. For the rest of this post, we'll focus on one of the function definitions. 

Here is the function definition we are going to work with: 

Looking at this function, there is further work that we can do to make things easier for our eyes and brains. First, notice that the variable names are random and not meaningful. This, again, is designed to throw us off from understanding what is going on. But we are tenacious and not about to give up. So the next thing to do is to review the variable names, including where and how they are used. If there are variables that are static throughout, then let's do simple search and replace for the variable names. In this case, we can do a search and replace for CcySlu=4 and vcN=5

We should also look for any places where function declarations are used in a similar way. For example function XKJepVPIJ(c) is simply returning the string representation for a character code that is passed in. So anywhere we see a call to XKJepVPIJ, we can replace it with String.fromCharCode. Finally, in this step let's perform any mathematical operations in the function, so that we are left with a single number instead of a series of numbers and operations that we would have to think about every time we come across them in a loop. 

Here's a look at the function after performing the above steps: 

This function still looks intimidating, but less so because we can now recognize that the for loop is going backwards instead of from 0 to the end of a string or array. This is probably another ploy to throw off static analysis. We also have static values to work with instead of randomized variable names, so we can begin to see simple math operations and simple function calls. With respect to function calls, I'm no javascript developer so I don't know and recognize all the javascript functions that I come across. In this case, I was unfamiliar with the parseInt function and that threw me for a bit of a curve at first. 

So I pulled out my local library card and hopped on my bike to do some research. Actually, that was a middle school flashback -- I'm showing my age here! I simply did a Google search for the parseInt function to learn what it does. According to my research, parseInt basically gives me the decimal value of what is passed in. Because there is no second value passed into any use of parseInt in our function, the use of the parseInt function is not necessary. So we can remove the parseInt calls. After parseInt is removed, we can rename some of the random variable names to some friendlier looking names and we're left with some readable code to step through. 

This is the final resulting code. It's much easier to get my head around. I've also put a few comments inline: 

For those of you wishing to try and step through this: 

var string='122-2+166-2+153-3+165-3+158-2+164-0+167-1+124-0+167-1+163-1+164-0+111-1+
160-4+163-1+153-3+152-0+167-1+158-2+163-1+162-2+123-1+105-3+157-3+167-1+167-1+
164-0+120-4+112-0+112-0+165-3+'; 

Now that this first function has been decoded, remember that there were multiple function definitions in this script injection. You should begin to see a script redirection created by the injected code. This script redirects visitors to an attack site while they are visiting the original site, which was injected with the above obfuscated code. As you can see, there was a lot of work done to hide the intent of the injected code. This obfuscation work is an attempt to evade recognition and removal of the injected code from a legitimate site. By understanding the deobfuscation process, we can generate more generic signatures that will help identify variations of this script injection. 

Security Researcher: Chris Astacio

Filed under:

WebsenseSecurityLabs

This Month in the Threat Webscape - February 2010
Posted: 13 Mar 2010 03:20 PM

Major Hits

Microsoft's Ninemsn, one of the most visited portals in Australia (Alexa rank 573), was compromised and injected with malicious code. The malicious code was identified to be part of the Gumblar mass injections. Another regional high profile compromise victim was Bollywood Hungama's Web site, a leading entertainment site (Alexa rank 1592).

There was no shortage of blackhat SEO campaigns this month. Bad guys continue to game Google to get their malicious links to rank high on search results for hot topics, such as the Olympics, the Chilean earthquake / Hawaiian tsunami, the Bloom Box breakthrough technology, and Canadian figure skater Joannie Rochette. Clicking on these infected search results would lead to the usual rogue AV malware with low anti-virus detection rates (video). In the case of the earthquake in Chile, the malicious search results actually led to a PDF file.

A bot network dubbed "Kneber" (Zeus variant) was recently uncovered, stealing financial data and online banking transactions from numerous government and commercial entities.

Web 2 dot uh oh

Google Buzz sent the media abuzz when it launched, complete with the controversial integration with Gmail and attendant privacy concerns. Barely two days after the launch, there was evidence that spammers had already latched on to this new medium for sharing information.

A rogue Facebook app with a "viral marketing" component was discovered, where users are enticed into clicking a link titled "Who is seeing your profile?" The user is then led to through a series of step-by-step instructions to help propagate the app, without realizing what they are actually doing.

Thousands of Twitter users fell for a phishing attack, including some notable victims from the UK, such as the Press Complaints Commission, a BBC correspondent, the Guardian's head of audio, the UK's environment minister, and even a bank.

Browser and friends

Adobe still fights against the vulnerabilities in their products. In February, Adobe delivered a security update for Adobe Flash Player. Two vulnerabilities have been fixed, including a critical one (CVE-2010-0186) that could subvert the domain sandbox and make unauthorized cross-domain requests. Also, an out-of-band security update for Adobe Reader and Acrobat has been released, ahead of the company's usual patch schedule. Two critical vulnerabilities were patched, including CVE-2010-0186 (just mentioned). Lastly, a critical vulnerability in Adobe Download Manager has been patched. This one could potentially allow an attacker to download and install unauthorized software onto a user's system.

Adobe's products were targeted most in 2009 according to Scansafe's report. Malicious PDF files comprised 56% of exploits in Q1 2009, growing to 80% by Q4 2009, while Flash exploits dropped from 40% to 18%. The fact that over 90% of PCs install Adobe products, and that most of the product versions are outdated, may be one reason why Adobe is the most targeted by attackers.

Mozilla has removed two experimental Firefox add-ons that turn out to contain a Trojan: Version 4.0 of Sothink Web Video Downloader, and all versions of Master Filer. But there have already been more than 4000 downloads of each. Mozilla released fixes for five security holes, including three critical vulnerabilities.

Microsoft

A Blackhat DC Presentation demonstrated a data leakage vulnerability that allows an attacker to read any file on a default installation of Internet Explorer on Windows XP (see MS advisory). As we reported, Microsoft's Ninemsn Australia site was compromised by Gumblar, adding to this month's web problems for Microsoft.

This month's Patch Tuesday was another big one, with 13 security bulletins addressing 26 vulnerabilities. These include vulnerabilities in Direct Show, SMB Client, and Windows Shell Handler, along with new Kill Bits and other fixes. Find more discussion from the MSRC team here. A number of companies reported experiencing the infamous Blue Screen of Death when applying the MS10-015 update, which Microsoft confirmed in a blog. However, it turns out that these companies already had a rootkit called "Alureon" on them, which was actually causing the problems. What started out as a bad Windows patch turned out to be a free malware scan!

Hello ThreatSeeker. You've got mail!

Our good friend Zeus is continuing his run around the block. However, we found a twist in this month's spam. Attackers seem to have used Zeus kits to target government and military personnel in the US and UK. One campaign pretended to be from the National Intelligence Council. It enticed victims to download a document about the "2020 project". Another targeted CIA personnel, luring them to download a Windows "update" against an attack. In both cases, victims who fell for the trap found their machines infected with the Zeus malware.

In other news, we also saw an interesting malicious campaign against all you Google fans who have applied for employment with the company.

Security Trends

Apple has fixed five documented vulnerabilities in iPhone OS 3.1.3 and iPhone OS 3.1.3 for iPod touch. These vulnerabilities expose iPhone and iPod touch users to malicious attacks when they open audio and image files.

The detailed and publicly obtainable financial data on Blippy can come in handy if spam attackers can obtain the emails of Blippy users.

The Breach Report for 2010 states that, based on the analysis performed by their forensic investigations, 40% of all the attacks relied on SQL injections, with another 20% based on a combination of SQL injection attacks and malware.

A new banking Trojan used by cyber-criminals to steal financial credentials from banks in the United States has been intercepted by malware hunters at SecureWorks.

And finally, Dancho Danchev has published a blog on the top 10 things you don’t know about the Koobface gang.

 

Thanks to the following contributors for this month's roundup:

- Ulysses Wang (Security & Technology Research)
- Jay Liew (Security & Technology Research)
- Lei Li (Security & Technology Research)
- Erik Buchanan (Security & Technology Research)
- Chris Astacio (Security & Technology Research)

 

 

Filed under:

WebsenseSecurityLabs

Searching for Corey Haim Leads to Rogue AV
Posted: 11 Mar 2010 03:19 PM

 

Websense Security Labs™ ThreatSeeker™ Network has discovered that search terms related to Corey Haim have become the latest target for Blackhat SEO poisoning attacks.

Corey Haim, 1980s teen idol actor and a star of such famous movies as "The Lost Boys" and "License to Drive", was found dead in his Los Angeles apartment at the age of only 38 on Wednesday.

Whether it's a natural disaster or a death, Blackhats monitor and adapt to popular search trends. Not long after the sad news emerged, the search phrase "Corey Haim" became one of the hottest topics in Google trends.

Screenshot of the Google trend:

Cybercriminals again jump at a chance to spread their rogue AVs. When users enter keywords such as "Corey Haim death" in Google, some of the results will lead them to download fake security software. The downloading FakeAV file has only 17% coverage from antivirus products.

Google searching results of "Corey Haim death" that lead to rogue AVs:

Websense Messaging and Websense Web Security customers are protected against this attack.

 

Filed under: ,

WebsenseSecurityLabs

Quarter Million Malicious Facebook Posts
Posted: 11 Mar 2010 03:17 PM

A word of caution to Facebook users: be careful when clicking links on Facebook, even if they're on your friend's page or your favorite superstar's page.

We have detected a malicious campaign that is quickly spreading on Facebook. The malware has very low anti-virus coverage and can be found on prominent Facebook pages such as ones belonging Justin Timberlake (2.1 million fans) and a few others. If you use Facebook and are worried about this, we have a Facebook app that solves this problem (read on). If you are a customer, yes - we stop this at the gateway in real-time.

To get an idea of how fast this link is being shared on Facebook (measured in seconds!), here's a video:

This is what the malicious campaign looks like (WARNING: Do *not* attempt to go to the link - your computer may get infected):

The malicious link isn't spreading through high profile names only, but also "long tail" relatively popular Facebook pages.

VirusTotal shows a < 15% anti-virus detection rate.

We also detected that this campaign is also spreading on Twitter:

Websense customers who click this link are protected from it:

If you're using Websense Defensio Facebook app , you are notified via email when someone posts something malicious on your Facebook page:

Websense Messaging and Websense Web Security customers are protected against this attack.

 

WebsenseSecurityLabs

WordPress Injection Attack
Posted: 09 Mar 2010 04:51 AM

 

Nowadays it is not surprising when people's blogs are attacked, especially when the blog owner is a well-known person. No matter how frustrated or disappointed the bloggers are, attacks still continue. If you search "my blog was hacked" on Google, you get 4,230,000 results; searching "my blog was hacked again" returns 2,380,000 matches, and the number keeps increasing daily. What we can see from the these rough stats? Apparently nearly 44% of attacked blogs are lucky and aren't attacked again, but over 56% of attacked blogs repeat the previous nightmare.

So why does this happen? There are several reasons, but the one we should absolutely never ignore is the vulnerabilities of blog platforms themselves. According to the following Open Source CMS Market Share Report 2009, WordPress, which has the most downloads among all competitors, is dominating today's market along with Joomla! and Drupal. Therefore, we have used WordPress for our research. 

Websense® Security Labs™ ThreatSeeker™ Network has been monitoring the latest WordPress injection attack for over 2 weeks and has found over 250,000 injections occurring in the past half month. Moreover, over 37,000 URLs in the wild are still being injected according to our observations. As the following chart shows, the daily stats go up and down a few times and always end up higher, so we believe the hackers are still continuing their attack. 

WordPress is so widely used all over the world that every version of it is studied and exploited by hackers, even the latest version (2.9.2, released on December 18, 2009). The following chart reveals the percentage split of different WordPress releases affected in this attack. 

The following obfuscated malicious code snapshot shows what the injection looks like. The ultimate purpose of the attack is all about making money, as Sophos has already investigated

These attacks probably happened due to SQL injection via some known and unknown WordPress vulnerabilities. SecuriTeam maintains a list of 23 known WordPress vulnerabilities, and if you search on milw0rm.com, you get almost 60 results. This means that 60 different vulnerabilities have been discovered to exist in different versions of WordPress. 

Injection is not the only way for hackers to utilize those vulnerabilities; compromising a site is also a good option. It has often been reported that compromised Web sites are used for Blackhat SEO to push rogue AVs. Novirusthanks has a great analysis here, and more investigation indicates that the compromise behind the attack is connected to WordPress vulnerabilities. 

 

WordPress users should be very familiar with the injection or compromise attack since it has been used frequently in the past. Although WordPress has 2-3 releases every year and has 3 releases planned this year as usual, it has proved to be not enough: we still can see many victimized sites with the latest 2.9.2 installation. However, without the help from WordPress developers, there are still some measures we can take to harden our blogs. In addition, some WordPress plugins are also very helpful. Typically, bloggers choose WP Security Scan for vulnerability checks and WordPress Exploit Scanner for injection checks. Moreover, when attacks really happen, don't panic: a great guide is already there to help you clear up the mess.

Websense Messaging and Websense Web Security customers are protected against this attack.

Security Researcher: Elson Lai, Tim Xia

 

Filed under:

WebsenseSecurityLabs

RSA 2010 Recap
Posted: 09 Mar 2010 04:39 AM

Dan Hubbard, myself, our awesome event managers, and the rest of the Websense crew have arrived home after attending and presenting at RSA 2010 in San Francisco. It was another successful year as the conference was very well attended and the presentations were quite informative.

Figure 1: Stephan Chenette's FireShark RSA Talk

 

Figure 2: Dan Hubbards's Threats to Cloud Computing RSA Talk

I presented the details of a Web security Firefox plugin that I will soon be releasing open sourced called FireShark. The plugin helps in visualizing various Web attacks such as mass URL injection attacks like Gumblar, Beladen, or Nine-ball. I have to personally thank Wladimir Palant, who you should know from his development effort on a plugin called AdBlock plus. Wladimir was instrumental in offering tips to Firefox plugin writing. Thanks Wladimir!

Essentially FireShark is a local plugin that, when used in a clustering architecture, can become a very powerful mechanism in visualizing the malicious Web. In my presentation, I shared several real-life scenarios of compromised Web sites. On one occasion, FireShark mapped out one particular malicious community that later, when operation b49 was exposed, uncovered that many of the hosts involved were also Waledac spamming domains. FireShark made it easy to see that these domains were responsible for acting as control points, redirecting users from legitimate compromised Web sites to landing pages serving rogue antivirus. More so, FireShark's post processing mechanism could conduct analysis on compromised machines, intermediary machines and the final landing pages, so that not one piece of information was left unknown. This includes the original source code, the de-obfuscated source code (final DOM view), and any window prompt or malware that the user is optionally asked to download and install. This is useful for one Web site, but FireShark does this for millions of sites every day. By correlating all the data, FireShark is able to take the normalized data and link various previously assumed unrelated attacks.

Figure 3: A Web site that was compromised and part of a small malicious community, graphed with GraphViz from FireShark output

 

Figure 4: Stephan Chenette (me) speaking at RSA

I sat down with Rob Lemos in an interview while at RSA; so if you're interested in knowing more about FireShark until it's released, you can read the article here.

Days before my presentation, Dan Hubbard co-presented with researchers from ZScaler outlining some of the current top cloud computing threats. Dan's presentation as well as all presentations given at the Cloud Security Alliance conference at RSA can be found here.

Here are a few images of the conference. If you were there, you know that our Websense booth was not easy to miss; it was probably the largest and most impressive booth I've ever seen.

Principal Security Researcher: Stephan Chenette 

 

 

WebsenseSecurityLabs

BBS of Sougou Compromised
Posted: 02 Mar 2010 01:58 PM

 

 

Websense® Security Labs™ ThreatSeeker™ Network has discovered that the BBS of Sougou has been compromised.

The Sougou BBS home page and other pages on the site have been injected with a malicious script. The script creates an IFrame that redirects users to an exploit site: a 5-day old domain at [snip]ow.info. The latter performs some checks before delivering the exploits, in order to subvert any analysis attempts.

At the time of writing this alert, the BBS of Sougou is still injected with the malicious script, but the exploit site is down. This could change at any moment.

This is the injected code in the home page and its contents:

Here is the exploit page:

Websense Messaging and Websense Web Security customers are protected against this attack.

 

Filed under:

WebsenseSecurityLabs

©2013 Websense, Inc. All Rights Reserved.