Chrome 在野零日漏洞
- 2019 年 11 月 28 日
- 筆記
原文：https://securelist.com/chrome-0-day-exploit-cve-2019-13720-used-in-operation-wizardopium/94866/ 譯者：neal1991
摘要
卡巴斯基安全防護是卡巴斯基產品的一部分，過去已成功檢測到許多零日攻擊。最近，為 Google的 Chrome 瀏覽器發現了一個未知的新漏洞。我們會立即將此情況報告給 Google Chrome 安全團隊。在審核了我們提供的 PoC 之後，Google 確認存在零日漏洞並將其分配為 CVE-2019-13720。Google 已針對 Windows，Mac 和 Linux 發布了 Chrome 版本78.0.3904.87，我們建議所有 Chrome 用戶儘快將其更新為最新版本！你可以點擊此處閱讀 Google 公告。
卡巴斯基端點產品藉助漏洞利用防禦組件檢測漏洞。該攻擊的裁決是 Exploit.Win32.Generic。
我們稱這些攻擊為 Operation WizardOpium。到目前為止，我們還無法與任何已知的威脅者建立明確的聯繫。與藍蓮花攻擊有某些非常弱的程式碼相似性，儘管這很可能是 false flag。目標網站的配置與最近部署了類似虛假標記攻擊的早期 DarkHotel 攻擊更加一致。
卡巴斯基情報報告的客戶可以獲取有關 CVE-2019-13720 和最近的 DarkHotel 的 false flag 攻擊的詳細資訊。有關更多資訊，請聯繫：[email protected]。
技術細節
攻擊利用朝鮮語新聞門戶上的水坑式注入。在主頁中插入了惡意的 JavaScript 程式碼，惡意程式碼又從遠程站點載入了分析腳本。
重定向到漏洞利用登錄頁面
主頁上託管了一個從 hxxp://code.jquery.cdn.behindcorona[.]com/ 中載入了遠程腳本的微不足道的 JavaScript 標籤。
然後，該腳本將載入另一個名為 .charlie.XXXXXXXX.js 的腳本。該 JavaScript 通過與瀏覽器的用戶代理進行比較來檢查受害者的系統是否能被感染，程式應在 64位 版本的 Windows 上運行，而不是 WOW64 進程；它還嘗試獲取瀏覽器的名稱和版本。該漏洞試圖利用 Google Chrome 瀏覽器中的 bug，腳本會檢查該版本是否大於或等於65（當前的Chrome版本為78）：
分析腳本（.charlie.XXXXXXXX.js）中 Chrome 版本檢測
如果檢測出瀏覽器版本，腳本將開始向攻擊者的受控伺服器 (behindcorona[.]com) 發送一些 AJAX 請求，其中路徑名指向傳遞給腳本（xxxxxxx.php）的參數。首先需要獲得一些將來有用的重要資訊。該資訊包括幾個十六進位編碼的字元串，這些字元串告訴腳本應從伺服器下載多少個實際漏洞利用程式碼，以及影像文件的 URL，這個圖片嵌入了最終載荷的密鑰和RC4密鑰從而對漏洞利用程式碼解密。
漏洞利用鏈– AJAX 請求 xxxxxxx.php
下載完所有程式碼塊後，RC4 腳本將所有部分解密並拼接在一起，這為攻擊者提供了一個包含完整瀏覽器漏洞的新 JavaScript 程式碼。為了解密這些部分，使用了之前的 RC4 密鑰。
另一次版本檢測
瀏覽器漏洞腳本被混淆；消除混淆後我們觀察到一些奇怪的事情：
- 對用戶代理的字元串進行另一項檢查–這次它檢查瀏覽器版本是 76 還是77。這可能意味著漏洞利用作者僅使用這些版本（先前的漏洞利用階段檢查的版本號為65或更高）或使用過去曾在舊版 Chrome 中使用過其他漏洞利用。
混淆後的漏洞利用程式碼
- 操作瀏覽器的內置 BigInt 類，這個類在 JavaScript 程式碼中執行 64 位算術很有用，例如，在 64位 環境中使用原生指針。通常情況下，漏洞利用開發者通過與32位數字實現自己的功能。但是，在這種情況下，使用的是BigInt，它應該更快，因為它是在瀏覽器的程式碼中本地實現的。漏洞利用開發者此處並未使用全部 64 位，而是使用較小的數字範圍。這就是為什麼它們實現一些功能以與數字的較高/較低部分兼容原因。
使用 64 位數字的程式碼片段
- 在實際的程式碼中有許多未使用的函數和變數。這通常意味著它們用於調試程式碼，然後在將程式碼移至生產環境時被遺忘。
- 大多數程式碼使用與瀏覽器的某些易受攻擊組件相關的幾個類。由於此 bug 仍未得到修復，因此我們此處不包括有關特定易受攻擊組件的詳細資訊。
- 有一些帶有數字的大數組，這些數字代表一個 shellcode塊 和一個嵌入式 PE 鏡像。
由於存在漏洞披露原則，我們在此提供的分析特意簡短。該漏洞利用了兩個執行緒之間的競爭條件錯誤，原因是它們之間缺少適當的同步。它使攻擊者處於釋放後使用（UaF）的狀態，這是非常危險的，因為它可能導致程式碼執行，這正是本例所發生的情況。
該漏洞利用程式首先嘗試觸發 UaF 對重要的64位地址（作為指針）執行資訊泄漏。結果是：1）如果地址成功泄漏，則表明漏洞利用正常。2）泄漏的地址用於定位堆/棧的位置，這使地址空間布局隨機化（ASLR）技術無效；3）通過在該地址附近進行搜索，可以找到其他一些有用的指針，以供進一步利用。
之後，它嘗試使用遞歸函數創建一堆大對象。這樣做是為了確定一些重要的的堆布局，這對於成功利用漏洞很重要。同時，它嘗試利用堆噴塗技術，該技術旨在重用先前在 UaF 部分釋放的指針。儘管實際上它們位於相同的記憶體區域，但該技巧可能會引起混亂，並使攻擊者能夠對兩個不同的對象進行操作（從 JavaScript 程式碼的角度來看）。
該漏洞嘗試執行許多操作來分配/釋放記憶體以及其他技術，這些技術最終為攻擊者提供了任意的讀/寫能力。這用於製作可以與 WebAssembly 和 FileReader 一起使用的特殊對象來執行嵌入的 Shellcode 有效載荷。
第一階段 shellcode
有效載荷說明
最終的有效載荷將作為加密的二進位文件（worst.jpg）下載，並由shellcode解密。
加密的有效載荷– Worst.jpg
解密後，惡意軟體模組將作為 updata.exe 拖放到磁碟上並執行。為了持久化，該惡意軟體會在 Windows Task Scheduler 中安裝任務。
有效載荷「安裝程式」是 RAR SFX 歸檔文件，其中包含以下資訊：
File size: 293,403 MD5: 8f3cd9299b2f241daf1f5057ba0b9054 SHA256: 35373d07c2e408838812ff210aa28d90e97e38f2d0132a86085b0d54256cc1cd
這個文檔包含兩個文件：
文件名: iohelper.exe
MD5: 27e941683d09a7405a9e806cc7d156c9 SHA256: 8fb2558765cf648305493e1dfea7a2b26f4fc8f44ff72c95e9165a904a9a6a48
文件名: msdisp64.exe
MD5: f614909fbd57ece81d00b01958338ec2 SHA256: cafe8f704095b1f5e0a885f75b1b41a7395a1c62fd893ef44348f9702b3a0deb
這兩個文件是同時編譯的，我們確信的依據是時間戳 "Tue Oct 8 01:49:31 2019」。
主模組（msdisp64.exe）嘗試從硬編碼的 C2 伺服器集中下載下一部分。下一部分位於 C2 伺服器上具有受害電腦名稱的文件夾中，因此威脅執行者可以了解有關哪些電腦被感染的資訊，並將下一階段模組放置在 C2 伺服器上的特定文件夾中。
卡巴斯基情報報告的客戶可以獲取有關此攻擊的更多詳細資訊。更多資訊，請聯繫：[email protected]。
IoCs
- behindcorona[.]com
- code.jquery.cdn.behindcorona[.]com
- 8f3cd9299b2f241daf1f5057ba0b9054
- 35373d07c2e408838812ff210aa28d90e97e38f2d0132a86085b0d54256cc1cd
- 27e941683d09a7405a9e806cc7d156c9
- 8fb2558765cf648305493e1dfea7a2b26f4fc8f44ff72c95e9165a904a9a6a48
- f614909fbd57ece81d00b01958338ec2
- cafe8f704095b1f5e0a885f75b1b41a7395a1c62fd893ef44348f9702b3a0deb
- [email protected]
譯者註：在影像中載入惡意程式碼也是一種常見的攻擊方式，之前也分析過一個黑產通過 Canvas 載入惡意程式碼
