前言

这篇文章是关于我在私人渗透测试期间在多个网站上观察到的帐户接管漏洞。
在进行Web应用程序测试时,我一直在寻找更新电子邮件或密码更新部分以及密码重置功能。由于此功能对于可能导致帐户接管的关键漏洞至关重要。由于私有项目和bug的重要性,不可能透露项目的名称。因此,我们将以示例[id] .com来理解目的。

事例1 #Business Logic错误,可以临时访问受害者的帐户,从而导致永久性的帐户接管。

说明:

应用程序的密码更改和电子邮件功能允许任何用户更改或重置其密码并更新电子邮件,无需管理员干预。当电子邮件更改时,应用程序应提示输入密码,但在我们的情况下,由于逻辑失败,它从未这样做过。
因此,即使在帐户恢复后,影响攻击者也可以持久访问完整帐户并重置用户密码。

场景:

让我们假设无辜的朋友:rgmail@mail.mysite。
1)攻击者朋友1:rotlu@my.site。
2)黑客:hacker@lo.com。
3)网址:https://example1.com/profile

重现步骤:

注意:临时需要物理访问。

  • 假设用户使用电子邮件rgmail@mail.mysite登录帐户并忘记注销,甚至忘记打开计算机,您可以在物理上访问它。

    用户登录页面

  • 恶意的朋友/黑客利用这个机会并更改电子邮件。

  • 点击编辑电子邮件,恶意朋友 从他的电子邮件中更新无辜的朋友电子邮件,即rotlu@my.site并对其进行分析。
  • 恶意的朋友再次将电子邮件恢复为原始电子邮件,即从他的电子邮件rotlu@my.site回复到他无辜的朋友的电子邮件rgmail@mail.mysite。
  • 在那之后,他们让计算机在物理上打开,另一个黑客进入图片。


恶意朋友更新了电子邮件并恢复为用户的电子邮件

这是有趣的部分!

  • 现在,黑客获得了物理访问权限并将电子邮件更改为他的电子邮件,即hacker@lo.com。

    黑客更新了他的电子邮件并将其还原

  • 电子邮件并再次将电子邮件更改为用户的原始电子邮件地址,即rgmail@mail.mysite。

  • 从hacker@lo.com到rgmail@mail.mysite然后将其恢复原状,以便用户无法知道发生的任何事情。Tadaa!该帐户被永久黑客入侵。

让我分解一下。这是这里的错误。我正在检查应用程序是否发送任何邮件或令牌以验证帐户中的更改。但它根本没有发生。然后我开始测试密码重置。

现在点击密码重置并输入攻击者电子邮件,即hacker@lo.com。
黑客在hacker@lo.com上收到密码重置链接。但此帐户与任何帐户均无关联。
点击密码重置并更改密码,但在这里我们仍然不知道谁更改了密码。

没有电子邮件注册或关联的黑客的密码重置页面

现在尝试使用黑客电子邮件ID和更新密码登录
查看配置文件中的电子邮件,它是用户原始电子邮件,即rgmail@mail.mysite。之后,如果rotlu@my.site尝试使用密码重置登录,它也可以登录到rgmail@mail.mysite。

在测试密码重置时,我一直在寻找已注册和未注册的电子邮件的成功和失败的响应。但对于任何已注册或更改的用户,其使用编辑电子邮件功能的电子邮件都能够获取密码重置链接并更改保存或编辑电子邮件的帐户的密码,甚至一次。

恶意朋友试图登录虽然他的电子邮件没有注册,但保存一次到受害者/用户的个人资料

所以基本上发生的事情是我们有三个帐户,一个是rgmail@mail.mysite的用户。另一个第二个帐户,即rotlu@my.site,这是一个恶意的朋友和hacker@lo.com,这是黑客。所以首先rotlu更改了电子邮件并保存了它的电子邮件,然后再将其恢复为用户原始电子邮件。
然后另一个第三帐户黑客将用户的原始电子邮件更改为他的电子邮件,然后将其还原回用户原始电子邮件。
因此,一个朋友和其他黑客的两个恶意实体总共将电子邮件更改为他们的电子邮件,然后将其还原回用户的原始电子邮件。因此,由于业务逻辑失败,所有三个人都能够通过配置文件中的电子邮件登录到一个帐户,这是一个普通的用户rgmail。

当攻击者保存他的电子邮件时,它被保存在数据库中并与用户的id映射。但是一旦它再次变回用户,应用程序没有将其从数据库中删除,现在一个用户ID被映射到两个电子邮件,或者在我们的情况下可以是多个电子邮件三个(我之后检查过)。
由于它是永久存储的,因此即使用户通过密码重置恢复帐户,也可以再次入侵,因为任何人都可以在将电子邮件保存到配置文件中然后将其更改回原始密码后重置密码。另一个失败是黑客使用他的电子邮件登录到其他人的帐户,在配置文件中设置了不同的电子邮件,在我们的例子中是rgmail。

事例二#不当的密码更新字段中的身份验证可能导致永久帐户接管。

在网站上,https://example2.com/ 有一个密码重置功能,可以将密码重置链接发送到用户的电子邮件。通过拦截请求然后更改电子邮件地址可以允许攻击者重置另一个电子邮件的密码,从而允许他获得对其他用户帐户的完全访问权限。

场景:

1)攻击者从重置页面请求重置密码,并在其电子邮件中获取密码重置链接。
2)通过使用Web代理,他尝试重置密码,但能够将自己的电子邮件修改为另一个用户的电子邮件,密码重置将用于重置另一个电子邮件的密码。
3)完成。

重现步骤:

  • 任何注册用户点击更新密码后。
  • 用户需要输入旧密码和新密码以及确认密码。
  • 拦截对/ user / systemuser的POST请求。

  • 向burp intruder发送请求并选择攻击类型作为集束炸弹。这里我第一次使用集束炸弹,因为需要枚举两个参数。
  • 在集群炸弹中添加old_password和userid参数作为payload1和payload2。

  • 对于old_password,选择任何单词列表或自定义单词列表,并选择4位数字上的用户ID集范围。
  • 还可以枚举有效的用户ID,然后使用它们来强制执行old_password字段。
  • 当入侵者同时命中old_password和user_id时,它将达到200 OK并且响应长度也会改变。


userid和旧密码强制执行后成功

  • 由于不存在速率限制,因此很容易将线程增加到100并加速该过程。

密码重置API中的事例3 #不当的身份验证可能导致永久帐户接管。

密码恢复功能可能导致用户名枚举,敏感信息泄露和密码重置漏洞。
攻击者请求重置密码并在其电子邮件中获取有效密码重置链接。通过拦截,攻击者可以使用密码重置令牌并将自己的电子邮件修改为受害者的电子邮件,并且相同的密码重置将用于受害者而不是攻击者。

场景:

1)让我们假设用户:user@gmail.com
2)ABC黑客:abc@gmail.com
3)网址:https://example3.com/password_reset/forgot.html

重现步骤:

  • 攻击者访问网站并注册他的帐户。
  • 现在在密码重置中,他输入了他的电子邮件。
  • 重置链接被发送到黑客邮箱,他访问该链接。
  • 他登陆https://example3.com/password_reset/forgot。html 并输入新密码并在代理拦截时确认密码。
  • 然后黑客在请求中修改受害者电子邮件的电子邮件并提交。
  • 提交请求后,密码已成功更改为受害者帐户的黑客所需密码。


将电子邮件从攻击者更改为受害者

这是在各种易受攻击的Web应用程序中发现的最通用的场景。这将导致完整的帐户接管。

配置文件中密码更新字段中的事例4 #Broken访问控制可能导致帐户接管。

在重置密码时,访问控制没有到位,所以我尝试重置密码,但它需要关键的auth参数,用于验证和更新每个用户的密码。

但是由于访问控制中断,这个问题得以解决,很容易获取持有auth参数的用户详细信息,这是用于创建JWT令牌,cookie和登录后收到的其他关键字段的十六进制用户ID。
此auth参数在PATCH中与新密码一起发送,没有这个密码就无法重置密码,当输入错误的auth参数时,它显示错误:userid的重复键:xxxx存在。

场景:

1)API:https://example4.com/api/users/idxxx
2)受害者用户ID:9991
3)攻击者用户名:7777

重现步骤:

第1部分

  • 使用授权标头将获取请求发送到GET / api / users / 7777。
  • 拦截对/ api / users的API请求,并将userid更改为受害者的用户ID,即9991。
  • 复制密码更新中需要的auth参数。


由于访问控制中断,请求获取用户数据

第2部分

  • 登录任意帐户。
  • 转到配置文件设置
  • 输入新密码和确认密码
  • 通过设置新密码提交并拦截请求。
  • 我们可以看到我们有PATCH请求而不是POST / PUT ,用于部分修改。
  • 将userid更改为受害者的用户ID并将请求体中的auth参数从攻击者的auth参数更改为受害者的auth参数。
  • 发送请求并检查响应是否成功。


添加有效的auth参数后重置成功密码

除此之外,JWT令牌被伪造为通过API调用获取有效的用户数据,从而使此攻击成功。

修复:

  1. 所有以前的密码重置链接应在用户更改其电子邮件地址后自动过期。
  2. 除了在个人资料中添加的电子邮件之外,甚至不允许用户使用任何其他电子邮件登录。
  3. 缓解重置漏洞的方法是进行一些强加密。发送加密的令牌并将其与特定用户绑定。
  4. 不要在JWT令牌中包含关键令牌参数,例如auth id,或者在访问控制中断的情况下轻松获取用户数据。
  5. 在多个地方,使用了JWT令牌,但很容易使用无算法伪造
  6. Csrf令牌存在多次可用于重置密码,因为它与会话绑定。因此,一个令牌可用于更改多个帐户的密码。因此,此令牌应为有状态(同步器令牌模式)或无状态(基于加密/散列的令牌模式)。
  7. 始终提供速率限制,以便用户ID枚举和暴力强制不会发生。

参考:

本文为翻译文章,来自:https://medium.com/@justm0rph3u5/tale-of-account-takeover-in-multiple-website-5d6e5e4eda04

点击收藏 | 0 关注 | 1
  • 动动手指,沙发就是你的了!
登录 后跟帖