如何進(jìn)行Windows NTLM篡改漏洞分析

如何進(jìn)行Windows NTLM篡改漏洞分析，針對這個問題，這篇文章詳細(xì)介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

2019年6月11日，Microsoft發(fā)布了六月份安全補丁更新。在該安全更新補丁中，對CVE-2019-1040漏洞進(jìn)行了修復(fù) 。攻擊者利用該漏洞可以繞過NTLM中的MIC（Message Integrity Code）。攻擊者可以修改已經(jīng)協(xié)商簽名的身份驗證流量，然后中繼到另外一臺服務(wù)器，同時完全刪除簽名要求。通過該攻擊方式可使攻擊者在僅有一個普通域賬號的情況下，運程控制域中任意機(jī)器（包括域控服務(wù)器）。

漏洞背景

NTLM中繼是對Active Directory環(huán)境最常見的攻擊方式之一。針對此攻擊技術(shù)一種重要的緩解措施是進(jìn)行服務(wù)器簽名。當(dāng)用戶與服務(wù)器建立了簽名會話，攻擊者如果無法檢索所需的會話密鑰，就無法劫持會話。但是在默認(rèn)情況下，只有域控服務(wù)器會強(qiáng)制執(zhí)行SMB簽名，這導(dǎo)致在許多情況下會使得域中其他敏感服務(wù)器容易受到攻擊。

圖1 NTLM中繼

在SMB中，通過在NTLM_NEGOTIATE消息中設(shè)置”NTLMSSP_NEGOTIATE_SIGN”標(biāo)志進(jìn)行協(xié)商會話簽名。如果攻擊者試圖中繼這種NTLM身份驗證，他們將需要確保不協(xié)商簽名。一種方法是通過中繼到NTLM消息不管理會話完整性的協(xié)議，如LDAPS或者HTTPS。但是這種協(xié)議并非每一臺機(jī)器都會打開。而SMB協(xié)議在局域網(wǎng)中是經(jīng)常打開的，且存在較多漏洞容易造成代碼執(zhí)行。因此，NTLM中繼攻擊的重點就在于將SMB身份驗證請求轉(zhuǎn)發(fā)給其他SMB服務(wù)器。為成功執(zhí)行此類中繼，攻擊者需要修改NTLM_NEGOTIATE消息并取消設(shè)置”NTLMSSP_NEGOTIATE_SIGN”標(biāo)志。

圖2 NTLM_NEGOTIATE消息指示是否協(xié)商SMB簽名

在SMB中，默認(rèn)情況下，通信的雙方都支持簽名，則必須進(jìn)行會話簽名。為了保證在NTLM協(xié)商階段不被攻擊者篡改數(shù)據(jù)，Microsoft在最終的NTLM身份驗證消息中添加了一個額外字段——MIC。但是，微軟對該字段的處理方式存在紕漏：允許無MIC的驗證消息。

MIC(Message Interity Code)消息完整性驗證

NTLM身份驗證由3種消息類型組成：NTLM_NEGOTIATIE，NTLM_CHALLENGE，NTLM_AUTHENTICATE。為確保在傳輸過程中不會被惡意篡改，在NTLM_AUTHENTICATE消息中添加了一個額外的MIC字段。MIC是使用會話密鑰應(yīng)用于所有3個NTLM消息的串聯(lián)的HMAC_MD5，該會話密鑰只有啟動了認(rèn)證的賬戶和目標(biāo)服務(wù)器知道。因此，任何試圖篡改其中一條消息的行為都無法生成相應(yīng)的MIC，保證傳輸?shù)陌踩浴?/p>

圖3 “MIC”字段可以防止NTLM消息修改

MIC存在于NTLM_AUTHENTICATE消息的’msvAvFlag’字段，標(biāo)志0x2表示該消息包括MIC。它應(yīng)該保護(hù)MIC被刪除。但是，微軟Microsoft服務(wù)器無法完全執(zhí)行該機(jī)制，而且允許了無MIC的NTLM_AUTHENTICATE消息。這為后續(xù)NTLM中繼攻擊提供了條件。

圖4 'flags'字段指示NTLM_AUTHENTICATE消息包括MIC

漏洞分析

4.1 攻擊思路

由于微軟允許無MIC的NTLM_AUTHENTICATE消息，攻擊者可以在獲取到合法的身份驗證后進(jìn)行中繼。主要是將SMB中繼到LDAP。

首先向Windows服務(wù)器（如Exchange）發(fā)起身份驗證，在獲得合法的驗證后將該身份驗證通過LDAP中繼到域控服務(wù)器，就可以在ActiveDirective中以中繼的受害者權(quán)限執(zhí)行一系列操作。

在Exchange場景下，可以獲得DCSync權(quán)限，該種權(quán)限是PrivExchange漏洞利用的基礎(chǔ)

在Resource Based Constrained Kerberos場景下，可以利用該種機(jī)制獲得受害主機(jī)的權(quán)限，進(jìn)而以管理員權(quán)限訪問服務(wù)器。

對需要中繼的身份驗證的MIC的處理流程如下：

1. 取消設(shè)置NTLM_NEGOTIATE消息中的簽名標(biāo)志（NTLMSSP_NEGOTIATE_ALWAYS_SIGN，NTLMSSP_NEGOTIATE_SIGN）

2. 從NTLM_AUTHENTICATE消息中刪除MIC

3. 從NTLM_AUTHENTICATE消息中刪除版本字段（刪除MIC字段而不刪除版本字段將導(dǎo)致錯誤）

4. 取消設(shè)置NTLM_AUTHENTICATE消息中的以下標(biāo)志：NTLMSSP_NEGOTIATE_ALWAYS_SIGN，NTLMSSP_NEGOTIATE_SIGN，NEGOTIATE_KEY_EXCHANGE，NEGOTIATE_VERSION。

4.2 攻擊途徑

1. 使用任意AD賬戶，通過SMB連接到受害主機(jī)Exchange服務(wù)器，觸發(fā)SpoolService的一個bug。然后使用網(wǎng)上公開的ntlmrelayx.py腳本中繼到LDAP。使用中繼的LDAP身份驗證，攻擊者可以獲得DCSync權(quán)限，然后使用DCSync轉(zhuǎn)儲AD中所有的密碼哈希。

2. 使用任意AD賬戶，通過SMB連接到受害主機(jī)Exchange服務(wù)器，觸發(fā)SpoolService的一個bug。然后使用網(wǎng)上公開的ntlmrelayx.py腳本中繼到LDAP。攻擊者使用中繼的LDAP身份驗證，獲取Resource Based Constrained Kerberos中的相關(guān)權(quán)限，然后攻擊者以受害主機(jī)服務(wù)器上的任意用戶進(jìn)行身份驗證。成功驗證后，可以進(jìn)一步進(jìn)行下一步攻擊，甚至控制整個Wshoindows域。

影響范圍

目前受影響的Windows版本：

Windows 10 for 32-bit SystemsWindows 10 for x64-based SystemsWindows 10 Version 1607 for 32-bit SystemsWindows 10 Version 1607 for x64-based SystemsWindows 10 Version 1703 for 32-bit SystemsWindows 10 Version 1703 for x64-based SystemsWindows 10 Version 1709 for 32-bit SystemsWindows 10 Version 1709 for ARM64-based SystemsWindows 10 Version 1709 for x64-based SystemsWindows 10 Version 1803 for 32-bit SystemsWindows 10 Version 1803 for ARM64-based SystemsWindows 10 Version 1803 for x64-based SystemsWindows 10 Version 1809 for 32-bit SystemsWindows 10 Version 1809 for ARM64-based SystemsWindows 10 Version 1809 for x64-based SystemsWindows 10 Version 1903 for 32-bit SystemsWindows 10 Version 1903 for ARM64-based SystemsWindows 10 Version 1903 for x64-based SystemsWindows 7 for 32-bit Systems Service Pack 1Windows 7 for x64-based Systems Service Pack 1Windows 8.1 for 32-bit systemsWindows 8.1 for x64-based systemsWindows RT 8.1Windows Server 2008 for 32-bit Systems Service Pack 2Windows Server 2008 for 32-bit Systems Service Pack 2 (Server Core installation)Windows Server 2008 for Itanium-Based Systems Service Pack 2Windows Server 2008 for x64-based Systems Service Pack 2Windows Server 2008 for x64-based Systems Service Pack 2 (Server Core installation)Windows Server 2008 R2 for Itanium-Based Systems Service Pack 1Windows Server 2008 R2 for x64-based Systems Service Pack 1Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation)Windows Server 2012Windows Server 2012 (Server Core installation)Windows Server 2012 R2Windows Server 2012 R2 (Server Core installation)Windows Server 2016Windows Server 2016 (Server Core installation)Windows Server 2019Windows Server 2019 (Server Core installation)Windows Server, version 1803 (Server Core Installation)Windows Server, version 1903 (Server Core installation)

修復(fù)建議

1. 由于針對該漏洞的 poc已在網(wǎng)上公開流傳，強(qiáng)烈建議廣大用戶及時安裝微軟針對該漏洞的安全更新補?。?/p>

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1040

2. 其他緩解措施

以下措施可以在無法及時安裝安全更新補丁時作為臨時解決方案，為確保安全，仍然建議廣大用戶在條件允許的情況下及時進(jìn)行補丁安裝：

1）開啟域中所有服務(wù)器的強(qiáng)制SMB 簽名 （在 Windows 域 中 ，默認(rèn)只有域控服務(wù)器開啟了強(qiáng)制 SMB 簽名）

2）對LDAP over TLS強(qiáng)制執(zhí)行LDAP簽名和LDAP通道綁定來阻止NTLM中繼到LDAP

3）開啟EPA，強(qiáng)制所有Web服務(wù)器（OWA，ADFS）只接受EPA的請求

4）開啟所有重要服務(wù)器（比如所有 Exchange 服務(wù)器）上相關(guān)應(yīng)用的Channel Binding

5）減少使用NTLM

6）如無特殊需求，禁用Printer Spooler服務(wù)

關(guān)于如何進(jìn)行Windows NTLM篡改漏洞分析問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識。