SophosLabs blog

Shortcut exploits have made the news in malware circles this month. After Stuxnet first used them, it wasn’t long before other malware started exploiting the zero-day vulnerability - Sality is among their numbers.

The authors of the Sality family added a new executable component, which we detect as Troj/Sallink-A, that enumerates network resources, dropping two files where it can. The first of these is a DLL file, detected as Troj/Salload-D, the other a LNK shortcut file, detected as Exp/Cplink-A. Simply browsing to the folder containing the LNK file will automatically execute the DLL file - that’s the nature of the CVE-2010-2568 vulnerability.

Different variants of Troj/Sallink-A format their payload in slightly different ways. Most drop the DLL using a filename consisting of random letters and numbers (usually ‘a’ to ‘f’, and ‘0′ to ‘9′), with earlier variants using <random>.dll and later ones using ~<random>.tmp or w<random>.tmp. For the shortcut file, earlier variants used the simple <random>.lnk, while later variants moved to using a wide variety of click-enticing names - for a full list, see the “More Information” tab of Troj/Sallink-A, but filenames include “My Photos.lnk”, “Gallery photos.lnk”, “XXX.lnk”, “Britney Spears XXX.lnk”, “Barrett Jackson nude photos.lnk”, and “Miss America Porno.lnk”.

I’m not quite sure why they’ve gone out of their way to give these the sort of filename that get people to click them, since the whole point of this vulnerability is that you don’t have to click the shortcut - in fact I’d say most of these names are far more likely to arouse suspicion on a network. But then, that’s what you get if you just steal a list of names from other malware - most of the names are recognisable as having been used by the Bagle family of malware more than 4 years ago.

For good measure, Troj/Sallink-A also tries to drop the LNK file to all subdirectories of the network share, maximising the chance that someone will browse there and trigger the DLL-executing exploit. When run, the DLL tries to contact a remote URL, and to drop a file to <temp>\<random>.exe - this is the main Sality component, which goes on to infect files, and to spread to all available drives (including USBs) and network shares. We detect this component as Mal/Sality-D.

In fact before the authors had even sent out the first dll-dropping exe or exe-dropping dll, we detected all of these files as Mal/Sality-D - we’re now using the names Troj/Sallink-A and Troj/Salload-D to help differentiate components of the chain, but we’ve always protected against them all.

It’s a bit surprising to see a malware family that concentrates on a rather old-school file infection keeping on top of new vulnerabilities, but clearly someone in their gang is reading the news - earlier in the month they sent exploited PDF spam, so (ab)using exploited LNK files is an obvious next step. It’s a shame the authors don’t spend more time on the actual virus itself, since it still has a nasty habit of corrupting files during infection.

Even once Microsoft releases a patch for the vulnerability, history has shown that lots of people won’t apply it with any due expediency, so it’s a safe bet that we’ll see more malware exploiting this in the future. We’ll continue to update our main shortcut exploit page as we get more information, and you might also want to download our Windows Shortcut Exploit Protection Tool to help keep you safe until the vulnerability has been patched.

I have to admit that I am not a huge fan of Las Vegas, but, when the reason to visit is as good as attending Blackhat and Defcon I instantly forget the heat, endless rows of slot machines, big crowds, kitschy hotels, bars and everything that makes Vegas, Vegas. I have missed the last two Blackats but I am glad that I am back and that not many things changed. Despite the huge number of delegates, Blackhat briefings were organised like a well oiled machine so every kudos goes to the crew. I am glad that Blackhat, despite the name, became a conference which equally addresses and promotes the offensive and the defensive side of the computer security.

Though some sessions I attended were a bit of a hit and miss, mostly because of the less than ideal presentation skills of the presenters, not the technical content of the sessions I can say that I thoroughly enjoyed seeing the enthusiasm which exuded from every single presenter who gave their best to show their work.

The highlight of the day one was the presentation by Barnaby Jack which successfully showed that ATMs are just computers, like any other and that by learning about their functionality it is possible to remotely compromise their operation. This can become quite a serious problem, especially if the attackers find an easy way to modify software running on the system. Big crowds attending the session had every right to be impressed by the show. Several good videos of Barnaby Jackpotting ATMs on the stage have been posted on Youtube.

I was particularly interested to attend sessions concerning malware analysis and reverse engineering techniques, and see if we can get new ideas and tools to use in Sophoslabs. Some interesting tools, such as Berkley University BitBlaze are already available and some others such as excellent VMM based debugger Virt-ICE are in relatively early stages of development showing good potential for future usage for malware analysis.

For me, another interesting area was the increased attention to smartphone platforms, primarily Android based devices and iPhones. We often discuss the protection techniques for smartphones and question the need to develop an anti-malware software for them and conclude that there are relatively few threats to warrant fully functional anti-malware protection, especially in a corporate, managed environment.

Kevin Mahaffey and John Hering from Lookout security have conducted an interesting research into functionality of all free applications available through Android Market and Apple App Store and found out a significant number of applications, developed by few developers which are developed with a clear intention to steal data available on the device and send the data to a central server managed by the developers. Malware? Maybe. Spyware? Certainly. Unfortunately, both Google and Apple are currently in the stage of threat denial and do not provide documented programming interfaces which would allow security vendors to create reliable protection for the platforms. Let us hope they are right and that they will be able to make sure that all applications published through their respective Application stores will always be free from malicious intent. I am a bit of skeptic on that front, but that may just be me.

On the corporate front, it is obvious that Microsoft is making a better job of handling vulnerabilities discovered in Windows, despite the recently discovered feature/bug in Windows handling of shorcuts to control panel extensions couple of weeks ago. Great news is that Adobe has decided to jump on the bandwagon and coordinate the incident response with Microsoft. Members of MAPP, including SophosLabs should be pleased to learn that technical information about issues in Adobe software will be distributed to all members through the channel already used to distribute information related to vulnerabilities in Microsoft’s products.

I am off now to the positive madness of Defcon and will make sure to let you know about the sessions I particularly enjoyed.

Every now and then we at SophosLabs receive a sample of malware or spam that (laughs aside) shows the true inventiveness of the spammers and malware authors.

During the World Cup I received some SMS spam on my phone but this week’s spam sample was even more sophisticated! (And by sophisticated, I mean lowbrow, grass-roots, snail-mail con-job, low-tech and yet probably more effective than regular email spam.)

I mean, what spammer would spend the time to type up a letter using some official looking letter head, sign and stamp it to add that official feel and even pay for postage! Dedication++ suggests the tangibility and effort might be paying off - but how different is this from your regular run-of-the-mill email spam (apart from the much reduced volumes)?

Fancy stuff aside, the letter boils down to the following 419 cliché - A random barrister is asking you to commit fraud in order to claim an inheritance of a sizeable amount of money, and of course the transaction and details are of utmost secrecy. It even has an apology incase you’ve been offended by the idea of committing fraud to pocket someone else’s cash!

Divulge your details and I assure you the only thing you’ll be getting is likely to be a call from your bank manager.

Now I guarantee that no anti-spam product on the market will stop this type of campaign. Luckily, due to its nature, it is of low volume - however, if you have received such a request, you may wish to have your local federal investigators examine it, or utilize the SophosLabs approved in-house anti-spam solution as shown below.

Q. What is the average size of a typical malware file?

Of course there is no definitive answer to this question, and different kinds of malware can have vastly different sizes, but for those wanting an answer I ran a quick calculation over some of SophosLabs’ monthly collections of malware samples.

In January 2005 the average size of a malware sample was 126 kB. In June 2010 it is 338 kB.

This growth in size is pretty much what one would expect, and can be for several reasons. Long gone are the days of hand crafted assembler code designed to be as small as possible. As computer memory, disk space and internet bandwidth grow, so does the output of a typical compiler. Software libraries become larger, and software (both legitimate and malicious) tends to contain increasing amounts of complexity and functionality.

Q. Can you give some examples for specific kinds of malware?

Troj/JSRedir-BV is an obfuscated Javascript, typically seen attached to spam email messages. If the attachment is opened the web browser will be redirected to a scam web site. Such redirection could be done in one line of Javascript, but due to the heavy obfuscation used a Troj/JSRedir-BV script is typically 3 kB to 5 kB in size.

Mal/Dloadr-Y is a downloading Trojan with functionality to change firewall settings, download a configuration file from a remote website, then download further malware as dictated by the configuration file. Samples of Mal/Dloadr-Y are typically 25 kB to 30 kB in size.

FakeAV Trojans are rogue anti-virus applications that display fake infection warnings to try and scare users into paying for cleanup. There are many different families of FakeAV, and even within a family there can be a large variation in size. For example, samples of Mal/FakeAV-DO range from about 300 kB to over 1 MB. These variations are partly because FakeAV authors frequently change packing or encryption techniques. Furthermore, in some cases each sample contains random amounts of junk data in an attempt to evade detection.

Viruses, although often relatively small in themselves, can infect legitimate applications of any size. For example, a typical variant of W32/Scribble-B contains about 20 kB of viral code, but infected applications can be just a few kilobytes or many megabytes in size.

W32/Scribble-B also injects a malicious iframe into htm, php and asp files. The iframe is just one line of html (about 80 bytes) but the infected web pages can be of any size. However, the iframe is always added at the end of the file, so it is easy to find and is detected as Troj/Fujif-Gen.

Q: As Malware gets larger, does Sophos’ scanning get slower?

From a customer point of view, this is the wrong question. Whilst SophosLabs has an ever increasing collection of malware (and increasingly powerful hardware to extract and analyze lots of data from it) the existence of malware on a customer machine should be a pretty rare thing. If the virus engine spends a few milliseconds identifying a malicious file that is no big deal. What matters is that it scans over a typical clean file in not milliseconds but microseconds. So the real question is: as legitimate software gets larger does SAV get slower?

Actually, individual file size has very little impact on Sophos’ scanning speed. Here in the labs we put a great deal of thought into optimizing the performance of our detection identities. Instead of linearly scanning through whole files for fixed patterns, each identity targets only those parts of the file where it needs to look.

To take an analogy, suppose you have misplaced your cell phone. Rather than starting at one end of the house, and slowly working your way to the other, searching everywhere with a fine comb, you probably stop and think: Where am I most likely to have left it? Where did I last use it? Where have I been since then? There is no need to check the attic if you haven’t been up there all week. Quite quickly you will identify the most important places to look. Even better, if you have access to another phone you can call your cell phone, and listen out for where it is ringing from.

Sophos’ identities use all sorts of shortcut techniques like that. For an executable file, one obvious place to check is the point from which code execution begins. The virus engine automatically loads some of this code, and many identities start by checking it. If it doesn’t match an expected pattern then it doesn’t matter whether the file is 10 kB or 10 MB, many identities don’t need to look any further. Even identities designed to detect such nasties as polymorphic (changes every time, so there is no fixed pattern to look for), mid infecting (viral code is not at the entry point) viruses use a clever combination of emulation and statistical pattern checking to only scan in a few key places.

Q: Is there an upper limit on the size of file SAV scans?

I was quite surprised to learn that some AV scanners have quite stringent limits like this, presumably in order to optimize their scanning performance. Some even have a configurable global setting where you can chose between a low limit (better performance, but risks missing some malware) or a higher one (finds more malware, but slower scanning.)

That is far from ideal. We have already seen how different malware families tend to have different sizes. So in SAV, instead of a global file size limit, each individual identity can (if necessary) specify appropriate limits according to the kind of malware it is trying to detect. As we have already observed, an identity to detect a virus has to scan files of any size, but can be optimized by knowing what to look for and where to look. Meanwhile, many generic identities to detect particular malware families can make use of size optimizations. A typical family of internet banking Trojans might be, say, between 3 and 4 MB. That is just one of several pieces of information that an identity might use to quickly eliminate 99.9% clean files from further scanning. Further investigation will only happen on those files that warrant it.

(Image from codesignstudious.com)

If we start to see new variants of that family increasing in size then SophosLabs can at any time issue an update with new size ranges. Similarly we can update many other checks to reflect the changes we are seeing. That is the reason why many of our generic detections ask customers to send in samples. Even when we proactively detect a new sample, we want to keep monitoring trends and staying one step ahead of the game.

So Sophos customers do not need to worry about typical size of malware files, nor do they need to worry about setting file size limits. SophosLabs is always monitoring the trends, and making any necessary performance decisions for you.

With the recent launch of SAV 9.5 the labs are getting more data than ever before. Whenever a generic identity detects a file, the size of that file is one of the key pieces of data that can be automatically sent back to SophosLabs. Automatic feedback only happens if customers consent to that option, but we have been very pleased by the number of customers turning it on. Sophos is already a leader in proactive detection, and with this new feedback data we can fine tune that detection to be even better! Thank you for helping us to help you.

It is now Australian Tax Refund time again. And right on cue, spammers have re-emerged in producing phishing scams as they would never miss this opportune moment to steal money. So, what does this year’s taxation spam look like?

It appears the spammers have learnt one important lesson from past years and that is to stick to the Keep It Simple Stupid (KISS) philosophy. The scam message is only 732 bytes long and contains a few eye-catching phrases in both the subject line and the message body.

Hold on…. but where is the dodgy call-to-action? Where is the fake link? Where is the accompanying dodgy PDF document of yesteryears?

This time, it is nefariously hidden in the HTML attachment which contains only a simple meta refresh link. In this way, when the email is opened, the link in the message automatically (without any further user intervention) redirects the recipient to the following bogus Australian Tax Office (ATO) website, from where it will attempt to harvest the victim’s credit card information.

Will we be seeing more of these phishing scams? There’s no doubt we will. Be it from the UK or the USA, it appears that tax time is a very lucrative opportunity for spammers and phishers. As usual, it is wise to be extra careful of unsolicited emails, especially those that appear to come from the government.

And yes, SophosLabs has already blocked this kind of phishing scam.

Here at SophosLabs we have recently been seeing samples of Zbot (also known as the Zeus crimeware kit) that refuse to execute on any of our testing machines.

Often when this happens it is because the sample is corrupt or will only execute on specific versions of Windows, or maybe because the file will only run on a specific date, or because a certain payload is only activated on a certain date (e.g. CIH).

However, these Zbot samples have been crafted to ensure that they only work when executed on one specific machine and from one specific path. Any attempt to execute the sample on a different machine or from a different path will result in early termination of the malware and no impact on the target system.

This is achieved through a form of hardware based digital watermarking that makes dymanic analysis of the sample effectively impossible for AV researchers.

Older versions of Zbot (pre version 2.0), when first installed would copy their executable to a fixed location (%SYSTEM%\sdra64.exe), sometimes appending random amounts of data to the end of the file to avoid checksum based detections. Version 2 creates a new file with a random file name inside a new folder under the user’s %APPDATA% directory. It then deletes the original file with a batch script.

The new file is almost identical to the original file except for a small block of encrypted data at the start of the “.data” section. This block contains the hardware and pathname information that ties the sample’s successful execution to one location on one machine.

 
The block contains several key pieces of information including:

• A string that includes information from the Computer Name and DWORD values generated using the OS install date and product key.
• A GUID generated using GetVolumeNameForVolumeMountPoint and CLSIDFromString.
• The randomly named directory and exe file that the new file will be dropped to.

The block is then encrypted using RC4 and embedded into the new file which is written to disk and executed. When the new file is executed it decrypts the block, re-computes the GUID based on the information from the machine it is now running on, compares it to the decrypted value and exits if they differ. The current path of the executable is then also checked against the decrypted path information from the block.

So when the malware sample is discovered on the machine and sent off for analysis it will be executed on a new machine and generate a new GUID based on different hardware and OS information, which will fail the comparison and result in a sample that does nothing, causing AV researchers to scratch their heads and wonder what’s going on.

 
This sophisticated technique is very similar to hardware based licensing systems employed by major software companies to protect their products from piracy. But until now I had not seen the technique used to protect malware binaries from analysis.

Fortunately Sophos customers are protected by Mal/Zbot-U.

Zbots have been recently going through several changes in their infection method and functionality. One of the new samples though, caught my attention due to its naïve evasion tricks.

First the old static analysis mangle

The correct offset of the push below should be 0×0041b22d but IDA thinks this doesn’t make sense

so it decides that an instruction that makes sense is at 0×0041b22b which confuses disassembly after that. This though is a very old trick that happens to be easily repaired as the correct offset is in the byte code. So going to the correct offset and forcing a code analysis from there would fix the problem.

Another old trick is the use of the rdtsc instruction for anti-debugging , this time though its used as an anti-emulation trick !

As seen below the rdtsc is called twice and the results compared to check the time difference. This “time” is actually a representation of the number of CPU cycles executed since the processor was started . Normally the compare instruction would be there to check if the number of cycles is too large between the two rdtsc instructions , thus a debugger is being attached to the process. In this case though, its used as a weak anti-emulation trick as the actual processor would populate the registers accordingly, some emulators though wouldn’t , thus the jump instruction would always succeed due to the mov in between .

Upon detecting that it is being emulated it jumps to an invalid memory read instruction to cause an exception.

Sophos detects this threat as Troj/Zbot-TG .

Every AV product on the market in these days is furnished with an emulator which provides a safe sandbox for running executables files, before they get loaded and executed in the proper environment. By definition an emulator will never be exactly like ‘the real thing’, and malware authors continually try to exploit this fact in order to evade detection.

In that sense x86 machine code is not helpful for us, since it allows certain assembly instructions to be encoded in different ways. A nice list of some of these tricks can be seen here .

While analyzing in IDA the dropper component of a pretty famous rootkit, it was quite obvious that something weird was going on.

Courtesy of the square bracket at the end of the mov disassembly listing I could notice that
the SIB byte ( 0×25, 0×65, 0xA5, 0xE5) was used although it doesn’t have any real effect.
You’re free to swap those bytes and if you are in the mood of fixing the offsets of the code
around, you could replace it with a shorter encoding.

It’s quite evident that this is done intentionally in order to break emulation, since this sequence of mov instructions is at the entry point of this dropper, while a similar piece of code in this very same sample uses a more standard encoding.

There are four new releases in this months Microsoft patch release, of which the stand out item must be MS10-042 which is a fix for last months 0-day (CVE-2010-1885) which we saw a number of exploits for.

Although none of the others are rated higher than medium risk by SophosLabs users are still urged to apply these updates as soon as possible.

For the full details of this months updates and links to Microsofts own advisories check out our vulnerabilities analysis page.

AntiVirus users may not be aware just how much effort malware authors put into their creations.

The main aims from that side of the fence are to design malware that:
- will avoid any existing detections when first released
- must be easy to update, so that detections too specific can be avoided with new releases

The global strategy of these gangs consists of trying to make a single piece of malware last for as long as possible, making few changes on each update, in order to maximize their ROI.

For us the challange lies in identifying the base building blocks, that are not going to be changed, and thus provide a proper generic detection.

This week I stumbled upon a couple of Fake AV samples, from which you can
clearly see the ‘update as less as possible’ scheme in action.

In the first sample you can see how a value is assigned to both the variables in
an obvious way.

The second screen is taken from a more recent sample, in which the assignment to
var_8 is done in a different but still straightforward way, relying upon a specific
error code returned after the call to an API with specific parameters.

An analyst knows that this code will change again, with new APIs and other fancy tricks,
that’s why the key to success in catching malware is to anticipate future changes.

A few weeks ago Richard posted a blog about malicious HTML attachments we were seeing in spam. Well, the attacks have continued since then along much the same lines. For example:

Current attachments are being blocked as Troj/JSRedir-BV.

As noted before, if the victim opens the HTML attachment, the embedded script will run within the browser, and redirect them to a another remote web page (hosted within a legitimate but compromised site). Sophos products block this page as Mal/Iframe-Q. From there, the attack is two-fold:

• META redirect to some spammy site (Canadian Pharmacy and similar)
• malicious IFRAME loading further content from another site

In this post I wanted to highlight one of the tricks used in the malicious JavaScript within the HTML attachments. The script is minified and peppered with junk code, hindering readability, but after prettifying and removing the junk code, it is fairly simple. The decryption function is called via setTimeOut, and consists of a simple xor.

There is a cunning little trick in the script, designed to break JavaScript emulation tools. By calling the decryption routine via setTimeOut, the script is able to ensure there has been a sufficient delay. Most emulation tools will tend to ignore the setTimeOut delay, resulting in an incorrect xor key being generated, and decryption failing.

When correctly deobfuscated, you can see that the script redirects the victim with a location.href:

These attacks are just another example of the growing number of tricks being used within malicious JavaScript to evade generic detection and hinder automated analysis techniques.

Miss November 2010

Looking through news sites I encountered articles about a full-frontal pin-up calendar (“EIZO - Pin-up Calendar 2010″) that shows a young lady more exposed than any I have seen before. Yet this calendar is reproduced on various respectable websites. It is all part of a clever marketing campaign by LCD monitor manufacturer Eizo. Now after the initial laugh & giggle no one would seriously say that there is anything wrong or immoral about these pictures, but…

This strikes me as another one of those grey areas, literally shades of grey in this case. It is difficult to have a universal definition of what is legitimate for public consumption and what should be censored as pornography. Now obviously a skeleton of a woman is not pornographic, yet full-frontal pictures of a live woman in erotic poses is obvious porn. So when is an image unacceptably pornographic?

A little bit of exposed flesh is alluring, a lot is rude. If a picture can be pornographic when you can see the exposed outer micrometer of flesh, as displayed in PlayBoy magazine etc. Then is being able to see the rest of the flesh that is below the skin going to be more pornographic, or less? And what ever the decision, why?

Is it context that counts, as in the “is it art or is it porn” argument? In this case the erotic poses would suggest it is definitely pornographic. There is certainly no medical reason involved for these particular poses.

In some countries the laws have defined pornography as how much and what bits of flesh are exposed. The film industry suffered with actresses in bedroom scenes having the amount of exposed breast measured by a censor before shooting was allowed. Well these pictures certainly fail that test.

Miss August 2010

Sometimes laws define pornography as “that which may shock, offend or corrupt”. But that surely depends on who is present at the time. Some regions with this type of law allow people to walk to the local supermarket whilst completely naked, whilst others are very restrictive in their interpretation. So are these X-rays offensive or likely to corrupt you?

Legal definitions of pornography in general vary drastically. It can depend on where you are, what social group you are in, who you are with at the time, age, period of history, gender and so many other factors. In the end it usually comes down to the interpretation of an individual censor or judge.

If we have ruled out law, artistry & offensiveness as suitable definitions of what should define pornography then should it depend on it’s arousal. Should it be down to whether someone might choose to experience the material because of it’s sexual effect. After all that is what the other methods are trying to restrict, namely images or actions that might cause a sexual response. So do these X-ray images cause you to be aroused? Possibly an interesting question. But yet again there is the huge variance from person to person. After all there is Objectum sexuality or Objectophilia where some people get sexually aroused by everyday objects. So should Apple’s iBook be banned because of it’s potential erotic effect?

I still don’t know if technically these X-rays are pornography. Why do I care? Because it can be our job at Sophos to help protect you from pornography, if only we knew what it is.

And if this isn’t explicit enough for you there is also a MRI video of sexual intercourse penetration that is part of the results from a paper submitted to the British Medical Journal some time back. Though this example is not pornography as it is medical research, lucky scientists.

Miss March 2010

SophosLabs has been tracking the results of what looks like a new SQL injection over the last week and updating detections to Mal/Badsrc-C to deal with it.

The script tag injected is now using port 8080 like similar campaigns recently.

<script type=”text/javascript” src=”http:\/\/[a-z]{1,10}\.[a-z0-9-_]{1,30}\.[a-z]{2,4}:8080\/[A-Z][A-Za-z0-9-_]{1,20}\.js”></script>
<!–[0-9a-f]{32}–>

Here the src attribute here has been replaced by a regex and the HTML comment has also been replaced.

This type of construction is used legitimately as well as maliciously which makes the detection difficult!

We were alerted to this attack over the last week by seeing feedback from the Sophos Web Appliance (SWA) of Troj/ExpJS-W, Troj/PDFJs-JS, and Troj/JSRedir-AR. So on Wednesday, SophosLabs released a Suspicious detection (Sus/Badsrc-F) to the SWA to gather data on this injection.

Several high profile sites are currently compromised with this injection:

• A publicly–owned business development company in Southern US.
• An Islamic Cultural Centre in London, UK.
• A hunting site in New England, US.
• A fan site for LOTR movies.
• A cooking shop in North Rhine-Westphalia, Germany.
• A French Jewelery site
• and a Sex blog!

Most of these sites are blocked by Google Safe Browsing (see StopBadware). I have contacted a number of the sites with no success and to find out, in the first case, that the admins are taking a long weekend to coincide with the July 4th holidays, Happy Holiday!

Sometimes malware authors make it really easy to spot a scam.

Today’s email attachment campaign is a fake car tax update. Apparently the “Ministry of Transport”  has made some sort of change to my car tax and details are in the attached file, “CAR_DOCUMENTATION.zip”.

But with spelling and grammar as bad as this, alarm bells should be ringing:

The executable contained inside the zip is called ”CAR_DOCUMENTATION.DOC.___________.exe” - the double extension is another clue that this missive from the “Ministry of Transport” should not be trusted.

To cap it all off the email is sent from a random looking email address that certainly doesn’t have anything to do with this Ministry of Transport that wishes me to “the cease of economize on your finance”.

Fortunately if you are unlucky enough to receive one of these emails and all these clues don’t cause you to delete it immediately, Sophos will come to the rescue and detect the file as Troj/Agent-NSQ.

Search engine optimisation (SEO) techniques have received a fair amount of attention recently, thanks mostly to their use in fake AV distribution. In this blog, I will describe an interesting piece of JavaScript I came across whilst investigating some SEO pages.

In a typical SEO attack, when the victim clicks through to the SEO page from the search engine results, they are immediately redirected to the target site (be that designed to infect them with malware or show them spammy services/goods). This is normally achieved using one of the following methods:

• 302 redirect
• JavaScript driven redirect
• Flash (ActionScript) driven redirect
• META redirect

The SEO pages I was looking at this week used an interesting JavaScript for the redirection. The script is shown below:

As you can see, the redirection is a little more obscure than the usual simplistic location.href=_some_url_! The script adds an event listener to the document using addEventListener or attachEvent for Mozilla et al. and IE respectively.

Upon the mousemove event firing, the exit() function is called, incrementing a counter. Once that counter hits 3, an anchor element is added to the page, and the redirection is delivered. A curious exercise in making the simple overly complex and cumbersome! Seems like the use of “hiding in plain sight” tactics in an attempt to evade detection.

The target of the redirect is changing (of course), but thus far the SEO efforts seem to have been focused on shifting software and other products.

In addition to blocking access to the target spammy pages via URL filtering, the malicious redirect script is also blocked as Troj/JSRedir-BU by Sophos products.

Remember all those long distance phone calls we made? No, me neither - so if you see an email asking you that same question, don’t open it.

The spam messages have a subject of “phone calls” and look like this:

Hey man..

Remember all those long distance phone calls we made.
Well I got my telephone bill and WOW.
Please help me and look at the bill see which calls where yours ok..

There’s an attachment called “PhoneCalls.pdf” which Sophos detects as Troj/PDFJs-II. This file tries to exploit an old vulnerability in how Adobe Reader handles TIFF images (CVE-2010-0188, APSB10-07) to download and execute more malicious code.

In fact the code it downloads is detected as Troj/SalLoad-B, which goes on to load the Sality virus into memory. We’ve talked about this particularly nasty virus several times in the past, not least its unfortunate tendency to corrupt files during infection, so it’s a nuisance to see it aggressively seeding in this way.

Of course you can help stop Sality from making those long-distance phone calls - just make sure your Acrobat Reader and AntiVirus are up to date, and careful what attachments you open!

Image source: KirrilyRobert’s Flikr photostream (Creative Commons 2.0)

Regular SophosLabs blog readers may have read previous posts about attacks that have poisoned ads content in order to inject malicious code into legitimate web sites. This is a nasty form of attack which can reach a potentially huge audience.

Yesterday I noticed another attack using poisoned ads content from an OpenX ads server.

The malicious script injected into the HTML served up from the compromised ads server is highlighted below.

Deobfuscating the script, we can see it adds an iframe to the page to load another malicious script.

This second script is obfuscated in the exact same manner.

It provides another iframe-driven redirect, in order to load a third obfuscated script. This final script is responsible for loading malicious Java and PDF content in order to exploit client-side vulnerabilities and infect the victim with the payload (pro-actively detected as Mal/TDSSPack-Z). Consistent with the recent rise we have reported in Java exploits, this attack involves malicious class files, targeting the HsbParser.getSoundBank vulnerability (CVE-2009-3867) and an old privilege escalation vulnerability in the handling of ZoneInfo objects during deserialization (CVE-2008-5353).

Sophos customers are already protected from this attack:

• The poisoned ads content and all the subsequent scripts loaded are pro-actively detected as Mal/ObfJS-CR
• The malicious Java content is pro-actively detected as Troj/BytVrfy-C and Troj/Clsldr-U
• Detection for the malicious PDF has been added as Troj/PDFJs-LE
• The payload is pro-actively detected as Mal/TDSSPack-Z

The most important message to learn from this attack concerns the use of third party software/applications in building web content. We have reported before about content management systems (CMS) providing easy targets for hackers looking to compromise sites. Third party advertising scripts are no different, providing a large population of target sites for the attacker.

There are various models for using OpenX advertising. One of them is OpenX Community Download, where the users host their own ad-server. Very convenient and quick to set up, but an often overlooked cost to this option is that the site administrator has to take on the responsibility of keeping their scripts updated. They need to keep up to date with vulnerabilities, security patches, new product versions etc. This is no small task, but failure to do so can result in what we have here - delivering malicious code to all the web sites loading the ad content. That is why hosted advertising models are also popular - leaving the hosting, updating and patching to the application vendor.

The ad-server hit in the attack described above is running v2.8.0, which is several versions out of date (the latest version is v2.8.5).

This article in Le Monde caught my eye today: Australie : pas d’antivirus, pas de connexion à Internet.

It concerns a report, published on June 21st by the Australian Standing Committee on Communications, in which the following recommendation is proposed:

“… la coupure de l’accès à Internet si l’usager dispose d’un ordinateur infecté par un programme malveillant, ou si la base de données de son antivirus ou son pare-feu n’est pas à jour”

For the benefit of any non-Francophones reading, this translates as “the disconnection of internet access if the user has a computer infected with malware, or if his antivirus software is either switched-off or out of date”

The suggestion appears to be that the ISP will be tasked with the responsibility of, effectively,  running anti-malware health checks on the client’s computer and imposing a kind of “Three Strikes And You’re Offline” rule.

It sounds like a good idea - I am all for systems to protect the innocent cyber-surfer - but it must surely involve the installation on the client’s computer of  “un logiciel espion” , spyware, which may not be acceptable to everyone.

This is, however, not unlike the system that I have imposed on my two offspring.  On arrival at my house their laptops and USB sticks are whipped away before you can say “Hi Mum can you lend me £10?”, checked to ensure that all security updates are applied and then scanned for infections.  Only once I am happy that they are not harbouring harmful malware are they allowed online access.

It may seem a little over-cautious but “mieux vaut prévenir que guérir“.

Troj/BHO-QP is a rogue Browser Helper Object (BHO) which masquerades as a Flash Player extension from Microsoft, when in fact the BHO is a backdoor agent installed alongside QQ game automation freeware.

The BHO has been seen installed as a file named directdbres.dll. The DLL spoofs Microsoft product information and is registered as “FlashPlayer.Class” component — forging the fields displayed in the “Manage Add-ons” window of Internet Explorer options. Even more devious is the tactic to install a rogue “VeriSign Class 3 Code Signing 2009 CA” certificate as a Trusted Root Certificate Authority, which allows the BHO to avoid the taboo of being declared “Not verified”. To make their DLL appear “trusted”, the malware authors have simply (a) generated a rogue Verisign certificate, (b) used the rogue Verisign certificate to issue another rogue certificate, for Microsoft this time, and (c) signed the DLL using the key for the fake Microsoft certificate. Installing their fake Verisign certificate on a victim’s computer is the final piece of the puzzle to ensure their malware appears to be a genuine Microsoft product.

Also notice how management of the BHO is restricted to administrators only (i.e. “This add-on is managed by your administrator” in the bottom left corner of the image) . The dropper sets the Group Policy registry entry HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Ext\CLSID\{<clsid of the BHO>} to 1 to ensure the add-on is enabled, but unmanagable from the browser interface (see “How to manage Internet Explorer add-ons in Windows XP Service Pack 2″).

So how do you distinguish the rogue Verisign certificate from the legitimate one?

The fact that a root certificate is installed by the same software it is supposed to verify should immediately raise suspicion. Tools like Sysinternals sigcheck can be useful, but only if run from a clean machine — once the rogue certificate is installed on the system, they won’t be able to help.

There are several details about the certificate itself that strongly indicate its illegitimacy. Examining the openssl x509 output for the rogue certificate reveals:

1. the rogue Subject is only identified by a Common Name (CN)
   Subject: CN=VeriSign Class 3 Code Signing 2009 CA
   while the genuine Verisign certificate has additional fields including Organization (O), Organizational Unit (OU), Country (C), etc.
2. the rogue certificate is its own Issuer
   Issuer: CN=VeriSign Class 3 Code Signing 2009 CA
   while the genuine Verisign certificate has “Class 3 Public Primary Certification Authority - G2″
3. the rogue certificate is version 3 but is missing many typical x509 v3 extensions, and especially lacks any reference to a certificate revocation mechanism, such as a CRL or OCSP provider
4. the rogue’s signature algorithm hash is MD5
   Signature Algorithm: md5WithRSAEncryption
   while the genuine certificate uses sha1WithRSAEncryption
5. the rogue’s validity period is similar to that of a root Certificate Authority (CA) certificate
   Validity
   Not Before: Sep 30 16:00:00 1999 GMT
   Not After : Jul 16 16:00:00 2036 GMT
   A root CA certificate is only intended for issuing other intermediate CA certificates and is not typically used to issue certificates for other purposes. An intermediate CA certificate is then used to issue code signing and SSL certificates to an organization, which typically have a shorter lifespan. For instance, the genuine VeriSign Class 3 Code Signing 2009 CA certificate is valid for only 10 years.

But these certificate details could be spoofed just as well. To be certain of a certificate’s legitimacy (or illegitimacy), just go straight to the source and ensure the certificate fingerprints match.

The malware authors are certainly targeting a vulnerable audience — folks already looking to take shortcuts by automating their gameplay — who are probably even less likely to scrutinize the software they have downloaded to serve that purpose. But regardless of the would-be victims, this technique, in addition to the fraudulent SSL certificate abuse we have already seen, serves as another reminder that the mere pressence of a digital signature does not mean that something is legitimate.

Yesterday, I found a sample of Symbian malware while I was working on generic stuff. This kind of malware is quite difficult to spot, so today we are going to analyze this sample, which targets Symbian based smartphones.

This malware spreads via a SIS file, which is a sort of archive, so first of all, let’s take a look at the content of this package.

Once the malware is installed on the victim mobile, it drops the following files:

The red group contains the components which are strictly related to the current malware, the yellow group clusters additional components required.

After a quick analysis, we can locate the origin of this malware. This malware comes from Russia, as confirmed by the strings being used in the malware and also from several links on the web which are directly related to this malware and its author.

The following Python code is the brain of this malware, for brevity we will report only the relevant parts.

The malware code is mainly contained inside an “infinite” loop:

firstly, the malware sends a message to a Russian (in this case) premium rate number with a custom text:

secondly, the malware waits for any incoming messages, in order to suppress any notification to the victim user:

at the end of each loop, the malware tries to clean all its traces on the mobile, before repeating the whole loop:

The code of this malware is really ugly, I doubt if the author has Python programming skills, in fact the author uses four similar code blocks repeated in an infinite loop. Eventually the malware will stop sending messages when the victim’s phone has no more credit.

Sophos detects this malware as: Troj/SymbSms-A.