(No Ratings Yet)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

February 7, 2018 1

X.509 Metadata Could Carry Information Through a Firewall

in Hashing Out Cyber Security

It’s a serious vulnerability, but it’s unlikely to be exploited

A researcher has published a Proof-of-Concept that shows how an X.509 certificate could carry information through a firewall.

Jason Reaves of Fidelis Cybersecurity demonstrated that X.509 certificate exchanges could carry malicious traffic last July at the BSides conference. Now he has published his PoC. It details how a covert channel could use files in X.509 extensions to pilfer data from an organization.

“In brief, TLS X.509 certificates have many fields where strings can be stored,” writes Reaves. “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. Cool, eh?

No, not really. This exploit would allow an attacker to potential sneak an executable or some other type of code into a certificate field, then use it to exfiltrate data.

So I decided to ask our Systems Application Specialist, Nick Perkins, about it.

Here’s what he said:

Reviewing the exploit, it appears to only be applicable for self-signed certificates as the extension field being used; SubjectKeyIdentifier, would be filled by the Certificate Authority (CA) (see below) and thus not reproducible. Within the SubjectKeyIdentifier field, in the example given the “hacker” has compromised the systems of the organization and the certificate that is being delivered is a self-signed certificate that contains a malicious binary to the end-user. This binary in the example is using Mimikatz which is capable of pulling the Username, Domain Network, and Password of a Windows user.

While it is a security risk, I would say that it is not anything to freak out about, because a majority of internal systems would be using a trusted SSL Certificate and therefore would produce an error with the self-signed certificate. If not, a majority of organizations that are using a self-signed certificate would have mechanisms ideally to key-pin the right SSL Certificate so that it does not mistake/connect to the wrong certificate. Furthermore, there are some limitations with the example given such as memory access and being able to hold/transmit the information within the end-user’s memory pool. Thus, it cannot exceed the memory pool and if it does it will error.

So the threat is real, but the likelihood of it getting exploited in the wild are low.

Still, here are a couple ways to look out for it:

• Check for executables in digital certificates. There’s no reason an SSL certificate should have .exe file in a certificate’s data.
• Additionally, you may want to block self-signed certificates at the perimeter.

• #SSL Certificates