怎么進行WindowsDHCPServer遠程代碼執(zhí)行漏洞分析

怎么進行Windows DHCPServer遠程代碼執(zhí)行漏洞分析，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

創(chuàng)新互聯(lián)公司堅持“要么做到，要么別承諾”的工作理念，服務領域包括：成都網(wǎng)站設計、成都網(wǎng)站建設、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務，滿足客戶于互聯(lián)網(wǎng)時代的會澤網(wǎng)站設計、移動媒體設計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡建設合作伙伴！

一 漏洞背景

2月12日，微軟發(fā)布2月份月度例行安全公告，修復了多個高危漏洞，其中包括Windows DHCP Server遠程代碼執(zhí)行漏洞CVE-2019-0626。當攻擊者向DHCP服務器發(fā)送精心設計的數(shù)據(jù)包并成功利用后，就可以在DHCP服務中執(zhí)行任意代碼，漏洞影響范圍較大。針對此漏洞，啟明星辰ADLab第一時間對其進行了詳細分析。

二 漏洞影響版本

Windows 7

Windows 8.1

Windows 10

Windows Server 2008

Windows Server 2012

Windows Server 2016

Windows Server 2019

三 協(xié)議簡介

DHCP，動態(tài)主機配置協(xié)議，前身是BOOTP協(xié)議，是一個局域網(wǎng)的網(wǎng)絡協(xié)議。DHCP通常用于集中管理分配IP地址，使client動態(tài)地獲得IP地址、Gateway地址、DNS服務器地址等信息。DHCP客戶端和DHCP服務端的交互過程如下圖所示。

傳輸?shù)腄HCP協(xié)議報文需遵循以下格式：

DHCP包含許多類型的Option，每個Option由Type、Length和Data三個字段組成。

Type取值范圍1~255，部分Type類型如下圖所示。

DHCP服務在處理VendorSpecific 類型（Type=43）的Option結(jié)構(gòu)存在安全漏洞。首先看下DHCP服務程序?qū)ption的處理過程， ProcessMessage函數(shù)負責處理收到的DHCP報文，調(diào)用ExtractOptions函數(shù)處理DHCP的Option字段，傳入函數(shù)ExtractOptions的參數(shù)1（v7）為DHCP報文指針，參數(shù)3（*(unsigned    int *)(v5 + 16)）對應指針偏移位置+16的數(shù)據(jù)，即Len字段。

ExtractOption函數(shù)如下所示。 v6 = (unsigned__int64)&a1[a3 - 1];指向報文末尾位置；v10=a1+240;指向報文中Option結(jié)構(gòu)。在for循環(huán)中處理不同類型的Option結(jié)構(gòu)，當type=43（Vendor Specific Information），傳入指針v10和指針v6作為參數(shù)，調(diào)用ParseVendorSpecific函數(shù)進行處理。

ParseVendorSpecific函數(shù)內(nèi)部調(diào)用UncodeOption函數(shù)。UncodeOption函數(shù)參數(shù)a1指向option起始位置，a2指向報文的末尾位置。UncodeOption函數(shù)存在安全漏洞，下面結(jié)合POC和補丁比對進行分析。

四 漏洞分析

構(gòu)造一個DHCP Discovery報文，POC如下所示，POC包含兩個vendor_specific類型的Option結(jié)構(gòu)。vendor_specific1是合法的Option結(jié)構(gòu)，Length取值0x0a等于Data的實際長度（0x0a），vendor_specific2是不合法的Option結(jié)構(gòu)， Length取值0x0f大于Data的實際長度（0x0a）。

（1）DHCP服務器收到Discovery請求報文，對數(shù)據(jù)包進行處理。首先執(zhí)行ExtractOptions處理Options，當處理vendor_specific類型的Option時，進入到ParseVendorSpecific進行處理。POC中構(gòu)造一個合法的vendor_specific1，目的是為了繞過84~85行的校驗代碼，使程序順利執(zhí)行到ParseVendorSpecific函數(shù)。

（2）ParseVendorSpecific調(diào)用UncodeOption函數(shù)。

a. 32~43行在do-while循環(huán)中計算Option結(jié)構(gòu)的 Length值之和，保存到v13，作為分配堆內(nèi)存長度。POC中包含兩個vendor_specific結(jié)構(gòu)，首先處理vendor_specific1，計算v13，即vendor_specific1長度a，并且使v12指向下一個Option結(jié)構(gòu)vendor_specific2，當進入43行while條件判斷，由于vendor_specific2長度不合法，do-while循環(huán)結(jié)束。

b. 48行調(diào)用HeapAlloc分配堆內(nèi)存，分配的內(nèi)存大小v13=a。

c. 51~58行在for循環(huán)中依次將vendor_specific結(jié)構(gòu)中的Data拷貝到分配的堆內(nèi)存中。進入第一次循環(huán)時，v1指向vendor_specific1，v8指向末尾位置，滿足條件v1<v8，55行調(diào)用memcpy將vendor_specific1的Data字段拷貝到分配的堆內(nèi)存，拷貝長度Length=a。進入第二次循環(huán)，v1指向vendor_specific2，v8指向末尾位置，仍然滿足條件v1<v8，再次調(diào)用memcpy將vendor_specific2的Data字段拷貝到分配的堆內(nèi)存，拷貝長度Length=0xf。由于分配的堆內(nèi)存大小只有a個字節(jié)，而拷貝的總長度=0x0a+0x0f，從而導致堆溢出。

五 補丁比對

補丁后的版本添加了對Length字段的有效性判斷。

六 安全建議

及時安裝安全補?。篽ttps://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0626

看完上述內(nèi)容，你們掌握怎么進行Windows DHCPServer遠程代碼執(zhí)行漏洞分析的方法了嗎？如果還想學到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！

網(wǎng)頁標題：怎么進行WindowsDHCPServer遠程代碼執(zhí)行漏洞分析
鏈接分享：http://muchs.cn/article22/iehdcc.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供營銷型網(wǎng)站建設、網(wǎng)站營銷、企業(yè)建站、定制網(wǎng)站、小程序開發(fā)、網(wǎng)站收錄

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)