挖掘微软高危安全漏洞全过程
本文中，Laxman Muthiyan将为读者详细介绍自己是如何在微软在线服务中挖掘到一个高危安全漏洞的——利用该漏洞，任何人都可以在未经用户同意的情况下接管任意的微软账户。目前，微软安全团队已经修补了这个漏洞，并为其颁发了5万美元的奖金。
在发现Instagram账户的接管漏洞之后，我一直在寻找其他服务中类似的漏洞。后来我发现，微软也在使用类似的技术来重置用户的密码，所以，我决定测试其中是否存在速率限制漏洞。
为了重置微软账户的密码，我们需要在“忘记密码”页面中输入自己的电子邮件地址或电话号码，同时，还要选择到底使用电子邮件还是手机号码来接收安全码。
当我们收到7位数的安全码后，必须输入该码，然后才能重置密码。在这里，如果我们能够遍历所有的7位数的安全码组合（即10^7=1000万个密码），就能够在未经许可的情况下重置任何用户的密码。但是，很明显，微软肯定会设置速率限制，以防止攻击者进行大量的尝试。
我们可以拦截向代码验证端点发出的HTTP POST请求，具体如下所示：
如上图所示，我们输入的1234567安全码并没有以明文形式出现在该请求中，因为它首先会进行加密处理，然后才会发送验证。之所以这么做，很可能是为了防止攻击者利用暴力破解攻击自动攻击该验证系统。也就是说，我们无法使用像Burp Intruder这样的工具自动测试大量的安全码，因为它无法处理加密的部分。
经过一段时间后，我终于弄明白了这里使用的加密技术，并实现了从加密安全码到发送多个并发请求的整个过程的自动化。
初步测试显示，正如预期的那样，这里的确存在速率限制。在发送的1000个安全码中，只有122个被放行，其他的安全码都被阻止了，并显示出错代码1211；也就是说，如果我们连续发送请求，超出一定的数量之后，系统会阻止相应的用户账户进一步发送发送请求。
然后，我试着像对Instagram那样同时/并发发送请求，虽然这种方式使我可以发送大量请求而不被阻止，但仍然无法在注入正确的7位安全代码时获得成功的响应。我认为他们肯定采取了某些控制措施来防止这种类型的攻击。尽管在发送正确的安全码时收到了出错信息，但仍然没有像我们在最初的测试中看到的那样阻止用户的迹象。所以，我认为还是有机会的。
过了些日子，我突然意识到，如果我们发送的所有请求没有同时命中服务器，他们就会把IP地址列入黑名单，因此，哪怕请求之间只有几毫秒的延迟，也能让服务器检测到攻击并阻止该攻击。因此，我调整了自己的代码，以处理这种情况，并再次进行了测试。
出乎意料的是，这次竟然成功了——这次收到了成功的响应。
为此，我发送了1000个左右的七位数安全码，其中包括正确的安全码，之后就可以进入修改密码的步骤了。
需要注意的是，上面描述的方法仅适用于没有启用双因素认证的用户；如果用户启用了2FA，我们首先需要绕过双因素码认证，然后才能修改密码。
我测试了一个启用了2FA的账号，发现他们使用的都是同一个终端，并且都容易受到这种攻击的威胁。一开始，用户会被提示输入一个由身份验证器应用程序生成的6位数安全码，然后才会被要求输入发送到他们的电子邮件或电话号码的7位数的安全码。之后，他们就可以修改密码了。
综合来看，攻击者必须发送所有可能的6位和7位数的安全码，为此，大约需要进行1100万次的请求尝试，而且必须同时发送，只有这样才能修改任意微软账户的密码（包括那些启用2FA的账户）。
要发送如此大量的并发请求，可不是一件容易的事情，因为这需要大量的计算资源以及数以千计的IP地址才能成功发动该攻击。
我立即录制了攻击过程的相关视频，并与重现该漏洞的详细步骤一起提交给了微软。之后，他们很快就确认了这个安全漏洞。
该漏洞已经于2020年11月得到了修复，但是，刚开始的时候，他们并不认为这是一个提权漏洞。于是，我要求他们重新考虑漏洞的性质，经过多次交涉之后，微软终于将漏洞归类为提权漏洞（同时，还涉及多因素认证绕过漏洞）。鉴于该攻击的复杂性，该漏洞的严重性被被定为“重要”而非“严重”。
来自MSRC的Bount电子邮件：
微软确认了本文报告的漏洞：
2021年2月9日，我通过hackerone收到了5万美元的赏金，并在3月1日获准发表这篇文章。在这里，我要特别感谢Dan、Jarek和整个MSRC团队，感谢他们耐心倾听我的所有意见，提供更新并修复了该漏洞。同时，这里也要感谢微软的慷慨。
参考来源：https://thezerohack.com/how-i-might-have-hacked-any-microsoft-account
转自：嘶吼roartalk
