• Search Blog Archives

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

June 2010 Posts

Malicious virus notification emails on the prowl
Posted: 10 Jun 2010 11:37 AM

Websense® Security Labs™ ThreatSeeker™ Network has detected a new wave of interesting malicious emails.  This new campaign uses some social engineering scare tactics to encourage users to open the HTML attachment sent in the email.  The interesting thing about the attachment is that it's only script code and the script code looks very much like script code which has been used in script injections on legitimate Web pages.  The body of the email states that the recipient has been infected with a number of viruses and that the recipient should open the attached HTML document to clean up his or her computer.

 

 

Screen shot of the email:

 

Looking at the raw contents of the attached HTML file, we can see that it is nothing more than an obfuscated script.  If the script is allowed to run, the script opens a new web page in your browser that either redirects you to an attack site or to a spam page.  The attack on your computer takes place only the first time the script runs, after that you are redirected to spam sites.

 

Screen shot of the HTML attachment:

 

Looking at the code on the attack site, we see that it uses a meta refresh tag to redirect visitors upon loading the page.  We also notice a small 1x1 iframe that is loaded in your browser.

 

Screen shot of the site opened by "Virus Scan.html":

 

The attack site contains more obfuscated JavaScript that creates an iframe to a PDF file and another to a Java .jar file.  It then attempts to attack your computer using either of these files.

 

Websense Messaging and Websense Web Security customers are protected against these attacks.

Chris Astacio

How the Adobe 0-day is used in attacks
Posted: 09 Jun 2010 08:07 AM

Matt Oh posted a great blog post yesterday about how the Adobe 0-day vulnerability works (CVE-2010-1297) and today we'll take a look at how the vulnerability is used in a live attack and how the Websense ACE technology protects customers.

 

The attack

So far we have only seen the vulnerability being used in targeted attacks via emails. The emails have either contained an attached PDF file that contains the exploit to force the machine to automatically download malware when opened or as in this example, contained a URL that performs a drive-by download when visited to infect the machine. This is similar to how some of the Aurora attacks took place. Below is an email that was picked up by our ThreatSeeker network:

 

For the exploit to work the attackers need shellcode to make the exploit do something, such as download and execute a file. When the attackers use a PDF file the shellcode is part of the PDF itself but in the drive-by scenario they're using JavaScripts in HTML pages to do it. A screenshot can be seen here of what it looks like:

 

 

Zero detection

The SWF file (Flash file) that gets pushed to the users PC is unfortunately not well detected. In fact, zero antivirus vendors detect it according to VirusTotal. Detection of the shellcode doesn't look much better either with just one vendor detecting it. We at Websense had this detected since January 5th, 2009 (that's over a year!!) thanks to our ability to do real-time scanning on web content in Websense Security Gateway. The actual malware that gets downloaded in the end isn't detected by anyone either. A quick analysis of the binary revealed it was an encrypted file with XOR 0x95, once decrypted by the shellcode the file detection is slightly improved.

 

The payload

In the next stage the shellcode runs the decrypted file which drops a file called iexplore.dll to %userprofile%\Start Menu\Programs\Startup\, this file is also very badly detected. After the file gets dropped its extension is changed to iexplore.exe by a batch script dropped at %programfiles%\Windows NT\cbt.bat. Then iexplore.exe attempts to open some content from hjkl.wekby.com/testaaaaaaaaa.txt with Microsoft's® HTML Help Executable located at %windir%\hh.exe (that's a legitimate file). Unfortunately, the URL wasn't responsive at the time of the analysis, but iexplore.exe constantly checks with another batch script located at %programfiles%\Windows NT\1.bat if the file gets successfully downloaded. An infected machine at this stage will have 5 files and repeated attempts to run the batch files and access hjkl.wekby.com for testaaaaaaaaa.txt, here are the system locations details and MD5s:

 

Encrypted executable: %userprofile%\local settings\temporary internet files\sss[1].exe c8816edfa228e460bf52eb1dbcb4a746
Decrypted executable: %userprofile%\local settings\temporary internet files\ssb[1].exe 7175b91dba6844439a94e7be2ef47059
Dropped file: %userprofile%\Start Menu\Programs\Startup\iexplore.exe 8ee79709f8c53c446eff31cdf93949fe
Batch file: %programfiles%\Windows NT\cbt.bat 6c47930dd19fa38777de8c63824f4658
Batch file: %programfiles%\Windows NT\1.bat f8e7044d6d62d42220933cf501d1b1e5

This is just one if several URLs and files we have seen used in these targeted attacks

 

Patch

Adobe has announced that they will release an updated Flash Player tomorrow, June 10, which will help in the drive-by scenario. The PDF attack vector will remain open until June 29 when the updated version of Adobe Reader/Acrobat will be made available. Until then, use extreme care when opening PDF files from unknown sources. Adobe has posted some possible workarounds in their advisory.

 

This post has been updated with information about the payload.

Patrik Runald

Having fun with Adobe 0-day exploits
Posted: 08 Jun 2010 06:56 PM

We had some time to analyze the latest Adobe Flash 0-day exploit (CVE-2010-1297) floating around on the Internet. By Googling the text inside the file, we found it was generated from a benign SWF file inside the AES.zip file. This might mean that the attacker used the SWF file for dummy fuzzing. We used our custom SWF decoder to perform this SWF diffing operation. The actual difference between the original file and the crashing one is just one byte in the Action Script Byte code (DoABC tag type). The original byte 0x66 was modified to 0x40.

 

 Figure 1: Diffing between original and exploit SWF records


You can look up the AVM2 reference to see what each opcode means. The original opcode 0x66 is "getproperty", while the modified opcode 0x40 means "newfunction".


We also confirmed this code modification by using an SWF decompiler and one of the file diff tools. We used abcdump.exe and a UNIX diff tool to get the following result.


 Figure 2: Diffing between decompiled codes


You can see that the original "getproperty" opcode has been changed to the "newfunction" opcode. Basically, this crash or exploit stems from either the SWF file, or a file embedded inside a PDF that contains the DoABC Tag Record with a "newfunction" opcode that has an invalid argument.

With more investigation, the theory we presented previously didn't fit into what we found later. The problem might cause security issues, but this exploit was not activated by that vector. Here's what we got with further analysis.

The shellcode is coming from dynamically generated code in the memory. In the following picture, the ECX register is already contaminated when the call is made.

 

 Figure 3: Contaminated ECX register

 

If you trace back to where the ECX value is originating, you can find that it's originally from the third argument for the function(dword ptr [ebp+10h]). It's not using the third argument value directly, but there are some indirections with fixed offsets. The problem is that this caller-supplied address contains an invalid address and the pointer value of this address happens to point inside heap-sprayed memory.

 

 

 

 Figure 4: Invalid address

 

We traced back to the caller and checked the third argument for the call. As you can see from the following picture, the third argument is coming from an EBX value in address1BEF0. It goes through an OR operation with 1, which makes the address unaligned. We don't think this is intended, but think this is a kind of  opcode generation error that is leading to invalid memory access.

 

 Figure 5: Third argument value

 

Heap-spray makes a lot of vulnerabilities exploitable that might previously have been thought useless. Code auditors should be more careful in locating this kind of vulnerability.

 

Matt Oh

Part 3: Another way of "Protection Centre" spreading
Posted: 08 Jun 2010 02:10 PM

Websense® Security Labs™ ThreatSeeker™ Network has detected another wave of malicious spam relating to Rogue AV's.  

 

This is not a new type of attack as we have seen a variation of this in the past as blogged about here.  The subject line of the email message and the content is exactly the same with the only difference between the two campaigns being the attachment.  This time the attachment is a pdf file which is an actual resume except this has embedded within it a script which invokes the a prompt to launch a Rogue AV. 

 

This attack proves just how easy cyber criminals can exploit unsuspecting users as this email seems legitimate enough from its contents and the subject.  So far we have seen in excess of 160,000 email messages with the same subject and content.

 

 

 

The attack is inline with the recent spell of attacks relating to twitter accounts needing passwords reset for users.  The spreading of the pdf file to get unsuspecting users to launch this and run the Rogue AV seems to be the main goal as seen in the previous campaigns.

 

Currently 19 out of the 41 engines on Virus Total detect the attachement as malicious as a result there is ample coverage for this.

 

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

Anonymous

Spam Summary of Last Weekend
Posted: 07 Jun 2010 07:00 AM

Websense® Security Labs™ ThreatSeeker™ Network was busy last weekend, and detected 3 spam campaigns with millions of emails.

 

Confirm Twitter password, and Twitter security model setup

 

As variants of the Reset Your Twitter Password spam we blogged last week, these continued the attack and increased it in scale from 55,000 to 170,000. We have seen quite a few different subjects, including the 2 below which are the most frequently seen.

 

 

 

 

Facebook account deactivated, or invited by somebody famous?

Over 144,000 of this kind of spam email have been caught by our Hosted Email Security system. When a user visits the fake Facebook link offered in the email, their system is compromised by the Eleonore Exploit Kit and eventually is turned into a bot.

 

 

 

 

 

 

Outlook Setup Notification

 

At the time this post was written, over 106,000 instances of this campaign have been caught in our system, and the number is still increasing.

 

 

The statistics below show that spam increased by 15,700 daily on average during the weekend, compared to work days. It seems that some spammers didn't take a break last weekend.

 

 

Websense Messaging and Websense Web Security customers are protected against these attacks.

 

Adobe 0-day vulnerability in Flash, Adobe Reader and Acrobat (CVE-2010-1297)
Posted: 07 Jun 2010 05:29 AM

Adobe announced a new 0-day vulnerability in Flash, Adobe Reader and Adobe Acrobat over the weekend. The vulnerability lies in how Flash and Adobe Reader/Acrobat handles a specially formatted SWF file and the attacker can use this to automatically execute malware on the machine when the user just visits a website or opens up a PDF file.

 

 

Even though the vulnerability is in a Flash file it is possible to exploit it via PDF file as well as these documents can contain embedded Flash files that gets automatically executed when opened. So far there is no patch available except to update to the Release Candidate of Flash Player 10.1. A workaround for Adobe Reader/Acrobat version 9.3.2 and earlier 9.x versions is available by deleting or renaming authplay.dll in the installation directory of the application but this is obviously not an ideal solution. Adobe Reader/Acrobat version 8.x is not vulnerable.

 

The attacks we have seen so far has been targeted and it's not in wide use - yet.

 

Websense customers are protected against both the SWF and PDF attack vector.

Patrik Runald

Part2: Twitter malicious spam or Threat Cocktail
Posted: 07 Jun 2010 05:14 AM

Websense® Security Labs™ ThreatSeeker™ Network has detected another wave of spam posing as a Twitter password reset notification. So far we have seen over 170,000 emails,  all with subjects like Twitter 281-01, Twitter 137-40, and Twitter 260-96. The numbers in the subject vary.

 

 

 

The spam emails contain a link to googlegroups hidden under the Twitter URL. Once the link is clicked, the user is prompted to download a malicious executable called Twitter_security_model_setup.zip.

 

 

The attack is detected as malicious (SHA1 : 6c9e6494045dd450d3598f46f7dc78b5b2a3f1fc) and is currently recognized by 14 of the 41 engines on Virus Total.

 

The malicious file downloads rogue AV, which is a part of the "Protection Center" trend we saw on 3rd June, onto the computer. When it runs, it silently installs itself into the "ProgramFiles\Protection Center" folder. It also adds itself to the Start menu and places several files into the Temp folder, such as kernel64xp.dll, mscdexnt.exe, and wscsvc32.exe.

 

The threat pops up different warnings like this:

 

 

If the user clicks on the icon, it then installs the rogue AV:

 

 

After this it keeps displaying a warning about serious security threats on the computer even though there is no threat.

 

 

 

Also it creates several icons on the desktop, several of which are links to porn sites:

 

 

Once the computer is infected, there is a blended threat cocktail on the computer. The ingredients: rogue AV, porn site links, and spam and trojan agents.

 

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

Artem Gololobov

Upcoming Security Conferences in 2010
Posted: 04 Jun 2010 05:00 PM

 

Although not an exhaustive list of upcoming security conferences, here are a few of the conferences taking place this summer and into 2011 that we recommend. Many of our researchers are speaking at these conferences, so plan on seeing some of their talks. They will give you a glimpse into various research projects being worked on inside our labs.

 

   -- this symbol indicates that we'll be speaking at the conference

 

June

 


EUSecWest

When: Jun 16 – 17, 2010
Where: Leidseplein, Amsterdam, Netherlands

 

Presentation: DarunGrim - A Tool for Binary Diffing and Automatic Vulnerabilities Pattern Matching
Websense Security Labs Researcher: Jeongwook (Matt) Oh

 


SyScan Singapore

When: Jun 17 – 18, 2010
Where: Singapore

 

Presentation: An RIA Security Solution - Flash and PDF Threat Handler
Websense Security Labs Researchers: Ulysses Wang & Hermes Lei Li


July

 


RECon

When: Jul 9 – 11, 2010
Where: DoubleTree Plaza Montreal, Montreal, Canada

 

Presentation: Using Fireshark to analyze a malicious Web attack
Websense Security Labs Researcher: Stephan Chenette


The Next HOPE

When: Jul 16 – 18, 2010
Where: Hotel Pennsylvania, New York, NY, USA

 


BlackHat USA

When: Jul 24 – 29, 2010
Where: Caesars Palace, Las Vegas, Nevada, USA

 

Presentation: ExploitSpotting: Locating Vulnerabilities Out Of Vendor Patches Automatically
Websense Security Labs Researcher: Jeongwook (Matt) Oh

 

BSides Las Vegas

When: Jul 28 – 29, 2010
Where: Las Vegas, Nevada, USA

 


DEFCON 18

When: Jul 29 – Aug 1, 2010
Where: Riviera, Las Vegas, Nevada, USA

 

Presentation: ExploitSpotting: Locating Vulnerabilities Out Of Vendor Patches Automatically
Websense Security Labs Researcher: Jeongwook (Matt) Oh

 

August


SyScan Taipei

When: Aug 19 – 20, 2010
Where: Taipei, Taiwan

 

 

September

 

SOURCE Barcelona

When: Sep 21 – 22, 2010
Where: Museu Nacional D’art de Catalunya, Barcelona, Spain

 


BRUCON 2010

When: Sep 24 – 25, 2010
Where: The Surfhouse, Brussels, Belgium

 

Presentation: Fireshark - Linking the Malicious Web (NG)
Websense Security Labs Researcher: Stephan Chenette

 

SyScan Vietnam

When: Sep 25 – 26, 2010
Where: Ho Chi Minh City, Vietnam

 


Virus Bulletin

When: September 29 - October, 1 2010
Where: Vancouver, BC, Canada

 

Presentation: P0isoning the social web
Websense CTO: Dan Hubbard

 

Presentation: Categorizing the entire web with autonomous system numbers
Websense CTO: Dan Hubbard & Websense Security Labs Researcher: Saeed Abu-Nimeh

 

October

 

MaLWARE 2010

When: October 20-21, 2010
Where: Grand Hotel De La Reine, Nancy, France


November

 

PACSEC

When: November 10-11, 2010
Where: Aoyama Diamond Hall in Tokyo, Japan

 

 

December

 

RUXCON 2010

When: Dec 4 – 5, 2010
Where: Royal Melbourne Institute of Technology (RMIT), Melbourne, Australia

Anonymous

Reset your Twitter Password malicious spam
Posted: 03 Jun 2010 11:18 AM

Websense® Security Labs™ ThreatSeeker™ Network has detected a spam posing as a Twitter Password Reset Notification.  We have seen about 55,000 instances of this malicious spam email so far. 

The spam contains a link to a compromised Web site that, when clicked or pasted into the browser, prompts the user to download a malicious executable named password.exe.  The executable turns out to be a rogue AV called Protection Center Safebrowser.  What distinguishes this rogue AV from the others is that it actually displays on the user's desktop some of the malicious files it installs.  This makes the attack notification more believable. 

 


The attack is detected as Trojan.Generic.Win32 (SHA:0b00649c14b96219dd080a0ce6492c4d04c7f45c) and is currently recognized by 19 of the 41 engines on Virus Total.

 

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

Mary Grace Timcang

Crypto-Analysis in Shellcode Detection
Posted: 03 Jun 2010 03:32 AM

Probably the biggest computer threats nowadays are the Exploits. Exploits seek out the vulnerabilities of an application to launch their malicious activities. Cyber criminals target popular applications such as Shockwave Flash and Adobe Acrobat PDF to keep the chances high that a user's computer is vulnerable. In this blog we will examine a Flash exploit using a very simple crypto-analysis technique we call X-ray.

 

Crypto-analysis of malicious code is not a new technology or invention. It has been used in fighting MS-DOS viruses since the '90s. This article provides an in-depth, detailed discussion on this subject, explaining how it works and how it can be used for malicious content detection in shell code.

 

First we need to understand the X-ray technique and how it works, and then we can see how it helps us to analyze and detect malicious content in shell code. X-ray is basically a differential crypto-analysis method which is a very easy way to attack simple encrypted data. What we assume is that when a simple block encryption algorithm is used, the difference between the consecutive data blocks remains the same.

 

One very good way to explain this is to encrypt a picture and then try decrypting it. Take a look at this picture:

 

 

The picture does not tell us much, except that we can see that it is encrypted. It looks random enough, even though we can spot some repetition. In fact the algorithm used is very simple stream ciphering with some avalanche effect. The result is a picture that suggests very little about itself. However, when we generate the difference in between the consecutive bytes, we get this:

 

 

Ah-ha! Now we see that this is the logo of our secret weapon against Internet threats.  :-)  (See the original graphic below)

 

 

Now, no wonder it is called X-ray!  We may not see the 'skin', but we clearly see the 'bones'. The resulting picture is far from the original one, but is good enough to see what it was. Nice, but how does it work?

 

To understand, we need to get into the math behind cryptography. Take a look at this very simple block ciphering algorithm. We have a message of:

 

Where M is the n length of plaintext message and m is the block of the message (typically a character).

 

In order to get the ciphered message of:

 

Where C is the n length of ciphertext (encrypted) message and c is the block of the message (typically a character),

 

we need to apply an encryption to each one of the message blocks using the same key:

 

Where E is the encryption algorithm using k key.

 

When E encryption algorithm is a simple XOR using the same k key on each block, then

 

 

the (above) formula gives us the encrypted stream. Usually we see this simple method in shell code with byte size blocks. In other words, each one of the characters of clear text is simply XORed with a constant (see the pseudo code). The reason this kind of encryption is so popular is that it is easy to understand and it is also easy to obfuscate the data and the code sections enough to avoid detection by a simple string detection engine.

 

 

Now we can note that a simple differential analysis will easily decypher this kind of encryption:

 

 

Why? Because:

 

 

Because XOR is commutative, we can remove the brackets and reorganize the equation to:

 

 

We know that:

 

 

Therefore:

 

 

As we can see, a simple block ciphering does not provide strong encryption. And because simple block ciphering is widely used in exploits, we can easily break those by decyphering known text or binary content in them. To put the theory in practice, let's take a look at this simple decryption loop taken out of shell code used in an SWF exploit:

(MD5 of the sample: 32398CBF94CA9B42E0B415BB93B00CFE)

 

As we can see, the code uses byte size blocks and a simple XOR ciphering with a constant 0x3D. Inside the code we can also see a pattern starts with some 0x3D following by a text "UIIM":

 

 

We might suspect that is an encrypted URL starting with "http://". Now that we know the algorithm and the encryption key, it is easy to double check if our suspicion is correct. The question is how do we find this string without knowing the key?

 

Do you remember the differential attack? All we need to do is to take a known text, which is "http://", and create a stream of differences:

 

 

 

 

Similarly, we create a difference on the encrypted stream:

 

 

 

 

And then, if we can find ΔM in ΔC, then we have what we are looking for. Obviously, the longer the known text, the less prone it is to falsely detecting the string.

 

The next step is to determine the key, and decipher the entire URL, which is very simple by just doing an XOR on the first detected block and the first block of the known text:

 

 

Knowing all of this, we can now write a simple analysis tool that can find and extract 'interesting text' from a binary file. As an example, here is the output of a small Perl hack I wrote earlier (see the script attached below):

 

 

The good thing about this technique is that we have to generate the differential set from the known text set only once in the lifetime of the application. Also, we need to generate the differences of the scanned shell code only once to check all the known text from our dictionary. Our dictionary therefore can be huge, including not only known and unknown URL patterns, but binary sequences that can identify each type of shell code we already know.

 

So far so good, however, life would be too easy if all of our work was finished now, yes? Many times, we see the shell code in compressed and otherwise obfuscated format. For example a Flash file could be compressed, or in a PDF file each stream can be compressed and encoded in different ways, which than can contain obfuscated JavaScript code that holds the shell code. The detection or analytics engine therefore first needs to do all the necessary transformations and de-obfuscations in order to be able to analyze the shell code. Maybe this is one of the reasons we can see simple encryptions most of the times.

 

Although in reality we see mostly simple block ciphers in exploits, there are many examples in viruses and trojans of much more sophisticated encryptions. These use a variety of block and stream ciphers with different length encryption keys, even applying more than one algorithm on top of each other to harden the encryption. Breaking such ciphertext requires more complex method, however, due to constantly increasing computing power, it is even possible to attack the DES algorithm. The good news is that even when stronger encryption has been applied, we have better techniques to detect malicious content.

 

More Posts « Previous page

©2013 Websense, Inc. All Rights Reserved.