今天小編分享的互聯網經驗：開機就能打？沒那麼玄乎！客觀分析 “狂躁許可”漏洞（CVE-2024-38077）及其影響範圍，歡迎閱讀。
一、事件背景
2024 年 7 月 9 日，微軟官方發布了一個針對 "windows 遠程桌面授權服務遠程代碼執行漏洞 "（CVE-2024-38077）的修復補丁包，起初并沒有引起大家的警覺。近日在國外某網站上疑似漏洞的作者公開了該漏洞的 "POC 驗證代碼 "。一時激起千層浪，該漏洞開始瘋狂發酵并在安全圈裡轉發。
該文章的原文鏈接為：
https://sites.google.com/site/zhiniangpeng/blogs/MadLicense
鏈接裡也附上了漏洞驗證視頻：
https://www.youtube.com/watch?v=OSYOrRS2k4A&t=8s
有意思的是，截至本文發稿前，這篇文章和文章裡提到的漏洞驗證視頻已均被作者删除。我們就先從作者發的這個鏈接來看看其中的一些端倪。
二、原文翻譯
注：以下内容為原文翻譯，我們對其中需重點關注的部分做了标記。
【背景】
今年早些時候，我們對 Windows 遠程桌面服務進行了深入分析，發現了多個漏洞，所有相關漏洞（56 例）都已報告給微軟。其中包括遠程桌面授權服務中的多個 Preauth RCE 漏洞（未經身份驗證的非沙盒 0-click RCE）。這些漏洞可用于構建針對 Windows 遠程桌面授權服務的多個 Preauth RCE 漏洞。是的，它們是多年來在 Windows 中未見過的 0-click preauth RCE。我們将它們稱為 Mad、Bad 和 Dead Licenses 漏洞。
本文是關于這些漏洞的系列文章中的第一篇。
在本文中，我們介紹了漏洞 CVE-2024-38077（我們将其命名為 MadLicense【狂躁許可】），并在啟用了完整和新緩解措施的 Windows Server 2025 上演示了該漏洞的利用。我們之所以選擇 Windows Server 2025，是因為微軟聲稱 Windows Server 2025 提供了下一代安全改進。并且該漏洞适用于 Windows Server 2000 到 2025（所有 Windows Server ）。
我們現在不會給出詳細的技術解釋，也不會提供完整的 POC 。但是這裡的偽代碼足以了解此漏洞。為了防止濫用，此處的 python 代碼實際上是偽代碼。你甚至無法使用此偽代碼觸發漏洞，更不用說利用它了。這足以證明其嚴重性，并為防御者在真正弄清楚如何利用它之前采取行動提供足夠的時間。
我們在一個月前就通知微軟這個漏洞可以被利用，但微軟仍将其标記為不太可能被利用。因此我們在此進行了負責任的披露。我們的目的是提高人們對該漏洞風險的認識，并鼓勵用戶及時更新系統以解決這些問題。Defender 還可以使用本博客中的信息來檢測和阻止可能的攻擊。
【介紹】
2024 年 7 月，我們報告的以下 7 個與 RDP 相關的漏洞已被 Microsoft 修復：
CVE-2024-38077：Windows 遠程桌面授權服務遠程代碼執行漏洞 CVE-2024-38076：Windows 遠程桌面授權服務遠程代碼執行漏洞 CVE-2024-38074：Windows 遠程桌面授權服務遠程代碼執行漏洞 CVE-2024-38073：Windows 遠程桌面許可服務拒絕服務漏洞 CVE-2024-38072：Windows 遠程桌面授權服務拒絕服務漏洞 CVE-2024-38071：Windows 遠程桌面許可服務拒絕服務漏洞 CVE-2024-38015：Windows 遠程桌面網關（RD 網關）拒絕服務漏洞
其中，Windows 遠程桌面授權服務中的 3 個 CVSS 評分為 9.8 的 RCE 漏洞值得關注。在微軟的公告中，他們認為這些漏洞不太可能被利用。但事實并非如此。事實上，我們在補丁發布之前就告知了微軟這些漏洞的可利用性。
在本博客中，我們将演示如何利用 Windows Server 2025 上的 CVE-2024-38077 進行預認證 RCE 攻擊，繞過所有現代緩解措施，在最新的 Windows Server 上實現零點擊 RCE。是的，你沒聽錯，只需利用一個漏洞，你無需任何用戶互動即可實現此目的。
【遠程桌面許可 ( RDL ) 服務】
遠程桌面許可服務是 Windows Server 的一個組件，用于管理和頒發遠程桌面服務的許可證，确保對遠程應用程式和桌面的安全且合規的訪問。
RDL 服務廣泛部署在啟用了遠程桌面服務的機器上。默認情況下，遠程桌面服務僅允許同時使用兩個會話。要啟用多個同時會話，您需要購買許可證。RDL 服務負責管理這些許可證。RDL 被廣泛安裝的另一個原因是，在 Windows 伺服器上安裝遠程桌面服務 ( 3389 ) 時，管理員通常會勾選安裝 RDL 的選項。這導致許多啟用了 3389 的伺服器也啟用了 RDL 服務。
在審計 RDL 服務之前，我們進行了網絡掃描，以确定 RDL 服務在互聯網上的部署情況。我們發現至少有 17 萬個活躍的 RDL 服務直接暴露在公共互聯網上，而内部網絡中的數量無疑要大得多。此外，RDL 服務通常部署在關鍵業務系統和遠程桌面集群中，因此 RDL 服務中的預認證 RCE 漏洞對網絡世界構成了重大威脅。
【CVE-2024-38077：一個簡單的堆溢出漏洞】
終端伺服器授權程式旨在管理将任何用戶或設備連接到伺服器所需的終端服務 CAL。在 CDataCoding::DecodeData 過程中，會分配一個固定大小的緩衝區（21 字節），然後使用該緩衝區計算并填充用戶控制的長度緩衝區，從而導致堆溢出。
這是調用堆棧和偽代碼：
windbg 0:012> k # Child-SP RetAddr Call Site 00 000000b9`d2ffbd30 00007fff`67a76fec lserver!CDataCoding::DecodeData 01 000000b9`d2ffbd70 00007fff`67a5c793 lserver!LKPLiteVerifyLKP+0x38 02 000000b9`d2ffbdc0 00007fff`67a343eb lserver!TLSDBTelephoneRegisterLicenseKeyPack+0x163 03 000000b9`d2ffd7d0 00007fff`867052a3 lserver!TLSRpcTelephoneRegisterLKP+0x15b 04 000000b9`d2fff0c0 00007fff`8664854d RPCRT4!Invoke+0x73 05 000000b9`d2fff120 00007fff`86647fda RPCRT4!NdrStubCall2+0x30d 06 000000b9`d2fff3d0 00007fff`866b7967 RPCRT4!NdrServerCall2+0x1a 07 000000b9`d2fff400 00007fff`86673824 RPCRT4!DispatchToStubInCNoAvrf+0x17 08 000000b9`d2fff450 00007fff`866729e4 RPCRT4!RPC_INTERFACE::DispatchToStubWorker+0x194 09 000000b9`d2fff520 00007fff`86688d4a RPCRT4!RPC_INTERFACE::DispatchToStub+0x1f4 0a 000000b9`d2fff7c0 00007fff`86688af1 RPCRT4!OSF_SCALL::DispatchHelper+0x13a 0b 000000b9`d2fff8e0 00007fff`86687809 RPCRT4!OSF_SCALL::DispatchRPCCall+0x89 0c 000000b9`d2fff910 00007fff`86686398 RPCRT4!OSF_SCALL::ProcessReceivedPDU+0xe1 0d 000000b9`d2fff9b0 00007fff`86697f4c RPCRT4!OSF_SCONNECTION::ProcessReceiveComplete+0x34c 0e 000000b9`d2fffab0 00007fff`840377f1 RPCRT4!CO_ConnectionThreadPoolCallback+0xbc 0f 000000b9`d2fffb30 00007fff`867f7794 KERNELBASE!BasepTpIoCallback+0x51 10 000000b9`d2fffb80 00007fff`867f7e37 ntdll!TppIopExecuteCallback+0x1b4 11 000000b9`d2fffc00 00007fff`85b11fd7 ntdll!TppWorkerThread+0x547 12 000000b9`d2ffff60 00007fff`8683d9c0 KERNEL32!BaseThreadInitThunk+0x17 13 000000b9`d2ffff90 00000000`00000000 ntdll!RtlUserThreadStart+0x20
C
void __fastcall CDataCoding::SetInputEncDataLen ( CDataCoding *this ) { // ... dword_1800D61D0 = 35; v1 = log10_0 ( ( double ) dword_1800D61C8 ) * 35.0; v2 = v1 / log10_0 ( 2.0 ) ; v3 = ( int ) v2 + 1; v4 = 0; if ( v2 > 3 ) + v4; // dwBytes is a fixed value 21}__int64 __fastcall CDataCoding::DecodeData ( CDataCoding *this, const unsigned __int16 *a2, unsigned __int8 **a3, unsigned int *a4 ) { // ... v4 = 0; v8 = 0; if ( a3 ) { // dwBytes is a global variable with value 21 v9 = dwBytes; *a3 = 0i64; *a4 = 0; ProcessHeap = GetProcessHeap ( ) ; v11 = ( unsigned __int8 * ) HeapAlloc ( ProcessHeap, 8u, v9 ) ; v12 = v11; if ( v11 ) { memset_0 ( v11, 0, ( unsigned int ) dwBytes ) ; while ( *a2 ) { // Str is BCDFGHJKMPQRTVWXY2346789 // a2 is user-controlled buffer v13 = wcschr_0 ( Str, *a2 ) ; if ( !v13 ) { v4 = 13; v18 = GetProcessHeap ( ) ; HeapFree ( v18, 0, v12 ) ; return v4; } // here change the integer a2 from base 24 to base 10 // but does not check the length of a2 v14 = v13 - Str; v15 = v12; v16 = ( unsigned int ) ( v8 + 1 ) ; do { v17 = dword_1800D61C8 * *v15 + v14; *v15++ = v17; LODWORD ( v14 ) = v17 >> 8; --v16; } while ( v16 ) ; if ( ( _DWORD ) v14 ) v12 [ ++v8 ] = v14; ++a2; } *a4 = dwBytes; *a3 = v12; } else { return 8; } } else { return 87; } return v4;}}
【POC】
這裡我們只是演示了漏洞利用。詳細的技術解釋将在本系列的後續博客文章中。這裡的 Python 代碼實際上是偽代碼。你甚至無法用這個偽代碼觸發漏洞，更不用說利用它了。這足以證明漏洞的嚴重性，也為防御者提供了足夠的時間，讓他們能夠在有人真正弄清楚如何利用漏洞之前采取行動。
适用于：Windows Server 2025 标準版本 24H2（26236.5000.amd64fre.ge_prerelease.240607-1502lserver.dll ( 10.0.26235.5000 )
https://github.com/CloudCrowSec001/CVE-2024-38077-POC/blob/main/CVE-2024-38077-poc.py
【讨論 POC】
該漏洞利用的 POC 在 Windows Server 2025 上的成功率超過 95%。考慮到服務崩潰後會重新啟動，不需要兩次洩露模塊基址，最終的成功率可以更高（接近 100%）。
此 POC 将在 Windows Server 2025 上在 2 分鍾内完成。但是我們這裡的堆整理技術是使用 Windows Server 2025 中引入的新 LFH 緩解措施的未優化版本。我們很懶，實際上并沒有完全逆轉 Windows Server 2025 中的段堆機制，所以我們的堆整理只是一種啟發式解決方案。它一點也不優雅。當然，你必須可以對其進行優化，以使漏洞在 Windows Server 2025 上運行得更快。
對于 Windows Server 2000 到 Windows Server 2022，利用此漏洞會更快，因為緩解措施較少。為簡單起見，POC 将加載遠程 DLL。但您可以讓它在 RDL 進程中運行任意 shellcode。這将使其更加隐蔽。
在 Windows Server 2025 之前的版本中利用此漏洞應該更容易和更有效，但當然，你需要調整代碼和偏移量。漏洞可以在 Windows Server 2000 到 Windows Server 2025 上構建。這裡我們只在 2025 進行演示，因為 Windows Server 2025 是最新和最安全的 Windows Server 。而且它仍處于預覽階段，因此 POC 不會對世界造成危害。如果要避免偏移量問題以使漏洞利用更加通用，動态搜索是可能的，但你需要将其替換為更高效的内存讀取原語以使漏洞利用更加高效。
這裡我們做了一個負責任的披露。為了進一步防止這個 POC 被濫用，這裡發布的 POC 只是偽代碼，并且是未優化的版本，其中的一些關鍵部分被隐藏了。但偽代碼中的信息足以讓研究人員檢測和阻止利用。
【演示】
視頻鏈接地址：
https://www.youtube.com/watch?v=OSYOrRS2k4A&t=8s
【時間線】
2024 年 5 月 1 日
向 Microsoft 報告此案例
2024 年 7 月 1 日
告訴微軟此案可利用
2024 年 7 月 9 日
修復為 CVE-2024-38077（微軟将其标記為不太可能被利用）
2024 年 8 月 2 日
将本文發送至 Microsoft
2024 年 8 月 9 日
微軟尚未對本文做出任何回應
2024 年 8 月 9 日
文章發布
【讨論】
在本文中，我們将演示如何利用單個漏洞繞過所有緩解措施，并在被認為是最安全的 Windows Server 2025 上實現預身份驗證遠程代碼執行 ( RCE ) 攻擊。這在 2024 年似乎很荒誕，但這是事實。盡管微軟幾十年來對 Windows 進行了各種防御，并且多年來我們都沒有在 Windows 中看到預身份驗證 0-click RCE，但我們仍然可以利用單個内存損壞漏洞來完成整個攻擊。看起來，具有 " 下一代安全改進 " 的系統這次無法阻止 30 年前同樣的舊内存利用。
本文的目的是提醒用戶盡快更新系統以修復漏洞。
這個組件中其實還有更多的利用，記住我們已經報告了 56 個案例（雖然微軟 SRC 合并了我們的許多案例，這很煩人）。有興趣的研究人員可以嘗試弄清楚。
這是本系列的第一篇博文。有關更多漏洞、更多漏洞、與 Microsoft SRC 合作的痛苦與收獲等，我們可能會在本系列的後續博文中讨論。
三、事件分析
不知道大家讀完原文之後是什麼感覺，筆者是體會到了原文作者對微軟的深深惡意。核心原因是作者把大量漏洞報送給微軟後，微軟對其提交的漏洞進行了合并，并 " 輕描淡寫 " 的進行了補丁更新，在補丁上也把該漏洞标記為了 " 不太可能被利用 "，對作者本人也并未做出任何回應。這一行為明顯觸及了技術宅的底線，一氣之下作者選擇了将其公布。在 crowdstrike 引發了 windows 藍屏事件後，又爆出了這個驚天大瓜，難免會引起唏噓，對微軟有不小的衝擊。
微軟給的官方補丁鏈接為：
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38077
這裡确實将該漏洞标記為了 " 不太可能利用 "，刺激到了作者。
另外文中反復強調，放出來的 POC 是 " 偽代碼 "，我們也第一時間對該代碼進行了驗證，發現确實不能直接利用，截至發稿前正在對其核心内容進行調試。網傳的 POC 和漏洞檢測工具更是錯綜復雜，提醒大家一定要留個心眼，不要人雲亦雲。
四、漏洞影響範圍
從目前得到的信息來看，觸發該漏洞需要兩個條件：
windows 版本：
Windows Server 2000 - Windows Server 2025
需要開啟服務：
Windows Remote Desktop Licensing（RDL）Service
這裡容易引起大家誤解的就是這個 RDL 服務了，容易和我們常見的 RDP 產生混淆，也是為什麼這個洞剛爆出來大家一致認為是 " 核彈級 " 的，能夠比肩 " 永恒之藍 " 的原因。實際上這個服務默認不會自動安裝，需要額外安裝才會生效，一般出現在企業環境中，個人用戶基本不會安裝這個服務。我們大致總結了下 RDL 和 RDP 的區别，以遍大家能更客觀的評估這個漏洞的影響範圍。
【RDP】
定義與功能：
RDP，即遠程桌面協定，是微軟開發的一種網絡協定，用于在圖形用戶界面（GUI）中提供遠程連接功能。它允許用戶通過網絡連接到其他計算機的桌面，以便進行操作和管理。RDP 的默認端口是 3389。
應用場景：
RDP 廣泛用于遠程管理伺服器、遠程辦公、技術支持等場景，允許用戶通過網絡在不同地點安全地訪問另一台計算機。
【RDL】
RDL，即遠程桌面許可服務，負責管理和頒發許可證。它是 Windows Server 角色之一，通常用于 Windows Server 系統。在啟用遠程桌面服務（RDS）的環境中，RDL 确保伺服器擁有足夠的授權許可證，以便允許多個用戶或設備通過 RDP 同時連接到該伺服器。當客戶端嘗試通過 RDP 連接到具有遠程桌面服務的伺服器時，RDL 會驗證并分配适當的許可證，以确保用戶遵循許可協定。啟用 RDL 服務時會随機開啟一個 RPC 的高端口，端口号通常在 49152 到 65535 之間。
RDL 一般出現在企業環境中，特别是當使用 Windows Server 進行遠程桌面會話主機（Remote Desktop Session Host，RDSH）或虛拟桌面基礎架構（VDI）時。它對用戶數量和會話數量的管理至關重要。
【主要區别】
目的：
RDP 的主要目的是提供連接和互動功能，允許用戶訪問和使用遠程計算機的桌面。
RDL 的主要目的是管理許可證，确保連接次數在合法範圍内，并控制同時允許的用戶或設備數量。
技術層面：
RDP 是一個協定，關注的是數據的傳輸和連接的建立，它是直接影響用戶體驗的部分。
RDL 是一種服務，确保合适的許可證可用并管理連接的合規性，它在後台運行，不會直接影響用戶的操作體驗。
使用場景：
RDP 可用于任何想要遠程連接到 Windows 計算機的用戶，不管是在個人設備還是在網絡環境中。
RDL 則更多應用于企業環境中，特别是在需要高密度并發用戶的遠程桌面服務中。
綜上所述，RDP 負責實現遠程連接和用戶互動，而 RDL 則負責管理連接的許可證和合規性。RDL 主要是确保遠程桌面服務在合規的用戶和會話數下運行，通俗來講，當某台伺服器需要建立多個 RDP 連接時才會考慮開啟這個服務，這個服務并不是默認加載的，需要手動安裝才能生效。
從公布的 " 偽 poc" 來看，整個漏洞的檢測邏輯是首先連接 rpc 的 135 端口，查詢 rdl 服務開啟的 rpc 端口，然後再連接 rdl 服務的 rpc 端口，訪問提供的認證功能，觸發漏洞。
rdl 開啟的 rpc 端口：
伺服器對應的 dll 檔案：
從 www.daydaymap.com 上大網測繪的數據可以看出，整個互聯網上開放 RDP 服務的資產有近 1700W 個， 而互聯網上 RDL 的資產僅有 17W 個（數據來源于原文作者），占比僅為 1%。目前我們還正在整理互聯網漏洞驗證的 POC 細節，後續會對互聯網上受影響的資產做更全面的摸排。從公開的數據已經可以看出，該漏洞的覆蓋範圍實際上很有限，并不是傳聞中的 " 開機就能打 "、" 有遠程連接服務就能打 " 或者 " 能探測到開放 3389 端口就能打 "。與其說是 RDP 的漏洞，不如描述成 RDL 或者 RPC 的漏洞更為合适。
盡管如此，這也并不意味着這是一個很雞肋的漏洞。一是因為内網資產裡使用遠程桌面服務的資產會遠多于互聯網。另外，一些集權系統如堡壘機、網域控等為了對 RDP 連接數做有效管理和控制，更容易開啟 RDL 服務，因此受到該漏洞影響的資產絕大多數是管理員的核心資產，從這一點上更需要引起大家的關注。我們已經發現很多堡壘機默認就會開啟這個服務，需要引起大家的重視。
五、漏洞修復建議
微軟已發布該漏洞的官方補丁，下載并安裝相關補丁即可。對于無法安裝補丁的情況，建議采取以下緩解措施：
1、如非必要，關閉 Remote Desktop Licensing 服務。
2、注意：此操作将影響遠程桌面授權認證和分發，可能導致遠程桌面出現問題影響正常業務或降低遠程桌面安全性。同時，微軟公告中提出：即便采取了上述緩解措施，微軟仍強烈建議盡快修復漏洞以全面防護系統。
另外目前正值攻防演練期間，往上會流傳大量的 " 檢測工具 "，現已發現一些惡意樣本在互聯網上流傳，大家一定要注意識别。
