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


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

Hadoop coop thrown for loop by malware snoop n' scoop troop? Oh poop

Attacks on distributed frameworks on the rise, it is claimed by infosec biz

Apache Hadoop spins cracking code injection vulnerability YARN

Loose .zips sink chips 2: Electric Boogaloo

Malware scum want to build a Linux botnet using Mirai

Hadoop YARN is the attack vector, so lock it away

Google logins make JavaScript mandatory, Huawei China spy shock, Mac malware, Iran gets new Stuxnet, and more

Roundup Plus, SystemD gets system de-bugged, again

China's clampdown on Tor pushes its hackers into foreign backyards

Comparing Middle Kingdom's hacker forums to Russia's? Apples and pears

Google Play Store spews malware onto 9 million 'Droids

How did these get through the net?

Fake mobile base stations spreading malware in China

'Swearing Trojan' pushes phishing texts around carriers' controls

When should I run backup, robot overlord? Autonomous Hadoop and NoSQL backup is now a thing

Imanis Data bets data management farm on backupbot

IBM leads BigInsights for Hadoop out behind barn. Shots heard

Data analytics platform sunset in December, but enterprise version spared

US-CERT warns of more North Korean malware

'Typeframe' springs from the same den as 'Hidden Cobra'