[[202730]]

一、前言

我們都知道，攻擊者會將合法的數字簽名證書應用于他們的惡意軟件中，想來應該是為了逃避簽名校驗。其中有個例子就是勒索軟件Petya。作為一個逆向工程師或者是紅隊開發人員，了解如何將合法簽名應用于未簽名、攻擊者提供的代碼中是很重要的。本文將介紹代碼簽名機制，數字簽名二進制格式，和在未簽名的PE文件中應用數字證書的技術。很快你就能看到我下個月發布的一些研究與這些技術有關。

二、背景

對PE文件(exe,dll,sys等)簽名了意味著什么?簡單來說就是如果打開PE文件的文件屬性，有個標簽頁是“數字簽名”，那么意味著它是簽名過的。當你看到標簽“數字簽名”，意味著PE文件是Authenticode簽名，在其文件內部有個二進制數據塊，它包含了證書和文件哈希(特別說明的是，在計算Authenticode哈希時不考慮PE頭)。Authenticode簽名的存儲格式可以在PE Authenticode規范中找到。

有很多文件有簽名，但是卻不包含“數字簽名”標簽頁(例如notepad.exe)。這是否意味著文件沒有簽名或者微軟發布了未簽名的代碼?當然不是。盡管notepad沒有內嵌的Authenticode簽名，但是它有另一種簽名(catalog簽名)。Windows包含了一個由很多catalog文件組成的catalog存儲，它基本上是個Authenticode哈希列表。每個catalog文件都被簽名，以表明任何匹配哈希的文件都來自catalog文件的簽名者(大部分微軟文件是這樣的)。因此盡管Explorer UI沒有試圖查找catalog簽名，但是可以使用其他簽名校驗工具來查詢catalog簽名，如powershell中的Get-AuthenticodeSignature和Sysinternals中的Sigcheck工具。

注意：catalog文件位于%windir%\System32\CatRoot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}

在上面的截圖中，SignatureType屬性表明notepad.exe是catalog簽名。還值得注意的是IsOSBinary屬性。盡管其實現是未文檔化的，如果簽名是已知的微軟根證書，那么這將顯示True。可以通過逆向CertVerifyCertificateChainPolicy函數來了解其中內部原理。

使用“-i”選項調用Sigcheck來驗證catalog證書，它也會顯示包含匹配到Authenticode哈希的catalog文件路徑。“-h”選項也會計算并顯示PE文件的SHA1和SHA256 Authenticode哈希(PESHA1和PE256)。

知道了Authenticode哈希，你就可以查看catalog文件中的各種條目。你可以雙擊一個catalog文件以查看它的信息。我寫了一個CatalogTools的PowerShell模塊來解析catalog文件。“hint”元數據字段表明了確實是notepad.exe的信息。

三、數字簽名二進制格式

現在，你已經了解了PE文件的簽名(Authenticode和catalog)，了解一些簽名的二進制格式是有用的。Authenticode和catalog簽名都以PKCS #7 signed data格式存儲，它是ASN.1格式的二進制數據。ASN.1只是一個標準，是用來表明不同數據類型的二進制數據是如何存儲的。在解析數字簽名之前，你必須首先知道它在文件中是如何存儲的。Catalog文件是直接包含了原始的PKCS #7數據。有個在線的ASN.1解碼器可以解析ASN.1數據，并直觀的顯示出來。例如，嘗試加載notepad.exe的catalog簽名，你將直觀的看到數據的布局。下面是解析結果的片段：

ASN.1編碼數據中的每個屬性都開始于一個對象ID(OID)，這是一種表示數據類型的唯一數字序列。上面片段中值得看的OID如下：

1. 1.2.840.113549.1.7.2：這表明了以下是PKCS #7簽名數據，它是Authenticode和catalog簽名的格式。
2. 1.3.6.1.4.1.311.12.1.1：這表明下面是catalog文件哈希數據

花時間瀏覽數字簽名中所有的字段是值得的。本文無法包含所有的字段，然而另外的加密/簽名相關的OID能在這里找到。

嵌入的PE Authenticode簽名

內嵌在PE文件中Authenticode簽名被追加到文件的末尾(這是格式良好的PE文件)。很明顯，操作系統需要一些信息以便提取出內嵌的簽名偏移和大小。使用CFF Explorer看查看下kernel32.dll：

內嵌的數字簽名的偏移和大小存儲在可選頭中的數據目錄的安全目錄中。數據目錄包含了PE文件中各種結構的偏移和大小，如導出表，導入表，重定位等。在數據目錄中的所有的偏移都是相對虛擬地址(RVA)，意味著它們是PE文件加載到內存中相對基址的偏移。只有一個例外，那就是安全目錄，其存儲的偏移是文件偏移。原因是Windows加載其不會將安全目錄的內容加載到內存中。

安全目錄中文件偏移指向的二進制數據是一個WIN_CERTIFICATE結構體。下面是這個結構在010Editor中的顯示(文件偏移是0x000A9600):

PE Authenticode簽名應該總是包含WIN_CERT_TYPE_PKCS_SIGNED_DATA的wRevision。PKCS #7,ASN.1編碼簽名的數據的字節數組和catalog文件中看到的是一樣的。唯一的不同是你找不到OID 1.3.6.1.4.1.311.12.1.1(其表明是catalog哈希)。

使用在線ASN.1解碼器解析原始的bCertificate數據，我們能確認我們處理的是正確的PKCS #7數據：

四、將數字簽名應用于未簽名的代碼

現在你已經對數字簽名的二進制格式和存儲位置有了大概的了解，你能開始將存在的簽名應用于未簽名的代碼中了。

內嵌的Authenticode簽名的應用

將簽名文件中內嵌的Authenticode簽名應用到未簽名的PE文件中是很簡單的。盡管過程可以自動化，但是我還是解釋一下如何通過一個二進制編輯器和CFF Explorer來手動實現。

第1步：確定你想要盜取的Authenticode簽名。在這個例子中，我使用kernel32.dll

第2步：確定安全目錄中的WIN_CERTIFICATE結構體的偏移和位置

上面截圖中的文件偏移是0x000A9600，大小是0x00003A68。

第3步：使用二進制編輯器打開kernel32.dll，選擇開始于偏移0xA9600的0x3A68字節，并復制這些字節。

第4步：使用二進制編輯器打開未簽名的PE文件(本例中是HelloWorld.exe)，滾動到文件末尾，粘帖從kernel32.dll拷貝的數據。保存文件。

第5步：使用CFF Explorer打開HelloWorld.exe，并更新安全目錄指向數字簽名的偏移(0x00000E00)和大小(0x00003A68)。修改后保存文件。忽略“不可靠”的警告。CFF Explorer不會將安全目錄作為文件偏移，當它試圖引用數據所在節時就產生了“困境”。

完成了!現在，簽名校驗工具將解析并顯示適當的簽名。唯一的警告是簽名是不可靠的，因為計算文件的Authenticode不能匹配存儲在證書中的哈希。

現在，如果你想知道SignerCertificate thumbprint值為什么不匹配，那么你是個有追求的讀者啊。考慮到我們使用了相同的簽名，為什么不能匹配證書thumbprint呢?這是因為Get-AuthenticodeSignature首先會試圖查詢kernel32.dll的catalog文件。這個例子中，它找到了kernel32的條目，并顯示了catalog文件中的簽名者的簽名信息。Kernel32.dll也是使用Authenticode簽名的。為了校驗Authenticode哈希的thumprint值是相同的，臨時關閉了負責查詢catalog哈希的CryptSvc服務。現在你將看到thumprint值已經匹配了，這表明catalog哈希是使用不同于kernel32.dll使用的簽名證書來簽名的。

將catalog簽名應用于PE文件

實際上，CryptSvc一直會運行并執行catalog查詢操作。假設你想注意OPSEC并想匹配用于簽名你目標二進制的相同的證書。事實上，你確實能通過交換WIN_CERTIFICATE結構中的bCertificate并更新dwLength來將catalog文件的內容應用于內嵌的PE簽名。注意我們的目標是將Authenticode簽名應用于我們的未簽名的二進制中，這和用于簽名catalog文件是相同的：證書thumprint 是AFDD80C4EBF2F61D3943F18BB566D6AA6F6E5033。

第1步：確定包含你的目標二進制的Authenticode哈希的catalog文件，本例是kernel32.dll。如果一個文件使用Authenticode簽名，Sigcheck解析catalog文件將失敗。但是Signtool(windows SDK中包含)還是可以用。

第2步：在16進制編輯器中打開catalog文件，文件大小是0x000137C7

第3步：在16進制編輯器中手動構造WIN_CERTIFICATE結構。讓我們瀏覽下我們使用的每個字段：

• dwLength：這是WIN_CERTIFICATE結構的全部長度，如bCertificate字節加上其他字段的大小=4(DWORD的大小)+2(WORD的大小)+0x000137C7(bCertificate，.cat文件的大小)=0x000137CF.
• wRevision: 0x0200表示WIN_CERT_REVISION_2_0
• wCertificateType: 0x0002表示WIN_CERT_TYPE_PKCS_SIGNED_DATA
• bCertificate：這包含了catalog文件的原始數據

當在16進制編輯器中構造完，注意按小端存儲字段。

第4步：從構造的WIN_CERTIFICATE中復制所有的內容，將他們附加到未簽名的PE文件中，并更新安全目錄的偏移和大小。

現在，假設你的計算和對齊是正確的，thumbprint將匹配catalog文件。

五、異常檢測

希望本文描述的技術能使人思考到如何檢測數字簽名的濫用。盡管我沒有徹底調查過簽名檢測，但是讓我們拋出一系列問題來激勵其他人開始研究并寫出簽名異常的檢測：

1. 對于合法簽名的微軟PE，PE時間戳和證書有效期是否有相關性呢?攻擊者提供的代碼的時間戳偏離上述的相關性嗎?

2. 在閱讀本文后，哈希不匹配的簽名文件的信任等級是多少?

3. 如何檢測內嵌Authenticode簽名包含catalog文件的PE文件?Hint：上述提到的特定的OID可能是有用的。

4. 停止/禁用CryptSvc服務對本地簽名驗證有什么影響?如果這中情況發生了，那么大部分系統文件，其所有的意圖和目的都將不會簽名

5. 每個合法的PE中我都能看到有0x10字節的填充。我演示的例子中沒有0對齊的x10。

6. 合法的微軟數字簽名和應用到自簽名證書中的所有證書屬性有什么不同?

7. 數字簽名之外有數據追加會怎么樣?參考這篇文章。

8. 專業人員在調查不同證書使用相同的代碼時，應該找到Authenticode哈希。VirusTotal提供了Authentihash值，該值也能通過Sigcheck –h計算。如果我調查一個例子的不同變種對應單獨的一個Authentihash，我發現那將非常有趣。