[[202730]]

一、前言

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

二、背景

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

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

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

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

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

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

三、數(shù)字簽名二進(jìn)制格式

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

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

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

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

嵌入的PE Authenticode簽名

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

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

安全目錄中文件偏移指向的二進(jìn)制數(shù)據(jù)是一個WIN_CERTIFICATE結(jié)構(gòu)體。下面是這個結(jié)構(gòu)在010Editor中的顯示(文件偏移是0x000A9600):

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

使用在線ASN.1解碼器解析原始的bCertificate數(shù)據(jù)，我們能確認(rèn)我們處理的是正確的PKCS #7數(shù)據(jù)：

四、將數(shù)字簽名應(yīng)用于未簽名的代碼

現(xiàn)在你已經(jīng)對數(shù)字簽名的二進(jìn)制格式和存儲位置有了大概的了解，你能開始將存在的簽名應(yīng)用于未簽名的代碼中了。

內(nèi)嵌的Authenticode簽名的應(yīng)用

將簽名文件中內(nèi)嵌的Authenticode簽名應(yīng)用到未簽名的PE文件中是很簡單的。盡管過程可以自動化，但是我還是解釋一下如何通過一個二進(jìn)制編輯器和CFF Explorer來手動實(shí)現(xiàn)。

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

第2步：確定安全目錄中的WIN_CERTIFICATE結(jié)構(gòu)體的偏移和位置

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

第3步：使用二進(jìn)制編輯器打開kernel32.dll，選擇開始于偏移0xA9600的0x3A68字節(jié)，并復(fù)制這些字節(jié)。

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

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

完成了!現(xiàn)在，簽名校驗(yàn)工具將解析并顯示適當(dāng)?shù)暮灻Ｎㄒ坏木媸呛灻遣豢煽康模驗(yàn)橛?jì)算文件的Authenticode不能匹配存儲在證書中的哈希。

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

將catalog簽名應(yīng)用于PE文件

實(shí)際上，CryptSvc一直會運(yùn)行并執(zhí)行catalog查詢操作。假設(shè)你想注意OPSEC并想匹配用于簽名你目標(biāo)二進(jìn)制的相同的證書。事實(shí)上，你確實(shí)能通過交換WIN_CERTIFICATE結(jié)構(gòu)中的bCertificate并更新dwLength來將catalog文件的內(nèi)容應(yīng)用于內(nèi)嵌的PE簽名。注意我們的目標(biāo)是將Authenticode簽名應(yīng)用于我們的未簽名的二進(jìn)制中，這和用于簽名catalog文件是相同的：證書thumprint 是AFDD80C4EBF2F61D3943F18BB566D6AA6F6E5033。

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

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

第3步：在16進(jìn)制編輯器中手動構(gòu)造WIN_CERTIFICATE結(jié)構(gòu)。讓我們?yōu)g覽下我們使用的每個字段：

• dwLength：這是WIN_CERTIFICATE結(jié)構(gòu)的全部長度，如bCertificate字節(jié)加上其他字段的大小=4(DWORD的大小)+2(WORD的大小)+0x000137C7(bCertificate，.cat文件的大小)=0x000137CF.
• wRevision: 0x0200表示W(wǎng)IN_CERT_REVISION_2_0
• wCertificateType: 0x0002表示W(wǎng)IN_CERT_TYPE_PKCS_SIGNED_DATA
• bCertificate：這包含了catalog文件的原始數(shù)據(jù)

當(dāng)在16進(jìn)制編輯器中構(gòu)造完，注意按小端存儲字段。

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

現(xiàn)在，假設(shè)你的計(jì)算和對齊是正確的，thumbprint將匹配catalog文件。

五、異常檢測

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

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

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

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

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

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

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

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

8. 專業(yè)人員在調(diào)查不同證書使用相同的代碼時，應(yīng)該找到Authenticode哈希。VirusTotal提供了Authentihash值，該值也能通過Sigcheck –h計(jì)算。如果我調(diào)查一個例子的不同變種對應(yīng)單獨(dú)的一個Authentihash，我發(fā)現(xiàn)那將非常有趣。