Responding to Firefox 0-days in the wild
On Thursday, May 30, over a dozen Coinbase employees received an email purporting to be from Gregory Harris, a Research Grants Administrator at the University of Cambridge. This email came from the legitimate Cambridge domain, contained no malicious elements, passed spam detection, and referenced the backgrounds of the recipients. Over the next couple weeks, similar emails were received. Nothing seemed amiss.
On June 17 at 6:31am, Gregory Harris sent another email, but this one was different. It contained a URL that, when opened in Firefox, would install malware capable of taking over someone’s machine.
Coinbase Security quickly discovered that these emails were anything but ordinary — they were all part of a sophisticated, highly targeted, thought out attack that used spear phishing/social engineering tactics and, most importantly, two Firefox 0-day vulnerabilities.
Within a matter of hours, Coinbase Security detected and blocked the attack. Here’s how it unfolded.
The exploit
There were two separate 0-days chained together in this attack, one that allowed an attacker to escalate privileges from JavaScript on a page to the browser (CVE-2019–11707) and one that allowed the attacker to escape the browser sandbox and execute code on the host computer (CVE-2019–11708). CVE-2019–11707 was simultaneously discovered by Samuel Groß of Google’s Project Zero and the attacker. Based on significant differences in the way the attacker, a group we track as CRYPTO-3 and is also referred to as HYDSEVEN, chose to trigger the vulnerability versus the trigger used by the Project Zero PoC, we do not believe that the attacker acquired the exploit from either Mozilla or Google but independently discovered the vulnerability. Samuel Groß goes into more detail about why this is the case here.
The second exploit, CVE-2019–11708, is also very interesting. While the core vulnerability has been present in Firefox for quite a while, the way this attacker chose to trigger the vulnerability has only been possible since May 12. This indicates a very rapid discovery-to-weaponization cycle on the part of the attacker (or whoever the attacker acquired the 0-day from). When reviewing the actual exploit code, there are a number of notable features. First, while the delivery of the 0-day was highly targeted (it was only delivered to about 5 individuals out of the 200 initially targeted), there was no effort to obfuscate the JavaScript itself. When reviewing the code, we noted that it was well structured.
Functions and variables have descriptive names, and the code is broken into reasonable functional units. Overall, it feels like the work of a group that has significant experience developing exploits.
The setup
Once the attackers had this initial capability, they turned their attention to the delivery method. They compromised or created two email accounts and created a landing page at the University of Cambridge, and on May 28 registered the domain used to deliver the exploit. We don’t know when the attackers first gained access to the Cambridge accounts, or whether the accounts were taken over or created. As others have noted, the identities associated with the email accounts have almost no online presence and the LinkedIn profiles are almost certainly fake. Cambridge provides its staff with the ability to host personal files under the Cambridge domain. Once the attackers had access to the accounts in question, they prepared a series of pages by cloning and modifying existing Cambridge University pages and making them available in the personal storage directories of the attacker-controlled accounts.
The attack
The first phishing emails began on May 30. The first emails to go out contained no malicious elements (the link in the below screenshot did not contain any malicious code).
The attackers went through a qualification process and multiple rounds of emails with potential victims, making sure they were high-payoff targets before they directed victims to the page containing the exploit payload. This process commonly spanned weeks and only about 2.5% of the people who received the initial emails ended up receiving a link to the page hosting the 0-day. The attackers did a good job of creating a sense that the victims were talking to legitimate people using several techniques. Compromised academic emails allowed them to avoid any email filtering or common spam detection, and by spreading the communication out, the attackers modeled normal human behavior. The contents of the email referenced real academic events and were narrowly targeted at the backgrounds of the individuals being phished.
Once the attackers had qualified a target, they sent a separate link containing the exploit payload. Stage one of this attack first identified the operating system and browser, and displayed a convincing error to macOS users who were not currently using Firefox, instructing them to install the latest version from Mozilla. After visiting the page in Firefox, the exploit code was delivered from a separate domain, analyticsfit[.]com, which was registered on May 28. The exploit payload used CVE-2019–11707 and CVE-2019–11708 to gain arbitrary code execution as the user. The attacker’s shellcode then shelled out a curl command to download and run a stage 1 implant. The stage 1 implant (07a4e04ee8b4c8dc0f7507f56dc24db00537d4637afee43dbb9357d4d54f6ff4) pulled down by the shellcode was 32-bit, which causes macOS to pop up a warning that 32-bit execution is being deprecated. The stage 1 binary was a variant of the Netwire family. While this implant is capable of acting as a fully-featured RAT, the attackers seem to use it mostly as an initial recon and credential theft payload. We detected the attacker at this stage, based on a number of behaviors (e.g. Firefox shouldn’t spawn a shell). After exfiltration of recon data and a basic pillage of obvious credential stores (.ssh, .aws, .gpg, keychain, etc) and document formats, followed by a delay indicative of human involvement, the stage 1 payload is used to bootstrap a stage 2 payload (97200b2b005e60a1c6077eea56fc4bb3e08196f14ed692b9422c96686fbfc3ad). The stage 2 payload is a variant of the Mokes family. The attackers seem to use this implant as a full-fledged RAT. We’ve observed activity of the stage 2 implant consistent with direct human control. Our assumption is that stage 1 only advances to stage 2 where the attackers believe they have landed on a host of value. We have also observed the attackers specifically target cloud services, e.g. gmail and others, via browser session token theft via direct access to browser datastores. This activity also offers the opportunity for behavior-based detection, as relatively few processes should be directly accessing those files.
Our response
We began investigating this incident based on both a report from an employee and automated alerts. First, we examined the employee’s machine in our endpoint detection and response tooling. Looking at recent process activity, Firefox shelling out to curl stood out immediately. The response team spun up an incident and first tried to determine the scope of the attack. We collected IOCs from the host in question and started hunting broadly in our network. We did not see any of the IOCs anywhere else in our environment, and blacklisted all the IOCs that we had at that time. Simultaneously, we collected samples, including capturing the 0-day, from the phishing site while it was still live and the attackers were likely unaware of our response. We also revoked all credentials that were on the machine, and locked all the accounts belonging to the affected employee. Once we were comfortable that we had achieved containment in our environment, we reached out to the Mozilla security team and shared the exploit code used in this attack. The Mozilla security team was highly responsive and was able to have a patch out for CVE-2019–11707 by the next day and CVE-2019–11708 in the same week.
We also reached out to Cambridge University to assist in securing their infrastructure and to collect more information about the attacker’s behavior. As a result, we were able to quickly degrade the attacker’s ability to continue their campaign and learn more about the scope of the campaign. We learned that over 200 individuals were targeted by this attacker, and identified the organizations employing these individuals so that we could reach out and give their security teams the information they needed to secure their infrastructure and protect their employees.
We were able to defend ourselves from this attack due to our security-first culture at Coinbase, complete deployment of our detection and response tooling, clear and well-practiced playbooks, and the ability to rapidly revoke access. The cryptocurrency industry has to expect attacks of this sophistication to continue, and by building infrastructure with excellent defensive posture, and working with each other to share information about the attacks we’re seeing, we’ll be able to defend ourselves and our customers, support the cryptoeconomy, and build the open financial system of the future.
Coinbase will continue to face tough security challenges in the future and meet them head on. If you’re interested in being a part of the security team here at Coinbase, check out some of the available positions on our careers page.
This website contains links to third-party websites or other content for information purposes only (“Third-Party Sites”). The Third-Party Sites are not under the control of Coinbase, Inc., and its affiliates (“Coinbase”), and Coinbase is not responsible for the content of any Third-Party Site, including without limitation any link contained in a Third-Party Site, or any changes or updates to a Third-Party Site. Coinbase is not responsible for webcasting or any other form of transmission received from any Third-Party Site. Coinbase is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement, approval or recommendation by Coinbase of the site or any association with its operators.
Responding to Firefox 0-days in the wild was originally published in The Coinbase Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
