03 Feb A Glimpse Behind "The Mask" GReAT
28 Jan A cross-platform java-bot Anton Ivanov
13 Dec Loophole in Safari Vyacheslav Zakorzhevsky
26 Jul New malware for Mac: Backdoor.OSX.Morcut Sergey Golovanov
29 Jun New MacOS X backdoor variant used in APT attacks Costin Raiu
19 Apr OS X Mass Exploitation - Why Now? Kurt Baumgartner
Join our blog
You can contribute to our blog if you have +100 points. Comment on articles and blogposts, and other users will rate your comments. You receive points for positive ratings.
In early 2013, we announced our research on RedOctober, a cyberespionage operation focusing on diplomatic institutions. In June 2013, we published our research on NetTraveler, and in September, our research on the Kimsuky attacks.
Our analysis of all these different APT operations indicated an unique use of languages, that offer clues regarding some of the people behind these operations. If the comments in the Flame C&C were written in English, artifacts in RedOctober indicated Russian speakers, NetTraveler indicated Chinese natives. Finally, Kimsuky indicated Korean speaking authors, which we linked to North Korea.
During the past months we have been busy analysing yet another sophisticated cyberespionage operation which has been going on at least since 2007, infecting victims in 27 countries. We deemed this operation "The Mask" for reasons to be explained later.
Early this year, we received a malicious Java application for analysis, which turned out to be a multi-platform bot capable of running on Windows, Mac OS and Linux. The bot was written entirely in Java. The attackers used vulnerability CVE-2013-2465 to infect users with the malware.
To make analyzing and detecting the malware more difficult, its developers used the Zelix Klassmaster obfuscator. In addition to obfuscating bytecode, Zelix encrypts string constants. Zelix generates a different key for each class – which means that in order to decrypt all the strings in the application, you have to analyze all the classes in order to find the decryption keys.
String initialization and decryption is implemented in the static initializer code (<clinit>).
In our search for various types of malicious code for Mac we recently came across a rather interesting peculiarity in Safari. It turns out that Safari for Mac OS, like many other contemporary browsers, can restore the previous browsing session. In other words, all the sites that were open in the previous session – even those that required authorization – can be restored in a few simple steps when the browser is launched. Convenient? Of course. Safe? No, unfortunately.
So that the browser knows what was open at the end of the previous session, the relevant information needs to be stored somewhere. Obviously, that needs to be somewhere that isn’t easily accessible to just anybody, and the information definitely needs to be encrypted.
Safari, however, doesn’t encrypt previous sessions and stores them in a standard plist file that is freely accessible. As a result, it’s easy to find a user’s login credentials:
It’s pretty clear that the login and password are not encrypted (see the red oval in the screenshot).
The complete authorized session on the site is saved in the plist file in full view despite the use of https. The file itself is located in a hidden folder, but is available for anyone to read.
The system can easily open a plist file. It stores information about the saved session – including http requests encrypted using a simple Base64 encoding algorithm – in a structured format.
There is a function in Safari – ‘Reopen All Windows from Last Session’ – that allows sites to be opened exactly as they were at the end of the previous session. This is the function that uses LastSession.plist.
The function is available in the following versions of Mac OS X and Safari:
You can just imagine what would happen if cybercriminals or a malicious program got access to the LastSession.plist file on a system where the user logs in to Facebook, Twitter, LinkedIn or their online bank account.
As far as we are concerned, storing unencrypted confidential information with unrestricted access is a major security flaw that gives malicious users the opportunity to steal user data with a minimum of effort.
We have informed Apple about the problem.
At the current time we can’t confirm whether or not there is malicious code out there that targets this file, but we’re ready to bet that it won’t be long before it appears.
This vulnerability has been fixed in Safari 6.1
But before we go into details, let’s start with a quiz:
- The Dalai Lama walks into an Apple Store. Why?
A possible answer is, “to buy one of the new MacBook Pro’s with the Retina display!” (speaking of which, I would very much like to buy one of those as well, but it’s kind of difficult to justify the hit to the family budget)
Joke aside, actually Dalai Lama is a well known Mac user. Here’s a photo of him using a Mac during a conf call:
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.
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
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
"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.
For the past two days, we have been monitoring a “fake” infected system - which is a typical procedure we do for APT bots. We were extremely surprised when during the weekend, the APT controllers took over our “goat” infected machine and started exploring it.
On Friday Apri 13, port 80 on the C&C server located at rt*****.onedumb.com and hosted on a VPS in Fremont, U.S. was closed. Saturday, the port was opened and bot started communicating with the C&C server. For the entire day, the traffic was just basic handshakes and exchanges, nothing more.
On the morning of Sunday April 15, the traffic generated by the C&C changed. The attackers took over the connection and started analysing our fake victim machine. They listed the contents of the root and home folders and even stole some of the goat documents we put in there!
Earlier this week, Dr.Web reported the discovery of a Mac OS X botnet Flashback (Flashfake). According to their information, the estimated size of this botnet is more than 500, 000 infected Mac machines.
We followed up with an analysis of the latest variant of this bot, Trojan-Downloader.OSX.Flashfake.ab.
It is being distributed via infected websites as a Java applet that pretends to be an update for the Adobe Flash Player. The Java applet then executes the first stage downloader that subsequently downloads and installs the main component of the Trojan. The main component is a Trojan-Downloader that continuously connects to one of its command-and-control (C&C) servers and waits for new components to download and execute.
The bot locates its C&C servers by domain names, and these names are generated using two algorithms. The first algorithm depends on the current date, and the second algorithm uses several variables that are stored in the Trojan’s body and encrypted with the computer’s hardware UUID using RC4 cipher.
We reverse engineered the first domain generation algorithm and used the current date, 06.04.2012, to generate and register a domain name, "krymbrjasnof.com". After domain registration, we were able to log requests from the bots. Since every request from the bot contains its unique hardware UUID, we were able to calculate the number of active bots. Our logs indicate that a total of 600 000+ unique bots connected to our server in less than 24 hours. They used a total of 620 000+ external IP addresses. More than 50% of the bots connected from the United States.
We cannot confirm nor deny that all of the bots that connected to our server were running Mac OS X. The bots can be only identified by a unique variable in their User-Agent HTTP header named “id”, the rest of the User-Agent is statically controlled by the Trojan. See example below:
"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0.1; sv:2; id:9D66B9CD-0000-5BCF-0000-000004BD266A) Gecko/20100101 Firefox/9.0.1"
We have used passive OS fingerprinting techniques to get a rough estimation. More than 98% of incoming network packets were most likely sent from Mac OS X hosts. Although this technique is based on heuristics and can’t be completely trusted, it can be used for making order-of-magnitude estimates. So, it is very likely that most of the machines running the Flashfake bot are Macs.
In April, the .co.cc and .cz.cc sub-domains were absolutely littered with malware distributing web sites, and the unusually telling DNS registration setup on .co.cc and .cz.cc had forecast the previously upcoming Apple FakeAv. That DNS setup later led to FakeAv downloads for the Mac as forecast. But FakeAv distribution has been steadily declining since the beginning of the year, and a few related major events have occurred over the past six months. Blackhole operators have migrated to .info domains, along with other related malicious site operators. Have they pushed .info to become the new .cc?
So, what has this dispersion looked like? Well, let's look back to the beginning of the year. .co.cc and .cz.cc domain registrars offered free dns registration and cheap or free hosting. Malware distributors abused these cheap resources and staged the Blackhole exploit pack using these URL names, serving up FakeAv and other nastiness. Java exploits became the most effective and most popular in the Blackhole set, followed by exploits targeting vulnerable Adobe Reader and Microsoft HCP software. Traffic was directed to these kits by Google Image Search Poisoning, by compromising legitimate sites and redirecting browsers to the kit sites with injected iframe and img src tags, and by successful malvertizing campaigns on major webmail providers. But, what goes up must come down.
At Virus Bulletin 2011, we presented on the exploding level of delivered Java exploits this year with "Firing the roast - Java is heating up again". We examined CVE-2010-0840 exploitation in detail, along with variants of its most common implementation on the web and some tools and tips for analysis. Microsoft’s security team presented findings for 2011 that mirrored ours in relation to Java exploit prevalence on the web – it is #1! At the same time, aside from the recent, well-known BEAST Java implementation, it is striking that it has been very uncommon to see Java backdoors, Trojans and spyware. But that lack of Java malware variety is beginning to change. My colleague, malware analyst Roman Unucheck, identified a new Java bot with some interesting characteristics that we named "Backdoor.Java.Racac".