介紹
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)在這項研究中的幫助。
文章轉自
售前咨詢(xún)
售后咨詢(xún)
備案咨詢(xún)
二維碼
TOP