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:
- 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.
- 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:
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:
- Filter target network events and send to netfilter queue
- Start logging on Server Hello
- 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