Yesterday's post titled "New Year themed Malicious Email on the Prowl" and the emails mentioned were an early campaign done by what's now believed to be Storm v3 or Waledac v2. As our friends over at ShadowServer mention the campaign has now changed to be much more basic:

The URL in the email leads to lots of different sites, all compromised, where the user is immediately redirected using a <meta refresh> tag to one of the following domains:

bethira.com
bitagede.com
cifici.com
darlev.com
elberer.com
envoyee.com
leolati.com
makonicu.com
scypap.com
suedev.com
teddamp.com

Once on that page the user is presented with a really simple page that just asks them to download a fake Adobe Flash player:

This simple page is not really what we've come to expect from Storm/Waledac who in previous attacks have used professional looking websites very relevant to the theme they've used. Here are some example:

Halloween theme

NFL theme

Krackin' theme

Kitty Greeting Card theme

In very few cases we have seen the page contain an obfuscated JavaScript that try to use exploits to push the file to the user's PC. In most cases however the user is redirected again after 5 seconds, this time to a site that serve exploits although this site is not available right now.

A few other noteworthy things about this attack:

• The domains it uses to serve the malware are fast-fluxing which means that when you request the URL it redirects to you a different IP address every time
• The file itself is either server-side generated or just updated very frequently
• AV coverage is pretty bad - 6/42 (14.3%)

The spam campaign itself is still ongoing and we'll keep monitoring this over the weekend to see how if the attack changes.

Websense Security Labs™ ThreatSeeker™ Network has discovered a slew of New Year-themed malicious email circulating today.  Websense customers are protected proactively against this ongoing malicious spam campaign by ACE, our Advanced Classification Engine.

As illustrated above, the email has an image urging the user to update their Flash Player. This is an effort to deceive users into clicking the image which then prompts them to download what turns out to be a fake Flash Player installer. 

This malware [MD5:d35d7c8d74b83fa80dd1458d40c91799] is currently recognized by 11/43 AV engines in VirusTotal.

Subjects in this malicious email campaign include:

• GCARDS New Year
• Greeting Cards
• Greeting Postcard
• New Year
• Happy New Year 2011!

An interesting tactic that spammers used in this campaign is the use of the HTML comment tag.  While this is not new, it hasn't been as popular as invisible text which we have been seeing for a while now.  Needless to say, this is yet another effort by spammers to evade detection by anti-spam engines.

Below is a simpler variation of this malicious email.  The link provided also prompts users to download a fake Flash Player installer.

And some Web sites will be a lot safer! While reviewing incidents and deobfuscating a Web site today, I discovered an installation of a particular exploit kit that won't work after New Year's Eve.  The site I found caught my attention because the code simply looks like garbage.  As the saying goes, "One man's trash is another man's treasure."  So I started digging into the obfuscation of the code and found something that I thought would be topical considering today's date.  The code in this exploit kit will actually expire at midnight on New Year's Eve local time!  In this post, I'll cover how I came across this and show you how and why the exploit kit installations will expire.

Here is a screen shot of the code in the original state as I found it:

You may notice right off the bat that there is a Java exploit in there, but the focus of this post is in the obfuscated script that is meant to exploit the client browser.  If you have read any of my previous blog posts, you know that I tend to zero in on long streams of data in an obfuscated script.  More often than not, that is where the multiple exploits of an obfuscated script live, and also usually where the deobfuscation routine can be found.  So let's have a look at that part of the script and beautify it a bit so that we can see more clearly what is going on.

Here is a screen shot of the part we want to focus on:

The attack script is obfuscated in the var w declaration above.  We can see that variable holds a long string of digits. We can also see that there is a masked String.fromCharCode a little further down in the script.  Right away, we might assume that this is a simple character code obfuscation, but with numbers like 1001, 1361, 426..., this assumption would be incorrect.  Just looking at the script for a bit, we can see what is going on for the deobfuscation.  A loop is using String.fromCharCode to generate characters from the difference between the latter half of w and the first half of w.  However, this is not the focus, and the funny part, of this blog posting. 

When you look at the above script, you can see that the Date() object is used to get the current date from the client JavaScript engine.  Later, we see that the object iilq, which is where the date is assigned, uses the getFullYear() method and subtracts 1 from the current year.  Up until December 31, 2010 11:59:59 local time, this resutl will be 2009.  At this point, var qgy looks like e2009al, so we can see that this variable is meant to be a masked eval.  To be used as an eval, this variable has to be unmasked, which is done in the following statement of .replace("2009","v").  The whole execution of the attack script depends on this eval. So what happens in 2011?  The varable will remain a masked eval (which will look like e2010al) because the following .replace will not work, which in turn renders the script benign! 

Here is what the attack script will look like until December 31, 2010 11:59:59:

In conclusion, we can only assume that this was an unintended mistake by the exploit kit writers and that it will probably be fixed.  However, I'm sure they were unaware of this mistake, as the obfuscation of their attacks is probably contracted out, or they use off-the-shelf software to obfuscate their kits.  Come New Year's Day, we will all be just a little safer out on the Web because of this!  Happy New Year all!!

As part of my research within Websense Security Labs, I collaborate with a group of researchers tasked with profiling exploit kits.  This helps us refine the analytics used in ACE, our Advanced Classification Engine.  In this post I want to cover the installation of Phoenix Exploit's Kit.  I'm not going to tell you how to install and use it, but I will cover some of the more interesting aspects of installation.  Specifically, I want to cover how the developers protect their code from being reverse engineered and how the developers have attempted to keep researchers from poking around in installed kits. 

To begin, let's have a look at the installer for the kit.  Like many exploit kits, this one is PHP-based but unlike most kits, the installer is actually obfuscated.  This is probably an attempt by the developers to make it harder for security researchers to understand how to install the kits, especially if there is no 'readme.txt' file included in a kit.  Typically, exploit kits come with some sort of installation and or revision documents which come in the form of a 'readme.txt' file or 'notes.txt'.  Without the readme file, it can be difficult to install a kit unless you reverse engineer the installation process.  Most of the time, the reverse engineering of kit installation is pretty easy because the PHP code is not obfuscated.

Here is a look at the obfuscated code in the PHP installer:

Looking at this code, we can see that it's Base64 encoded and a ZLIB compressed stream of data.  The PHP script uses an 'eval' statement with 'gzuncompress' and 'base_64decode' functions to decode the stream of data.  For us to get the clear text code, we can use a simple substitution trick along with the PHP CLI so that we can then analyze the installer's code. To do this, we simply need to replace the 'eval' with a 'print' and run the install.php script on the command line. 

Here is a snippet of the deobfuscated install.php script:

Looking at this code, if you're like me, you might think that the interesting thing about it is the variable declarations with long base64 encoded streams.  It actually turns out that each one of those variables is holding obfuscated PHP code for the page for which the variable is named.  For example the '$config' variable holds the base64 encoded 'config.php' file and the '$activate' variable holds the 'activate.php' code, which we will get to in a bit.  This is where things get interesting, as far as protection mechanisms go.  The reason that the PHP code for each of these scripts is held in a variable is because the page names actually get randomized for each installation!  This helps to prevent security researchers from easily finding and possibly viewing statistics about the site hosting a Phoenix Exploit's Kit.  Prior to the version being analyzed here, Phoenix came with standard page names so once the exploit page was found, it was easy to find the statistics page and try to break in to view stats from that particular installation. 

Here is what the install looks like when it's visited from the browser:

As you can see, when viewing the installer from the browser, there is really nothing special about it.  You get to choose the language of the installation instructions, either English or Russian. And on the next page you have a form to fill out for various resources.  I'm not going to show you this form for the reason that it contains sensitive information.  However, I will show you the result after filling out the form so that you can see the randomized page names and what has to be done to activate the kit.

This is a look at my current working directory before the install of Phoenix Exploit's Kit:

Here is the same directory after the completion of the install script:

As you can see, the install script contains just about everything needed to install the kit.  It extracts the necessary scripts and randomizes the file names, and thus the purpose of the file.  If you have a look at the code in each file, you can begin to figure out the purpose of each file.  The thing to notice and realize from here is that each installation creates unique names for each of the pages.  Again, what this means is that a researcher can't find statistics for an installed kit after finding the page serving up the exploits.  Rather, for any given kit installed in the wild, it's anybody's guess as to the names used for statistics and other pages used by that kit! 

Regarding the installation we've been examining, at this point the kit isn't at all usable because it doesn't yet contain the exploits.  To obtain the exploits, the purchaser of the kit must contact the developer to activate their kit.  The "installation success" page explains this: "To activate this installed copy of Phoenix Exploits Kit please send the following activation string to the author."

Here is a screen shot of the installation success page:

In summary, we can see that the developers of Phoenix Exploit's Kit are working on not only protecting their exploit code from being recognized, but also their installations.  This makes it difficult for researchers to further dissect and understand how the kit works, especially if a researcher comes across just the install script.  It also makes things more difficult for others who want to study and report on the statistics found from individual installations of Phoenix by randomizing the page names used in the kit installations.

Two different new zero-day exploits were published on December 22.  Remote attackers could use these exploits to take complete control of a vulnerable system. Websense Security Labs is monitoring the situation, and we will update this blog post as we discover more. Websense customers are protected by our real-time analytics in ACE. 

The first vulnerability CVE-2010-3971 targets the way Internet Explorer handles Cascaded Style Sheets (CSS). When parsing an HTML page that contains a recursive CSS import, some memory is released but later referenced and re-used, and can lead to arbitrary code execution. All Internet Explorer versions 6, 7, and 8 can be affected by this vulnerability. The effectiveness of the exploit on Internet Explorer 9 hasn't yet been verified.

The use of built-in protections of DEP and ASLR on the Windows platform and Internet Explorer doesn't guarantee to stop the exploit. It stems from the fact that the affected DLL mscorie.dll used by Internet Explorer wasn't compiled to support ASLR - this fact allows an attacker to also bypass DEP by using ROP (return to oriented programming) and successfully exploit the system. Microsoft offers other ways to mitigate this vulnerability before a patch is released in their blog. You can find more information about the vulnerability in the security advisory released by Microsoft.

The second vulnerability takes advantage of the Microsoft WMI Administrative Tools ActiveX Control. Internet Explorer is vulnerable only if Microsoft WMI administrative tools is installed. The vulnerability is the result of a design flaw where the AddContextRef() and ReleaseContext() functions of the WMI Object Viewer control can be passed an object pointer that can result in arbitrary code execution. An Internet Explorer user with WBEMSingleView.ocx installed can be exploited by visiting a malicious Web page. If the ActiveX control is installed, the vulnerability can be mitigated by applying the kill bit on the affected CLSID {2745E5F5-D234-11D0-847A-00C04FD7BB08}.

Both vulnerabilities were first disclosed by WooYun.org.

Metasploit added modules for the two vulnerabilities. For more information, see MS11_xxx_ie_css_import and WMI_admintools  

It's that time of the year again where we peak into the future and predict what we believe will be the top threats for the next 12 months.

Prediction #1: The Stuxnet sequels are coming, stay tuned for “When State-sponsored Malware Attacks!”

• Stuxnet targeted critical industrial infrastructure, but it was only a preview. Based on how long it takes to develop complicated attacks like Stuxnet, we predict similar exploits will be carried out once or twice in 2011. These state-sponsored offenses will test national infrastructure systems to determine what is effective for future attacks.

Prediction #2: Only the strong survive blended threats. Companies will struggle to stay secure while covering more ground.

• Blended threats like Zeus and SpyEye will continue to evolve and use a variety of delivery methods. Today’s threats are no longer binary files delivered in attachments; they are script-based or are embedded within rich media. Many spread rapidly through social media.
• Strained IT departments will need to defend more territory and allow more access, despite these increasingly sophisticated threats.

Prediction #3: Status update: More corporate data breaches will occur over social media channels.                                                      

• Search poisoning won’t be limited to Google, it will migrate to Facebook. Hackers will manipulate Facebook search algorithms to trick users into visiting fake brand and celebrity pages and increase exposure to malware.
• Employees will post confidential corporate data to public pages.
• Social media users will also be vulnerable to spam and malicious data-stealing content.

Prediction #4: You down with DLP? Malware exploit kits will add zero-day vulnerabilities faster, increasing their use in drive-by download attacks.

• As more targeted attacks are researched, more zero-day vulnerabilities will be discovered.
• Data loss prevention and up-to-the-minute threat protection will become increasingly more important as organizations work to keep malicious content out and corporate information in.

Prediction #5: Is there an app for that? The iPad, iPhone and other smartphones will be prime targets for cybercriminals.

• Mobile devices are a gold mine of personal and confidential data. Cybercriminals will successfully use mobile drive-by download attacks to steal confidential data and expose users to malicious content.
• Many of next year’s mobile attacks will exploit the mobile Web browsers in the iPhone, iPad and Android-based devices. Rogue applications will also increase in number and sophistication.

Agree or disagree? Let us know via comments.

Month of November

Major Hits

Amnesty International's Web site in Hong Kong was compromised and was attempting to infect its visitors using various exploits for Adobe Flash, Adobe Shockwave, Apple Quicktime, and even the latest zero-day for Internet Explorer. In other parts of Asia, India's number 1 financial portal (moneycontrol.com) was also compromised and injected with a malicious iframe.

Malicious hackers capitalized on important local and global events, such as midterm elections (US), Veteran's Day (US), and Prince William's engagement (UK), to infect more Web users via poisoned search engine results. This scam is of the usual garden variety: fake antivirus Web sites, or sites offering fake Adobe updates and fake Firefox updates, which prompt a user to download an .exe file that is really malware.

Web 2 dot uh oh

Google recently launched "Google Instant Previews," a new service that aims to give Google-rs a bird's eye view of what the site they are about to visit looks like.  This service should initially protect users against unwanted content, but our research proves that it could mislead users when snapshots used in the service are not as current as assumed.

Social engineering is the game in Facebook this month. Our Defensio Facebook App spotted scam wall posts containing a link that attempts to post on the victim's behalf.  Phishing messages claiming to be from Facebook Security warn that a user account will be deactivated unless it's reconfirmed.  The phishing page itself is either loaded from within Facebook via iframe or redirected from the link provided in the message.

Browser and friends

Adobe released a security update for Adobe Flash Player in early November. Eighteen security holes have been patched, including vulnerability CVE-2010-3654, which is a zero-day vulnerability in the wild found in October.

Another zero-day vulnerability (CVE-2010-4091) has been identified in Adobe Reader 9.4 (and earlier versions) and Adobe Acrobat 9.4 (and earlier versions). A proof of concept has been published that it could lead to a Denial of Service, although that has not been demonstrated. Arbitrary code execution may be possible. Adobe patched the hole in 2 weeks; the security update is here.

A vulnerability in Shockwave Player has been discovered. Successful exploitation allows the execution of arbitrary code, but a user must be tricked into opening the "Shockwave Settings" window when viewing a Web page.

Google patched several high-risk vulnerabilities in Chrome 7.0.517.44. A $7500 award was paid out of Google's new vulnerability reward program.

A Denial of Service vulnerability has been found in Firefox 3.6.12. The proof of concept is published here.

The recent security update for Safari 5.0.3 and 4.1.3 contains 27 patched vulnerabilities. More than 40 vulnerabilities have been patched in iOS 4.2. Click here for details.

Microsoft

This month's round of "Black Tuesday" Microsoft patches was rather light, but contained fixes for some particularly severe issues.

On the unpatched side, Windows is currently vulnerable to 2 known privilege escalation exploits, one of which was found in a kernel API, allowing users to bypass user account control (UAC) entirely. The second, an exploit originally used in StuxNet, attacked the Windows Task Scheduler.

Internet Explorer once again finds itself host to an actively exploited bug (CVE-2010-3962) caused by a dereferencing error.

Hello ThreatSeeker. You've got mail!

An increase in the number of phishing emails has been a focal point over the course of this month. Most of them seem to be directed attacks at Email Service Providers (ESPs) in order for the attackers to gain access to "industry-grade email deployment systems" to do their bidding.  Spear-phishing, as it is known to most, is on the rise with several of these messages having the look and feel of legitimate requests to the unsuspecting user.  Like most of the email campaigns reported in the past, the format is usually the same: A user is lured into clicking a link within an email or to open an attachment, which results in the machine being infected.

Also in this month, with the release of the new, improved version of Adobe Reader, came the recycled phishing email messages enticing and advising users to upgrade  their readers to the newer version with all the bells and whistles.  As reported in Lenny Zeltser's blog, the format of these messages did not change much.  These types of email messages are not new, although it is interesting to note that cyber-criminals are keeping abreast of current changes and news and taking advantage of them.

Security Trends

A new version of the GpCode ransomware has been detected, using RSA-1024 and AES-256 as crypto-algorithms. It is now stronger than before, because it overwrites data in the files instead of deleting it after encryption, so users cannot get data back by using data-recovery software.

Google announced an experimental new vulnerability reward program that applies to Google Web properties. Google said it would pay the bounty for any serious bug that “directly affects the confidentiality or integrity of user data.”

Adobe released the Reader X version on November 19, 2010. A built-in sandbox feature has been implemented to contain the damage from potentially malicious PDF files. Adobe's blog posted a multi-part series about the new sandboxing technology used in the Adobe Reader.

A security researcher named Nitesh Dhanjani has discovered that a rogue Web site, or a Web site whose client code may have been compromised by a persistent XSS, can pull the user out of the Safari browser in iOS. A malicious Web site can initiate a phone call without the user's explicit permission with the us of insecure handling of URL Schemes. He also discusses a particular UI Spoofing behavior of Safari on iPhone, The consequence of full screen apps in iOS using UIWebView as the default Web browser on iPhone means the UI can display the fake URL bar on a page while the real URL bar is hidden.

This month's roundup contributors:

• Jay Liew
• Lei Li
• Grace Timcang
• Ulysses Wang
• Amon Sanniez
• Paul Westin