How does the Hacking Team network malware work? How bad is it?
Hi, I've read the Intercept's writeup[1], and read through Citizen Lab's writeup[2]. I'm having trouble understanding the attack surface, and how widely applicable the vulnerability is. Are MS and Google targeted because of their ubiquity, or is there also something (besides not using HTTPS) that they did to make their services vulnerable? How can there be a remote code vulnerability so low in the stack that it can be injected at the packet level, but high enough that TLS encryption foils the attack? Does this affect Windows only? Through particular browsers? I'm certainly up for using this as an argument for how difficult it is to predict the severity and creativity of MITM attacks, but I would like to better understand the magnitude of the disclosure. Thanks, Eric [1] https://firstlook.org/theintercept/2014/08/15/cat-video-hack/ [2] https://citizenlab.org/2014/08/cat-video-and-the-death-of-clear-text/ -- https://konklone.com | https://twitter.com/konklone
On Sun, Aug 17, 2014 at 05:24:38PM -0400, Eric Mill wrote:
I've read the Intercept's writeup[1], and read through Citizen Lab's writeup[2]. I'm having trouble understanding the attack surface, and how widely applicable the vulnerability is.
Are MS and Google targeted because of their ubiquity, or is there also something (besides not using HTTPS) that they did to make their services vulnerable?
As an attacker, you want your attack to be targeted to a single user. (It's not the end of the world if you QUANTUMINSERT a few extra machines, but byspray increases the likelihood of a sample escaping to a non-colluding AV vendor [if there are any of those] or a curious researcher.) So you want to target a HTTP session that you have high assurance belongs to the targeted user. For targets who have a Google account, Google has helpfully assigned cookies which associate the user's account with the HTTP stream. These cookies are initially established over https, but are linked to YouTube cookies for unencrypted http so that YouTube can provide valuable advertising services at lower cost than serving over HTTPS.
How can there be a remote code vulnerability so low in the stack that it can be injected at the packet level, but high enough that TLS encryption foils the attack?
The general technique is flexible to any targeted vulnerable network software, but to make my description more concrete, the Flash one is very understandable. The Flash plugin has hundreds of unpatched RCE vulns. The exploit for these vulns is generally a sequence of a few hundred ActionScript bytecode instructions. The YouTube webpage serves a very standardized Flash .flv file which is nearly identical for every video. So as the QUANTUMINSERT vendor, you code up a module which takes the .flv off the wire from the server, patches it to include the exploit, and puts a new .flv on the wire to the user. Then you wire that up to an inline capture appliance which uses an FPGA running at 10GigE wire speed to match HTTP responses that contain the desired cookie, and just wait for your target to desire a fuzzy kitten video. I don't know any details of any fielded systems, so the following is just my description of a sensible way to build this product. (I have some experience building products with these technologies.) The injection is extremely low level, at the Ethernet frame processing layer. The FPGA has the responsibility of running at line rate and forwarding all frames except those belonging to a stream marked as a match. When the regex engine running in the FPGA sees the Cookie: header of the target, it notes the IP-4-tuple (srcIP, srcPort, dstIP, dstPort) as an intercepted stream, and forwards those packets to a higher-level software layer. Every other stream on the network keeps running as normal. At the higher layer, QUANTUMINSERT wants to keep youtube.com happy, so it forges the ACK packets that the browser would have been sending. QUANTUMINSERT also can see what packets the browser has received so far, and the data that youtube.com was sending. QUANTUMINSERT then edits the FLV, on the fly, so that it contains the exploit code *and* the fluffy kitten video. The resulting FLV is the same size or maybe a few hundred bytes longer, but that's peanuts compared to the size of the MPEG video stream, so nobody notices.
From the point of view of youtube.com, the unmolested flv was served. From the point of view of the browser, youtube.com sent it a flv to run, it just arrived 150 milliseconds later than expected (due to the QUANTUMINSERT flv editing software). From the point of view of the user, the fluffy cat video pranced as expected. From the point of view of the Mukhabarat, they've got a backdoor into the PC of another dangerous twitter user.
(OK the Bahraini Mukhabarat don't use QUANTUMINSERT, they are a Hacking Team customer. Same difference.)
Does this affect Windows only? Through particular browsers?
Any specific attack is platform+browser dependent, but the general technique works everywhere where you have 0day RCE vulns. (ie everywhere.) Browser and OS vulnerability mitigation techniques like ASLR and (especially) sandboxing highly vulnerable components like Flash can help enormously by raising the complexity of exploits, by reducing the supply of known+weaponized 0day, and by requiring more complicated multistage exploits. If you haven't read it already, the WaPo spy story is *incredible*: http://www.washingtonpost.com/world/national-security/spyware-tools-allow-bu... -andy
participants (2)
-
Andy Isaacson -
Eric Mill