至頂網軟件頻道消息： 微軟在本周的"補丁星期二"發布的補丁的更新方式中的一個問題導致一些用戶的電腦和服務器出現藍屏、宕機和/或無法重啟。
微軟針對Windows 10 1703（Windows 10 Creators Update）、Windows 10 1607（Windows 10周年紀念更新）和Windows Server 2016的更新對一些將其作為10月10日的"補丁星期二"更新的一部分進行部署的商業用戶造成了嚴重的破壞。安裝后導致問題的更新是KB4041676和KB4041691。
造成這個問題的顯然不是補丁本身，而是因為微軟不小心在Windows Server Update Services（WSUS）和System Center Configuration Manager（系統中心配置管理器）中同時發布了Cumulative更新（累計更新）和Delta更新（增量更新），因此兩者可能同時被安裝到機器上，從而引發這個問題。由于微軟不會將Delta更新（增量更新）發布到Microsoft Update（微軟更新），因此如果用戶不使用WSUS和Configuration Manager（配置管理器）的話，這個問題就不會影響到他們。
正如微軟在其docs.com網站上的一篇文章中解釋的那樣，"如果您同意并部署相同版本的Delta（增量）和Cumulative（累積）更新，則不僅會生成額外的網絡流量--因為它們都將下載到PC，而且你在重啟計算機后可能無法重新啟動Windows。"
受到影響的用戶可以采取一些步驟讓系統再次運行，微軟在docs.com網站上的這篇文章中詳細介紹了這些步驟。
另一個網站：DeploymentBunny.com為那些同時使用了Cumulative（累積）和Delta（增量）更新之后無法重新啟動的用戶提供了一些其他選擇。WorkingHardinIT.Work逐步使用DISM（部署映像服務和管理命令行工具）來刪除更新。
用戶應該只使用Cumulative Updates（累積更新），而不要使用Delta更新（增量更新）?？蛻魬撉宄齏SUS上的緩存，這樣Delta更新就不會出現了。
我已經向微軟詢問有哪些人受到了影響以及該公司建議用戶還要采取哪些其他的步驟等信息。作為回應，該公司的一名發言人發了以下聲明：
"有些客戶可能會在Windows Server Update Services（WSUS）部署了KB 4041676和KB 4041691后遇到的問題，這個問題已經解決了。絕大多數客戶接收到的Windows和Microsoft Update更新并沒有受到影響。"
銀雁冰·獵影實驗室
隨著Windows平臺的幾大主流瀏覽器(Chrome, Edge, IE)和文字處理軟件(Office, Adobe Reader)相繼引入沙箱機制，Windows內核提權漏洞的需求也隨之上升。在這個背景下，近幾年披露的Windows內核提權0day攻擊事件也居于高位。下表展示了2017年-2021年(至今)全球范圍內披露的Windows內核提權在野0day編號及對應的披露廠商，從表中可以直觀地感受到上述現象。
統計 | 披露年份 | CVE編號 | 漏洞模塊 | 披露廠商 |
2 | 2017 | CVE-2017-0005 | win32k | Lockheed Martin |
2017 | CVE-2017-0263 | win32k | FireEye, ESET | |
4 | 2018 | CVE-2018-8120 | win32k | ESET |
2018 | CVE-2018-8453 | win32k | Kaspersky | |
2018 | CVE-2018-8589 | win32k | Kaspersky | |
2018 | CVE-2018-8611 | nt/tm | Kaspersky | |
6 | 2019 | CVE-2019-0797 | win32k | Kaspersky |
2019 | CVE-2019-0803 | win32k | Alibaba | |
2019 | CVE-2019-0808 | win32k | ||
2019 | CVE-2019-0859 | win32k | Kaspersky | |
2019 | CVE-2019-1132 | win32k | ESET | |
2019 | CVE-2019-1458 | win32k | Kaspersky | |
3 | 2020 | CVE-2020-0938 | atmfd | |
2020 | CVE-2020-1027 | sxssrv | ||
2020 | CVE-2020-17087 | cng | ||
1(截止3月) | 2021 | CVE-2021-1732 | win32k | DBAPPSecurity(安恒信息) |
這些Windows內核提權零日漏洞成本高昂，因此其背后一般都是水平高超或實力雄厚的APT組織。對威脅情報部門來說，如何有效狩獵這些在野的Windows內核提權漏洞樣本已經變為一個需要深入思考的問題。
關于這個問題，Kaspersky作為Windows內核提權0day狩獵方面的先行者，已經公開分享過一些他們在這方面的經驗；CheckPoint在最近半年也分享了3篇關于內核提權樣本狩獵的研究文章，非常值得學習(對這些資料的引用將會列舉在本文的最后，供讀者參考)。
本文將分享安恒威脅情報中心獵影實驗室在這方面的一些思考，討論側重點為內存破壞類內核提權漏洞，這一塊我們尚處在摸索階段，不足之處敬請斧正。
內存破壞類內核提權漏洞一般由C/C++語言的不安全操作引發，最為常見的是win32k組件中由于Callback機制導致的UAF漏洞。
為什么win32k組件中的UAF漏洞這么多？這要從Windows NT的設計歷史說起。在Windows操作系統設計初期，win32k子系統是在用戶態的(實線的上半部分)，如下：
但從Windows NT4開始，這部分代碼被移到了內核態(實線的下半部分)，內核態新增了一個win32k.sys模塊：
上述重新設計引入了如下3個不安全因素：
重新設計后，上述3點都可能引發新的安全漏洞，Windows內核團隊也意識到了這幾點，所以針對性地進行了加固，但安全研究人員還是不斷從中找出安全漏洞。
在2011年Blackhat USA大會上，Tarjei Mandt公開了他對Win32k User-Mode Callback機制的研究成果，從此大量研究人員開始關注win32k模塊中的User-Mode Callback攻擊面，并發現了許多新的win32k模塊UAF漏洞。
有過漏洞研究基礎的同學都知道，一個典型的漏洞利用過程大概有這幾個環節：
我們可以從上述每一個階段入手，分別思考一下每一階段潛在的一些狩獵點。
靜態層面，首先，我們可以檢查PE文件的導入表中是否導入了user32.dll中的下面幾個函數，因為大部分win32k漏洞利用都需要創建窗口或菜單：
其次，Win32k User-Mode Callback漏洞一定存在Hook回調表的操作，這是一個可疑行為(64位樣本會存在和下面很像的一個代碼片段)：
mov rax, gs:[60h]
lea rax, [rax+58h]
mov rax, [rax]
ret
動態層面，對于UAF漏洞和部分越界讀寫漏洞，可以通過開啟Driver Virifier進行檢測，UAF漏洞樣本在開啟Driver Virifier的環境中會觸發藍屏異常，判定0day最簡單的標準就是：
當然，有一些內存破壞類內核提權漏洞無法通過Driver Virifier檢測到，一個典型例子就是我們捕獲的CVE-2021-1732。
堆噴射階段變化比較多，可以創建多個Windows或多個Bitmaps，例如CVE-2018-8453的在野利用；也可以創建多個加速表(CreateAcceleratorTable)，例如CVE-2017-8465的開源利用代碼；也可以創建多個tagCLS結構，比如《LPE vulnerabilities exploitation on Windows 10 Anniversary Update》這個PPT第36頁提出的方法。
關于Windows內核信息泄露技巧，Github上有一個項目(項目地址列舉在文末)總結得較為完整。項目中有一張表格，該表格詳細列出了Windows內核信息泄露的各種技巧，并且通過不同的圖標展示了這些技巧在各版本Windows操作系統中的可用性。
這張表格只將操作系統寫到Windows 1703(Redstone 2)，但僅根據表格內信息我們也可發現：只有HMValidateHandle這一技巧一直穩定存在(從1803開始也進行了緩解)。
靜態層面，我們可以通過查找HMValidateHandle的代碼特征來發現內核信息泄露的線索。以下是一段查找HMValidateHandle的典型代碼，如果在靜態分析時遇到類似代碼片段，就應值得留意：
PVOID find_HMValidateHandle(PVOID pIsMenu)
{
ULONG HMValidateHandleAddr = 0;
while (TRUE)
{
if (*(BYTE*)pIsMenu == 0xE8)
{
HMValidateHandleAddr = *(DWORD*)((ULONG)pIsMenu + 1);
HMValidateHandleAddr += (ULONG)pIsMenu + 0x05 - 0x100000000;
return (PVOID)HMValidateHandleAddr;
}
pIsMenu = (BYTE*)pIsMenu + 1;
}
return 0;
}
動態分析層面，由于HMValidateHandle是一個未導出函數，系統在正常調用這個函數時，對其調用的地址來自user32.dll內部；但當這個函數被用于信息泄露時，對其調用的地址位于漏洞利用模塊，這個地址并不位于user32.dll模塊。我們可以借助這一原理進行運行時檢測：將來自user32.dll外的對HMValidateHandle的調用標記為可疑行為并記錄。這方面已經有國外的研究員做了樣例，一并列舉在文末。
在Windows內核利用的歷史中，相繼有操作tagWND，Bitmap，Palette，Menu等相關結構體的API登場，發展到現在，已經公開且還沒有被完全緩解的任意地址讀寫原語輔助函數已經只剩SetWindowLong*系列函數和Menu相關函數，所以查看導入表中是否有user32.dll中的下面幾個函數是一種思路：
除了上述API，早期版本的一些利用代碼還可以包括下面這些導入函數：
對于Windows內核提權漏洞而言，其主要目的是為了提升權限，而提升權限的主要手法就是進行Token替換，因此可以通過以下幾個特征點進行檢查：
Windows內核團隊和漏洞緩解團隊一直致力于減少Windows內核的漏洞&利用攻擊面，簡單了解Windows系統中的內核安全攻防時間線有助于我們對Windows內核利用歷史的了解和對Windows內核利用趨勢的預測，這些對狩獵都有幫助。
更多內容請前往微信公眾號：安恒威脅情報中心
安恒威脅情報中心介紹
安恒威脅情報中心匯聚了海量威脅情報，支持多點渠道數據輸入，支持自動情報數據產出，能實現網絡安全的高效賦能。平臺使用者可通過自定義策略進行威脅監控、威脅狩獵，并對輸入數據進行自動化的生產加工，同時支持人工分析團隊對情報進行復核整理。