There was a weekend this past July when security pundits and the tech media got little if any sleep.
“On Sunday night, unidentified hackers published a massive, 400 gigabyte trove on bittorrent of internal documents from the Milan-based Hacking Team, a firm long accused of unethical sales of tools that help governments break into target computers and phones,” wrote WIRED’s Andy Greenberg. “The breached trove includes executive emails, customer invoices and even source code; the company’s twitter feed was hacked, controlled by the intruders for nearly 12 hours, and used to distribute samples of the company’s hacked files.”
Two senior security researchers at Malwarebytes, Jean Taggart and Jérôme Segura avoided the feeding frenzy, taking advantage of a rare opportunity to observe how the digital netherworld functions; in particular, how fast the bad guys take exploit proof-of-concept information and turn it into working malcode.
Among the 400 gigabytes of the Hacking Team’s data, researchers sifting through the data discovered three previously unknown exploits: two for Flash Player and one for the Windows kernel. Taggart and Segura focused on one of the Flash-Player vulnerabilities: CVE-2015-5119.
Taggart, during a phone conversation, said, “One of the first things we noticed was that the Hacking Team presented information (the partial ReadMe file shown below) about the exploit in a clear and concise manner, as if the target audience included customers who lacked the technical ability to find and develop their own zero-day malware.”
The UaF memory coruption exists inside the AS3 "opaqueBackground property
setter of the flash.display.DisplayObject class.
The DisplayObject source code is not published like the core AS3 classes, so
you have to view opaqueBackground setter in your dissassembler.
TODO: low-level details.
3. AFFECTED SOFTWARE
Adobe Flash PLayer 9+ 32/64-bit (since Jun 2006)
And the race between good guys and bad guys was on
Segura and Taggart soon realized they had a golden opportunity. Bad guys and good guys were learning about the exploits at the same time — what would be first: patches or malware? The following is the race time line for the CVE-2015-5119 vulnerability.
July 6, 2015 (approximately 12:00 PDT): Public disclosure of Hacking Team data breach and that 400 gigabytes of data were stolen. Taggart and Segura downloaded the data and began searching for anything useful.
July 6, 2015: webDEViL (@w3bd3vil), a security researcher, sent out a tweet referencing the CVE-2015-5119 Flash zero-day and the above ReadMe file.
Then Segura and Taggart got busy. The two added the Malwarebytes Anti-Exploit program to several test computers — that way, if a test computer got co-opted, Anti-Exploit would send telemetry back to the researchers, and hopefully block the malware from activating. The researchers then directed the test computers toward certain websites. (All I know about these particular websites is that it’s best to avoid them.)
Since the CVE-2015-5119 exploit is zero-day, I asked Taggart how Anti-Exploit would find anything. “Anti-Exploit does not rely on identifying bits of code,” said Taggart. “Anti-Exploit baselines the computer’s normal operation and reports all abnormal behavior.”
July 7, 2015 (15:23 PDT): Malware reported. Segura recorded a hit from the Neutrino exploit kit, and more importantly, the exploit kit made use of the CVE-2015-5119 vulnerability. In the screen shot below, please notice the red rectangle on the left side encircling “Protection Technique: Exploit code executing from Heap memory blocked.” This is of interest, and you will see why in a bit.
July 7, 2015 (15:40 PDT): Another exploit kit spotted. Taggart said they immediately noticed the different “Protection Technique: Exploit Stack Pivoting attempt blocked.” This signified a different exploit kit. In this case, one called Angler, and it also had incorporated CVE-2015-5119.
As the day progressed, more and more exploit kits were captured.
July 8, 2015 (12:13 PDT): Finally a patch. Brian Krebs reported that Adobe issued an update addressing the vulnerability with Flash Player 18.104.22.168. Taggart said the Adobe update did in fact remove the zero-day status from CVE-2015-5119. However, the exploit will remain effective for the foreseeable future, as not everyone is diligent about keeping programs up-to-date.
What does this mean?
When asked what this all meant, Taggart cautioned me that his answer depends on whether I am asking him as a digital citizen or as a security researcher. As a user of the internet, he is concerned. The bad guys are able to pull together working malware and get it distributed throughout the world faster than most would have thought.
As a security researcher, he is thrilled about what they learned. I asked for specifics. Here’s his list.
- The underground must have teams of competent coders on standby, as the time of discovery to working exploit kit was one day.
- The bad guys must have a large network of compromised web servers to which they can add snippets of malcode at will.
- The exploit kit makers are not that concerned about patches being available. New exploit kits were spotted almost two weeks after Adobe pushed out the update.
As for what this means about the system, it does not bode well for the good guys. In a fair race, the good guys were a full day behind in getting a patch out, or should I say making the patch available (it still needs to be installed). The problem is the bad guys seldom if ever play fair.
Money back guarantee?
There is a certain amount of irony in all this. Organizations and individuals who have purchased “information” from the Hacking Team prior to the data breach are probably not real happy. With the element of surprise gone, I wonder if they’re asking for their money back.
Also see on ZDNet
- APT Darkhotel deploys Hacking Team zero-day vulnerability
- Hacking Team data theft culprit exposed
- Hacking Team: We won’t ‘shrivel up and go away’ after cyberattack
- Researcher lashes out at Hacking Team over open-source code discovery
Note: ZDNet and TechRepublic are CBS Interactive sites.