28 Jan A cross-platform java-bot Anton Ivanov
03 Sep NetTraveler Is Back: The 'Red Star' APT Returns With New Tricks Costin Raiu
12 Aug Central Tibetan Administration Website Strategically Compromised as Part of Watering Hole Attack Kurt Baumgartner
13 Jun AutoRun. Reloaded Konstantin Markov
19 Apr An ambush for peculiar Koreans Dmitry Tarakanov
10 Jan Java 0day Mass Exploit Distribution 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.
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>).
During the last week, several spear-phishing e-mails were sent to multiple Uyghur activists. Here’s an example:
A snippet of code on the Central Tibetan Administration website redirects CN speaking visitors to a Java exploit that drops an APT-related backdoor. For some context, the site claims the administration itself as "...the Central Tibetan Administration (CTA) of His Holiness the Dalai Lama, this is the continuation of the government of independent Tibet." The selection of placement for the malicious code is fairly extraordinary, so let's dive in.
The attack itself is precisely targeted, as an appended, embedded iframe redirects "xizang-zhiye(dot)org" visitors (this is the CN-translated version of the site) to a java exploit that maintains a backdoor payload. The english and Tibetan versions of the website do not maintain this embedded iframe on the Chinese version (please do not visit at this time). At this point in time, it seems that the few systems attacked with this code are located in China and the US, although there could be more. The Java exploit being delivered is the 212kb "YPVo.jar" (edd8b301eeb083e9fdf0ae3a9bdb3cd6), which archives, drops and executes the backdoor as well. That file is a 397 kb win32 executable "aMCBlHPl.exe" (a6d7edc77e745a91b1fc6be985994c6a) detected as "Trojan.Win32.Swisyn.cyxf". Backdoors detected with the Swisyn verdict are frequently a part of APT related toolchains, and this one most certainly is.
The Java exploit appears to attack the older CVE-2012-4681 vulnerability, which is a bit of a surprise, but it was used by the actor distributing the original CVE-2012-4681 0day Gondzz.class and Gondvv.class in August of last year. You can see the 4681 exploit code in the image above along with code setting the jvm SecurityManager to null to disable Java's policy checks and then running the Payload.main method. The Payload.main method contains some interesting but simple capabilities that enable an attacker to download the payload over https and AES decrypt it using Java's built-in AES crypto libraries, but the package is not configured to use that code in this case. Instead, a couple of lines in its configuration file direct the exploit to drop and execute the jar file's win32 exe resource. The backdoor itself is detected by most of the AV crowd as variants of gaming password stealers, which is flatly incorrect. The related C2 is located at news.worldlinking.com (184.108.40.206).
This threat actor has been quietly operating these sorts of watering hole attacks for at least a couple of years and also the standard spearphishing campaigns against a variety of targets that include Tibetan groups. Our KSN community recorded related events going back to at least a busy late 2011 season. We also show Apple related Java exploits from this server targeting the more recent CVE-2013-2423.
UPDATE 2013.08.13: The CN version of the site at "xizang-zhiye(dot)org" appears to be cleaned up and has not been serving any malicious code that I can find over the past day. The administrators appear to have cleaned everything up on early Tuesday their time/later Monday "western" time and there are no indications of any return since. We will continue to monitor the site for signs of compromise.
Kaspersky Lab’s products detect these special worms as Worm.JS.AutoRun and Worm.Java.AutoRun. They are also detected by heuristic methods as HEUR:Worm.Script.Generic and HEUR:Worm.Java.Generic respectively.
These two worms have three key features in common: heavy obfuscation, backdoor-type essential payloads, and similar methods of propagation. Both worms spread by copying themselves and the configuration file autorun.inf into the root folders of logical volumes of removable storage media and network disks. If these infected storages are opened on other computers, the infection can spread. Having infected the operating system and established a foothold on the victim computer, the malicious programs deploy their principal payload.
For months, the number of AutoRun worms detected on Kaspersky Lab users’ computers remained essentially unchanged. According to Kaspersky Security Network data, half of all script worms spread themselves this way. As for Java worms, this is not their usual method of propagation. However, in the last three months we have seen a dramatic rise in the number of new Worm.Java.AutoRun modifications.
While researching PlugX propagation with the use of Java exploits we stumbled upon one compromised site that hosted and pushed a malicious Java applet exploiting the CVE 2013-0422 vulnerability. The very malicious Java application was detected heuristically with generic verdict for that vulnerability and it would have been hardly possible to spot that particular site between tons of other places where various malicious Java applications were detected with that generic verdict. But it was a very specific search conducted back then and this site appeared in statistics among not so many search results. Well, to be honest it was a false positive in terms of search criteria, but in this case it was a lucky mistake.
The infectious website was an Internet resource named - minjok.com and it turned out to be a news site in Korean and English languages covering mostly political events around the Korean peninsula. We notified an editor of this site about the compromise and although he has not responded, the site got closed after a while.
This is how minjok.com is described at http://www.northkoreatech.org/the-north-korean-website-list/minjok-tongshin/:
Description of minjok.com
Just a quick note, it's only the second week of January, but early 2013 brings with it the first Java 0day mass exploit distribution of the year.
There appears to be multiple ad networks redirecting to Blackhole sites, amplifying the mass exploitation problem. We have seen ads from legitimate sites, especially in the UK, Brazil, and Russia, redirecting to domains hosting the current Blackhole implementation delivering the Java 0day. These sites include weather sites, news sites, and of course, adult sites. A few obfuscated files are being delivered to victim systems with names like Stretch.jar, Edit.jar, UTTER-OFFEND.JAR, and more. The first appearance of the exploit's prevention in our KSN community seemed to be January 6th. But as we dig back further, we find related samples from mid-December. So, we have been preventing this 0day in particular for quite some time. At this point, it seems that the first instance of the particular 0day jar file contents ITW is 7550ce423b2981ad5d3aaa5691832aa6. Filenames for the class files remain the same until recently. It would be interesting to see an earlier instance.
Update (2012.01.10 3:30 p.m. MT) - Metasploit developers have added an exploit module targeting this vulnerability CVE-2013-0422.
The Java 0day activity that we have been monitoring and preventing for almost the past week has been irresponsibly reported on other blogs, with early posts publicly linking to known sites serving the 0day. In itself, the race to publish on this 0day that will be assigned CVE-2012-4681 (a problem with processing access control within "protection domains"), has been irresponsible. Would you encourage folks to walk down a mugger's dark alley with no protection or would you work to communicate the muggers' whereabouts to the right folks and work on lighting the alley or giving better directions? Would you provide muggers with some new weapons that they haven't considered? The efforts this time around seem misplaced.
Anyway, initial sites hosting the exploit were unique and spreading known APT related toolset components, including a Poison Ivy variant. Here is a somewhat unexpected heat map of early, related PIvy detections.
All the related malware that I have seen to this point targeted Windows systems. The exploits are effective against Java 7 and since the initial targeted attacks, news and the samples spread throughout the broader security community and the exploits made their way to metasploit developers, who added PoC to the open source framework. In turn, the Blackhole authors added the exploit to their COTS. So the attacks are widespread at this point. The first victim regions to be hit with the Blackhole stuff were the US, the Russian Federation, Belarus, Germany, the Ukraine and Moldova. But, in relation to the other exploits included in the pack, victims are getting hit only a fair number of times with the 0day. Internet Explorer users are being hit the most, followed by Firefox, Chrome, and Opera, and then a variety of other applications that handle URLs within their documents and eventually pass the malicious .jar on to a Java client, like Adobe Reader.
We are using a variety of detections and techniques to identify the malicious sites, the web pages involved, the exploit code, and the backdoor payloads delivered by these sites. Even though this particular Java 0day is getting hyped, other older exploits in the Blackhole exploit pack continue to get hit on victim systems with higher volume. So our community is protected from the Blackhole sites themselves, the Blackhole webpages serving the Blackhole Java 0day, compromised sites redirecting to the Blackhole sites, the more prevalent older Blackhole exploits and their delivery pages, and the trojans being delivered by these Blackhole sites. In addition to all that, Kaspersky "Advanced Exploit Prevention" adds another runtime/behavioral layer of protection against the 0day itself with with "Exploit.Java.Generic". This addition is the most interesting to myself - exploit pack authors have been focused on improving their Java exploit server-side polymorphism, and this AEP feature defeats those efforts. So, our user community will see access denied altogether for current Blackhole sites, individual Blackhole web pages detected with variations on "Trojan-Downloader.JS.Agent", the backdoors detected with "Trojan.Win32.Generic" and others (i.e., 61A3CE517FD8736AA32CAF9081F808B4, DEC9676E97AE998C75A58A02F33A66EA, 175EFFD7546CBC156E59DC42B7B9F969, 0C72DF76E96FA3C2A227F3FE4A9579F3), and the 0day Java exploit code detected with "HEUR:Exploit.Java.Agent.gen" (i.e. E441CF993D0242187898C192B207DC25, 70C555D2C6A09D208F52ACCC4787A4E2, E646B73C29310C01A097AA0330E24E7B, 353FD052F2211168DDC4586CB3A93D9F, 32A80AAE1E134AFB3D5C651948DCCC7D) among others, along with the runtime AEP prevention. So while you may see a few links to Virustotal with the inevitable complaining that a scanner is missing a specific chunk of altered code along with innaccurate claims that "AV is dead!" or "AV can't detect it", you should take them for the grain of salt that they are. The real story about client side mass exploitation is more complex than those claims. Some researchers call the various points in a delivery vector a kill chain, and Kaspersky products are killing it.
At the same time, Oracle needs to step it up and deliver an OOB patch, which historically they have failed to do. Maybe this event will provide even more pressure to step up their security update delivery process. They have been snapping up some good security research talent and beginning to reach out, which is a start. A very late start.
UPDATE (2012.08.30): Oracle patches CVE-2012-4681 and two other client side RCE vulnerabilities. It is probably a better idea for Windows users to go to their control panel, find the Java applet, and use the Java update software to manually get the latest JRE 7 and 6 releases - the default delay for the Java Update package to check is currently one week for the Java 7 installer.
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.
In this webcast, Kurt Baumgartner talks about the rise of exploits against vulnerabilities in Oracle’s Java software. The discussion centers around the exploitation of Java vulnerabilities in exploit kits and the poor state of patching on the Windows platform.
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.