CVE-2020-1472简要分析

阅读量231893

发布时间 : 2020-09-16 14:30:51

 

漏洞简介

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

 

漏洞原理

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 chanllenge,该部分内容攻击者可控,设置为全0,AES使用的key是将secret、chanllenges进行运算后得到的值,也就是说,key会随着每一轮server chanllenge的变化发生变化,那么如果IV和client chanllenge为全0的话,那么整个AES运算过程变成图1-3所示:

图1-3

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

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

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

 

漏洞验证

1.无法获取域内用户凭据信息

2.执行PoC测试

3. DC01置空后,获取域内凭据信息

 

参考

https://www.secura.com/blog/zero-logon

https://github.com/dirkjanm/CVE-2020-1472

本文由奇安信代码卫士原创发布

转载,请参考转载声明,注明出处: https://www.anquanke.com/post/id/217475

安全客 - 有思想的安全新媒体

分享到:微信
+12赞
收藏
奇安信代码卫士
分享到:微信

发表评论

奇安信代码卫士

奇安信代码卫士是国内第一家专注于软件开发安全的产品线,产品涵盖代码安全缺陷检测、软件编码合规检测、开源组件溯源检测三大方向,分别解决软件开发过程中的安全缺陷和漏洞问题、编码合规性问题、开源组件安全管控问题。微信公号:codesafe。

  • 文章
  • 387
  • 粉丝
  • 104

热门推荐

内容需知
  • 投稿须知
  • 转载须知
  • 官网QQ群8:819797106
  • 官网QQ群3:830462644(已满)
  • 官网QQ群2:814450983(已满)
  • 官网QQ群1:702511263(已满)
合作单位
  • 安全客
  • 安全客
Copyright © 北京奇虎科技有限公司 360网络攻防实验室 安全客 All Rights Reserved 京ICP备08010314号-66