一種新的隱蔽通道數據傳輸方法：濫用X.509公鑰證書繞過網路防禦

一、簡介

最近，我們威脅研究小組研究發現了一種新的隱蔽通道數據傳輸方法，使用在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位元組的數據代替。為此，創建一個正則表達式：/x06x03x55x1dx0ex04.x04/。然後我們想看看此模式下的下一個位元組何時不是Hash長度（使用MD5、SHA1、SHA256、SHA384和SHA512這些最常見的Hash演算法）。正常SubjectKeyIdentifier擴展（8位元組只在特定服務中出現）中，長度為（0x10，0x14，0x20，0x30，0x40）之一。 添加到正則表達式中：/x06x03x55x1dx0ex04.x04[^x08x10x14x20x30x40]/。

五、Fidelis Elevate

現在，為直接在Fidelis Elevate的證書上應用此正則表達式，需要為測試的PCAP生成一個YARA規則。當這些擴展非常大時會導致大多數庫限制最終握手數據包的大小，但證書自身的擴展可創建一個只受內存限制的長度。如果Octet字元串的長度超過127，那麼我們的正則表達式不再有效。我們可以利用一些長形式的Octet編碼[10]來簡單地查找長度大於127的擴展實例，而不是試圖檢測每一種可能性。比二進位形式的127位元組，就很可疑。這就使得我們可以創建另一個YARA字元串來查找，它將查找SubjectKeyIentifier中數據長度大於127的任一Octet字元串。

rule abnormal_subjectkeyid

{

meta:

author = "Jason Reaves"

strings:

$shortlens = /x06x03x55x1dx0ex04.x04[^x08x10x14x20x30x40]/

$longlens =

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:"/x06x03x55x1dx0ex04.x04[^x08x10x14x20x30x40]/"; 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:"/x06x03x55x1dx0ex04[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

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！