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