Market share! It’s an easy answer, but not the only one.

In 2011, Apple was estimated to account for over 5% of worldwide desktop/laptop market share. This barrier was a significant one to break - Linux maintains under 2% market share and Google ChromeOS even less. This 15 year peak coincided with the first exploration by the aggressive FakeAv/Rogueware market targeting Apple computers, which we discovered and posted in April 2011 and later in May 2011, which no longer seem to be such an odd coincidence. Also, the delay in Apple malware until now most likely was not because Apple exploits were unavailable, or because the Mac OS X system is especially hardened. The 2007 "Month of Apple Bugs" demonstrated that the Mac OS X and supporting code is full of exploitable flaws. Safari, Quicktime, and other software on Apple devices is regularly exploited during pwnage contests, but widespread cybercrime attention hadn’t caught on until this past year.

At this point, we still don't know who is behind Flashfake, so we don’t know for sure that they were the same Mac OS X FakeAv/Rogueware group. Speculating that eastern euro-cybercrime is behind the botnet would be a pretty confident way to go right now. There are known groups from the region that have succeeded at wringing ad revenues from traffic hijacking. We don't believe that other sensitive data has been targeted. And the exploit distribution URLs that we are aware of have only targeted mac users. These factors limit the operational and technical needs of a financially motivated cybercrime gang.

In a sense, it would appear that their activity was somewhat similar to the Koobface or Tdss gangs. They haven't commited large unique financial crimes to attract the attention of law enforcement, and their malware contains hooks and other code to perform more sophisticated banking crime than search traffic hijacking, but they most likely were looking to make a multitude of small financial gains. On the other hand, thankfully, Apple hasn't given these guys ample notice to make their run. There can be plenty of money in that business - it is estimated that the Koobface guys ran off with millions after Facebook "outted" their operation under investigation. But based on the domain registrations we have examined, the individuals are not quite so public and they are hiding their identities while they hijack search engine traffic. The malware itself injects a number of hooks into running applications, much like the Zeus, SpyEye, and other spyware. If these were used for financial crimes, the group operating this botnet would need to organize money mules and accomplices to launder their stolen money, which would grow the group and attract the attention of other authorities.

On the technology side, Java is a big part of the puzzle. Although the Trojan is called Flashfake because users were being convinced to install the malware as an Adobe Flash update, more recent versions of the malware were being installed via client-side Java exploitation.

Three vulnerabilities were targeted with client-side exploits, none of them were 0day, which seem to have become much more difficult to come by. Besides, this set worked just as well for these operators. It is interesting to note the duration of time from the original Oracle Java security update to the Apple Java security update, and when in that timeframe the release offensive security research publicly appeared. And, when were Metasploit open source exploit modules were released targeting the related Java vulnerabilities? The windows of time may be alarming – these are not 0day exploits, but Apple simply hasn’t released patches, leaving their customers exposed to the equivalent of known 0day exploits.

CVE-2012-0507

2012-02-15 Oracle patches Atomic Reference Array vulnerability

2012-03-10 First Itw exploits targeting the vuln

2012-03-30 Metasploit developers add Java atomicreferencearray exploit module

2012-04-03 Apple patches their code

CVE-2011-3544

2011-05-12 Reported to vendor

2011-11-18 Oracle patched their Java SE

2011-11-30 Metasploit developers add "Rhino exploit" module

2011-11-30 Krebs reports operational Blackhole site with the new Java exploit

2012-3-29 Patched by Apple

CVE-2008-5353

"Deserializing Calendar objects"

2008-08-01 Reported to Sun with first instance of the vulnerability

2008-12-03 Sun patches their code (Sun link down)

2009-05-15 Apple patches MacOSX code

2009-06-16 Metasploit developers add Java deserialization exploit

Also on this list is a lame exploit described as a signed applet social engineering trick.

I'd prefer to call it the "the terribly confused user presented with the Java 'do you want to trust this applet?' dialog and will run anything you present them" gamble. It first became a part of the Metasploit exploit module list on 2010-01-27. Basically, these guys present the user with a file that the user thinks is a JavaUpdate provided by Apple Inc themselves, which they grant trust to perform any action on their machine. The downloader will then communicate with a couple of sites to register and download new Flashfake components. These components in turn, collect the system UUID and timestamp, then auto-generate with a crypto algorithm a set of C2 domains, along with maintaining a list of hard coded domains. A couple of the newer components inject into running processes on the system hooking software functionality and hijacking traffic, much like past TDS malware.

At the moment, there are more than 100 million Mac OS X users around the world. The number has grown switfly during the past years we expect this growth to continue. Until recently, Mac OS X malware was a somehow limited category and included trojans such as the Mac OS X version of DNSChanger and more recently, fake anti-virus/scareware attacks for Mac OS X which boomed in 2011. In September 2011, the first versions of the Mac OS X trojan Flashback have appeared, however, they didn’t really become widespread until March 2012. According to data collected by Kaspersky Lab, almost 700,000 infected users have been counted at the beginning of April and the number could be higher. Although Mac OS X can be a very secure operating systems, there are certain steps which you can take to avoid becoming a victim to this growing number of attacks.

Here’s our recommendation on 10 simple tips to boost the security of your Mac:

I’m often asked about the real danger of Android malware. This is a difficult question as it has many factors to consider, such as your location, your device, how many apps you install, and how reckless you are with the apps that you choose.

There are two common factions often at odds with each other. There is one side of the argument that states that the threat to Android is overblown, and that because the number of malicious samples discovered so far is so small in comparison with Windows malware, it’s insignificant. In fact when a company discloses their findings and they show any type of marked growth in this sector, they’re often accused of scaremongering to generate sales.

The cyber-criminal groups behind fake anti-virus (scareware/rogueware) infections have run into some significant roadblocks over the last few years, but there is much more to the overall story.

Some groups have been arrested. Some have had their operations and entire call support centers shut down.
Some groups attracted too much attention, picked off the low hanging fruit and eventually walked away from their botnets.
In some cases, the groups just weren't very skilled at developing anti-anti-malware techniques, blackhat SEO, and malware distribution. They couldn't keep up with the changes in anti-malware technologies, weren't exactly dedicated to the effort, and simply fell off the map.

However, some of the remaining scareware distribution gangs upped the ante and are aggressively developing difficult-to-detect polymorphic installers and difficult-to-remove support components. And the newest of these malware components include some of the first ITW 64-bit malware components to be taken seriously. But, for the most part, the scareware program itself remains the same. The development continues to change and progress, all for the purpose of evading anti-malware solutions and helping coerce the end-user to pay for the fake product, including support/rootkit components like TDSS (and its extreme complexities) or the more recent Black Internet (also known as "Trojan-Clicker.Win32.Cycler") support/rootkit components. These complex Mbr infectors and other rootkit components meant to maintain money-making scareware on the system are signs of this somewhat extreme development effort.

Interesting news on Trojan SMS Blockers (Winlock etc). These programs block Windows and demand a ransom in the form of a text message which is sent to short number for a fee. It's a very popular type of racket at the moment, both in Russia and a few other countries.

The whole affair has now reached the General Prosecutor’s office of Russia – the criminals have been identified and detained (or so it seems) and will be prosecuted in Moscow soon.

Altogether the criminals have earned an estimated 790,000 roubles, or $25K. Moreover, they have caused other damages by blocking or crashing a yet to be determined number of personal and company PCs. Very often people have needed to re-install the OS and all software and then restore data from backups - even after paying the ransom.

But I wanted to focus on the outcome – or the possible outcome of this incident, not on the investigation, arrests and so forth.

Vacation is a time for visiting friends and family, going abroad, eating ice-cream, gardening – whatever helps you regroup and recharge. Computer security is probably the last thing on your mind, even if you’ve taken your laptop home with you to keep tabs on what’s going on at the office.

But as my colleague Christian pointed out in this article last year, summer often brings some serious security issues. And I’ve got recent further proof of this: just a few weeks ago I was attending our annual security conference at a very classy hotel in Cyprus. Everything seemed perfect – until we connected to the hotel Wi-Fi.

If you’ve ever taken your laptop with you on business or vacation, you’ll know the drill. When you want to connect to the Internet via a hotel network, you get redirected to a site controlled by the hotel’s router. You need to either enter a code provided by the hotel, or your credit card details – all on a site which may or may not be secure.

In Cyprus, we found out that the page you get redirected to when you try and access the Internet was infected with Gumblar. The hotel was lucky to have 30+ security experts staying there – but if we hadn’t been holding our conference there, the site could have stayed infected for quite a while!

Logging on via insecure connections isn’t the only seasonal security issue. People’s computer and online habits change when they’re on holiday – they tend to use their computers less, and in short bursts, just to get the information they need. For instance, you’ll often see people logging on for ten minutes to quickly check email, download maps or details about the places they’re planning to visit, etc.

If you’re quickly checking for some information that you need via GPRS or a slow Wi-Fi connection, you’re probably not going to bother updating your antivirus or installing security patches. You might rationalize your decision (if you even think about it) by telling yourself that you don’t go to dodgy sites which are likely to be hosting malware. But our experience in Cyprus really highlights the fact that malware is everywhere.

Ignoring security patches and antivirus updates while you’re on vacation means that if you log on, you are putting yourself at risk. And when you get back to work after two, three, or even four weeks off, if you haven’t been using your computer, the very first thing you should do is make sure that it’s fully patched, and security software up to date. Of course you want to get to all the funny YouTube links etc. that your colleagues sent while you were away – but update before you start checking your mail or clicking through links and attachments.

Insecure networks, infected sites, and vulnerable software and systems are all technical aspects of IT security. But apart from all the technical stuff, lots of people are giving out far too much information on Facebook, Twitter, and even in their Out Of Office replies. Posting that you’re off to some exotic resort for two weeks is almost an open invitation to burglars and other criminals to come and rifle your property while you’re gone…

Simple tips on how to have a more secure vacation

Before you go

• Don’t write on your social network that you’re going on holiday!
• Make sure you’ve got all the latest security patches installed, including patches for third party applications such as PDF readers, browsers, chat programs, etc.

While you’re away

• Make sure that your antivirus is up to date. You never know what might be lurking on the network!
• Use common sense - don’t enter credit card details or passwords unless it’s essential, and only if you’re confident the network is secure
• If you’re paranoid, disable programs that autostart such as Skype or MSN – you wouldn’t want someone to steal your passwords over an insecure network.

When you get back

Make sure you scan and patch your work computer before you start reading emails and working.

Over the weekend I spent more time looking into the zero-day LNK (shortcut) Windows vulnerability that Aleks blogged about last week. It’s now been classified as CVE-2010-2568 and is being actively exploited in the wild.

My main conclusion is that this vulnerability is a fundamental part of how Windows handles LNK files. This means there are two huge negatives – firstly, as this functionality is pretty standard, it's going to be harder to create effective generic detections which don't cause false positives.

Secondly, I suspect Microsoft is going to have a very hard time patching this one. There doesn’t seem to be any security model associated with how Windows handles shortcuts. This whole situation reminds me a bit of vulnerabilities in the WMF format – it’s another case of legacy code coming back to bite Microsoft.

We’ve released generic detection for malicious LNK files which try to exploit the feature. I think that the LNK format will start receiving a lot more attention now, both from the good guys, and the bad, so do take a look at the mitigations put up by Microsoft. I’m sure it will be time well spent, as I fully expect this vulnerability to be widely exploited while we’re waiting for the patch.

Today Microsoft is ending support for XP/Service Pack 2. According to reports there are still a lot of machines running XP/SP2. So this sounds like a serious problem, right? Actually, I’m not convinced of that.

Let’s look first at consumer machines – those which aren’t being centrally managed. Why would these machines still be running SP2? Obviously, Windows Updates must have been disabled. I can only think of two main reasons why that would be the case: either a malware infection which is somehow preventing WU from working, or people have disabling WU on pirate versions to be sure they can continue to use Windows without having to pay for it.

In the first case, infection already occurred. In the second case, it’s very unlikely that the machine was ever patched after the initial SP2 install. That means that such machines are vulnerable to any of the exploits that exploited XP vulnerabilities discovered after August 25, 2004, when SP2 was released. In other words, these computers have been vulnerable for a long, long time.

What about the business environments still running SP2? In the vast majority of cases the admins will have decided that the time just isn’t ripe for SP3. SP3 was released just over two years ago. If admins haven’t rolled out SP3 yet, it seems pretty unlikely that the other software they’re running - such as Office and Adobe Reader – is going to be up to date. These are the same companies that are still running Internet Explorer 6.

Given all this, I don’t think ending support for SP2 will create any sort of nirvana for cybercriminals. All the unpatched (and attackable) machines have been this way for a long time now – and chances are, if they were going to be infected, it would have happened a long time ago.

AMTSO (the Anti-Malware Testing Standards Organization) is a coalition of security professionals, including many antivirus product vendors, product testing organizations and publishers, and some interested individuals. Given the highly technical nature of its activities, it is inevitable that the organization owes some of its authority to the expertise of the security specialists within its ranks, but that doesn’t make it a vendor lobby group. As Kurt Wismer (not himself a member) points out here “many of them are employed by vendors precisely because that's one of the primary places where one with expertise in this field would find employment.” Given some recent negative publicity aimed at AMTSO ( example), we want to collectively clarify the following points on behalf the anti-malware industry, where we come from, and indirectly on behalf of AMTSO.

We find it strange that expertise in the testing field is somehow seen as a disqualification, given the specialist expertise that characterizes the group.

While some distrust anything a vendor says and accept uncritically anything a tester says, others are puzzled that different tests can vary so dramatically in their evaluation of the same product. While this may sometimes be simply due to poor testing practice, there are other, deep-seated reasons, one being the high volume of malware and new attacks seen every day. Vendors work hard to close the gap between the ideal 100% detection and what is actually achievable, by developing a range of technologies, both proactive and reactive. The capabilities of products can change, while tests using broadly similar methodology can generate dramatically ‘conflicting’ results due to different approaches to the selection, classification and validation of samples and URLs, among other factors.

AMTSO aims to promote precisely the kinds of tests that clearly show up these variations, and its members were flying the flag for real world testing before AMTSO ever formally existed, believing that sound testing benefits vendors and customers as well as testers. As an industry, we are all too aware that we cannot currently offer detection of all known and unknown malware. The relatively high scores achieved in established tests by major vendors do not necessarily reflect real world performance, but real-world detection cannot be measured in terms of product comparison with no checks on selection, classification and validation of malicious samples and URLs.

Another misconception is that AMTSO members simply don’t like tests done by non AMTSO members. This is not the case: none of the undersigned have a problem with labs that intend to provide objective, real-world testing. (Though other testers are entitled to object vehemently when one company claims to be the only one doing live, internet-connected testing, and that all other testers are doing static testing based on the WildList).

However, charging consultancy fees for the release of any information relating to a test (even to participants) is very different to the transparency that AMTSO advocates, though we recognize that full-time testers generate revenue like any other business. However, when a tester claims to have shared information about methodology in advance, and fails to provide methodological and sample data subsequently, even to vendors prepared to pay the escalating consultancy fees required for such information, this suggests that the tester is not prepared to expose its methodology to informed scrutiny and validation, and that compromises its aspirations to be taken seriously as a testing organization in the same league as the mainstream testing organizations committed to working with AMTSO.

No-one believes that AMTSO has all the answers and can “fix” testing all by itself, but it has compiled and generated resources that have made good testing practice far more practicable and understandable. The way for testers (and others) to improve those resources is by talking to and working with AMTSO in a spirit of co-operation: the need for transparency is not going to go away.

Roel Schouwenberg, Kaspersky Lab
Luis Corrons, Panda Security
David Harley, ESET
Mark Kennedy, Symantec Corporation
Igor Muttik, McAfee

Amongst some others the Zeus bot is one of the most prolific bots in the wild and in the media. Lately there has been quite a few reports on the aspects surrounding Zeus, such as new research and the Troyak takedown.

Naturally, this is great news. However, awareness is still lacking and the heavy reporting around Zeus is making more people aware of the sophistication of the cyber criminal underground. Unfortunately, In many of the reports there is a recurring incorrectness. These reports talk about “the Zeus botnet”, which is an inaccurate reflection of reality.

The reality is that there are many, many different Zeus botnets all maintained by different cyber criminals. The amount of unique Zeus botnets is likely to be in the hundreds. The cyber criminals behind the Zeus bot will sell it to anyone who can then start their own unique botnet. Going even further there are some side-branches of Zeus maintained by other cyber criminals.

Given this situation it’s not unlikely that in a large enterprise machines may be infected with Zeus bot variants which are controlled by different cyber criminals and therefore belong to different Zeus botnets.

In order to create greater distinction we’ve seen a security company give a particular Zeus botnet another name when talking about it in the media. From my own perspective this novel idea didn’t quite work as it seemed to cause more confusion rather than less.

Sadly, I’m not convinced that a botnet naming convention for variants of a particular bot will help the public have a better understanding in the short term. So where does that leave us? Well, I think there is an easy guideline.

If the security community is reasonably sure that a certain bot is controlled by one cyber criminal group we can refer to the threat as a botnet. Examples of this rule are Conficker, Storm and Mebroot. If the bot is available in the underground we should refer to the threat as bot or botnets created by the following bot. Examples of this rule are Zeus, SpyEye and Poison Ivy.