Sometimes What’s Missing is Right in Front of Us, We Only Need to Look

Introduction:

Recent research conducted by our threat research team has identified a new method of covert channel data exchange using a well-known and widely implemented public key certificates standard (X.509) utilized in both TLS and SSL cryptographic internet protocol implementations. While certificates are a critical component of secure web communications, the way they are exchanged may be abused to allow the certificate itself to be hijacked for command and control communication. Detection is possible today and we know of no confirmed cases of this abuse being used in the wild. However, the widespread use of certificates means that many organizations are potentially open to this new data transfer method.

Key Findings

1. X.509 extensions can be used for covert channel data transfer.
2. Certificates are exchanged during the TLS handshake allowing C2 without an established TLS session[4].
3. Data transferred via X.509 extensions may bypass detection methods that do not inspect certificate values.
4. A custom-built framework will be provided with this blog as a proof of concept Technical detection methods using both Suricata and our own Fidelis Elevate platform will also be covered to help the community implement protections to identify possible future use of these covert channel data transfer mechanisms.

Covert Channels

Using covert channels to move data across a network is not new. There are historic references[1] to doing so occurring in a variety of publications over the past two decades. Appending data to ICMP, for example, was proposed as a means to transfer data back in 2005[2], with citations pointed to publications from 1997. Indeed, one of the earliest mentions of practical covert channel use comes in a government publication from 1993[3]. Researchers continue to find novel ways to abuse protocols and RFC implementations to achieve difficult-to-detect data transfer methods.

In January 2018, Fidelis researcher Jason Reaves published his research into using X.509 extensions for covert channel purposes[7] which expands on previous research into this subject[6]. You can read about the proposed method in the published research[5][17].

In his paper, Jason describes a system that could be used to send or receive data from both a client and a server perspective utilizing research into X.509 certificates specifically in areas where you can place arbitrary binary data into the certificate or utilizing them as a covert channel. The research demonstrates that a sufficiently motivated attacker can utilize technologies outside of their intended purposes to not only accomplish their goals but also end up bypassing common security measures in the process.

In brief, TLS X.509 certificates have many fields where strings can be stored. You can see them in this image[16]. 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. Cool, eh?

Now that you know the “what” and “why” of it, let’s look at “how” we see it on the wire and can implement protections for it going forward.

Anomalous Extension Abuse

Aside from the RFC data mentioned above, there are a number of excellent write-ups surrounding OID and ASN.1 [10,11,12] that can help alleviate digging through RFCs. Specifically, we’re going to talk about detecting anomalous X.509 extension SubjectKeyIdentifier which is OID 2.5.29.14, converted to BER encoding gives us 60 03 55 1d 0e.

TAG := 06 - Object Identifier
  LENGTH:= 03
    OID := 55 1d 0e SubjectKeyIdentifier 2.5.29.14

Figure 1: OID Breakdown

In the data generated from our proof of concept framework we can see the extension in the certificate data from the SSL handshake.

Figure 2: Extension in PCAP data

The following data after the OID or 04 0c 04 0a is:

TAG := 04 - Octet String
  LENGTH := 12
   TAG := 04 – Octet String
     LENGTH := 10

Figure 3: Breakdown of Tag Bytes for Octet String

The following 10 bytes are the octet string in question. This extension is supposed to hold a hash value, but instead we see 10 bytes of data. Creating a regex for this would be like “/x06x03x55x1dx0ex04.x04/”. Then we want to see when the next byte in this pattern is not a hash length or using the most common hash algorithms of MD5, SHA1, SHA256, SHA384 and SHA512. A length would be one of (0x10, 0x14, 0x20, 0x30, 0x40) in a normal SubjectKeyIdentifier extension(8 bytes as well shows up with certain services). Adding this to our regex produces “/x06x03x55x1dx0ex04.x04[^x08x10x14x20x30x40]/”.

Fidelis Elevate

Now, since we can apply this regex directly on certificates in Fidelis Elevate, that’s all we need to produce a YARA rule for our test PCAP. These extensions can be very large which causes most libraries to attempt to limit the ultimate handshake packet size, but the extension in the certificate itself can be created to a length that appears to only be limited by memory. If the length of the octet string exceeds 127, then our regex is no longer valid. Instead of trying to detect every possibility however we can utilize some of the knowledge of the long form length octet encoding [10] to simply look for instance of this extension where the length is greater than 127. Finding that would mean a hash length of greater than 127 bytes in binary form, which would also be suspect. That allows us to create another YARA string to look for this “{06 03 55 1d 0e 04 8?}” which would look for any octet string in a SubjectKeyIentifier with a data length greater than 127.

rule abnormal_subjectkeyid
{
meta:
author = "Jason Reaves"
strings:
$shortlens = /x06x03x55x1dx0ex04.x04[^x08x10x14x20x30x40]/
$longlens = {06 03 55 1d 0e 04 8?}
condition:
any of them
}

Figure 4: Yara rule for abnormal subjectkeyidentifier extensions

Suricata

The latest Suricata release included a number of features revolving around TLS, but unfortunately did not include extensions. Luckily we can still signature on the certificate data through TCP directly.

Extensions in X.509[8] have all their data stored in ASN.1 format[9] with OIDs:

     Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension

     Extension ::= SEQUENCE {
          extnID OBJECT IDENTIFIER,
          critical BOOLEAN DEFAULT FALSE,
          extnValue OCTET STRING

Figure 5: X.509v3 extensions

     Tag Length    Value
     30  15:       SEQUENCE {
     06  3:        OBJECT IDENTIFIER basicConstraints (2 5 29 19)
     01  1:        BOOLEAN TRUE
     04  5:        OCTET STRING, encapsulates {
     30  3:        SEQUENCE {

Figure 6: ASN.1 OID

Since we can’t peg on the extension itself using the TLS package in Suricata we need to pivot on the SSL handshake at the beginning and then make an educated guess on where start looking for the unexpected extensions. Utilizing the research we already did in the creation of our YARA rule we create the following Suricata rule:

alert tcp any any -> any any ( msg:"Abnormal x509v3 SubjectKeyIdentifier extension"; dsize:>768;
​content: "|16 03|"; depth:2; content:"|06 03 55 1d 0e 04|"; offset:0x150;
pcre:"/x06x03x55x1dx0ex04.x04[^x08x10x14x20x30x40]/"; classtype:misc-attack;
sid:1000001; rev:1;)

To find the very large octet length versions we do something similar:

alert tcp any any -> any any ( msg:"Fidelis abnormal very long x509v3 SubjectKeyIdentifier
extension"; dsize:>768; content: "|16 03|"; depth:2; content:"|06 03 55 1d 0e 04|"; offset:0x150;
pcre:"/x06x03x55x1dx0ex04[x80-xff]/"; classtype:misc-attack; sid:1000002; rev:1;)

Framework / Mimikatz

To expand on our own research and the framework we decided to write up a proof of concept demonstrating transferring a file using the X.509 covert channel. What better file for a demonstration of transferring a file over a covert channel than Mimikatz[13] in the clear? For the proof of concept being released the malicious binary is being transferred over TLS negotiation traffic to simulate a threat actor transferring Mimikatz to an already compromised system.

Figure 7: Mimikatz inside certificate in PCAP

Another possibility for signaturing is checking for executables in certificates. Why would you have an executable file inside of a certificates data? For those interested the demonstration code and PCAP file have been uploaded to Github[14].

Finally, within the published framework we are using self-signed certificates. Blocking self-signed certificates at the perimeter could be a useful protection mechanism for these attacks as well. After all we have free alternatives now with LetsEncrypt[15] which has picked up a lot of steam from the community as a whole.

Conclusion

Research into covert channel command and control mechanisms continue to produce interesting new ways to transfer data. Here we have described our research into one way to implement covert data transfer that may go unnoticed by network perimeter protections. We’ve gone on to describe a number of possible ways to detect anomalous certificates carrying covert communications.

Fidelis Elevate detects the anomalous certificate activity described in this post to protect our customer environments.

References:

1 Piscitello, Dave, VP Of Security and ICT Coordinator, “What Is a DNS Covert Channel?”
https://www.icann.org/news/blog/what-is-a-dns-covert-channel

2 Fielder, Wayne, “Ping? A Covert Channel??”, https://www.giac.org/paper/gcih/664/ping-covertchannel/104890

3 NCSC-TG-030, Covert Channel Analysis of Trusted Systems (Light Pink Book), 1993 from the United States Department of Defense (DoD) Rainbow Series publications.

4 IBM Corporation (1999), “An overview of the SSL or TLS handshake”, https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.1.0/com.ibm.mq.doc/sy10660_.htm

5 Reaves, J. (2018). Covert Channel by Abusing X.509 Extensions. https://vixra.org/abs/1801.0016

6 Scott, Carlos. (2008). Network Covert Channels: Review of Current State and Analysis of Viability of the use of X.509 Certificates for Covert Communications

https://www.researchgate.net/publication/48602678_Network_Covert_Channels_Review_of_Current_State_and_Analysis_of_Viability_of_the_use_of_X509_Certificates_for_Covert_Communications

7 Covert channel. (2017, December 19). https://en.wikipedia.org/wiki/Covert_channel

8 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. https://tools.ietf.org/html/rfc5280

9 ASN.1 Translation. https://tools.ietf.org/html/rfc6025

10 OCTET STRING. https://msdn.microsoft.com/enus/library/windows/desktop/bb648644(v=vs.85).aspx

11 Introduction to ASN.1 and the Packed Encoding Rules. https://www.w3.org/Protocols/HTTPNG/asn1.html

12 Kaliski Jr., B. (1993). A Layman’s Guide to a Subset of ASN.1, BER, and DER. https://luca.ntop.org/Teaching/Appunti/asn1.html

13 https://github.com/gentilkiwi/mimikatz

14 https://github.com/fideliscyber/x509

15 https://letsencrypt.org/

16 https://www.cem.me/art/cryptoposters/x509.png

17 https://securitybsides.com/w/page/121779924/BSidesSpfd%202017

Watch Jason’s presentation at BSides 2017 – https://www.youtube.com/watch?v=y38-xLf4iEo