標題:NTLM Relay

taibeihacker

Moderator

NTLM Relay​

1 前言​

1.1 背景介绍​

NTLM Relay,中間人攻擊或重放攻擊是一個意思。
B 是一個smb 服務器,A 來進行認證,B 將A 的認證信息轉發到C 上,如果A 的憑證在C 上認證成功就能進行下一步操作,如創建服務執行命令。如果在域中控制了某些常用服務,如:WEB OA 系統、文件共享等服務則可以嘗試使用SMB 中繼攻擊來引誘域管理員訪問達到獲取其他機器權限的目的。
2001 年,最早由Dystic 實現,SMBRelay
2004 年,發展為HTTP - SMB,BlackHat,未開源
2007 年,HTTP - SMB 被集成到MetaSploit
2008 年,HTTP - HTTP的NTLM 攻擊被實現(MS08-067)

1.2 认证过程​

两端模型:
20200509090900.png-water_print

三端模型:
20200207143016.png-water_print

在域环境下的 NTLM Relay 的模型:
20200207143306.png-water_print

1.3 HTTP - SMB 攻击实验​

1.3.1 nmap 探测 SMB 签名​

nmap 掃描:
1
nmap -p445 --script=smb-security-mode.nse IP --open

1.3.2 使用 ntmlrelayx.py 测试​

ntmlrelayx.py 腳本在empire 包中
1
ntlmrelayx.py -tf hosts.txt -socks -smb2support
20200509100947.png-water_print

注意
發起攻擊時,HTTP - SMB,開啟80 端口,需要保證端口未被佔用
攻擊成功後,會在攻擊機本地開啟1080 socks 端口,通過proxychain 等代理工具,即可控制目標機器。
1
2
# mac 下proxychain-NG
proxychains4 /Users/Geekby/opt/anaconda3/bin/python secretsdump.py pentest.com/[email protected]
20200509104954.png-water_print

注意
進行認證時會提示輸入密碼,留空即可使用relay 後的憑據進行認證。

1.4 Hot Potato​

Hot Potato 是一個經典的利用NTLM Relay 獲取高權限用戶控制權的例子,可以參考「Potato 家族提權分析」這篇文章。

1.5 NTLM Relay 防御​

目前有許多針對NTLM 重放攻擊的防禦措施,主要包括以下幾種:
SMB LDAP 簽名
EAP (Enhanced Protection Authentication)
LDAPS Channels
Server target SPN Validation

1.5.1 SMB LDAP 签名​

完成認證後,應用服務器和客戶端之間的所有流量都有簽名驗證保護;用戶簽名的會話密鑰基於客戶端的NTLM 值生成,應用服務器在NETLOGON 階段從DC 服務器獲取;客戶端採用和DC 相同的算法,基於自身的NTLM 值生成會話密鑰,因此中間人攻擊沒有辦法獲取會話密鑰
20200207144728.png-water_print

1.5.2 EAP (Enhanced Protection Authentication)​

NTLM 認證和一個安全通道進行綁定,在NTLM 認證過程中,最後的NTLM 認證數據報文包含一個目標應用服務器的證書摘要,這個摘要使用客戶端的NTLM 值進行簽名保護,可以防止偽造證書的攻擊。

1.6 关于 NTLM 协议的一些总结​

NT Hash=md4(unicode(hex(password)))
NTLMv2 Hash=HMAC-MD5(unicode(hex(upper(username+domain))), NT Hash)
NTProofStr=HMAC-MD5(challenge + 數據, NTLMv2 Hash)
Session Key=HMAC_MD5(HMAC_MD5(NTLMv2 Response + Challenge, NTLMv2 Hash), NTLMv2 Hash)
MIC=HMAC_MD5(NEGOTIATE_MESSAGE + CHALLENGE_MESSAGE + AUTHENTICATE_MESSAGE, Session key)

2 CVE-2015-0005​

2.1 原理​

應用服務器在收到用戶客戶端的認證信息後,由於本身沒有存儲用戶的口令信息,所以必須依賴域服務器進行認證,將收到的認證信息發送給域服務器,這個過程基於NETLOGON 協議。該協議在應用服務器和域服務器之間建立一個安全會話,安全會話共享密鑰基於應用服務器主機賬號的口令NTLM 生成。

2.1.1 NETLOGON 步骤​

均為RPC 遠程向認證服務器調用
NetrLogonSamLoginEx
NetrLogonSamLogonWithFlags
NetrLogonSamLogon
NetrLogonSamLogoff

2.1.2 攻击场景​

win10x64en$ 上的用戶eviluser ,訪問內服務器win2008R2$ 的SMB 服務,採用NTLM 認證方式,域服務器為Win2016-dc01$ ,認證過程概括如下:
win10x64en$ 首先向win2008R2$ 的SMB 445 端口發起一個連接NTLM_NEGOTIATE,協商使用NTLM 認證方式;
win2008R2$ 收到後,發送NTLM CHALLENGE 返回給win10x64en$;
win10x64en$ 收到NTLM CHALLENGE 後,向win2008R2$ 發送一個NTLM 認證報文;
Win2008R2$ 和域控服務器之間共享了Win2008R2$ 的口令NTLM,以此生成會話密鑰,創建一個NETLOGON 安全會話。 Win2008R2$ 通過RPC 調用域服務器的NetrLogonSamLogonWithFlags 函數,並將win10x64en$ 發送過來的認證信息加上此前的挑战信息全部填裝進入作為參數;
域服務器收到信息後,驗證認證信息,如果認證合法則返回STATUS_SUCCESS;
如果NetrLogonSamLogonWithFlags 調用成功,則應用服務器會返回NETLOGON_VALIDATION 數據結構,該結構的結尾可能是以下結構中的一種: NETLOGON_VALIDATIN_SA_FO ,NETLOGON_VALIDATION_SAM_INFO2,NETLOGON_VALIDATION_SAM_INFO4。在這個結構中有一個重要的數據,就是SessionKey ,用於用戶客戶端和應用服務器之間的簽名、加密等;
20200207151317.png-water_print

SessionKey 基於客戶端用戶的口令NTLM 生成,應用服務器從DC 獲取,客戶端用戶自己採用相同的算法生成,因此應用服務器和客戶端不需要交互SessionKey;
20200207151646.png-water_print

第二個參數為主機名(微軟的解釋「Computer Name: The Unicode string that contains the NetBIOS name of the client computer calling this method」),主機名為調用該函數的客戶端主機名,也就是應用服務器通過RPC 遠程調用的該函數,因此該主機名理論上應該與應用服務器和域服務器之間安全會話密鑰的主機賬號應該一致。
20200207152025.png-water_print

所以任何一台域內主機,只要能拿到此前用戶和應用服務器的認證信息,就可以向域服務器發起NETLOGON,從而獲取SessionKey,這樣後面可以偽造應用服務器和客戶端用戶之間的數據簽名,滿足中間人攻擊。

2.2 实战​

利用impacket 中的smbrelayx 進行中間人攻擊,如果目標機器強制使用SMB 簽名,該模塊會使用NETLOGON 直接獲取簽名用的sessionKey
環境:
攻击机(非域内主机):192.168.68.24
客户端服务器(被中间人攻击的服务器): SERVER-2008
目标主机、应用服务器: Windows Server 2012 - 172.16.147.130
資訊
如果是非域主機,需要指定當前域內任意一台主機的hash,且指定域控的IP。
1
python2 smbrelayx.py -h 172.16.147.130 -machine-account pentest-ad/SERVER-2008$ -machine-hashes bab7079288e58b875c46601f274001e6:bab7079288e58b875c46601f274001e6 -domain 172.16.147.130
可以使用-e 參數指定目標機器要執行的文件,不指定的話,默認dump 下目標機器的Hash,-c 可以指定要執行的命令。
20200509154315.png-water_print

2.3 防御​

影響Windows Server 2012 及以下,對個人PC 無影響
微軟發布了補丁MS15-027,針對這個漏洞進行了修補,對ComputerName 和NetBIOS 這2 個字段進行了校驗,並且對這個消息認證塊進行了簽名校驗

3 CVE-2019-1019​

在CVE-2015-0005 漏洞被修補後,域服務器會校驗ComputerName 和NetBIOS 這2 個字段是否一致。但是如果ComputerName 字段缺失,則域服務器會接受,而且不會對認證消息進行完整性校驗(MIC) 。

3.1 原理​

由於NTLM_AUTHENTICATION 報文中的很多信息,包括ComputerName 字段信息,是從NTLM-CHALLENGE 中拷貝獲取,因此在攻擊者可以截獲由應用服務器發送給客戶端的挑戰信息,並將ComputerName 字段進行刪除,客戶端收到挑戰信息後,由於找不到ComputerName 字段,會導致隨後的NTLM_AUTHENTICATION 也不包含該字段。
20200208103534.png-water_print

通過配置,可以讓NTLM 啟用完整性校驗,即在認證消息中添加一個字段MIC(Message Integrity Code),在新版本中這是默認開啟的功能。 MIC 是用來保護NTLM 認證報文的完整性,即NTLM_CHALLENGE。
MIC 通過基於SessionKey 會話秘鑰的HMAC_MD5 算法實現完整性保護,而此前的分析中,我們有能力方法獲取這個SessionKey,因此修改後重新計算MIC 即可。
20200208103900.png-water_print

20200208104134.png-water_print

客戶端發起到應用服務器的NTLM_NEGOTIATE,被重放攻擊者捕獲
攻擊者將NTLM_NEGOTIATE 轉發給真正的應用服務器,也即我們的攻擊目標
應用服務器返回一個NTLM_CHALLENGE 給攻擊者
重放攻擊者將NTLM_CHALLENGE 中的ComputerName 字段去掉,然後轉發給客戶端
客戶端收到修改後的NTLM_CHALLENGE ,基於這些信息構造NTLM_AUTHENTICATE ,將認證信息發送給重放攻擊者,此時認證消息已經包含MIC
重放攻擊者向域服務器發起一個NETLOGON 會話請求,由於認證消息中ComputerName 字段缺失,域服務器不進行完整性校驗,認可該認證消息,並返回一個Sessionkey
重放攻擊者重新計算MIC ,並將新的NTLM_AUTHENTICATE 發送給應用服務器
應用服務器收到NTLM_AUTHENTICATE 後,校驗MIC,然後向域服務器發起NETLOGON 會話請求,域服務器返回認證成功的響應,其中包含會話密鑰,這個會話密鑰和第6 步中的會話密鑰相同
重放攻擊者成功地與應用服務器建立了一個帶簽名的會話,獲取了客戶端用戶在應用服務器上的訪問權限,如果客戶端用戶是管理員,而應用服務器是域服務器,則重放攻擊者俱備了在域服務器(應用服務器)上的管理員權限(客戶端)。

3.2 实战​

利用impacket 中的ntlmrelayx.py 進行中間人攻擊,使用-remove-target 參數。
20200509095846.png-water_print

1
python3 ntlmrelayx.py -h 172.16.147.130 -remove-target --enum-local-admins -smb2support -machine-account pentest-ad/SERVER-2008$ -machine-hashes bab7079288e58b875c46601f274001e6:bab7079288e58b875c46601f274001e6 -domain 172.16.147.130

4 CVE-2019-1040​

4.1 原理​

在安裝了CVE-2015-0005 的補丁後,系統會校驗NetBIOS 的名稱和NetrLogonSamLogonWithFlags 函數的ComputeName 參數是否相同。因此,此前通過修改ComputerName 來獲取SessionKey 的方法失效。
但是如果認證信息中的NetBIOS 被刪除或者消失後,認證服務器不會再進行前面的名字校驗,也就是說我們再修改ComputerName 參數,能達成CVE-2015-0005 漏洞的效果,從而獲取會話密鑰。
針對這種情況,可以通過配置“服務器拒絕任何沒有NetBIOS 的請求”來阻止此類攻擊。但是在NTLMv1 中,NTLM 消息塊結構體中,本來就沒有這個字段,因此這種攻擊在NTLMv1 場景中難以通過策略或者補丁來杜絕,仍然存在很大的脆弱性。
客戶端和服務器在NTLM 協商時,通過下圖中NegotiatFlags (即msvAvFlags 字段)來標識是否需要MIC 來保護會話的完整性,見下圖中紅色框標識。
20200208114101.png-water_print

SMB 客戶端在NTLM 認證時,默認設置需要MIC 進行完整性校驗保護。直觀而言,一般會有幾種方式對抗MIC,一是修改MIC,前提條件是獲取會話密鑰,在前面我們看到:如果配置了防護策略,通過刪除NetBIOS 不能獲取會話密鑰;二是直接丟棄MIC,這時需要將msVAvFlags 字段中的標誌位同樣進行修改,以及版本信息,因為有些版本默認是必須要有MIC。
msvAvFlags 字段的定義,查看微軟知識庫,如果為0x00000002 表示客戶端通過MIC 來保護數據報文的完整性
20200208114702.png-water_print

msvAVFlags 字段由用戶的NTLM 散列值進行簽名保護,因此不能修改msvAVFlag 字段。實際中非常神奇,域服務器並不真正在乎MIC 和Version 信息是否存在,如果存在,則校驗,如果不存在則不校驗。
上述的攻擊方式,可以通過配置進行阻止,即如果msvAVFlags 字段表明有MIC 完整性校驗,就必須要有MIC 的存在,而且進行校驗。但是在實際應用場景中,仍然存在一些隱患,例如MacOS 、Linux 系統中的FireFox 默認情況下,不添加MIC。

4.2 实战​

利用impacket 中的ntlmrelayx.py 進行中間人攻擊,使用--remove-mic 參數。
20200509095534.png-water_print

1
python3 ntlmrelayx.py -h ldap://172.16.147.130 --remove-mic --escalate-user commonuser -smb2support -machine-account pentest-ad/SERVER-2008$ -machine-hashes bab7079288e58b875c46601f274001e6:bab7079288e58b875c46601f274001e6 -domain 172.16.147.130

5 EPA-Bypass​

5.1 原理​

EPA (Enhanced Protection for Authentication),將認證報文綁定到一個安全通道中,主要用於保護Windows 集成認證的服務,例如OWA、ADFS、 LDAPS。
具體的做法是,在認證報文中添加一個字段Channel Bindings,根據微軟的說明,Channel Bindings 為一段MD5 Hash 值,表示結構體gss_channel_bindings_struct 的MD5Hash 值。
 
返回
上方