ZeroHour
Kaspersky Securelistpublished ()ingested @Securelist

OS X Mass Exploitation

criticalExploit / PoC exploited in the wildimportance 60CVE-2012-0507CVE-2011-3544CVE-2008-5353

Vulnerabilities mentionedAll →

CVEVulnerabilityCVSSEPSSFlagsAffectedExposurePublished
CVE-2011-3544
Remote Code Execution in Oracle Java SE JRE Applet Rhino Script Engine

CVE-2011-3544 is an access control flaw in the Rhino JavaScript Script Engine component used by Java applets in Oracle's Java Runtime Environment. It is triggered when a user's browser loads a malicious Java applet, allowing script executed through the Rhino engine to bypass Java's access restrictions. An attacker who successfully exploits it gains the ability to run arbitrary code on the victim's machine with the privileges of the logged-in user, typically via drive-by download from a compromised or attacker-controlled website. Any system with a vulnerable Oracle Java SE JDK or JRE and an enabled Java browser plugin is affected. Exploitation is confirmed in the wild: the flaw was added to CISA's KEV on 2022-03-03, carries a 96.7% EPSS probability of exploitation within 30 days, and contemporary reports show it weaponized in the BlackHole/Whitehole exploit kits and used in mass OS X exploitation.

Do: Apply updated Oracle Java SE builds per Oracle's vendor instructions, prioritizing internet-facing and end-user systems listed in the KEV guidance. Where patching is delayed, disable the Java browser plugin or block Java applets at the web gateway, since the attack vector is malicious applets served over the web. Review endpoints for signs of exploit-kit drive-by compromise, especially legacy Windows and OS X machines with outdated Java.

97% KEV
  • Oracle Java SE JDK and JRE
masshundreds of millions of desktops and servers with a Java runtime installed; exact count unknown
CVE-2012-0507
Type Confusion RCE in Oracle Java SE Concurrency Component

CVE-2012-0507 is an 'incorrect type' (type-confusion) vulnerability in the Concurrency component of Oracle's Java Runtime Environment that corrupts memory when crafted Java content is processed. It is triggered by running malicious Java content — classically via the browser Java plugin or an exploited Java application — allowing an attacker to execute arbitrary code with the privileges of the Java process. Anyone running an affected Oracle Java SE installation is exposed, which historically included the vast majority of desktops and many servers, with 2012-era campaigns hitting Mac users via Java exploits (e.g., the SabPub backdoor) and drive-by exploit kits. Exploitation is confirmed in the wild: the flaw is on CISA's Known Exploited Vulnerabilities catalog (added 2022-03-03) with known ransomware use, and EPSS assigns a 98.1% probability of exploitation within 30 days (100th percentile). CVSS has not been scored in the source data, but the combined KEV/EPSS signal marks this as actively and widely exploited.

Do: Apply Oracle's Java SE updates per CISA's required action — Oracle shipped the fix in its February 2012 Critical Patch Update, so any current, fully patched Java release clears the flaw; verify no legacy unpatched Java builds (including Apple-delivered Java on macOS, given the 2012 OS X exploitation campaigns) remain on endpoints. Remove or disable the Java browser plugin where it is not required, and restrict execution of untrusted applets and Java Web Start content.

98% KEV ransomware
  • Oracle Java SE
mass≈1 billion+ Java installations worldwide (desktop/server JRE and browser plugin deployments)
Full article866 words · extracted from securelist.com · click to collapse

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 patchesAtomic 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.

Text extracted automatically; images, tables and formatting may be missing. Original: https://securelist.com/os-x-mass-exploitation-why-now/33808/