X.509 metadata can carry information through the firewall

Certificate exchange used as a side-channel before the certs get to work

By Richard Chirgwin

Posted in Security, 6th February 2018 05:02 GMT

Video A security researcher, who last year demonstrated that X.509 certificate exchanges could carry malicious traffic, has now published his proof-of-concept code.

Fidelis Cybersecurity's Jason Reaves has disclosed a covert channel that uses fields in X.509 extensions to sneak data out of corporate networks.

The X.509 standard defines the characteristics of public key certificates, and anchors much of the world's public key infrastructure; for example, it defines the certificates exchanged at the start of a TLS session.

The reason this matters, Reaves explained in a presentation at the Bsides conference in July 2017, is that if a company's systems were hijacked by hackers, the miscreants could exfiltrate sensitive internal documents over the X.509 path without being noticed.

TLS uses X.509 for certificate exchange, during the handshake process that sets up an encrypted communication.

Fidelis' paper describing the data-leaking technique, put out this month, explained:

In brief, TLS X.509 certificates have many fields where strings can be stored … The fields include version, serial number, Issuer Name, validity period and so on. The certificate abuse described in our research takes advantage of this fact to hide data transfer inside one of these fields. Since the certificate exchange happens before the TLS session is established there appears to never be data transfer, when in reality the data was transferred within the certificate exchange itself.

The particular field Reaves' proof-of-concept code abused is called SubjectKeyIdentifier, and while “most libraries” try to cap the packet size during the handshake, “the extension in the certificate itself can be created to a length that appears to only be limited by memory.”

It would be hard to spot, Reaves said in his Bsides presentation: “How do you detect this? You have to parse out all the data inside X.509, and there's a lot."

In the proof-of-concept code (here), Fidelis transferred a copy of Mimikatz in the TLS negotiation, simulating an attacker pushing Benjamin Delpy's attack tool into a compromised network. Here's what that looks like:

Mimikatz in an X.509 certificate. Image: Fidelis Cybersecurity

Reaves wrote that the proof-of-concept code used self-signed certificates, and blocking those may be a useful way to defeat any such attack. A video of his presentation is below. ®

Sign up to our NewsletterGet IT in your inbox daily


More from The Register

IBM leads BigInsights for Hadoop out behind barn. Shots heard

Data analytics platform sunset in December, but enterprise version spared

Fake mobile base stations spreading malware in China

'Swearing Trojan' pushes phishing texts around carriers' controls

Microsoft emergency update: Malware Engine needs, erm, malware protection

Stop appreciating the irony and go install the patch now

Insecure Hadoop installs next in 'net scum crosshairs

Because MongoDB, Elasticsearch ransomware attacks are sooo last week

Taiwanese cops give malware-laden USB sticks as prizes for security quiz

What was second prize? We think we'd rather have that

Crumbs! Crunchyroll distributed malware for a couple of hours

Anime-streamer is fine again, and disinfection is easy

First shots at South Korea could herald malware campaign of Olympic proportions

Russia, Norks and dog lovers all potential perps, say pundits

China staggering under WannaCrypt outbreak

Middle Kingdom's CERT puts infection rate in the thousands

China plots new Great Leap Forward: to IPv6

It'll be a doddle because we invented it, claims state-owned organ Xinhua

Clusters f**ked: Insecure Hadoop file systems wiped by miscreants

Weak default settings attract data deletion attacks despite warnings