绕过不安全双重身份验证 (2-FA) 实施的 7 种方法

双因素身份验证 (2FA) 已成为增强账户安全的首选解决方案。越来越多的公司正在部署 2FA，有些公司甚至强制用户使用，以保护账户安全，防止未经授权的访问。但如果 2FA 未能正确实施会怎样？本文将探讨 7 种绕过 2FA 的方法，包括一些高级漏洞利用方法！

什么是双因素身份验证 (2FA)？

2FA（双因素身份验证，也称为多因素身份验证或MFA）是一种安全方法，要求用户在登录帐户时提供两种或更多种不同类型的证明来验证其身份。

传统上，网站使用电子邮件和密码的组合来验证用户身份并确认其访问权限。然而，弱密码或不安全的身份验证实现通常会降低应用程序整体安全性。

2FA 是一种额外的身份验证方法，它基于用户必须拥有并提供的临时凭证，用户无法凭空记住。这种方法更加安全，因为额外的安全层可以防止恶意行为者未经授权访问他人的用户帐户。

2FA 实施示例

什么是 2FA 漏洞？

遗憾的是，并非所有双重身份验证 (2FA) 都按照安全标准和最佳实践正确实施。有些实施方案可以被完全绕过，这使其再次容易出现身份验证漏洞。这主要是因为公司会自行部署 2FA 实施方案，而其他公司则倾向于依赖第三方服务。当进行额外修改或忽视安全最佳实践时，各种 2FA 漏洞都可能出现，从而允许任何人绕过任何强制性的多因素身份验证。

识别2FA漏洞

当 2FA 实现薄弱（例如可预测的令牌）或开发不足（逻辑错误）时，就会出现 2FA 漏洞。我们还可以采用其他间接方式绕过 2FA（例如，CSRF 或 IDOR 漏洞）。

下面，我们将探讨如何利用 2FA 漏洞并利用其不安全实现中存在的任何逻辑缺陷的几种方法。

利用基本的 2FA 漏洞

强制浏览

某些双因素身份验证 (2FA) 实现无法将验证令牌与当前会话状态关联。实际情况下，情况如下：

1. 用户登录他的账户
2. 用户的会话状态现在设置为“已验证”
3. 然后，用户将被重定向到多因素身份验证页面，在该页面中他/她需要提供 2FA 令牌。

这种实现方法存在缺陷，因为任何攻击者都可以跳过第三步，仍然获得帐户访问权限。恶意用户只需尝试请求其他只有经过身份验证的用户才能访问的页面（例如个人资料页面），即可获得访问权限，而无需提供 2FA 令牌。

暴力破解

缺乏速率限制，加上可预测和/或较短的令牌，使得任何双因素身份验证 (2FA) 实现都容易受到暴力破解攻击。某些应用程序使用 4 个字符的 2FA 令牌，没有设置速率限制，并且在令牌过期前留出足够的时间。这些错误配置可以帮助我们使用 BurpSuite 或 ZAProxy 等自动化工具猜测唯一令牌，从而完全绕过 2FA！

使用 Burpsuite 进行暴力破解的示例

弱的2FA令牌

绕过 2FA 实现的另一种简单方法是检查令牌并检查：

• 您可以重复使用相同的旧令牌，或者根本不提供任何令牌
• 您可以重复使用任何备份令牌
• 令牌与会话无关
• 令牌位于 HTTP 响应中暴露的任何位置
• 任何用于测试和开发目的的令牌（例如“0000”或“123456”）在生产中仍可接受

检查您之前使用的令牌在第二次登录时是否仍然有效。双重身份验证令牌应该是临时的，并且仅在固定期限内有效。令牌在首次使用后也必须过期。

备用双因素身份验证令牌也需遵循相同规则。此外，还需测试是否存在逻辑错误，例如在未提供令牌的情况下跳过双因素身份验证。请尝试发送不带令牌的请求，甚至不带参数的请求。

如果双因素身份验证 (2FA) 未与您的会话绑定，则很可能意味着它已保存在数据库中已接受令牌的集合下。这种方法存在缺陷，攻击者可以利用您的双因素身份验证 (2FA) 令牌解锁其他帐户。

测试此极端情况的最佳方法是设置两个测试账户。使用第一个账户登录并保存 2FA 令牌，然后使用第二个令牌登录，并使用你从第一个测试账户保存的 2FA 令牌。

某些应用程序设计为在客户端验证 2FA 令牌，为此，需要有效的 2FA 令牌。检查 HTTP 响应，并检查令牌是否反映在 HTTP Cookie 或隐藏的输入字段参数中。

开发人员在开发过程中通常会使用静态 2FA 令牌，以避免每次登录时都必须输入唯一的 2FA 令牌。但是，如果这些令牌也在生产环境中被接受，它们可以帮助您完全绕过 2FA 实施。

我们建议尝试常见的 2FA 测试令牌，例如“0000”、“1111”甚至“123456”，具体取决于应用程序接受的令牌格式和类型。

利用高级 2FA 漏洞

现在我们已经介绍了最简单的绕过方法，让我们深入研究更高级的方法。

跨站请求伪造（CSRF）

跨站请求伪造（甚至点击劫持）也可以通过编写一个可以禁用双因素身份验证的概念证明 (POC) 来绕过双因素身份验证 (2FA)。这种攻击方式需要最终用户的操作，因此您必须确保：

1. CSRF 是可能的（阅读我们关于利用 CSRF 漏洞的详细文章以获取更多信息）
2. 负责禁用 2FA 的端点不需要密码或任何其他唯一凭证

当这些条件适用时，就有可能绕过 2FA。

你能发现开发人员哪里犯了错误吗？

不安全的直接对象引用（IDOR）

如果负责禁用 2FA 的端点容易受到 IDOR 攻击，只要端点不需要之前的 2FA 令牌，我们也可以有效地禁用受害者的 2FA 并完全绕过此安全实施。

提示！有时，IDOR 漏洞的迹象会隐藏在 HTTP 请求中！每当您看到指向某个帐户的静态关键字（例如“current”）时，请尝试将其更改为您的用户 ID，然后重新发送请求！更多信息：

4️⃣ 使用静态关键字利用 IDOR 您可能之前在特定应用程序或 API 中见过它，它使用静态关键字来引用当前用户。在某些端点上，您可以轻松地将静态关键字与另一个用户 ID 交换并测试 IDOR！😎

密码重置

密码重置功能旨在帮助那些意外忘记密码且无法再次访问其帐户的用户。但是，在某些情况下，当用户请求新密码时，此功能也会自动禁用该特定帐户的双重身份验证 (2FA)。即使在设置新密码之前也可以执行此操作。

只需启动新的密码重置操作即可禁用 2FA，从而允许我们绕过多因素身份验证。

通过路径遍历绕过二阶 2FA

通过路径遍历绕过二阶双因素身份验证 (2FA) 的情况在复杂应用程序中非常罕见，通常是由于输入验证不足而导致的。该应用程序维护了一种存在缺陷的验证方法，允许我们绕过帐户的双因素身份验证 (2FA)。

让我们看一个易受攻击的代码片段的简单示例，以便更好地理解这种情况！

易受攻击的代码片段示例

如上图所示，该应用程序包含两个服务：后端 API 和内部验证 API。后端 API 会转发我们的 2FA 令牌，而不会对我们的输入执行任何类型的验证。此外，该 API 仅检查内部验证 API 返回的状态码是否为 200 OK。

这使我们能够发送带有路径遍历有效负载的 2FA，以成功绕过多因素身份验证：

1234/../../../../

实际上，它看起来如下所示：

HTTP 请求图

始终建议在测试中包含各种有效负载，因为您永远不知道底层代码如何使用或转换您的输入。

结论

2FA 绕过的影响不容忽视，我们始终建议对其进行测试，特别是针对具有关键资产或存储敏感信息的应用程序的目标。

原文始发于微信公众号（迪哥讲事）：绕过不安全双重身份验证 (2-FA) 实施的 7 种方法