天天看點

已遭利用的微軟0day CVE-2020-1464,原來是兩年前的老相識

已遭利用的微軟0day CVE-2020-1464,原來是兩年前的老相識

 聚焦源代碼安全,網羅國内外最新資訊!

編譯:奇安信代碼衛士團隊

在本月更新檔星期二中,微軟修複了一個已遭利用的 0day 漏洞 CVE-2020-1464。它可導緻MSI 檔案被轉換為惡意的 Java 可執行檔案,同時保留公司的合法數字簽名。

代碼簽名是指使用基于證書的數字簽名來簽名可執行檔案和腳本,驗證作者的身份并確定該代碼自作者簽名起并未遭修改或損壞。

微軟将該漏洞稱為欺騙漏洞,是由 Windows 不正确地驗證簽名檔案導緻的,“攻擊者如成功利用該漏洞,可繞過安全特征,不正确地加載已簽名檔案。在攻擊場景中,攻擊者能夠繞過旨在阻止加載不正确簽名檔案的安全特征”。微軟證明稱該漏洞已遭利用。

随後,Zengo 公司的安全研究員 Tal Be’ery 和 SafeBreach 實驗室的研究員 Peleg Hadar 釋出部落格文章指出,實際上微軟早在2018年8月18日就獲悉該漏洞(他們将該漏洞稱為 GlueBall),當時的決定是不修複。最近,又有研究員在2020年6月釋出 Security-in-bits 部落格文章指出,有惡意軟體濫用了該弱點。

已遭利用的微軟0day CVE-2020-1464,原來是兩年前的老相識
已遭利用的微軟0day CVE-2020-1464,原來是兩年前的老相識
已遭利用的微軟0day CVE-2020-1464,原來是兩年前的老相識

早在2018年就已檢測出

2019年1月,谷歌旗下VirusTotal 公司的研究員 Bernardo Quintero披露稱2018年,惡意簽名的 Java 可執行檔案如何被上傳到 VirusTotal Monitor 服務且被檢測到(59個引擎中的28個檢測到)、他分析後發現該 .jar 檔案是一個 MSI 檔案,且其尾部附加了一個 Java JAR 檔案。盡管該 MSI 檔案遭篡改并被更名為一個 JAR 檔案,但問題在于,Windows 仍然認為該檔案是由源自谷歌的一個合法證書簽名的。

已遭利用的微軟0day CVE-2020-1464,原來是兩年前的老相識
已遭利用的微軟0day CVE-2020-1464,原來是兩年前的老相識

由于某些安全解決方案使用數字簽名來判斷未知檔案是否應運作,是以威脅者可以使用這種技術建立 Java 惡意軟體,繞過安全軟體。發現這個缺陷後,Quintero 負責任地在2018年8月18日将其告知微軟,但微軟表示不會修複。

Quintero 指出,“這個攻擊向量已在 Windows 10 的最新更新版本以及可用 Java 版本中得到驗證(Windows 10 版本1809和 Java SE RuntimeEnvironment 8 Update 191)。微軟雖然已證明問題存在,但表示将不在目前的 Windows 版本中修複該問題,并同意我們公開這個案例和研究成果。”

為了檢測到這種類型的惡意 JAR 檔案,VirusTotal 在分析中增加了對這些已遭篡改檔案的檢測,SysInternal 的簽名檢查工具也被上傳到引擎。

釋出更新檔後,如果 MSI 檔案已遭附加的 JAR 檔案篡改,則微軟不再認為MSI 檔案已簽名。我們檢視 Windows 1909(圖左)和 Windows 10 2004(圖右)中使用該技術的惡意 JAR 檔案屬性時,就會看到微軟的修複方案。BleepingComputer 測試認為該安全更新僅僅是删除了由 JAR 檔案修改的 MSI 檔案上的數字簽名。

已遭利用的微軟0day CVE-2020-1464,原來是兩年前的老相識

如果在 MSI 檔案後面附加一個 .exe 可執行檔案,MSI 的簽名仍然是有效的,則表明簽名并未被修改。2019年,Chronicle 公司曾表示由于隻有 JAR 檔案能利用這個問題,是以它并不算缺陷,“截至目前來看,這種技術極其少見。當你在 MSI 末尾附加任何東西時,在這個案例中,隻有 JAR 将以原部落格文章所述方式執行。”

至于微軟為何花了兩年的時間才修複這個已遭利用的問題,微軟并未正面回應,隻是表示應用了最新安全更新的使用者免受該攻擊。目前也不清楚為何微軟未将Quintero 列為漏洞發現者。

MSI 檔案為何會遭篡改

鑒于 MSI 檔案的讀取方式,我們可以在不對簽名進行驗證的情況下篡改 MSI 檔案。

Tal Be’ery 表示,當 Windows 讀取 MSI 檔案時,它會從檔案開頭開始讀取,一直到有效的 MSI 簽名末尾結束并舍棄其它部分。是以在檢測到合法的 MSI 檔案結構後,它會忽略被附加的資料,而不管它是什麼。

如2019年報道的那樣,JAR 檔案隻不過是 ZIP 檔案,并且在執行時由 Java 運作時從檔案末尾開始讀取,直到檢測到有效 ZIP 檔案結構的開頭為止,然後它将丢棄檔案的其餘部分。

已遭利用的微軟0day CVE-2020-1464,原來是兩年前的老相識

當 Windows 開始從開頭讀取而 JAVA 從末尾讀取時,它允許 Windows 作業系統将 JAR 檔案看作是合法簽名的檔案。

同時,JAVA 從末尾開始讀取 JAR 檔案并丢棄其餘部分。

如此,我們就知道惡意行動者如何建立惡意 JAR 檔案同時欺騙公司的合法數字證書。

相關部落格文章請見:

https://www.securityinbits.com/malware-analysis/interesting-tactic-by-ratty-adwind-distribution-of-jar-appended-to-signed-msi/

https://medium.com/@TalBeerySec/glueball-the-story-of-cve-2020-1464-50091a1f98bd

推薦閱讀

微軟更新檔星期二修複120個漏洞,含2個已遭利用的 0day

已遭利用的Windows 0day漏洞 CVE-2020-1380分析

原文連結

https://www.bleepingcomputer.com/news/security/microsoft-fixes-actively-exploited-windows-bug-reported-2-years-ago/

https://krebsonsecurity.com/2020/08/microsoft-put-off-fixing-zero-day-for-2-years/comment-page-1/

題圖:Pixabay License

本文由奇安信代碼衛士編譯,不代表奇安信觀點。轉載請注明“轉自奇安信代碼衛士 www.codesafe.cn”。

已遭利用的微軟0day CVE-2020-1464,原來是兩年前的老相識
已遭利用的微軟0day CVE-2020-1464,原來是兩年前的老相識

奇安信代碼衛士 (codesafe)

國内首個專注于軟體開發安全的

産品線。

已遭利用的微軟0day CVE-2020-1464,原來是兩年前的老相識

 覺得不錯,就點個 “在看” 吧~

繼續閱讀