Security researchers the world over have been digging through the massive HackingTeam dump for the past five days, and what we’ve found has been surprising. I’ve heard this situation called many things, and there’s one description that I can definitely agree with: it’s like Christmas for hackers.
“On the fifth day of Christmas Bromium sent to me a malware analysis B-L-O-G” – You
This is a very interesting situation we’ve found ourselves in. We have our hands on the code repositories of HackingTeam, and inside of them we’ve found the source code for a cross-platform, highly-featured, government-grade RAT (Remote Access Trojan). It’s rare that we get to do analysis of complex malware at the source-code level, so I couldn’t wait to write a blog about it!
For those paying attention to infosec news, it’s no secret that HackingTeam – a provider of exploits and malware to governments around the world – has been hacked. The hackers who hacked the hackers released a torrent with over 400GB of internal HackingTeam software, tools, write-ups, and, of course, 0-day exploits. One of the exploits we’ve come across was first exposed by the Twitter user @w3bd3vil, and is reminiscent of the “ActionScript-Spray” attack used in CVE-2014-0322 and first documented by Bromium researcher Vadim Kotov. In summary, CVE-2014-0322 used a UAF (user after free) vulnerability in Microsoft’s Internet Explorer to increase the size of an ActionScript Vector object, giving the attacker access to the heap of the process. HackingTeam’s exploit uses this idea to achieve execution, but uses a UAF bug internal to the ActionScript 3 engine.
Note: before diving in, let’s remember that this is not a weaponized 0day, but a PoC that HackingTeam provided to customers, so we don’t have any malicious payload to accompany it; only a simple calc.exe pop.
In a typical drive-by-download attack scenario the shellcode would download and execute a malware binary. The malware binary is usually wrapped in a dropper that unpacks or de-obfuscates and executes it. Droppers’ main goal is to launch malware without being detected by antiviruses and HIPS. Nowadays the most popular way of covert launching would probably be process hallowing. Recently we found a couple of curious specimen that does not follow this fashion. These cases are not new, but we thought they’re worth mentioning because we’ve been seeing quite a few of those lately.
Here at Bromium Labs, we’re always striving to further our knowledge of the rapidly-changing attack landscape that threatens our enterprise customers. Over the past few months, our dedicated team of researchers have collectively developed a severe chemical dependency on caffeine in search of a paradigm to clearly define this landscape in a way that could benefit the security community as a whole. What they came up with is truly groundbreaking, and will go down in history as “The ABC’s of APT.”
As we all know, the term APT refers to an “Advanced Persistent Threat.” In our research, we realized each APT has unique behavior, and casting them all under one umbrella can be a slippery slope towards people marrying their television sets. For this reason, we devised our own paradigm that strips the broad term “APT” from threat diagnoses and, instead, categorizes them using a more specialized spectrum. Surprisingly, this spectrum happens to encompasses twenty-six different distinct behaviors – each of which can be represented using one letter of the alphabet. And, thus, The ABC’s of APT were born. Without further blabbering, here’s our finished diagnosis table:
Gamers may be used to paying to unlock downloadable content in their favorite games, but a new crypto-ransomware variant aims to make gamers pay to unlock what they already own. Data files for more than 20 games can be affected by the threat, increasing what is already a large target for cybercriminals. Another file type that hasn’t been targeted before is iTunes related. But first, let’s have a look at the initial infection.
CVE-2014-9322 is described as follows:
arch/x86/kernel/entry_64.S in the Linux kernel before 3.17.5 does not properly handle faults associated with the Stack Segment (SS) segment register, which allows local users to gain privileges by triggering an IRET instruction that leads to access to a GS Base address from the wrong space.
It was fixed on 23rd November 2014 with this commit.
I have seen neither a public exploit nor a detailed discussion about the issue. In this post I will try to explain the nature of the vulnerability and the exploitation steps as clearly as possible; unfortunately I cannot quote the full 3rd volume of Intel Software Developer’s Manuals, so if some terminology is unknown to the reader then details can be found there.
Memory corruption has plagued computers for decades, and these bugs can often be transformed into working cyber-attacks. Memory corruption is a situation where an attacker (malicious user of an application or network protocol) is able to send some data that is improperly processed by the native computer code. That can lead to important control structure changes that allow the attacker unexpected influence over the path a program will travel.
Recently I presented at the 31st Chaos Communication Congress (together with Corey Kallenberg) and presented a talk titled “Attacks on UEFI security”. We described (and demoed) vulnerabilities allowing us to achieve write access to the flash chip (that stores UEFI code) and to SMM memory (that holds the code for the all-powerful System Management Mode). The CERT vulnerability notes are here, here and here ; you are also encouraged to read the presentation, the whitepaper and the second whitepaper.
TL;DR-style, these vulnerabilities are useful for an attacker who already has administrative privileges in the operating system, and wants to install a UEFI-based or SMM-based rootkit. So no, the sky is not falling, and this type of attack is not seen often in the wild. Yet some well knows cases are known, and as the topic gains quite some attention recently, there might be more in the future.