MFA 疲劳与推送轰炸：当批准弹窗本身成为攻击
多因素认证在第二个因素要求一个深思熟虑的动作时才最有效。而推送批准弹窗要求的东西少得多：一次点击。MFA 疲劳攻击——也叫推送轰炸（push bombing）——利用的正是这个缺口。已经持有有效密码的攻击者反复触发登录尝试，用批准请求刷爆目标手机的屏幕，直到其中一条被接受——出于条件反射、出于厌烦，或者因为相信只要点了批准，弹窗就会停下来。
一次推送轰炸攻击是如何运作的
在安全团队记录过的案例中，套路是一致的。攻击者从别处窃取的凭据起步——批量出售的 infostealer 日志是常见来源——并确认密码仍然有效。然后反复尝试登录，在受害者已注册的设备上生成推送通知。每一条弹窗看起来都与合法的完全一样，而多年无害的日常批准早已训练许多用户几乎不假思索地点下批准。这类行动常常再加一层：一通电话或一条来自“IT 支持”的消息，指示目标接受这些弹窗好让它们停下。 从用户这一侧看，这种令人迷惑正是设计出来的。弹窗表现得好像登录是你自己发起的，但通知上没有任何东西证明是谁发起的。原则上弹窗是一项安全控制；实际上，它是你屏幕上的一条消息，任何持有你密码的人都能生成它，而且能一遍又一遍地生成，直到疲劳替他完成剩下的部分。把这样的弹窗当作不可信输入对待，正是这些攻击绕开的心理转变。Uber，2022 年 9 月：教科书式的案例
被引用最多的例子仍是 2022 年 9 月的 Uber 数据泄露。据 TechCrunch 报道，Uber 将这次入侵归因于一名隶属于 Lapsus$ 的黑客，并称一名外部承包商的公司密码可能是在暗网市场上购买的——据报道来自 RedLine 窃密型恶意软件的日志。只有密码并不够，因为账号要求第二重因素。攻击者触发推送弹窗超过一个小时，随后以 Uber IT 的身份通过 WhatsApp 联系这名承包商，告诉他只要接受通知就会停止。攻击者后来用一句话向 TechCrunch 概括了结果：And well, he accepted and I added my device.凭借那次批准，攻击者把自己的设备注册为 MFA 设备，并通过 VPN 进入 Uber 的内部网络。据 BleepingComputer 记录，访问迅速扩大：Uber 的 Slack 里出现了一条宣布被入侵的消息，攻击者抵达云控制台、Windows 域和公司的 HackerOne 工单，据报道在访问被切断前下载了私有的漏洞报告。在一个网络共享上，一段 PowerShell 脚本暴露了 Uber 特权访问平台的管理员凭据。TechCrunch 的报道还指出，据报道在最要紧的账户上并未启用 number matching。
Cisco：同一根杠杆，不同的用法
Cisco 的事件响应团队 Talos 在同一年记录了另一个平行案例。2022 年 5 月 24 日，Cisco 得知一起入侵，它始于一名员工的个人 Google 账户——保存在 Chrome 里的公司凭据同步到了那里。攻击者把冒充可信支持机构的语音钓鱼电话与反复的 MFA 推送请求结合起来，直到其中一条被接受，获得了 VPN 访问权。Talos 以中高置信度评估认为，该行为者是一名初始访问经纪商，与 UNC2447、Lapsus$ 以及 Yanluowang 勒索软件运营者相关联，并把活动描述为“勒索软件前置”模式：先拿访问权，之后再变现。两起事件，同一扇门：在压力下被批准的推送弹窗。Number matching 与缓解手段的阶梯
缓解手段是清楚的。CISA 的指导意见直截了当：“抗钓鱼 MFA 是所有行业领袖都应追求的标准，但任何 MFA 都好过没有 MFA。”该机构指出 FIDO/WebAuthn 认证是唯一广泛可得的抗钓鱼选项，在不可行之处则建议“采用 number matching 的 MFA，以阻断移动端推送轰炸”。此后 Microsoft 把 number matching 变成了标准行为，适用于 Authenticator 的推送通知：登录屏幕显示一个数字，批准时必须在应用中输入该数字。一条脱离上下文的弹窗没有数字可输——这正是该技术能击败盲点式批准的原因。- 把每一条意料之外的弹窗都当作不可信输入：拒绝它、上报它，并更换它所试探的那条密码。
- 优先选择要求刻意动作的因素——验证器生成的代码或硬件密钥——而不是点一下就批准的推送。
- 绝不要把工作或高价值凭据同步进个人浏览器配置文件；Cisco 那位攻击者正是从这里进来的。
- 把硬件安全密钥留给最重要的账户；据 TechCrunch 报道，在 Cloudflare 面对类似攻击时，正是硬件密钥挡住了攻击。