一、简介

最近，我们威胁研究小组研究发现了一种新的隐蔽通道数据传输方法，使用在TLS和SSL加密协议中广泛采用的公钥证书标准（X.509）实现。虽然证书是安全Web通信的关键组件，但交换方式可能会被滥用，从而导致证书本身被劫持用于命令和控制通信。而到目前为止，我们尚未证实这种滥用在野使用。但是，证书的广泛使用意味着许多组织都可能开源这种新的数据传输方法。

二、主要研究结果

1、X.509扩展可用于隐蔽通道数据传输。

2、在没有建立TLS会话的情况下，TLS握手期间允许C2交换证书[4]。

3、通过X.509扩展传输的数据可绕过不检查证书值的检测方法。

4、本博客将提供一个定制的框架作为poc，同时使用Suricata和我们自己Fidelis Elevate平台的技术检测方法，帮助社区加强保护措施，识别未来可能使用的隐藏通道数据传输机制。

三、隐蔽通道

使用隐蔽通道在网络上传输数据并不新鲜。在过去的二十年，各种刊物上都有这样的参考文献[1]。例如，向ICMP追加数据被认为是2005年采用的数据传输方式[2]，其引用了1997年的文献。实际上，最早提出采纳实用的隐蔽通道出自1993年的政府刊物[3]。研究人员不断的寻找滥用协议及RFC的新颖方法，以实现难以检测的数据传输方法。

2018年1月，Fidelis的研究人员Jason Reaves发表了使用X.509扩展来实现隐藏通道的研究[7]，扩充了此前的研究[6]。可在已发表的研究[5] [17]中阅读相关方法。

Jason在论文中描述了一个系统，可用来发送或接收来自客户端和服务器的数据。通过对X.509证书的研究，特别是可将任意二进制数据嵌入证书，或许可将其用作隐蔽通道。研究表明，动力十足的攻击者可利用此技术实现超出预定目标的攻击，最终可绕过常见的安全措施。

简而言之，TLS X.509证书有很多可以存储字符串的字段，可参见这张图片[16]。这些字段包括版本、序列号、颁发者名称、有效期等。在研究中描述的证书滥用，就是将传输的数据隐藏在这些字段中的一个。由于证书交换在TLS会话建立之前，因此好像没有进行数据传输，而实际上数据在证书交换过程中传输。

已经了解了这些，接下来看看该如何做出保护。

四、滥用异常扩展

除了上面提到的RFC之外，OID和ASN.1 [10,11,12]中还有许多优秀的文章可以参考。具体来说，我们讨论检测异常X.509扩展SubjectKeyIdentifier，OID为2.5.29.14，转换为BER编码则为06 03 55 1d 0e。 

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

图1：OID解析

从poc框架生成的数据中，可以看到来自SSL握手中证书数据的扩展。

图2:  PCAP 数据中的扩展

OID之后的数据04 0c 04 0a如下：

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

图3：Octet字符串标签字节的解析 

接下来的10个字节是有问题的Octet字符串。此扩展用来保存一个Hash，但我们可看到已被10字节的数据代替。为此，创建一个正则表达式：/\x06\x03\x55\x1d\x0e\x04.\x04/。然后我们想看看此模式下的下一个字节何时不是Hash长度（使用MD5、SHA1、SHA256、SHA384和SHA512这些最常见的Hash算法）。正常SubjectKeyIdentifier扩展（8字节只在特定服务中出现）中，长度为（0x10，0x14，0x20，0x30，0x40）之一。 添加到正则表达式中：/\x06\x03\x55\x1d\x0e\x04.\x04[^\x08\x10\x14\x20\x30\x40]/。

五、Fidelis Elevate

现在，为直接在Fidelis Elevate的证书上应用此正则表达式，需要为测试的PCAP生成一个YARA规则。当这些扩展非常大时会导致大多数库限制最终握手数据包的大小，但证书自身的扩展可创建一个只受内存限制的长度。如果Octet字符串的长度超过127，那么我们的正则表达式不再有效。我们可以利用一些长形式的Octet编码[10]来简单地查找长度大于127的扩展实例，而不是试图检测每一种可能性。比二进制形式的127字节，就很可疑。这就使得我们可以创建另一个YARA字符串来查找{06 03 55 1d 0e 04 8?}，它将查找SubjectKeyIentifier中数据长度大于127的任一Octet字符串。

rule abnormal_subjectkeyid
{
meta:
author = "Jason Reaves"
strings:
$shortlens = /\x06\x03\x55\x1d\x0e\x04.\x04[^\x08\x10\x14\x20\x30\x40]/
$longlens = {06 03 55 1d 0e 04 8?}
condition:
any of them
}

图4：异常subjectkeyidentifier扩展的Yara规则 

六、Suricata

最新版本的Suricata包括很多围绕TLS的功能，但不幸的是没有包含扩展。幸运的是，我们仍然可以通过TCP直接在证书数据上签名。X.509[8]中的扩展将所有数据都以ASN.1格式[9]存储在OID中：

     Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
 
     Extension ::= SEQUENCE {
          extnID OBJECT IDENTIFIER,
          critical BOOLEAN DEFAULT FALSE,
          extnValue OCTET STRING

图5：X.509v3扩展

     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 {

图6: ASN.1 OID

由于Suricata中的TLS包不能绑定扩展自身，所以我们首先需要在SSL握手中进行转换，然后有根据的猜测从哪里开始寻找意外扩展。利用在创建YARA规则方面所做的研究，创建以下Suricata规则：

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:"/\x06\x03\x55\x1d\x0e\x04.\x04[^\x08\x10\x14\x20\x30\x40]/"; classtype:misc-attack;
sid:1000001; rev:1;)

要查找超长的octet字节，类似规则如下:

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:"/\x06\x03\x55\x1d\x0e\x04[\x80-\xff]/"; classtype:misc-attack; sid:1000002; rev:1;)

七、Framework / Mimikatz

为扩充自己的研究和框架，我们决定写一个poc，演示如何使用X.509隐蔽通道传输文件。还有比在隐蔽通道上传输Mimikatz [13]更好的选择么？在poc中，恶意二进制文件通过TLS协商传输，模拟威胁行为者将Mimikatz传输到已经攻陷的系统上。

图7：PCAP中的证书包含Mimikatz

签名的另一作用是检查证书中的可执行文件。为什么在证书数据内有一个可执行文件？感兴趣的话，演示代码和PCAP文件已经上传到Github [14]。

最后，在已发布的框架中，我们使用自签名证书。在边界阻止自签名证书可能会成为针对这些攻击的非常有用的保护机制。毕竟，现在我们有LetsEncrypt [15]的免费证书，可从整个社区中获取大量的资源。

八、总结

隐蔽通道命令和控制机制的研究会不断产生有趣的传输数据的新方法。本文我们将自己的研究描述为一种实现隐蔽数据传输的方法，此方法可能会被网络边界保护所忽略。此外，还描述了一些检测异常证书来进行隐蔽通信的可能的方法。 

Fidelis Elevate能检测本文中描述的异常证书行为，保护客户。

九、参考文献

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. http://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. http://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 http://securitybsides.com/w/page/121779924/BSidesSpfd 2017

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