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

Security bods liberate EITest malware slaves

Miscreants' command and control network traffic sent down sinkhole

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

Stop appreciating the irony and go install the patch now

Medic! Orangeworm malware targets hospitals worldwide

Hacking campaign goes after care providers and equipment

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

Hey, govt hacker bod. Made some really nasty malware? Don't be upset if it returns to bite you

RSA 2018 Cough, cough, EternalBlue, cough, cough Wannacry, splutter, Stuxnet

Prez Donald Trump to save manufacturing jobs … in China, at ZTE

Sanctions for Chinese networks-and-smartmobe outfit one week, diplomacy the next

Infosec brainiacs release public dataset to classify new malware using AI

Data is the secret sauce to advancing AI research