CVE-2019-1040漏洞分析学习

前言

前面写到在PetitPotam漏洞复现时可以结合CVE-2019-1040进行利用，绕过ntlm认证的mic校验。
而且无法通过中继自己的smb到自己的ldap，这是由于ldap需要协商签名，域控默认开启smb签名，并且存在mic防止篡改，如果绕过mic的校验就可以使smb中继到ldap进行利用，当然如果是http或者webadv的 不要求签名，可以参考。
当然还有一个问题就是无法使用自己的smb中继到自己的ldap，由于微软修复了ms08-068，原理大致是通过缓存challenge与pszTargetName，如果中继到自己的话会在发现自身存在缓存的内容，认证失败，当然 也存在一个绕过cve-2019-1384，因为默认的缓存是300秒，可以通过这个时间进行绕过，
网上的很多文章都是说ms08-068修复了smb中继到smb 但是如果按照缓存challenge的说法，不管是smb http 还是ldap，都是可以使用ntlm认证，
下面是本人理解,如果有错误欢迎斧正

不管是哪种协议，最终都会使用ntlm协议的认证过程，所以只要通过判断缓存，就可以防止ntlm中继到自身，也就出现了实际应用中无法自己修改自己的操作

分析

主机	机器名	ip	用户	密码	版本
域控1	ad.test.com	192.168.164.147	administrator	Aa1234	win2012r2
域控2	ad2.test.com	192.168.164.146	administrator	Aa1234	win2012r2
域内机器	user.test.com	192.168.164.129	user1	Uu1234.	win2008r2
kali	192.168.164.128	192.168.164.128	xxx	xxx	kali

默认情况下，SMB中的NTLM身份验证:NEGOTIATE_SIGN为set状态

如果Negotiate Sign为set，会触发ldap的签名，中继之后则无法通过ldap签名校验，所以需要设置为not set
而不能通过直接改包，会导致mic校验不通过，所以接下来的思路是绕过mic校验
ntlm身份校验由三种消息类型组成

NTLM_NEGOTIATE
NTLM_CHALLENGE
NTLM_AUTHENTICATE

下图是成功中继的的流量红色为smb 绿色为ldap

这些分别对应ntlm认证过程中的协商，质询，和身份验证操作
在正常的过程中 会使用mic进行完整性检查

MIC是使用会话密钥应用于所有3个NTLM消息的串联的HMAC_MD5，该会话密钥只有启动了认证的账户和目标服务器知道。因此，任何试图篡改其中一条消息的行为都无法生成相应的MIC，保证传输的安全性。
mic存在于NTLM_AUTHENTICATE消息的msvAvFlag字段

所以需要对数据包进行处理，

1.取消设置NTLM_NEGOTIATE消息中的签名标志（NTLMSSP_NEGOTIATE_ALWAYS_SIGN，NTLMSSP_NEGOTIATE_SIGN）

2.从NTLM_AUTHENTICATE消息中删除MIC

3.从NTLM_AUTHENTICATE消息中删除版本字段（删除MIC字段而不删除版本字段将导致错误）??

4.取消设置NTLM_AUTHENTICATE消息中的以下标志：NTLMSSP_NEGOTIATE_ALWAYS_SIGN，NTLMSSP_NEGOTIATE_SIGN，NEGOTIATE_KEY_EXCHANGE，NEGOTIATE_VERSION。

下图是ntlmrelayx的中继流量对比,左边为smb右边为ldap（图片看不清可以复制图片链接打开）
1.NTLMSSP_NEGOTIATE

2.NTLMSSP_CHALLENGE

3.NTLMSSP_AUTH

参考文章

https://www.freebuf.com/vuls/207399.html
https://daiker.gitbook.io/windows-protocol/ntlm-pian/7#5-cve-2019-1040