Perhaps one of the most explosively discussed subjects of 2015 was the compromise and data dump of Hacking Team, the infamous Italian spyware company.
For those who are not familiar with the subject, Hacking Team was founded in 2003 and specialized in selling spyware and surveillance tools to governments and law enforcement agencies. On July 5, 2015, a large amount of data from the company was leaked to the Internet with a hacker known as “Phineas Fisher” claiming responsibility for the breach. Previously, “Phineas Fisher” did a similar attack against Gamma International, another company in the spyware/surveillance business.
The hacking of Hacking Team was widely discussed in the media from many different points of view, such as the legality of selling spyware to oppressive governments, the quality (or lack of…) of the tools and leaked email spools displaying the company’s business practices.
One of these stories attracted our attention.
So reads the title of a fascinating article written for Ars Technica by Cyrus Farivar on July 10, 2015. The article tells the story of Vitaliy Toropov, a 33-year-old exploit developer from Moscow who made a living by selling zero-day vulnerabilities to companies such as Hacking Team.
In the Ars Technica article, Cyrus writes the following paragraph, which shows the original offer from the exploit seller:
Excerpt from the Ars Technica article
For a company like Hacking Team, zero-days are their “bread and butter” — their software cannot infect their targets without effective exploits and zero-days, especially those that can bypass modern defense technologies such as ASLR and DEP. Those exploits are in very high demand.
The trade between these two continued until they finally agreed on purchasing an Adobe Flash Player zero-day, now defunct, for which Vitaliy Toropov promptly received a $20,000 advance payment.
A good salesman, Vitaliy Toropov immediately mailed back and offered a discount on the next purchases. So writes Cyrus, in his Ars Technica story:
Excerpt from the Ars Technica article
This section of the story immediately spiked our attention. A Microsoft Silverlight exploit written more than two years ago and may survive in the future? If that was true, it would be a heavyweight bug, with huge potential to successfully attack a lot of major targets. For instance, when you install Silverlight, it not only registers itself in Internet Explorer, but also in Mozilla Firefox, so the attack vector could be quite large.
In the past, we successfully caught and stopped several zero-days, including CVE-2014-0515 and CVE-2014-0546 (used by the Animal Farm APT group), CVE-2014-0497 (used by the DarkHotel APT group) and CVE-2015-2360 (used by the Duqu APT group). We also found CVE-2013-0633 a FlashPlayer zero-day that was used by Hacking Team and another unknown group.
We strongly believe that discovery of these exploits and reporting them to the affected software manufacturers free of charge makes the world a bit safer for everyone.
So while reading the Ars Technica story, the idea to catch Vitaliy Toropov’s unknown Silverlight exploit materialized.
How does one catch zero-days in the wild? In our case, we rely on several well-written tools, technologies and our wits. Our internal tools include KSN (Kaspersky Security Network) and AEP (Automatic Exploit Prevention).
To catch this possibly unknown Silverlight exploit we started by investigating the other exploits written by Vitaliy Toropov. Luckily, Vitaliy Toropov has a rather comprehensive profile on OVSDB. Additionally, PacketStorm has a number of entries from him:
This one caught our attention for two reasons:
One can easily grab the PoC from the same place:
Which we did.
The archive contains a well-written readme file that describes the bug, as well as source codes for the PoC exploit.
The exploit in this PoC simply fires up calc.exe on the victim’s machine. The archive includes a debug version compiled by the author, which is extremely useful to us, because we can use it to identify specific programming techniques such as specific strings or shellcode used by the developer.
The most interesting file in the archive is:
SilverApp1.dll:Size: 17920 bytesmd5: df990a98eef1d6c15360e70d3c1ce05e
This is the actual DLL that implements the Silverlight exploit from 2013, as coded by Vitaliy Toropov.
With this file in hand, we decided to build several special detections for it. In particular, we wrote a YARA rule for this file which took advantage of several of the specific strings from the file. Here’s what our detection looked like in YARA:
Pretty straightforward, no?
Actually, nowadays we write YARA rules for all high-profile cases and we think it’s a very effective way to fight cyberattacks. Great props to the Victor Manuel Alvarez and the folks at VirusTotal (now Google) for creating such a powerful and versatile tool!
After implementing the detection, we waited, hoping that an APT group would use it. Since Vitaliy Toropov was offering it to Hacking Team, we also assumed that he sold it to other buyers, and what good is a zero-day if you don’t use it?
Unfortunately, for several months, nothing happened. We had already forgotten about this until late November 2015.
On November 25th, one of our generic detections for Toropov’s 2013 Silverlight exploit triggered for one of our users. Hours later, a sample was also uploaded to a multiscanner service from Lao People’s Democratic Republic (Laos).
This file was compiled in July 21, 2015, which is about two weeks after the Hacking Team breach. This also made us think it was probably not one of the older 2013 exploits but a new one.
It took us some time to analyse and understand the bug. When we were absolutely sure it was indeed a new zero-day exploit, we disclosed the bug to Microsoft.
Microsoft confirmed the zero-day (CVE-2016-0034) and issued a patch on January 12, 2016.
The vulnerability exists in the BinaryReader class. When you create an instance of this class you can pass your own realization of the encoding process:
Moreover, for the Encoding process you can use your own Decoder class:
Looking at the BinaryReader.Read() code, we see the following:
Indeed, the “index” value was checked correctly before this call:
But if you will look deeper inside InternalReadChars (this function is marked as unsafe and it is using pointers manipulations) function you will see the following code:
The problem appears because the GetChars function could be user-defined, for instance:
Therefore, as you can see we can control the “index” variable from user-defined code. Let’s do some debugging.
This is a Test.buf variable, where 05 is the array length before triggering the vulnerability:
After calling BinaryRead.Read method we are stopping in InternalReadChars method (index is 0):
After this call we stopped in user-defined code:
This is a first call of user-defined function and we return incorrect value from it. In the next iteration, the “index” variable contains the incorrect offset:
After we change the offset we can easily modify memory, for instance:
This is a Test.buf object after our modifications in decoder method:
One of the biggest questions we have is whether this is Vitaliy Toropov’s Silverlight zero-day which he tried to sell to Hacking Team. Or is it a different one?
Several things make us think it’s one of his exploits, such as the custom error strings. Of course, there is no way to be sure and there might be several Silverlight exploits out there. One thing is for sure though – the world is a bit safer with the discovery and patching of this one.
One final note: due to copyright reasons, we couldn’t check if the leaked Hacking Team archive has this exploit as well. We assume the security community which found the other zero-days in the HackingTeam leaks will also be able to check for this one.
If you’d like to learn how to write effective YARA rules and catch new APTs and zero-days, why not take our elite YARA training before SAS 2016? Hunt APTs with Yara like a GReAT Ninja (with trainers Costin Raiu, Vitaly Kamluk and Sergey Mineev). The class is almost sold out!
Kaspersky products detect new Silverlight exploit as HEUR:Exploit.MSIL.Agent.gen.