微软 Authenticator 零权限漏洞技术细节公开:冒充 Teams 就能骗出工作账号 token,微软称 9 月已修
Enclave 10 月 23 日公布 CVE-2026-80097:零权限安卓应用冒充 Teams 可骗取工作账号 token,微软称已修复。

微软 Authenticator 在安卓上替整组微软应用保管登录凭证,安全研究员 Ofek Levin 找到一条绕过它的路:任何一款零权限的安卓应用,只要把自己包装成 Microsoft Teams,就能从 Authenticator 手里收到工作账号的 access token、refresh token 和 ID token。 Levin 所在的 Enclave 于 10 月 23 日公布了完整技术细节,漏洞编号 CVE-2026-80097,微软给出 CVSS 8.6;按微软漏洞公告的记录,这个编号早在 9 月 8 日就已发布,修复落在 6.2606.4246 版。换句话说,可复现的完整攻击配方已经公开,而漏洞本身早已不在——今天的新闻点是细节,不是新洞。
要点
- 漏洞出在 Authenticator 的导出组件
com.microsoft.identity.client.AccountChooserActivity:它只检查「调用方声称自己是谁」,签名校验对的是声称方安装包的签名,真实调用者身份只被记录、不参与信任判断(Enclave 10 月 23 日技术细节)。 - 影响安卓版 6.2606.4246 之前的所有 Authenticator;该版本在 Play 商店已上线一段时间,微软漏洞公告记录 CVE 于 9 月 8 日发布。
- 双方对利用条件说法不一:Enclave 称除 broker 在场且有已登录工作账号外无需任何用户交互(「没有弹窗,没有警告」);微软通过 The Hacker News 表示利用还需受害者完成一次登录步骤,并称未发现实际攻击。
背景
Authenticator 这类应用在微软的体系里叫「broker」:装在手机上之后,Outlook、Teams 等一方案应用需要登录令牌时不各自找微软的服务器要,而是向 broker 发请求,由它统一签发。这个设计本身是把安全收拢到一处,代价也在这——broker 一旦被冒充,整组应用的令牌都经它之手。 Levin 的测试对象正是这套机制:他写的恶意应用分别冒充 Teams、Teams 聊天后端和 Authenticator 自己,三种角色都拿到了本不该拿的 token。
站里之前写过两件相关的事。一是假日历邀请钓鱼,那轮活动的载体是合法的 .ics 日历数据,不碰任何软件漏洞,骗的是人;CVE-2026-80097 反过来,骗的是应用之间的信任,凭证交出时用户按理说毫不知情。二是passkeys 不是陷阱里对 attestation 的讨论——「谁能证明调用者真的是它声称的那个应用」正是同一个问题在另一层的模样。
事实部分
攻击链的关键在组件的校验逻辑。AccountChooserActivity 在manifest 里声明为 android:exported="true",任何应用都能调起它;它对调用方的「防伪」只有两条:getCallingActivity() 不为空(任何用 startActivityForResult 的应用都满足),以及把请求里 redirect_uri 和「声称方」安装包签名推导出的重定向 URI 做比对。问题在「声称方」本身来自调用者传入的 intent extra——包括一个伪造的 caller.info.uid 和一份 broker_request_v2 JSON(内含 client_id、redirect_uri、scopes 等字段)。冒充一个真装在手机上的一方应用(比如 Teams,client ID 1fec8e78-bce4-4aaf-ab1b-5451cc387264),用它的 SHA1 签名构造出合法的 msauth:// 重定向 URI,校验就永远通过。真实的调用者包名其实可以通过 getCallingActivity().getPackageName() 拿到,但代码只用它做了记录。最后 token(access、refresh、ID token 及 client_info)通过 setResult 明文塞回结果 intent,恶意应用在 onActivityResult 里照单全收。
拿到 Teams 的身份能换到的 Microsoft Graph 权限包括 Mail.ReadWrite、Mail.Send、Files.ReadWrite.All、Calendars.ReadWrite、ChatMessage.Send、Sites.ReadWrite.All——Levin 的测试应用可以读写邮件、动文件、发 Teams 消息;冒充 Authenticator 自身则更进一步,拿到 UserAuthenticationMethod.ReadWrite 和 Passkey.Create、Passkey.Delete,也就是能改登录方式、增删 passkey。第三方安全媒体 CyberSecurityNews 称受影响版本为 6.2606.4246 之前、CVSS 8.6,与 NVD 记录一致;但该媒体称修复版「2026 年 7 月发布」,这一点只有它一家这么说,微软公告原文未写发布月份。
| 项目 | 内容 | 来源 |
|---|---|---|
| 编号与评分 | CVE-2026-80097,CVSS 8.6(AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H) | NVD,2026-09-08 发布 |
| 受影响 | Android 版 Authenticator < 6.2606.4246 | Enclave;CyberSecurityNews |
| 漏洞组件 | com.microsoft.identity.client.AccountChooserActivity(exported) | Enclave |
| 修复 | 6.2606.4246(Play 商店已上线) | 微软漏洞公告;Enclave |
| 前置条件 | 设备装有 Authenticator 且有已登录工作账号;双方对是否需用户操作说法不一 | Enclave;The Hacker News |
各方说法
对「利用到底需不需要用户参与」,两边说法对不上。Enclave 原文的表述是除 broker 在场且有已登录工作账号外无需交互,Help Net Security 10 月 27 日的报道写成「无声无息。没有弹窗,没有警告,什么也看不见」;CyberSecurityNews 同样写「无需用户批准」。The Hacker News 10 月 27 日则转述微软的说法:利用还需要受害者在 Authenticator 里完成一次登录步骤,且微软称未观察到该漏洞被实际利用。值得注意 CVSS 向量里的 UI:R(需要用户交互)是微软自己打的分。本稿无法核对 The Hacker News 全文(页面拒绝抓取),这一句引自其首页摘要,谁对谁错目前没有第三方裁决。
两家安全媒体的处置建议一致:Play 商店更新到 6.2606.4246 或更高,企业用 MDM/EMM 把最低版本盯住,限制侧载来路不明的 APK,并留意异常的 Graph 活动、陌生的 token 使用。Help Net Security 补了一句研究背景:Levin 通过 Enclave 的 fellowship 项目做这项研究,走的是负责任披露。
编辑判断
时间差是这条新闻真正值得记的地方:CVE 在 9 月 8 日就挂上了编号,修复版也早已推送到 Play 商店,但「漏洞怎么被利用」的完整技术细节直到 10 月 23 日才公开。微软没有发布单独公告、没有 CVE 页之外的说明,按 The Hacker News 转述它连利用条件都和研究者各执一词——这件事在 10 月底进入公共视野,靠的全是研究者一方的博客。
给读者一个一分钟的动作项:安卓手机打开 Play 商店,搜 Microsoft Authenticator,版本号 ≥ 6.2606.4246 就没事,低于它就更新;管设备的企业把它加进 MDM 的最低版本策略。不确定的地方也说清楚:「9 月已修」意味着过去一个多月里没升级的设备一直暴露在可复现的攻击路径下,至于这段时间有没有真实利用,目前只有微软一家的「未观察到」。另外 Help Net Security 提到的 passkey 增删权限说明这类漏洞的后续风险不止读邮件——身份验证方式本身可以被改,这也是 Enclave 选择公开细节想让行业看到的攻击面。