是什么严重漏洞让4亿微软账户险遭暴露（附详情）？
编译：360代码卫士团队
在 SafetyDetective 公司工作的印度赏金猎人 Sahad Nk 发现并向微软报告了微软账户中的一系列严重漏洞并获得一笔数额不明的奖金。
这些漏洞出现在用户的 MS Office 文件、Outlook 邮件等的微软账户中。也就是说所有类型的账户（超4亿）和所有类型的数据均易遭攻击。如果结合使用这些漏洞，将成为获取用户微软账户访问权限的完美攻击向量。攻击者需要的不过是强制用户点击某链接。
Sahad Nk 在博客中表示，微软的一个子域名“success.office.com”配置不正确，这也是为何他能使用 CNAME 记录控制该子域名的原因。CNAME 记录是域名之间连接的规范记录。Sahad 使用 CNAME 记录能够定位配置错误的子域名并将其指向个人 Aure 实例，从而获取对子域名和它所获取的所有数据的控制。
然而，问题的根本在于 MS Office、Sway 和 Store app 可被轻易诱骗将认证登录令牌转给受攻击者控制的域名，前提是用户通过微软 Live 登录。这种现象发生的原因是易受攻击的应用程序使用了通配符正则表达式，导致所有子域名受信任。
受害者点击通过邮件收到的特殊设计的链接后，他或她将使用微软 Live 的登录系统登录。当受害者输入用户名、密码和双因素认证码（如启用），那么会生成一个账户访问令牌，使用户在无需重新输入登录凭证的情况下登录。
如果有人获得这个访问令牌，那么就会获得真实的用户凭证。因此，攻击者能够在无需警告账户原始所有人、甚至无需警告微软越权访问的情况下入侵账户。
恶意链接旨在强制微软登录系统将账户令牌转给受控制的子域名。在本案例中子域名由 Sahad 控制，然而，如果被恶意攻击者控制，那么可导致数量庞大的微软账户遭风险。更重要的是，恶意链接看似是真实的，因为用户仍然通过合法的微软登录系统输入。
Sahad Nk 已将问题告知微软，后者已修复。目前尚不知晓 Sahad 获得的奖励金数额是多少。
详情
Sahad 在博客中发布了这两个严重漏洞的具体情况：
第一个漏洞
在第一次侦测过程中，Sahad 检索了 office.com 所有指向很多很多 Azure 实例的可能的子域名。其中一个是 success.office.com，它并未解析到任何 IP 地址，但有一个 CNAME 指向一个 Azure web app 实例 successcenter-msprod。如果域名未解析的话，你很有可能控制一个 Azure 实例。因此 Sahad 尝试在自己的 Azure 门户网站上创建了名为“sucesscenter-msprod”的web app，且它被接受为合法名称。换句话说，之前拥有这个名称的实例已被删除，现在已被释放。也就是说，不管我们在 sucesscenter-msprod 上托管什么，success.office.com 都会将其指为 CNAME 记录所述内容。
第二个漏洞
微软使用 WS Federation 为多数应用程序实现集中化登录系统，包括 Outlook、Sway、Microsoft Store 等。WS Fed 类似于 Oauth。WS Fed 中的 wreply 相当于 Oauth 中的 redirect_url。不为 wrepy 或 redirect_url 使用确切的 URL 匹配（或不当验证）造成的后果很危险。在这个案例中，微软允许 office.com (*.office.com) 的任意子域名成为合法的 wreply URI。
由于其中一个子域名受控制，因此能够使用域名作为合法的 wreply url 并泄露如下访问令牌：
https://login.live.com/login.srf?wa=wsignin1.0&rpsnv=13&ct=1529775349&rver=6.7.6643.0&wp=MBI_SSL&wreply=https://success.
从本质上来说u，如果任何用户已得到认证（或将认证），点击动了手脚的特殊构造的链接，令牌就会被泄露，而这个令牌可交换会话令牌，最终导致账户遭控制。
被泄令牌如下：
推荐阅读
原文链接
https://www.hackread.com/critical-bug-in-microsoft-left-400m-accounts-exposed/
https://pagefault.me/2018/12/12/office-subd/
本文由360代码卫士编译，不代表360观点，转载请注明“转自360代码卫士 www.codesafe.cn”。