🔐 Device Code Phishing:为什么“官方登录码”也能被钓鱼

很多人对钓鱼的直觉还停留在“假登录页骗密码”,但现在更危险的一类攻击,恰恰不需要你把密码输进假网站。它利用的是 OAuth 2.0 Device Authorization Grant,也就是很多电视、游戏机、CLI 工具常见的“请在另一台设备输入 8 位验证码完成登录”。这套流程本来是给“输入能力差的设备”准备的,设计上没问题,问题出在攻击者可以把“真实平台生成的合法验证码”拿来骗你替他授权。

事情为什么会发生?因为用户看到的是正确域名、正确登录页、正确验证码,整套交互都像真的。攻击者先在目标平台上发起一次 device flow,拿到一个 user_code,然后把这个码通过邮件、IM、假工单、假客服消息发给你,说“你的账户异常,请立刻输入此验证码验证身份”。你一旦真的在官方页面输入并登录,平台会认为“这次授权已经得到用户同意”,接下来访问令牌会发给谁?不是发给你,而是发给最初发起 device flow 的那个客户端,也就是攻击者控制的程序。

这类攻击最麻烦的地方就在于,它不靠伪造页面,不靠键盘记录,甚至能绕过一部分“只认官方域名”的安全习惯。用户完成的是一次“真授权”,只是授权对象被偷换了。现实里它常见在 Microsoft 365、GitHub、云平台 CLI、企业 SSO 和各种支持“代码登录”的 SaaS 服务里,尤其适合被用在社工攻击里,因为它比“给我密码”更像正常操作。

防它不能只喊“别乱点链接”,那太空。关键是让用户在授权最后一步看清“你正在授权给谁”。如果页面显示的是陌生应用名、可疑权限范围,或者请求的是长期离线访问(offline_access)、读取邮箱、读取代码仓库、管理组织之类高权限,就该立刻停下。企业侧更实际的做法是限制 device flow 的适用范围,只允许受信客户端使用,给高风险 OAuth 授权加条件访问策略,监控异常的新应用同意记录,还要尽量关闭普通用户对第三方应用的自由授权能力。很多团队的坑在这里:MFA 做了,反钓鱼培训也做了,但 OAuth 同意界面没人管,于是账户还是被拿走。

🧪 你在公司 IM 里收到一条“IT 支持”消息:由于邮箱系统升级,请你访问 microsoft.com/devicelogin 并输入代码 F7K9-L2Q 完成验证。页面域名正确,登录后也没有报错。这个操作最核心的风险点是什么?


💡 核心记忆:看到“官方验证码登录”别只看网址,对安全来说更重要的是“我到底在授权给哪个应用、给了什么权限”。

#Security