两因素身份验证测试和可能的解决方法



甚至在我开始理解复杂的信息安全科学之前,在我看来2FA身份验证是一种保护您的帐户的有保证的方法,而且“这些黑客”无法抽出我的本国货币来购买游戏帐户中角色的衣服。 但是随着时间的流逝,已经通过实验证明了两因素身份验证系统可能具有大量漏洞。

简而言之,两因素身份验证通过输入生成的代码以提高安全性,并在移动过程中或移动开始之前,将有条件的黑客扔入条件黑客的行列中,从而对操作进行确认。

代码确认系统非常广泛,它在各个站点上的任何地方都可以使用,并且可以连接为主次登录。 但是,应用程序不限于此-开发人员在密码恢复,注册/订阅确认,金融交易的其他确认,密码更改,个人数据更改的功能上附加确认。 同样,有时会在注销后将2FA用作隔离墙,而不是使用密码或其他确认方式。

在本文中,我收集了测试2FA的漏洞,漏洞利用方法以及规避针对某些类型攻击的现有保护的可能选择的方法。 让我们看一下适用于2FA的漏洞检查列表:

1.缺乏限速


速率限制算法用于测试是否可以限制用户会话(或IP地址)的尝试次数或速度,以及这种情况在什么情况下发生。 如果用户在一定时间内完成了太多请求,则Web应用程序可以使用429代码(许多请求)进行响应或应用速率限制而不会显示错误。 没有速率限制意味着在正常枚举期间对尝试次数和/或速度没有任何限制-允许在会话/令牌有效期内对代码进行任意次数(以任何速度)迭代。

通常,您必须处理“无噪音”的速率限制,如果您看到没有错误并且后续请求中的HTTP正文/代码没有更改,则应该过早地满意,首先,您需要使用有效的代码检查攻击的最终结果。

2.速率限制已存在,但可以规避


我之前必须遇到的案例:

1)达到一定速度后限制流动速度而无阻塞


安全研究人员通常会尝试使用5个或更多线程来拾取代码,以加快攻击速度(在Burp Intruder中,默认线程数为5,没有延迟)。 但是有时候,破坏或常规负载均衡器提供的安全系统只能响应这一单个因素。 如果尝试使用5个线程进行暴力破解,则应将数量减少为1,然后减少为1,并延迟一秒钟。 早些时候,我很幸运地观察到了这种行为,并且正是在这种操纵的帮助下,成功地选择了代码,这才导致了帐户接管。 如果2FA代码没有特定的到期日期,那么我们有很多时间来进行排序。 如果存在有效期,则会降低攻击的成功率,但仍然存在漏洞的潜在危险,因为仍然有进入所需代码的机会。

2)生成的OTP代码不变


这不适用于不断变化的代码(例如Google Authenticator中的代码),而仅适用于通过短信,电子邮件或通过Messenger亲自发送的静态代码。

这种绕过的本质是,相同的OTP代码会不断发送或持续发送一段时间,例如5分钟,在整个这段时间内都是有效的。 确保没有静音速率限制发生也是值得的。

报告示例: hackerone.com/reports/420163

假设应用程序生成了一个从001到999的随机代码,并将其发送到手机,在启用“再次发送”功能的10分钟内,我们得到了相同的代码。 但是速率限制绑定到请求,这限制了每个请求令牌的尝试次数。 我们可以不断地请求新代码,生成新的请求令牌,将其应用于后续请求(使用burp套件中的grep-match或使用我们自己的脚本),并执行从001到999范围内的数字的暴力破解。因此,不断地使用新的请求令牌我们将成功选择正确的代码,因为该代码在一段时间内不会改变并且是静态的。 这种攻击的局限性是长数字或字母与数字混合作为确认代码。

这种情况不应该被鼓励,您应该尝试对列表的至少一部分进行排序,因为所生成的代码可能是在列表的此部分中,因为它是随机生成的。 尝试时,您需要依靠随机性,但是仍然有机会进入正确的组合,这证明了确实需要修复的漏洞。

3)更新代码时重设速率限制-a。


在代码验证请求中,存在速率限制,但是在激活了重新发送代码的功能后,将其重置并允许您继续使用蛮力代码。
报告示例:

https://hackerone.com/reports/149598,-理论;
hackerone.com/reports/205000 ,基于先前报告的动手利用。

4)通过更改IP地址来绕过速率限制


许多锁定都是基于从IP接收请求的限制,在执行请求时,该限制已达到一定尝试次数的阈值。 如果更改了IP地址,则有机会规避此限制。 为了检查此方法,只需使用代理服务器/ VPN更改IP,然后查看阻止是否取决于IP。

更改IP的方法:

  • 可以使用针对Burp Suite github.com/RhinoSecurityLabs/IPRotate_Burp_Extension的IP Rotator插件在攻击中使用代理。 在我看来,这是最佳选择,因为它为我们提供了无限的暴力破解尝试和IP地址,可让您执行暴力攻击而不会出现42x错误和中断。
  • 一个不错的选择可能是带有代理请求模块的python脚本,但是首先您需要在某处获取大量有效代理。

由于IP轮换工具使用AWS IP地址发送请求,因此如果Web应用程序位于CloudFlare防火墙之后,所有请求都将被阻止。



在这种情况下,您需要另外发现原始Web服务器的IP或找到与AWS IP地址无关的方法。

5)该站点包括对X-Forwarded-For的支持


内置的X-Forwarded-For标头可用于更改IP。 如果应用程序对此标头进行了内置处理,则只需发送X-Forwarded-For:required_IP即可替换IP以绕过该限制,而无需使用其他代理。 每次从X-Forwarded-For发送请求时,Web服务器都会认为我们的IP地址与通过标头传输的值匹配。
关于此主题的材料:
hackerone.com/reports/225897
medium.com/@arbazhussain/通过欺骗起源ip-ff06adf34157绕过速率限制保护

3.通过替换另一帐户会话中的部分请求来绕过2fa


如果发送了具有特定值的参数以验证请求中的代码,请尝试将值从请求发送到另一个帐户。

例如,在发送OTP代码时,将检查与发送代码相关联的表单ID,用户ID或cookie。 如果我们将要绕过代码验证的帐户(帐户1)的参数中的数据应用于完全不同的帐户(帐户2)的会话中,我们将获取代码并将其输入到第二个帐户中,然后可以绕过第一个帐户的保护。 重新加载页面2FA后应该会消失。

4.使用“记忆功能”绕过2FA


许多支持2FA授权的站点都具有“记住我”功能。 当用户不想在后续登录中输入2FA代码时,此功能很有用。 确定“记住” 2FA的方式很重要。 这可以是Cookie,会话/本地存储中的值,也可以只是将2FA附加到IP地址。

1)如果使用cookie附加了2FA,则cookie值必须不可猜测


也就是说,如果cookie由一组数字组成,每个数字都会增加,那么很有可能对cookie值施加暴力攻击并绕过2FA。 开发人员应为cookie(以及关键会话cookie和CSRF令牌)提供HttpOnly属性,以便它不能使用XSS窃取并用于绕过2FA。

2)如果2FA连接到IP地址,则可以尝试替换它


要确定此方法,请使用2FA存储功能登录到您的帐户,然后切换到其他浏览器或当前浏览器的隐身模式,然后再次尝试登录。 如果根本不要求2FA,则2FA已附加到IP地址。
要替换IP地址,如果Web应用程序支持,则可以在输入登录名和密码的阶段使用X-Forwarded-For标头。

如果帐户设置中存在IP地址白名单功能,您也可以使用此标头绕过IP地址白名单功能。 它可以与2FA结合使用,以提供额外的帐户保护,或者如果IP地址与白名单匹配(在用户同意下),甚至可能不会要求2FA。 因此,即使在没有将2FA附加到IP地址的情况下,在某些情况下也可以通过规避关联的保护方法来规避2FA。
通常,将2FA附加到IP地址并不是完全安全的保护方法,因为当您位于同一网络中时,如果使用静态IP地址连接到同一VPN / Internet服务提供商,则可以绕过2FA。

保护自己的最安全的方法是完全不记住2FA,以免影响可用性。

5. 2FA输入页面上的访问控制错误


有时,用于输入2FA的对话框页面会显示为带有参数的URL。 使用URL中的参数所包含的cookie与用于生成该页面的cookie不匹配或完全没有cookie来访问此类页面是不安全的。 但是,如果开发人员决定接受风险,那么您需要经历几个重要点:

  1. 2FA输入的链接是否过期?
  2. 链接是否在搜索引擎中被索引。

如果链接寿命长和/或搜索引擎包含2FA输入的有效链接/可以为链接建立索引(robots.txt /元标记中没有规则),则可以在2FA输入页面上使用2FA旁路机制,其中完全绕过登录名和密码,并可以访问其他人的帐户。

6.第2FA页上的个人数据检查不足


在页面上发送OTP代码时,检查制度用于保护个人数据,例如电子邮件,电话号码,昵称等。 但是,这些数据可以在API端点和我们在2FA阶段拥有足够权限的其他请求中完全公开。 例如,如果最初不知道此数据,例如,我们仅输入了登录名却不知道电话号码,则将其视为“信息泄露”漏洞。 知道电话号码/电子邮件可用于后续的网络钓鱼和暴力攻击。

使用凭据填充利用漏洞的示例。 假设有一个公共域中的数据库,其中包含站点A的登录名和密码。攻击者可以在站点B上使用该数据库中的数据:

  • 首先,他们在注册/恢复密码时使用“帐户枚举”错误检查用户是否存在于站点B数据库中。 通常,许多站点不会将其视为漏洞,并且会冒险。 “漏洞”在于用户在网站上注册的事实存在错误。 理想情况下,密码恢复页面上的安全消息如下:



  • 在获得现有用户的数据库后,攻击者将密码应用于这些帐户。
  • 如果遇到2FA,则会卡住。 但是,如果对用户数据的检查不够充分,他们可以为其数据库补充其个人数据(如果它们不在原始数据库中)。

7.在某些情况下忽略2FA


当执行某些操作导致自动登录到您的帐户时,可能不会要求2FA。

1)恢复密码时忽略2FA


完成密码恢复过程后,许多服务会自动登录到您的帐户。 由于可以立即访问该帐户,因此,当您登录2FA帐户时,可以忽略它,也可以完全忽略它。

我最近发送的类似黑客报告的影响:
如果攻击者可以访问受害者的电子邮件(他可以使用网络钓鱼,暴力攻击,凭据填充等方式入侵帐户),则可以绕过2FA,尽管在这种情况下2FA应该可以保护帐户。 目前,对于2FA,您需要验证Google Authenticator代码或备用代码,但不能验证电子邮件中的代码,因此这种绕过是有意义的。

2)通过社交网络登录时忽略2FA


您可以将社交网络附加到您的用户帐户,以快速登录到您的帐户,同时设置2FA。 通过社交网络登录帐户时,可以忽略2FA。 如果受害者的电子邮件被黑客入侵,则可以恢复社交网络帐户的密码(如果允许)并输入服务,而无需输入2FA。

其中一份报告的影响:
  1. 还有许多其他漏洞,例如先前发送的OAuth错误配置#577468,可以完全捕获该帐户,从而破坏了2FA。
  2. 如果攻击者入侵了用户的电子邮件,则他可以尝试重新获得对社交网络帐户的访问权限并登录该帐户,而无需进行其他验证。
  3. 如果攻击者曾经入侵受害者的帐户,则他可以将社交网络与该帐户相关联,以后再登录该帐户,而完全忽略2FA并输入登录名/密码。

3)在较旧版本的应用程序中忽略2FA


开发人员经常将Web应用程序的暂存版本添加到域/子域中,以测试某些功能。 有趣的是,如果您使用用户名和密码登录,将不会请求2FA。 也许开发人员正在使用较旧的应用程序版本,其中没有针对2FA的保护,或者禁用2FA本身,或者故意将其禁用以进行测试。

另外,您可以同时检查其他漏洞,-在生产版本数据库中存在其电子邮件的登台服务器上注册新用户可以为我们提供生产中的个人数据; 重要功能(例如密码恢复)中没有速率限制。 最新漏洞的一个例子是一个价值15,000美元的Facebook错误,该漏洞允许在beta.facebook.com www.freecodecamp.org/news/responsible-disclosure-how-i-could-have-hacked-all- facebook-accounts-f47c0252ae4d

4)在跨平台的情况下忽略2FA


移动或台式机版本的2FA实施可能与应用程序的Web版本不同。 2FA可能比网络版本弱或完全不存在。

7.禁用2FA时,不需要当前代码。

如果在禁用2FA时不要求其他确认,例如google authenticator应用程序中的当前代码,电子邮件/电话中的代码,则在这种情况下存在一定的风险。 发出干净请求后,就有可能遭受CSRF攻击。 如果找到CSRF保护的旁路矢量(如果有),则可以禁用2FA。 也可以使用点击劫持漏洞-毫无疑问的用户单击几次后,2FA将断开连接。 鉴于潜在的CSRF / XSS / Clickjacking攻击以及CORS错误配置,对先前代码的验证将添加额外的2FA保护。

我以hackerone.com为例,-当您以一种形式关闭2FA时,您需要同时输入两个变量,-使用Google Authenticator应用程序和密码的当前代码。 这是最好的建议保护措施。



8.先前创建的会话在2FA激活后仍然有效


启用2FA时,最好在同一帐户末端显示并行会话,并显示2FA输入对话框,但同时更改密码。 如果帐户已被盗用,并且受害者的第一反应是将2FA包括在内,则攻击者的会话将被禁用,下一次登录和密码将要求2FA。 总而言之,这是要遵循的最佳实践。 我经常注意到加密货币交易所如何增加类似的保护。 HackerOne报告示例,-
https://hackerone.com/reports/534450。

9.您的帐户中没有利率限制


2FA可以在用户个人帐户的各种功能中实现,以提高安全性。 这可以是电子邮件地址,密码的更改,金融交易代码更改的确认等。 输入帐户后,您帐户中的rate-a可能与2FA中存在rate-a的情况有所不同。 我经常遇到类似的情况,可以在我的帐户中自由选择2FA代码,而在入口处设置了“严格”​​限速。

如果开发人员最初添加了防止未经授权的数据更改的保护,则必须通过所有可能的旁路来支持和纠正此保护。 如果找到旁路,则将其视为由开发人员实施的安全功能旁路漏洞。

10. API版本控制


如果您在网络应用程序的请求中看到类似/ v * /的信息,其中*是数字,则可能是您可以切换到API的旧版本了。 API . , API production/staging .
, /endpoint/api/v4/login , . 2FA , /endpoint/api/v4/2fa_check, . API 2FA, , , . /endpoint/api/v3/login /endpoint/v3/login_successful?code=RANDOM, 2fa_check , API, 2FA .

, — /endpoint/api/v4/2fa_check rate-limit, /endpoint/api/v3/2fa_check - .

11. Improper Access Control


2FA . ( ). CORS /XSS , «» , 2FA, .

, 2 , , , 2FA web , — . , 2FA ( Salesforce, Valve) 2FA. 2FA , 2FA bypass-.

, , bug bounty , , . Stay safe!

Source: https://habr.com/ru/post/zh-CN483134/


All Articles