Events

Telescope – Peering Into the Depths of TLS Traffc in Real-Time (HITB16)

Last week we have visited the HITBSecConf16 – conference in Amsterdam.
There were many interesting talks, and in this post I am going to tell you about a talk held by Radu Caragea – “Telescope: Peering Into the Depths of TLS Traffic in Real-Time”.

While performing a dynamic malware analysis one often needs to analyze network traffic in order to determine malware communication with C&C servers, to observe the malware delivery from sites, or to investigate honeypot traffic under TLS.
There are already existing solutions to help with this task. However in the given talk considering virtual environments the speaker presented a novel technique that works for virtualized machines with a minimal overhead, and is actually OS-agnostic and crypto-library-agnostic.

First of all, let’s take a look at the existing solutions.

  • SSLKEYLOGFILE variable: implemented in libNSS (Firefox) and openSSL (Chrome).
    • Is blatantly visible.
  • adding a custom root CA to the machine: used by AVs/proxies to intercept TLS traffic.
    • Is visible to malware scanning the disk.
  • PANDA keyfind plugin: for the machine running under QEMU, traces memory writes using pre-established “trace points”.
    • Huge overhead.
    • Is non portable.

We know, that while a conection is active, the keys must be in memory. What if one looks for them? There can be two problems:
1. The exact location of the key is unknown, so one would have to dump all the memory, which takes time and space; moreover, multiple connections occur one after another or are interspersed.
2. How to distinguish the keys from random memory?

To understand the approach being presented, let us have a closer look at the TLS connection, namely at the TLS handshake. With help of RFC5246/4346, one can find out when the keys get generated – this happens after Client Finished event, as Radu Caragea has shown on the following scheme:

Selection_130

Thus, if one can track the memory between Client Hello started and finished, then there is no need to dump the whole memory, which would solve partially the Problem 1.

To track memory, the given approach suggests reusing part of the Live Migration mechanisms present in most hypervisors. In particular Xen hypervisor and Logdirty mechanism were in focus.
The mechanism is the following: start tracking memory pages and flush the RAM to the target on the network, then get the “dirty” pages and send to the target again, repeat until number of pages is under threshold. Then stop the VM, do one last iteration, and continue execution.

Now, altogether the method used by TeLeScope is the following:
1. Filter target network events and send to netfilter queue
2. Start logging on Server Hello
3. Stop logging and dump pages on Client Finished
The result is a micro-memdump which can be processed any time offline.

The solution to Problem 2 depends on the cipher suite used. The Client/Server Finished messages have a fixed form:
14 00 00 0C [12 random bytes]
But one would need to be able to decrypt the first 4 bytes. Now the Telesync component is responsible for this. To see in details how does it work for different block ciphers, you can check the whitepaper by Radu Caragea.
The given technique can be applied also to other protocols that use a similar negotiation technique for the symmetric keys, such as VPN, SSH, Tor.

Two live demos were presented by the speaker showing the efficiency and speed of the given method. The first demo demonstrated extracting the keys for decrypting traffic. The second demo showed that with Telescope incorporated your hypervisor can track HTTPS connections, so you could see what an attacker is doing on your system/honeypot 😉
Telescope works in milliseconds, does not need to stop a VM for a long time to take a big memory dump and therefore becomes less noticeable.

You can find the presentation slides here!

Have a nice week,
Olga

Leave a Reply

Your email address will not be published. Required fields are marked *