Security

Insider threat

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

13 SHARE

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

13 Comments

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

US-CERT warns of more North Korean malware

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

Alibaba and Elastic slingshot searchable, analyticky cloud ... outside China

That noise was AWS rolling over in its sleep

China-based hackers take an interest in Cambodia's elections

Group named 'TEMP.Periscope' releasing RATs says FireEye

Snooping passwords from literally hot keys, China's AK-47 laser, malware, and more

Roundup Your two-minute guide to the week's infosec bits

Security bods liberate EITest malware slaves

Miscreants' command and control network traffic sent down sinkhole

Russian malware harvesting Telegram Desktop creds, chats

Python programmer may have outed himself on YouTube

FBI fingers North Korea for two malware strains

'Joanap' and 'Brambul' harvest info about your systems and send it home

Google's cuddling up to China with clouds in its eyes – reports

Drive and Docs may end up in Tencent-owned DCs