微软Authenticator翻车实录：我是如何利用0权限App窃取全量Token的 (CVE-2026-80097)

原创

Hankzheng
Hankzheng

技术修道场

2026年11月1日 08:31
广东

去阅读

最近安全圈出了个大瓜，安全机构 Enclave 的研究员 Ofek Levin 挖出了微软 Android 版 Authenticator App 的一个高危漏洞（CVE-2026-80097，CVSS 评分高达 8.6）。这个漏洞离谱到什么程度？一个不需要向系统申请任何权限的“三无”恶意 App，只要装在你的手机上，就能伪装成 Teams，直接把你工作账户的登录 Token 给顺走。

拿到 Token 意味着什么，不用我多说了吧？你的企业邮箱、日历、云端文件，统统在攻击者面前“裸奔”。

今天我就带大家扒一扒这个漏洞的技术细节，看看这么大厂的应用，是怎么在基础组件校验上翻车的。

身份代理：成也萧何，败也萧何

要讲明白这个漏洞的原理，咱们得先聊聊 Authenticator 在安卓系统里的角色定位。

在 Android 生态里，Authenticator 可不仅仅是个用来看 6 位数动态验证码的工具人，它的核心身份其实是一个 Identity Broker（身份代理）。你可以把它理解为一个单点登录管家。当你在手机上打开 Teams、Outlook 等微软全家桶应用需要登录时，这些应用不会自己去处理繁琐的认证逻辑，而是向 Authenticator 发起请求。Authenticator 验证完毕后，直接给应用派发一个 数字通行证。

因为 Broker 掌控着整个账户体系的生杀大权，按理说，它在“给谁发 Token”这件事上，应该严防死守、六亲不认才对。但坏就坏在，它的门禁系统出了个低级 Bug。

核心复现路径：组件暴露与虚假的“签名校验”

这个漏洞的命门，在于 Authenticator 暴露了一个名为 AccountChooserActivity 的 Activity 组件。

做过 Android 逆向或者开发的朋友都知道，未做访问限制的暴露组件是越权漏洞的重灾区。由于没有任何权限限制，设备上的任何 App 都能直接拉起这个 Activity。

攻击者的骚操作就开始了：

1. 发起请求伪造身份

恶意 App 直接启动 AccountChooserActivity，并在请求参数中夹带私货，大言不惭地告诉 Authenticator：“你好，我是 Teams，给我开个 Token。”
2. 形同虚设的签名校验

Authenticator 收到请求后，其实是做了一道安全校验的——它会去检查所请求的那个 App 的签名。但问题恰恰出在这套校验逻辑的“死脑筋”上。
3. 逻辑绕过

Authenticator 并没有去查“到底是谁发起的请求”，而是去查“被伪装的那个应用（Teams）的签名是否合法”。由于受害者的手机上确实安装了正版 Teams，系统里能读到真实的 Teams 签名，校验直接 Pass！

简单来说，这就像是张三戴着马云的面具去银行取钱，银行柜员不去查张三的身份证，而是查验了一下马云的账户确实存在且合法，就把钱全交给了张三。Authenticator 明明能通过系统 API 获取到真实的请求调用方，但它在发放 Token 时偏偏没有使用这个关键信息。

细极思恐的影响面：无交互获取 Graph Token

根据 Enclave 研究员的测试，攻击者利用这种伪装手段请求 Microsoft Graph API 的 Token，能够轻松获取极高权限。返回的 Token 权限包括但不限于：

• 读取和发送电子邮件
• 读取和写入文件
• 读取和写入日历

更值得我们吃瓜的是，安全研究员和微软官方在漏洞利用条件上“掐”起来了。

• Enclave 方面表示

在他们的 PoC 测试中，只要设备上存在已登录的工作账户，获取 Token 的过程完全不需要用户进行任何交互操作。
* 微软官方的漏洞公告则坚称

攻击者除了安装恶意 App 外，还必须“诱导用户在 Authenticator 中完成身份验证流程”才能触发，因此把利用难度评级标为“较小可能”。

不管谁对谁错，对于我们一线 IT 人员和安全从业者来说，这种能接管工作流资源池的漏洞，绝对值得拉响红色警报。

修复方案与安全建议

微软已经在 2026 年 9 月的补丁星期二中秘密修复了这个问题，直到 10 月 23 日技术细节才被公开。目前该漏洞还没有在野利用的记录。

如何防范？

没别的，赶紧升级！

将你的 Android 版 Microsoft Authenticator 更新到 6.2606.4246 或更高版本。如果你是企业的 IT 管理员，建议立刻在 MDM策略里强制要求 Android 设备的最低版本基线。

另外，微软的公告里并没有明确说明“更新应用后，恶意 App 已经拿到的旧 Token 是否会被强制失效”，所以对于有严格安全要求的企业来说，最好的做法是在后台做一次大规模的 Session 重置。

技术的发展日新月异，哪怕是微软这种体量的巨头，依然会在基础的业务逻辑判断上栽跟头。这也提醒我们，在做 Android 应用开发，尤其是涉及鉴权、SSO、跨进程通信等核心模块时，永远不要轻信客户端传来的参数，严格校验调用方的真实身份才是王道。

大家在平时的业务开发中有没有遇到过类似的“坑”？欢迎在评论区一起交流探讨！