[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

How does the Hacking Team network malware work? How bad is it?



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-buyers-to-slip-malicious-code-into-youtube-videos-microsoft-pages/2014/08/15/31c5696c-249c-11e4-8593-da634b334390_story.html

-andy