This article is more than 1 year old
X.509 metadata can carry information through the firewall
Certificate exchange used as a side-channel before the certs get to work
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. ®
Biting the hand that feeds IT
