關(guān)注獲取即時動態(tài)【安全公告】CVE-2020-1350 Windows DNS服務(wù)器蠕蟲嚴(yán)重漏洞
2020-07-17 16:41:03 來源：藍(lán)隊云 閱讀量：24732
介紹
DNS，通常被稱為“互聯(lián)網(wǎng)電話簿”，是一種將人類友好的計算機主機名轉(zhuǎn)換為IP地址的網(wǎng)絡(luò)協(xié)議。由于它是Internet的核心組成部分，因此存在許多DNS服務(wù)器的解決方案和實現(xiàn)，但是只有少數(shù)幾種被廣泛使用。
“ Windows DNS服務(wù)器”是Microsoft的實現(xiàn)，是Windows域環(huán)境的必要組成部分和要求。
SIGRed（CVE-2020-1350）是Windows DNS服務(wù)器中的一個可蠕蟲，嚴(yán)重漏洞（CVSS基本評分為10.0），影響Windows Server 2003至2019版，并且可能由惡意DNS響應(yīng)觸發(fā)。由于該服務(wù)以提升的特權(quán)（SYSTEM）運行，因此，如果成功利用該服務(wù)，則會向攻擊者授予域管理員權(quán)限，從而有效地?fù)p害了整個公司的基礎(chǔ)結(jié)構(gòu)。
動機
我們的主要目標(biāo)是找到一個漏洞，使攻擊者可以破壞Windows Domain環(huán)境，最好是未經(jīng)身份驗證的環(huán)境。各種獨立安全研究人員以及民族國家贊助的研究都有很多相關(guān)研究。大多數(shù)公開和可公開獲得的資料和漏洞利用都集中在Microsoft對SMB（EternalBlue）和RDP（BlueKeep）協(xié)議的實現(xiàn)上，因為這些目標(biāo)同時影響服務(wù)器和端點。要獲得Domain Admin特權(quán)，一種直接的方法是直接利用Domain Controller。因此，我們決定將研究重點放在主要存在于Windows Server和域控制器上的，鮮為人知的攻擊面上。輸入WinDNS。
Windows DNS概述
“ 域名系統(tǒng)（DNS）是構(gòu)成TCP / IP的行業(yè)標(biāo)準(zhǔn)協(xié)議套件之一，并且DNS客戶端和DNS服務(wù)器共同為計算機和用戶提供計算機名稱到IP地址的映射名稱解析服務(wù)。” – 微軟。
DNS主要在端口53上使用用戶數(shù)據(jù)報協(xié)議（UDP）來服務(wù)請求。DNS查詢包括來自客戶端的單個UDP請求和來自服務(wù)器的單個UDP響應(yīng)。
除了將名稱轉(zhuǎn)換為IP地址外，DNS還具有其他用途。例如，郵件傳輸代理使用DNS查找最佳的郵件服務(wù)器來傳遞電子郵件：MX記錄提供域和郵件交換器之間的映射，這可以提供附加的容錯和負(fù)載分配層?？捎?/span>DNS記錄類型及其對應(yīng)用途的列表可在Wikipedia上找到。
但是，本博客文章的目的不是要對DNS功能和歷史進(jìn)行冗長的論述，因此我們鼓勵您在此處閱讀有關(guān)DNS的更多信息。
您需要了解的內(nèi)容：
· DNS通過UDP / TCP端口53運行。
· 一條DNS消息（響應(yīng)/查詢）在UDP中限制為512字節(jié)，在TCP中限制為65,535字節(jié)。
· DNS本質(zhì)上是分層的和分散的。這意味著當(dāng)DNS服務(wù)器不知道收到的查詢的答案時，該查詢將轉(zhuǎn)發(fā)到層次結(jié)構(gòu)中位于其上方的DNS服務(wù)器。在層次結(jié)構(gòu)的頂部，全球共有13臺根DNS服務(wù)器。
在Windows中，DNS客戶端和DNS服務(wù)器在兩個不同的模塊中實現(xiàn)：
· DNS客戶端 – dnsapi.dll負(fù)責(zé)DNS解析。
· DNS服務(wù)器 – dns.exe負(fù)責(zé)在安裝了DNS角色的Windows Server上回答DNS查詢。
我們的研究圍繞dns.exe模塊進(jìn)行。
準(zhǔn)備環(huán)境
我們的攻擊面主要有兩種情況：
1. DNS服務(wù)器解析傳入查詢的方式中的錯誤。
2. DNS服務(wù)器解析轉(zhuǎn)發(fā)查詢的響應(yīng)（答案）的方式中的錯誤。
由于DNS查詢沒有復(fù)雜的結(jié)構(gòu)，因此在第一種情況下發(fā)現(xiàn)解析問題的機會較小，因此我們決定將目標(biāo)定位為解析傳入查詢的功能以轉(zhuǎn)發(fā)查詢。
如前所述，轉(zhuǎn)發(fā)查詢是利用DNS體系結(jié)構(gòu)來將不知道答案的查詢轉(zhuǎn)發(fā)到層次結(jié)構(gòu)中位于其上方的DNS服務(wù)器。
但是，大多數(shù)環(huán)境將其轉(zhuǎn)發(fā)器配置為知名的，受人尊敬的DNS服務(wù)器，例如8.8.8.8（Google）或1.1.1.1（Cloudflare），或者至少是不受攻擊者控制的服務(wù)器。
這意味著即使我們在解析DNS響應(yīng)時發(fā)現(xiàn)問題，也需要建立一個中間人來加以利用。顯然，這還不夠。
NS記錄救援
NS代表“名稱服務(wù)器”，該記錄指示哪個DNS服務(wù)器是該域的權(quán)限（哪個服務(wù)器包含實際的DNS記錄）。NS記錄通常負(fù)責(zé)解析給定域的子域。一個域通常具有多個NS記錄，這些記錄可以指示該域的主要和備用名稱服務(wù)器。
若要使目標(biāo)Windows DNS服務(wù)器解析來自惡意DNS名稱服務(wù)器的響應(yīng)，請執(zhí)行以下操作：
1. 將我們域的（deadbeef.fun）NS記錄配置為指向我們的惡意DNS服務(wù)器（ns1.41414141.club）。
2. 查詢受害Windows DNS服務(wù)器的NS記錄deadbeef.fun。
3. 受害DNS尚不知道該查詢的答案，將查詢轉(zhuǎn)發(fā)到位于其上方的DNS服務(wù)器（8.8.8.8）。
4. 權(quán)威服務(wù)器（8.8.8.8）知道答案，并響應(yīng)的NameServer deadbeef.fun為ns1.41414141.club。
5. 受害Windows DNS服務(wù)器處理并緩存此響應(yīng)。
6. 下次我們查詢的子域時deadbeef.fun，目標(biāo)Windows DNS服務(wù)器也會查詢ns1.41414141.club其響應(yīng)，因為它是該域的NameServer。
圖1：查詢我們的惡意服務(wù)器的受害DNS服務(wù)器的數(shù)據(jù)包捕獲。
漏洞– CVE-2020-1350
函數(shù)：dns.exe!SigWireRead
漏洞類型：整數(shù)溢出導(dǎo)致基于堆的緩沖區(qū)溢出
dns.exe 為每種受支持的響應(yīng)類型實現(xiàn)解析功能。
圖2： Wire_CreateRecordFromWire：RRWireReadTable被傳遞給RR_DispatchFunctionForType確定的處理功能。
圖3：RRWireReadTable及其一些受支持的響應(yīng)類型。
支持的響應(yīng)類型之一是SIG查詢。根據(jù)Wikipedia的說法，SIG查詢是SIG（0）（RFC 2931）和TKEY（RFC 2930）中使用的“ 簽名記錄 ” 。RFC 3755指定RRSIG替代DNSSEC內(nèi)部使用的SIG。”
讓我們檢查一下Cutter為dns.exe!SigWireReadSIG響應(yīng)類型的處理函數(shù)生成的反匯編：
圖4：dns.exe!SigWireRead在Cutter中看到的拆卸圖。
RR_AllocateEx通過以下公式計算傳遞給第一個參數(shù)（負(fù)責(zé)為“資源記錄”分配內(nèi)存的函數(shù)）：
[ Name_PacketNameToCountNameEx結(jié)果] + [0x14] + [簽名字段的長度（rdi– rax）]
簽名字段的大小可能會有所不同，因為它是SIG響應(yīng)的主要有效負(fù)載。
圖5：根據(jù)RFC 2535的SIG資源記錄的結(jié)構(gòu)。
正如你可以在下面的圖片中看到，RR_AllocateEx預(yù)計其參數(shù)在傳遞16位寄存器，因為它僅使用dx部分rdx和cx部分rcx。
這意味著，如果我們可以使上面的公式輸出的結(jié)果大于65,535字節(jié)（16位整數(shù)的最大值），則整數(shù)溢出會導(dǎo)致分配的分配比預(yù)期的要小得多，這有望導(dǎo)致基于堆的分配。緩沖區(qū)覆蓋。
圖6：RR_AllocateEx將其參數(shù)轉(zhuǎn)換為其16位值。
方便地，此分配的內(nèi)存地址隨后作為的目標(biāo)緩沖區(qū)傳遞memcpy，從而導(dǎo)致基于堆的緩沖區(qū)溢出。
圖7：從中分配的緩沖區(qū)RR_AllocateEx被傳遞到中memcpy。
總而言之，通過發(fā)送包含大（大于64KB）SIG記錄的DNS響應(yīng)，我們可以在小的分配緩沖區(qū)上引起大約64KB的基于堆的受控緩沖區(qū)溢出。
觸發(fā)漏洞
現(xiàn)在我們可以使受害DNS服務(wù)器查詢我們的DNS服務(wù)器以解決各種問題，我們已經(jīng)有效地將其轉(zhuǎn)變?yōu)榭蛻舳?。我們可以使受?/span>DNS服務(wù)器詢問我們的惡意DNS服務(wù)器特定類型的查詢，并分別以匹配的惡意響應(yīng)進(jìn)行回答。
我們認(rèn)為觸發(fā)此漏洞所需要做的只是使受害DNS服務(wù)器向我們查詢SIG記錄，并為其回答帶有長簽名（長度> = 64KB）的SIG響應(yīng)。我們很失望地發(fā)現(xiàn)基于UDP的DNS的大小限制為512字節(jié)（如果服務(wù)器支持EDNS0，則為4,096字節(jié)）。無論如何，這不足以觸發(fā)漏洞。
但是，如果服務(wù)器出于正當(dāng)理由發(fā)送大于4,096字節(jié)的響應(yīng)會怎樣？例如，冗長的TXT響應(yīng)或可以解析為多個IP地址的主機名。
DNS截斷–但是，還有更多！
根據(jù)DNS RFC 5966：
“在沒有EDNS0（DNS 0的擴(kuò)展機制）的情況下，任何DNS服務(wù)器需要發(fā)送超過512字節(jié)限制的UDP響應(yīng)的正常行為是服務(wù)器截斷響應(yīng)使其符合該限制，然后在響應(yīng)標(biāo)頭中設(shè)置TC標(biāo)志。當(dāng)客戶端收到這樣的響應(yīng)時，它將TC標(biāo)志作為指示它應(yīng)改為通過TCP重試。”
大！因此，我們可以TC在響應(yīng)中設(shè)置（截斷）標(biāo)志，這將導(dǎo)致目標(biāo)Windows DNS服務(wù)器啟動與惡意NameServer的新TCP連接，并且我們可以傳遞大于4,096字節(jié)的消息。但是要大多少？
根據(jù)DNS RFC 7766：
“ DNS客戶端和服務(wù)器應(yīng)同時（例如，在單個“寫入”系統(tǒng)調(diào)用中）將兩個八位字節(jié)的長度字段以及該長度字段描述的消息傳遞到TCP層，以使得所有數(shù)據(jù)更有可能在單個TCP段中傳輸。”
由于郵件的前兩個字節(jié)表示其長度，因此TCP上DNS中郵件的最大大小表示為16位，因此限制為64KB。
圖8：DNS over TCP消息的前兩個字節(jié)代表消息的長度。
但是，即使長度為65,535的消息也不足以觸發(fā)漏洞，因為消息長度包括標(biāo)頭和原始查詢。計算傳遞給的大小時，不會考慮此開銷RR_AllocateEx。
DNS指針壓縮–少即是多
讓我們再來看一個合法的DNS響應(yīng)（為方便起見，我們選擇了類型A的響應(yīng)）。
圖9：的DNS響應(yīng)dig research.checkpoint.com A @8.8.8.8，如Wireshark所示。
您可以看到Wireshark 0xc00c將答案的名稱字段中的字節(jié)評估為research.checkpoint.com。問題是，為什么？
根據(jù)對DNS的熱烈歡迎，powerdns.org表示：
“為了將盡可能多的信息壓縮到512字節(jié)中，可以（通常必須）壓縮DNS名稱……在這種情況下，答案的DNS名稱編碼為0xc0 0x0c。c0部分設(shè)置了兩個最高有效位，表示接下來的6 + 8位是指向消息中較早位置的指針。在這種情況下，這指向數(shù)據(jù)包內(nèi)的位置12（= 0x0c），緊隨DNS頭之后。”
與數(shù)據(jù)包開頭的偏移量0x0c（12）是什么？是research.checkpoint.com??！
在這種壓縮形式中，指針指向編碼字符串的開頭。在DNS中，字符串被編碼為（<size> <value>）鏈。
圖10：<size> <value>鏈的示意圖。
因此，我們可以使用“魔術(shù)”字節(jié)0xc0從數(shù)據(jù)包中引用字符串。讓我們再次檢查計算傳遞到的大小的公式RR_AllocateEx：
[ Name_PacketNameToCountNameEx結(jié)果] + [0x14] + [簽名字段的長度（rdi– rax）]
反向Name_PacketNameToCountNameEx確認(rèn)我們上面描述的行為。目的Name_PacketNameToCountNameEx是計算名稱字段的大小，并考慮指針壓縮。當(dāng)僅用兩個字節(jié)表示分配時，擁有一個允許我們大量增加分配大小的基元正是我們所需要的。
因此，我們可以在SIG簽名者的“名稱”字段中使用指針壓縮。但是，僅指定0xc00c為簽名者的名稱不會引起溢出，因為查詢的域名已經(jīng)存在于查詢中，并且從分配的值中減去開銷大小。但是呢0xc00d？我們唯一需要滿足的約束是編碼的字符串是有效的（以結(jié)尾0x0000），并且我們可以輕松做到這一點，因為我們有一個沒有任何字符約束的字段-簽名值。對于域41414141.fun，0xc00d指向域的第一個字符（'4'）。然后，將此字符的序數(shù)值用作未壓縮字符串的大小（“ 4”表示值0x34（52））。該未壓縮字符串的大小加上我們可以在Signature字段中容納的最大數(shù)據(jù)量（最多65,535，具體取決于原始查詢）的匯總將導(dǎo)致大于65,535字節(jié)的值，從而導(dǎo)致溢出！
讓我們用連接到的WinDBG進(jìn)行測試dns.exe：
我們墜毀了！
盡管似乎由于試圖將值寫入未映射的內(nèi)存而使我們崩潰，但是可以以允許我們覆蓋一些有意義的值的方式來調(diào)整堆的形狀。
還值得一提的是，由于SIG記錄和RRSIG記錄具有相同的結(jié)構(gòu)，因此Microsoft使用相同的函數(shù)（SigWireRead）來解析這兩種記錄類型。在檢查時可以看到RRWireReadTable：索引0x18（24）和46（0x2e）都指向該函數(shù)SigWireRead。
這意味著記錄類型SIG和RRSIG均可用于觸發(fā)此漏洞，因為它們是由相同的易受攻擊的函數(shù)-解析的SigWireRead。
dns.exe可以在線獲取以前的利用嘗試。例如：更深入地了解ms11-058。
從瀏覽器觸發(fā)
我們知道此錯誤可能是由LAN環(huán)境中存在的惡意參與者觸發(fā)的。但是，我們認(rèn)為看看是否可以在沒有LAN訪問權(quán)限的情況下遠(yuǎn)程觸發(fā)此錯誤會很有趣。
在HTTP中走私DNS
到現(xiàn)在為止，您應(yīng)該知道DNS可以通過TCP傳輸，并且Windows DNS Server支持此連接類型。您還應(yīng)該熟悉基于TCP的DNS的結(jié)構(gòu)，以防萬一，這里有個快速的回顧：
圖11：DNS over TCP消息格式。
考慮以下標(biāo)準(zhǔn)HTTP有效負(fù)載：
0000 50 4f 53 54 20 2f 70 77 6e 20 48 54 54 50 2f 31 POST /pwn HTTP/1
0010 2e 31 0d 0a 41 63 63 65 70 74 3a 20 2a 2f 2a 0d .1..Accept: */*.
0020 0a 52 65 66 65 72 65 72 3a 20 68 74 74 70 3a 2f .Referer: http:/
即使這是HTTP有效負(fù)載，將其發(fā)送到端口53上的目標(biāo)DNS服務(wù)器也會導(dǎo)致Windows DNS Server將此有效負(fù)載解釋為DNS查詢。它使用以下結(jié)構(gòu)進(jìn)行此操作：
0000 50 4f 53 54 20 2f 70 77 6e 20 48 54 54 50 2f 31 POST /pwn HTTP/1
0010 2e 31 0d 0a 41 63 63 65 70 74 3a 20 2a 2f 2a 0d .1..Accept: */*.
0020 0a 52 65 66 65 72 65 72 3a 20 68 74 74 70 3a 2f .Referer: http:/
Message Length: 20559 (0x504f)
Transaction ID: 0x5354
Flags: 0x202f
Questions: 28791 (0x7077)
Answer RRs: 28192 (0x6e20)
Authority RRs: 18516 (0x4854)
Additional RRs: 21584 (0x5450)
Queries: [...]
幸運的是，Windows DNS服務(wù)器支持RFC 7766的 “連接重用”和“管道重用” ，這意味著我們可以在單個TCP會話上發(fā)出多個查詢，而我們無需等待答復(fù)就可以這樣做。
為什么這很重要？
當(dāng)受害者訪問我們控制的網(wǎng)站時，我們可以使用基本的JavaScript從瀏覽器向DNS服務(wù)器發(fā)出POST請求。但是，如上所示，POST請求以我們無法控制的方式進(jìn)行解釋。
但是，我們可以通過將http://www.tjdsmy.cn:53/帶有二進(jìn)制數(shù)據(jù)的HTTP POST請求發(fā)送到目標(biāo)DNS服務(wù)器（）來濫用“連接重用”和“管道傳遞”功能，該二進(jìn)制數(shù)據(jù)在POST數(shù)據(jù)中包含另一個“走私的” DNS查詢，需要分別進(jìn)行查詢。
我們的HTTP有效負(fù)載包括以下內(nèi)容：
· HTTP請求頭，我們不控制（User-Agent，Referer，等）。
· “填充”，以便第一個DNS查詢在POST數(shù)據(jù)內(nèi)具有適當(dāng)?shù)拈L度（0x504f）。
· POST數(shù)據(jù)中的“走私” DNS查詢。
圖12：在單個TCP會話中的多個查詢，如Wireshark所示。
實際上，大多數(shù)流行的瀏覽器（例如Google Chrome和Mozilla Firefox）都不允許HTTP請求訪問端口53，因此只能在有限的一組Web瀏覽器中利用此bug，包括Internet Explorer和Microsoft Edge（基于非Chromium） ）。
變異分析
出現(xiàn)此錯誤的主要原因是因為RR_AllocateExAPI期望size參數(shù)為16位。通?？梢园踩丶僭O(shè)單個DNS消息的大小不超過64KB，因此此行為應(yīng)該不會引起問題。但是，正如我們剛剛看到的那樣，當(dāng)Name_PacketNameToCountNameEx在計算緩沖區(qū)大小時考慮到結(jié)果時，這種假設(shè)是錯誤的。發(fā)生這種情況是因為該Name_PacketNameToCountNameEx函數(shù)計算的是未壓縮名稱的有效大小，而不是其在數(shù)據(jù)包中表示該字節(jié)所花費的字節(jié)數(shù)。
要查找此錯誤的其他變體，我們需要找到一個滿足以下條件的函數(shù)：
· RR_AllocateEx 以可變大小（而不是恒定值）調(diào)用。
· 調(diào)用了Name_PacketNameToCountNameEx，其結(jié)果用于計算傳遞給的大小RR_AllocateEx。
· RR_AllocateEx使用16位或更大范圍內(nèi)的值來計算要傳遞給的值。
dns.exe滿足這三個條件的唯一其他功能是NsecWireRead。讓我們檢查一下我們通過反編譯函數(shù)得出的以下簡化代碼片段：
RESOURCE_RECORD* NsecWireRead(PARSED_WIRE_RECORD *pParsedWireRecord, DNS_PACKET *pPacket, BYTE *pRecordData, WORD wRecordDataLength)
{
DNS_RESOURCE_RECORD *pResourceRecord;
unsigned BYTE *pCurrentPos;
unsigned int dwRemainingDataLength;
unsigned int dwBytesRead;
unsigned int dwAllocationSize;
DNS_COUNT_NAME countName;
pResourceRecord = NULL;
pCurrentPos = Name_PacketNameToCountNameEx(&countName, pPacket, pRecordData, pRecordData + wRecordDataLength, 0);
if (pCurrentPos)
{
if
(pCurrentPos >= pRecordData // <-- Check #1 - Bounds check
&& pCurrentPos - pRecordData <= 0xFFFFFFFF // <-- Check #2 - Same bounds check (?)
&& wRecordDataLength >= (unsigned int)(pCurrentPos - pRecordData)) // <-- Check #3 - Bounds check
{
dwRemainingDataLength = wRecordDataLength - (pCurrentPos - pRecordData);
dwBytesRead = countName.bNameLength + 2;
// size := len(countName) + 2 + len(payload)
dwAllocationSize = dwBytesRead + dwRemainingDataLength;
if (dwBytesRead + dwRemainingDataLength >= dwBytesRead // <-- Check #4 - Integer Overflow check (32 bits)
&& dwAllocationSize <= 0xFFFF) // <-- Check #5 - Integer Overflow check (16 bits)
{
pResourceRecord = RR_AllocateEx(dwAllocationSize, 0, 0);
if (pResourceRecord)
{
Name_CopyCountName(&pResourceRecord->data, &countName);
memcpy(&pResourceRecord->data + pResourceRecord->data->bOffset + 2, pCurrentPos, dwRemainingDataLength);
}
}
}
}
return pResourceRecord;
}如您所見，此功能包含許多安全檢查。其中一項（檢查＃5）是16位溢出檢查，可防止此功能的漏洞變型。我們還要提及的是，此功能比中的普通功能具有更多的安全性檢查dns.exe，這使我們想知道是否已經(jīng)注意到并修復(fù)了該錯誤，但僅在該特定功能中。
如前所述，Microsoft在兩個不同的模塊中實現(xiàn)了DNS客戶端和DNS服務(wù)器。雖然我們的漏洞確實存在于DNS服務(wù)器中，但我們想看看它是否也存在于DNS客戶端中。
圖13：Sig_RecordReadfrom的反匯編片段dnsapi.dll。
看起來，與不同dns.exe!SigWireRead，dnsapi.dll!Sig_RecordRead 它確實驗證了Sig_RecordRead+D0傳遞給其的值dnsapi.dll!Dns_AllocateRecordEx小于0xFFFF字節(jié)，從而防止了溢出。
此漏洞不存在dnsapi.dll，并且兩個模塊之間的命名約定不同，這一事實使我們相信Microsoft管理DNS服務(wù)器和DNS客戶端的兩個完全不同的代碼庫，并且不同步錯誤補丁他們。
開發(fā)計劃
根據(jù)Microsoft的要求，我們決定保留有關(guān)漏洞利用原語的信息，以便為用戶提供足夠的時間修補其DNS服務(wù)器。相反，我們討論了適用于Windows Server 2012R2的開發(fā)計劃。但是，我們確實認(rèn)為該計劃也應(yīng)適用于其他版本的Windows Server。
該dns.exe二進(jìn)制文件是使用Control Flow Guard（CFG）編譯的，這意味著覆蓋內(nèi)存中函數(shù)指針的傳統(tǒng)方法不足以利用此bug。如果此二進(jìn)制文件不是使用CFG編譯的，那么利用此錯誤將非常簡單，因為很早以前我們就遇到了以下崩潰：
圖14：在崩潰ntdll!LdrpValidateUserCallTarget。
如您所見，我們在墜毀ntdll!LdrpValidateUserCallTarget。這是負(fù)責(zé)驗證作為CFG一部分的函數(shù)指針目標(biāo)的函數(shù)。我們可以看到，待驗證的指針（rcx）是完全可控的，這意味著我們在此過程中的某處成功重寫了函數(shù)指針。我們看到崩潰的原因是，函數(shù)指針被用作每個地址具有“允許” /“不允許”位的全局位圖表的索引，而我們的任意地址導(dǎo)致對該表本身中未映射頁面的讀取。
為了在克服CFG的同時將此漏洞利用到完整的遠(yuǎn)程代碼執(zhí)行中，我們需要找到具有以下功能的原語：在哪里寫（精確地覆蓋堆棧上的返回地址）和信息泄漏（泄漏內(nèi)存地址） ，例如堆棧）。
信息泄漏
為了實現(xiàn)Infoleak原語，我們使用溢出來破壞仍在緩存中的DNS資源記錄的元數(shù)據(jù)。然后，當(dāng)再次從緩存中查詢時，我們能夠泄漏相鄰的堆內(nèi)存。
WinDNS的堆管理器
WinDNS使用該功能Mem_Alloc動態(tài)分配內(nèi)存。此功能管理自己的內(nèi)存池，以用作有效的緩存。有4個內(nèi)存池存儲區(qū)，用于不同的分配大?。ㄗ畲鬄?/span>0x50、0x68、0x88、0xA0）。如果請求的分配大小大于0xA0字節(jié)，則默認(rèn)為HeapAlloc，使用本地Windows堆。堆管理器為內(nèi)存池頭分配額外的0x10字節(jié)，其中包含元數(shù)據(jù)，包括緩沖區(qū)的類型（已分配/空閑），指向下一個可用內(nèi)存塊的指針，用于調(diào)試檢查的cookie等。堆管理器以單鏈接列表的方式實現(xiàn)了其分配列表，這意味著將按照釋放時的相反順序分配塊（LIFO）。
寫在哪里
為了實現(xiàn)“在哪里寫”原語，我們通過破壞塊的標(biāo)頭（元數(shù)據(jù)），事實上破壞了空閑列表來攻擊WinDNS堆管理器。
在空閑列表損壞之后，下次我們嘗試分配大小合適的任何內(nèi)容時，內(nèi)存分配器都會為我們分配我們選擇的內(nèi)存區(qū)域作為可寫分配–“ Malloc-Where”利用原語。
要繞過CFG，我們希望該內(nèi)存區(qū)域位于堆棧上（由于信息泄漏，我們希望知道其位置）。一旦在堆棧上具有寫功能，就可以將返回地址覆蓋到要執(zhí)行的地址，從而有效地劫持了執(zhí)行流程。
值得一提的是，默認(rèn)情況下，DNS服務(wù)會在前3次崩潰中重新啟動，從而增加了成功利用的機會。
結(jié)論
Microsoft已確認(rèn)此高嚴(yán)重性漏洞，并將其分配給CVE-2020-1350。
我們相信，利用此漏洞的可能性很高，因為我們在內(nèi)部發(fā)現(xiàn)了利用此漏洞所需的所有原語。由于時間限制，我們沒有繼續(xù)追求該漏洞的利用（包括將所有利用原語鏈接在一起），但我們確實相信，堅定的攻擊者將能夠利用它。成功利用此漏洞將產(chǎn)生嚴(yán)重影響，因為您經(jīng)常會發(fā)現(xiàn)未打補丁的Windows域環(huán)境，尤其是域控制器。此外，某些Internet服務(wù)提供商（ISP）甚至可能已將其公共DNS服務(wù)器設(shè)置為WinDNS。
強烈建議用戶修補受影響的Windows DNS服務(wù)器，以防止利用此漏洞。
作為臨時的解決方法，在應(yīng)用補丁之前，建議將DNS消息（通過TCP）的最大長度設(shè)置為0xFF00，這樣可以消除此漏洞。您可以通過執(zhí)行以下命令來這樣做：
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters" /v "TcpReceivePacketSize" /t REG_DWORD /d 0xFF00 /f net stop DNS && net start DNS
Check Point IPS刀片可抵御以下威脅：
“ Microsoft Windows DNS服務(wù)器遠(yuǎn)程執(zhí)行代碼（CVE-2020-1350）”
Check Point SandBlast Agent E83.11已經(jīng)可以抵御這種威脅
披露時間表
· 2020年5月19日–向Microsoft提交的初次報告。
· 2020年6月18日– Microsoft發(fā)布了此漏洞的CVE-2020-1350。
· 2020年7月9日– Microsoft承認(rèn)此問題為CVSS評分為10.0的可蠕蟲，嚴(yán)重漏洞。
· 2020年7月14日–微軟發(fā)布了修復(fù)程序（星期二修補程序）。
參考資料
非常感謝我的同事Eyal Itkin（@EyalItkin）和Omri Herscovici（@omriher）在這項研究中的幫助。
文章轉(zhuǎn)自
