0x01 前言
近期在实战中遇到了多种经典的2FA绕过场景，涉及多个海外大厂，包括Web3领域的厂商。这些案例暴露了双因素认证（2FA）在实现上依然可能存在的薄弱环节。本文将通过具体实例，详细解析四种不同类型的2FA绕过漏洞。
0x02 2FA Bypass场景案例
一：第三方登录绕过
第一个是较为经典的场景，出现在Hackerone上一个Web3厂商的平台中。该漏洞表现为第三方登录绕过了2FA验证。在正常的账号密码登录流程中，输入凭证后系统会要求提供一次性密码（OTP）。
然而，该平台同时提供了第三方登录选项，允许用户直接通过Google账号进行认证。
通过Google账号登录后，可以顺利进入平台后台，整个过程完全跳过了OTP验证步骤。
二：授权检查缺失
在正确的流程中，服务器应在用户成功通过OTP验证后，才为会话Cookie或令牌授予“已登录”的完整权限。如果系统在验证OTP之前就提前发放了具备全部访问权限的认证令牌，攻击者便可利用此令牌直接访问后台数据，从而绕过2FA。
这个案例来自YesWeHack上的一个支付网关厂商。在输入账号密码后、进入OTP验证界面时，通过浏览器开发者工具观察网络请求，发现请求头中已经包含了一个授权（Authorization）令牌。
随后，直接使用这个尚未经过OTP验证的Auth Token去请求用户的敏感数据接口，发现请求成功。这证明了授权检查存在缺失，未经验证的令牌被错误地赋予了权限，导致了2FA被绕过。
三：令牌复用
一个设计良好的OTP令牌应具备两个关键特性：一次性使用和与特定操作上下文绑定。在此案例中，后端未能使已使用的令牌失效，导致了重放攻击。
该漏洞存在于Bugcrowd上的某银行厂商。在平台的“邀请用户”功能中，每次执行邀请操作都需要输入2FA验证码。
首先，通过正常流程将一个邮箱邀请为“Owner”角色，并在此过程中捕获了用于此次操作的HMAC令牌值。
该平台机制是：将邮箱添加为“User”角色需要一次2FA验证；若之后想将其权限提升为“Owner”，则需要再次进行2FA验证以获取新的HMAC值。
在捕获到第一次邀请（成为Owner）的令牌后，先正常操作将该邮箱添加为“User”角色。
接着，通过直接调用后台API，复用之前捕获的、本应已失效的HMAC令牌，尝试将该“User”角色的权限提升为“Owner”。操作成功，该用户的角色从“User”变更为“Owner”，实现了授权检查缺失导致的权限提升。
四：OTP重放攻击
OTP的设计本应基于时间窗口（TOTP）和单次使用性。如果一个OTP码在有效期内可以被重复使用来获取多个有效的认证令牌，那么就构成了OTP重放攻击。Hackerone上的一个电子钱包厂商存在此类问题。
初步分析，漏洞成因在于服务器端缺少对已使用OTP的记录机制。这使得OTP在过期前的一分钟内可以被无限次重复使用，时间校验过于宽松。
在正常登录流程中，输入账号密码后，服务器会返回一个loginToken，用于后续的OTP验证步骤。
随后，页面会跳转到要求输入验证码的界面。
假设我们通过某种方式（如预测、窃取）获得了当前有效的2FA验证码 218198。在获取到loginToken后，在一分钟的有效窗口内，重复使用同一个OTP码和loginToken向验证接口发起多次请求。结果发现，每次请求都成功返回了不同的、有效的authToken。
最后，使用这些通过重放攻击获取的大量authToken去访问用户个人信息接口，均能成功获取数据，证实了这些令牌的完全有效性。
0x03 总结
以上四个案例分别展示了第三方集成漏洞、授权逻辑缺陷、令牌生命周期管理不当以及OTP验证机制不严谨所导致的2FA绕过。这些漏洞常出现在复杂的业务逻辑和身份验证流程交织之处，对于从事安全/渗透/逆向测试的安全研究人员而言，深入理解业务、仔细审计每一步的权限校验和状态管理至关重要。希望这些实战分享能为大家在漏洞挖掘中提供新的思路。更多安全技术讨论，欢迎访问云栈社区。
发表于 4 天前
|
查看: 16|
回复: 0
