• Search Blog Archives

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

June 2011 Posts

Blackhat SEO poisoning leads to Blackhole Exploit Kit
Posted: 29 Jun 2011 06:19 PM

 

Instead of blogging about another case of Blackhat SEO poisoning (yes, Blackhat SEO poisoning does happen every day), I'm going to focus more on what happens after clicking on the poisoned search result. Although in the majority of cases unpatched users are exploited, I want to show how sometimes researching these cases can lead to a dead end.

 

This morning I saw a case that led a user from a Google search result to a Blackhole exploit kit, one of the most widely used exploit kits in the wild. 

 

Like most exploit scenarios, attackers always have a lure to attract the user to click on a link and start them on the path of exploitation or installation of malware. This can be done in numerous ways: Phishing emails, Facebook social networking viral scams, Google search engine poisoning, etc. In this case, attackers have poisoned search engine results of the keywords "shia labeouf", which is #10 on Google's hot trends:

 


(Figure 1: Google Hot Searches. "shia labeouf" is #10)

 

If a user was to search for "shia labeouf", search result #45 leads to  hxxp://shiantology[dot]com/:

 


(Figure 2:  hxxp://shiantology[dot]com/ screen shot)

 

This site has been compromised, and has an iframe injection that leads to a Blackhole exploit kit:

 

The iframe injected in the code silently makes a connection to the above IP address:

(Figure 3:  hxxp://shiantology[dot]com/ redirection chain)

 

65 [dot] 75 [dot] 129 [dot] 9 responds with the following payload (obfuscated HTML code + a JavaScript deobfuscation algorithm):

 

(Figure 4: Obfuscated text within HTML div tags)

 

(Figure 5: JavaScript deobfuscation algorithm)

 

The code above causes the browser to make a connection to /games/A.class.

hxxp:// 65 . 75 . 128 . 9/Home/index.php makes a connection hxxp:// 65 . 75 . 128 . 9/Home/games/A.class 


Normally, we'd be able to see this by looking at the final resulting DOM of the browser (after all the JavaScript has run and the document.ready event has been triggered):

(Figure 6: 65 [dot] 75 [dot] 129 [dot] 9 final DOM)


One thing to notice is that looking at the above DOM code, there is no object or applet tags that are shown and require an A.class. Good thing we were watching the network connections and JavaScript hooked events. This is a reminder that a Web page with the use of dynamic client-scripting like JavaScript can continually change.The finalized DOM does not always represent the DOM at all stages of the document, changing due to JavaScript functions being called. 


What happened is that during the deobfuscation phase, the algorithm above created a series of document nodes. One of them was most certainly an object or applet which required A.class. It then did some other checks, for example browser type, and function existence all for the purpose of verifying which browser was actually running (this is an alternative to checking the user agent string) and then redirecting the browser based on the result to another redirector:


Status: 302
Location : hxxp:// 109 . 236 . 81 . 40/
Content-Type : text/html; charset=iso-8859-1


hxxp:// 109 . 236 . 81 . 40/ is a redirector that redirects the browser to google.com


Status: 302
Location : http://google.com
Content-Type : text/html


In this particular case our research has led us to a dead end. Many times the obfuscated code and checks will only trigger if ALL conditions are correct. If they are, the code redirects the browser to exploit files. If they are NOT then the redirector redirects the browser somewhere else. In this case the browser was redirected to hxxp://google[dot]com, but we could have just as well been redirected to Bing or Yahoo! or another major search engine as means of leading you off track. In many cases your browser will also be redirected to hxxp://
searchportal.information[dot]com

 

Websense Labs has a group of researchers specifically focused on exploit kits. Websense customers are protected from the Blackhole exploit kit as well as other exploit kits by ACE, our Advanced Classification Engine.

 

If you have any comments on this blog or questions about engine poisoning or exploit kits please ask them below: we always look forward to hearing from our readers and hopefully helping them understand how to protect themselves from the ever-changing threat landscape.

 

Thanks! 

Stephan Chenette - Principal Security Researcher
Contributions by Elad Sharf - Security Researcher 

Filed under: ,

Anonymous

XSS Attack on Sina MicroBlog
Posted: 29 Jun 2011 06:48 AM

If you have not heard of Sina Weibo in China, you are behind the times. Sina Weibo is the most popular microblog service in China, with more than 100 million registered customers. Just yesterday (28 June), Sina Weibo was attacked through an XSS exploit: more than 30,000 high profile customers were affected and sent out messages containing a malicious link.  Sina provided a quick response, within two hours, to stop this campaign. Websense customers are protected from this attack by ACE, our Advanced Classification Engine.

 


Here is a snapshot of a message with a malicious link posted by a high-profile customer. The content of the message is related to some hot topic or film star in China to lure the followers to click on the link.

 

 


 

Followers who click the malicious link are redirected to a page hosted on "weibo.com/pub/star", which contains an XSS exploit to allow the execution of malicious JavaScript from www.2kt.cn.

 

The malicious JavaScript code could post messages on the follower's microblog account, add a follow to a suspicious account, and send a personal message to his followers. Until now, the campaign has just spread itself with no other malicious intention. Interestingly, the suspicious account which affected customers was named "hellosamy", showing some respect to the world's first XSS worm "Samy", which spread on MySpace in 2005.

 


Although no malicious software was installed in this campaign, Websense reminds customers to do a simple check before you click on any suspicious URL, even it comes from your best friends.

 

 

uwang

Blackhat Google SEO Poisoning of keyword "patti labelle"
Posted: 28 Jun 2011 07:22 PM

 

Blackhat SEO poisoning is something we have blogged about numerous times in the past [1] [2] [3].

 

If you aren't familiar with the topic here are the basics:

 

Attackers that control botnets have the ability to poison search engine results to point to pages they own or that they have compromised in order to redirect users to web sites hosting malicious code. When a user clicks on a poisoned search result, their machine may be exploited or they may be prompted with rogue antivirus to which they are almost always tricked into installing.

 

The ThreatSeeker® Network regularly monitors "trending topics" on Google,  Twitter, major news outlets, and other sources to see which keywords attackers are most likely to attempt to poison. Here is an example that our ThreatSeeker Network picked up one morning.


Google hot search keyword "patti labelle" poisoned
 

:

(Figure 1: The Google "Hot Searches" for June 27, 2011)

 

As you can see "patti labelle" is "hot search" topic #6.

 

Using our ThreatSeeker Network, which includes our backend processes, customer feedback loops, and most importantly ACE, our Advanced Classification Engine, we routinely monitor billions of pages. Amongst those are potentially poisoned search results.

 

This morning when I checked my inbox for notifications and alerts this is what I found:

 

Google "hot search" keyword = "patty labelle" found in URL 30 : hxxp://www.divastation.com/patti_labelle/labelle_bio.html

 

Details:
4 Security connections:

  • src: hxxp://www.divastation[dot]com/patti_labelle/labelle_bio.html (Malicious Web Sites), dest: hxxp://toolbarqueries-google[dot]com/in.cgi?default (Emerging Exploits)
  • src: hxxp://dalanaya[dot]cz.cc/dtr.php?a=QQkFBwQDDAIFAAUEEkcJBQcEDAUGBAcNDQ==(Malicious Web Sites), dest: hxxp://778887467/sdghsdfv (Malicious Web Sites)
  • src: hxxp://win-update[dot]cz.cc/in.php?a=QQkFBwQDDAIFAAUEEkcJBQcEDAUGBAcNDQ==(Malicious Web Sites), dest: hxxp://dalanaya[dot]cz.cc/dtr.php?a=QQkFBwQDDAIFAAUEEkcJBQcEDAUGBAcNDQ== (Malicious Web Sites)
  • src: hxxp://toolbarqueries-google[dot]com/in.cgi?default (Emerging Exploits), dest:hxxp://win-update[dot]cz.cc/in.php?a=QQkFBwQDDAIFAAUEEkcJBQcEDAUGBAcNDQ== (Malicious Web Sites) 

 

I then checked Google Search and confirmed the findings. Searching for "patty labelle", I found a malicious link on the 3rd page (result 30) of Google search results:


(Figure 2: Poisoned Google search results)


What happens to the user if they click on the link?

By clicking on the link from Google search results the user is sent to:
hxxp://www.divastation[dot]com/patti_labelle/labelle_bio.html

Upon visiting this site the following network connections are made:

:
 (Figure 3:
divastation[dot]com redirection chain)

 

The attackers payloads consist of various PDF and Java Exploits that will be attempted and executed if the user is not patched:


(Figure 4: Attempted exploitation of APSB06-20)


(Figure 5: Attempted exploitation of CVE-2010-0840 (more detailed analysis below))


(Figure 6: Attempted exploitation of CVE-2010-0886)


The end result of successful exploitation is that a trojan downloader is downloaded and executed on the users machine.


Update (2011/06/29) upon further research, hxxp://dalanaya[dot]cz.cc is hosting the Incognito exploit kit


The Details

hxxp://www.divastation[dot]com/patti_labelle/labelle_bio.html contains an injected iframe, which causes a connection from the user's machine to a website owned by an attacker, this is done without any user interaction.

Analyzing the source and dom in the browser we can see this more clearly:




(Figure 7: Source and DOM of 
hxxp://www.divastation[dot]com/patti_labelle/labelle_bio.html)


Here is the order of web sites that a user will be redirected to upon visiting the compromised site (redirection chain):

  1. User visits hxxp://www.divastation[dot]com/patti_labelle/labelle_bio.html (compromised web site)
  2. An iframe connection to hxxp://toolbarqueries-google[dot]com/in.cgi?default is made
  3. hxxp://toolbarqueries-google[dot]com/in.cgi?default redirects the user via 302 redirect to (Status: 302) to hxxp://win-update[dot]cz.cc/in.php?a=QQkFBwQDDAIFAAUEEkcJBQcEDAUGBAcNDQ==
  4. hxxp://win-update[dot]cz.cc/in.php?a=QQkFBwQDDAIFAAUEEkcJBQcEDAUGBAcNDQ== redirects the user via iframe to hxxp://dalanaya[dot]cz.cc/dtr.php?a=QQkFBwQDDAIFAAUEEkcJBQcEDAUGBAcNDQ==
    AND also attempts to load a jar file hxxp://dalanaya[dot]cz.cc/bodun.jar (see analysis below) and a PDF exploit.
  5. hxxp://dalanaya[dot]cz.cc/dtr.php?a=QQkFBwQDDAIFAAUEEkcJBQcEDAUGBAcNDQ== attempts to load a jar file file from hxxp://778887467/sdghsdfv which returns a "503-Service Unavailable" status code.


778887467 is just 46.108.225.43 decimal encoded (this is a very typical technique used by malicious attackers and spammers to obfuscate URL links). 

Logic:
46 = 00101110
108 = 01101100
225 = 11100001
43 = 00101011


Joining all the binary digits together results in 00101110011011001110000100101011 binary, which equals 778887467 decimal. Browsers correctly interpret decimal encoding.


Although the jar file from 46.108.225.43 returns "503-Service Unavailable", the interface to ThreatSeeker allows me to see any previous exploits or malware that the site hosted. Here are the results:

  • hxxp://46.108.225.43/dira/jar.class (sha1: 530f83a963927963908d272de90760de30577add) (TrojanDownloader:Java/OpenConnection.OF) - date first seen: 2011-05-24 22:46:47
  • hxxp://46.108.225.43/srv.exe  (sha1: d917dc291259def9dd65ab17c4f51b6e88488648) (TrojanDownloader:Win32/Carberp.G) - date first seen:  2011-06-03 05:10:20
  • hxxp://46.108.225.43/update_us.exe  (sha1: ffba80822ad9c12a827b07ee652a59a579ecbc9b) (Rogue:Win32/FakeRean) - date first seen: 2011-06-23 19:06:41
  • hxxp://46.108.225.43/srv_1.exe (sha1: c079a4d11125e5868965327fdc5949d1bafa1bc6) (TrojanDownloader:Win32/Carberp.C) date first seen: 2011-06-17 12:13:56 
  • hxxp://46.108.225.43/update.exe (sha1: bdfaee06a6335005bbaf04339fe9370679e858f4) (Win32/LockScreen.AHO trojan)  date first seen: 2011-06-27 03:07:38


As we can see this IP has hosted other exploits and malware in the past.


Network Analysis of bad players

Let's analyze the sites involved because they are all malicious, either acting as a redirector or serving a potential exploit. 


hxxp://www.divastation[dot]com/patti_labelle/labelle_bio.html  is a compromised site that the attackers can control and update.

The "whois" record shows the following creation and expiration data:


 (Figure 8: whois record for 
divastation[dot]com)


The clue that makes the case that this is a compromised site as opposed to a site owned by an attacker, is that it's been around since 1998, typically malicious sites are registered within a few days to a few months of being used. 


toolbarqueries-google[dot]com resolves to 91.214.209.19, 195.226.218.101, 195.226.218.101, 193.105.240.11


(Figure 9: whois record for toolbarqueries-google[dot]com)


win-update[dot]cz.cc resolves to 207.58.177.96
dalanaya[dot]cz.cc resolves to 207.58.177.96
46.108.225.43 


The following whois lookup, courtesy of team cymru, exposes the following information:


whois -h whois.cymru.com " -v 91.214.209.19"
AS | IP          | BGP Prefix           | CC                             | Registry   | Allocated  | AS Name
196808  | 91.214.209.19    | 91.214.208.0/22     | UA             | ripencc     | 2009-06-24 | KOMSERVICE-AS NET KOMSERVICE


whois -h whois.cymru.com "-v 207.58.177.96" 
AS      | IP               | BGP Prefix          | CC | Registry | Allocated  | AS Name
25847   | 207.58.177.96    | 207.58.128.0/18     | US | arin     | 2004-04-29 | SERVINT - ServInt


whois -h whois.cymru.com " -v 46.108.225.43"
AS      | IP      | BGP Prefix          | CC | Registry |  Allocated  | AS Name
50244   | 46.108.225.43    | 46.108.224.0/21     | RO | ripencc  | 2010-07-21 | ITELECOM Pixel View SRL



Although both win-update[dot]cz.cc and dalanaya[dot]cz.cc resolve to the same IP address (207.58.177.96), the rest of the redirector chain is quite distributed. 


Let's take a quick look at the jar exploit that ends up being served to the user:


Analysis of hxxp://dalanaya[dot]cz.cc/bodun.jar

hxxp://dalanaya[dot]cz.cc/bodun.jar (sha1: de573766f4095ab979174df2033b834c62abd603(Java/TrojanDownloader.OpenStream.NCE trojan) - date first seen: 2011-06-26 10:45:40


A JAR file is nothing more than a file that has been 
PKZIP'd (compressed) and that includes several Java class files that are used for execution.


bodun.jar contains the following class files:

 
(Figure 10: IDA display of bodun.jar class files) 


shalun\nterhoop.class - 
Exploit.Java.Agent.ff - exploits CVE-2010-0840, which allows for downloading and execution (in this case a trojan downloader)
pinoche.class - Trojan-Downloader.Java.Agent.mc (this class is responsible for downloading and executing the trojan downloader)


pinoche.class makes a connection based on params sent in from the main webpage:


(Figure 11: Java Applet object HTML code)

 

The class files within the jar file contain obfuscated strings throughout the code base, but the intention of the code is to initiate an Internet connection to download and execute a file.

(Figure 12: Java code in Java Decompiler)


The actual executable that was downloaded was not analyzed, but you can see how simple it is for an attacker to use jar files to exploit a user.

 

Targeting JRE (Java run-time) is currently the number one drive-by exploit vector on the web. Most exploit kits and attackers who use custom exploits will typically use both Adobe PDF exploits and Java exploits to run code on a user's machine. Typically, exploitation  is silent. Websense Security Labs would like to emphasize that users should always be careful when searching the web. This is true for Google, Bing, Yahoo and all popular and lesser known search engines.


Hopefully. this example has shown the potential dangers in clicking on search engine results.


Stephan Chenette - Principal Security Researcher

Filed under:

Anonymous

Malware campaign uses direct injection of Java exploit code
Posted: 20 Jun 2011 10:19 AM

 

Our ThreatSeeker® Network is constantly on the lookout to protect our customers from malicious attacks. Recently, it has detected a Rogue AV campaign that directly attacks the user's system instead of first redirecting to a dedicated attack server. Websense customers are protected from this attack by ACE, our Advanced Classification Engine.

 

Attackers usually compromise web pages to drive traffic to web servers hosting exploit kits. In this injection though, we see exploit code directly planted into legitimate pages:

 

 

The code shown attacks an Oracle Java vulnerability (CVE-2010-4452) by exploiting a design flaw in the Java class loader to execute an unsigned Java applet with local user rights. The exploit affects Java Runtime Environment versions 6 Update 23 and earlier. It was addressed by Oracle with Update 24 in February 2011. In internal tests, we could confirm that the malicious applet would load in all popular browsers with built-in Java support like IE, Firefox, and Opera. The applet in this attack is used to locate and execute a .exe payload that is disguised in the foreground parameter of the applet-tag as a .jpg file. While the system gets attacked, the user would only see the Java icon popping up in the Windows taskbar:

 

 

The payload in this case is the nowadays ubiquitous Rogue Antivirus:

 

 

In case you haven't already done so, don't forget to update your Java version as soon as possible.

Filed under: ,

Armin Buescher

CVE-2011-2110 for Adobe Flash Player being exploited in the wild
Posted: 17 Jun 2011 08:30 PM

 

Earlier this week Adobe released security updates for several of their products and now the CVE-2011-2110 vulnerability in Flash Player is actively being used in drive-by and spear-phishing attacks. Websense customers are protected from this scam by ACE, our Advanced Classification Engine.

 

The vulnerability is triggered when a website is viewed in a browser that has the Adobe Flash Player plugin installed by a simple command that loads a malicious SWF file, as can be seen in this sample code as seen by the Websense ThreatSeeker® Network:

 

 

Technical details

We are still analyzing the vulnerability and how the exploit works but here's what we know. The exploit samples we've seen so far use heap information leakage, so that it doesn't have to spray the heap. Once the vulnerability is triggered, the transfer of execution from legitimate code to malicious code takes place when the stack pointer is replaced with EAX.

 

 

Once the stack has been compromised, it carries out the ROP portion of the attack to allocate an executable memory page for the second stage of the shellcode.

 

 

Once the shellcode has executed, it will try to download an encrypted binary file that's decrypted by an embedded ActionScript. The decrypted file is saved in the %TEMP% folder on the computer and then executed. Here's a VirusTotal link to one binary we saw used by one of the exploit files, but each exploit downloads a different file from a different server.

 

 

 

We also found an interesting debug string in one of the SWF files we looked at, which is a greeting to Rising, a Chinese antivirus company.

 

 

Below is a list of URLs where we've seen the exploit being hosted.

 

 

As always, it's crucial that you install the latest version of Adobe Flash Player as soon as possible if you haven't done so already. The vulnerable versions are any version older than 10.3.181.26. If you're unsure which version of Adobe Flash Player you have installed, you can find out by going to this link hosted at Adobe.


Our friends over at Shadowserver has posted some information about this vulnerability on their blog.


(Technical analysis done by Victor Chin)

Patrik Runald

Instant Exploits?
Posted: 14 Jun 2011 12:02 PM

Earlier today, Google announced a number of new technologies as part of their Google Inside Search Launch (http://www.google.com/insidesearch/). One of the more interesting is their idea to speed up the Web with something called "Instant Pages." The basic idea is that they are taking their ability to correctly guess what a user is going to search on, and pre-loading the content from the origin server onto your local machine. Apparently, this only works with the Chrome browser.

 

This leads to some interesting exploit scenarios. In the past, search algorithms have been duped to have malicious pages show up in results. In those cases, although they are dangerous, the user still has to click on one of the top results to get infected. In the new scenario, the big question is if a user can be exploited by simply searching, without even clicking on a link.

 

In slightly related news, Google also announced voice recognition to search. It will be interesting to see how/if the rogue AV camps will also be utilizing this to their advantage in the future.

 

Filed under: ,

Anonymous

Fake Facebook site threatening Thai population
Posted: 08 Jun 2011 01:37 PM

"Do you want to be my friend? I will add you on Facebook." This kind of conversation is quite common nowadays, and is reasonably safe in most cases -- but not in Thailand!

 

Websense® ThreatSeeker® Network has found a fake Facebook site in Thailand. The Web page looks greatly different than the popular social networking portal, so it is unlikely that the site owner would use the usual social engineering tricks to steal credentials. However, as we will see the site does host some malicious applications to trap their unaware users.  Websense customers are protected from this attack by ACE, our Advanced Classification Engine.

  

 

 

 

As we can see in the picture above, the home page looks different than the original Facebook, even if it shares a few similarities such as the color and the style of the buttons at the top. Analysis by FireShark also shows us a legitimate-looking picture, as most of the connections seem to be going the right way, as well as to legitimate and clean destinations:

 

 

 

 

At this point, a security researcher might think that the creator of this site only wanted to gain some capital by buying the top-level domain name for their country (domain squatting), as this then opens negotiations for a trade or buy-out. However, before we close this book and put it back on the shelf, take a look at some of the other pages it hosts:

 

 

 

 

 

As we can see, some of the pages hold malicious applications, able to install a bot (Win32/Dorkbot.A) and another malware agent on users' computers. Websense Security Labs would like to emphasize that this site is not the original Facebook, and users should always be careful when visiting sites that are unknown or uncategorized.

 

Filed under:

Tamas Rudnai

©2013 Websense, Inc. All Rights Reserved.