[$5K] Misconfigured Reset password that leads to Account Takeover (No user Interaction ATO)

[ $5K ]错误配置重置密码,导致帐户接管(无用户交互 ATO)

Hello Folks,

大家好,

I hope you are all keeping yourselves safe and healthy through this challenging time, Aditya here today I would like to share one of my findings that I came across on a public program on Hackerone which I expect is known by many of them here, so let’s begin.

我希望你们都能在这个充满挑战的时刻保持自己的安全和健康,Aditya 今天在这里我想分享一下我在 Hackerone 的一个公共项目上看到的一个发现,我想这里的很多人都知道,所以让我们开始吧。

Summary

摘要

I usually hunt on Hackerone and while hunting on it, one of the well-known public program grabbed my attention, nothing much about the target but it’s one of the leading online Adult Entertainment Platform so you can guess it ;)(They also have Private with a wide scope so I got invited for submitting this finding to their private program as the domain was out of scope in public program)

我通常在 Hackerone 上寻找,在寻找的过程中,一个著名的公共项目吸引了我的注意力,虽然没有太多关于目标的内容,但它是一个领先的在线成人娱乐平台,所以你可以猜到它; (他们也有一个广泛的私人项目,所以我被邀请把这个发现提交给他们的私人项目,因为这个域名已经超出了公共项目的范围)

I found out there is a page for affiliate registration which has the Vulnerable function of Password Reset that leads to Account takeover.

我发现有一个网页的代销商注册,其中有脆弱的功能,密码重置,导致帐户接管。

This is one of my interesting and quickly found critical issue wherein I was able to exploit this vulnerability within 5–10 mins of time so let’s get started and know more about it. Let’s assume the vulnerable target as company.com

这是我感兴趣并且很快发现的关键问题之一,我能够在5-10分钟内利用这个漏洞,所以让我们开始并了解更多。让我们假设易受攻击的目标是 company.com

Technical Details and Exploiting the Issue in wild:

技术细节和开发的问题:

When Testing on the Login Pages and Signup page I didn’t Find anything impressive here, There was an OAuth miss-config which led to an Open redirect on the login page. I also tested the forgot password functionality and as expected it sends a reset token link on performing the forgot password action so no luck here.

当测试登录页面和注册页面我没有发现任何令人印象深刻的东西在这里,有一个 OAuth miss-config 导致登录页面上的一个开放重定向。我还测试了忘记密码的功能,正如预期的那样,它会发送一个重置令牌链接来执行忘记密码的操作,所以在这里没有运气。

But I didn’t give up here and tried my luck again and looked into the page source of the application to discover anything interesting as the web application was working on AJAX Request(AJAX allows web pages to be updated asynchronously by exchanging data with a web server behind the scenes. This means that it is possible to update parts of a web page, without reloading the whole page.). When the user clicks on forgot password there is no process or reloading on-page, the user just gets a password reset link with a set of unique tokens. An ordinary user will have no idea of what’s happening behind there.

但是我没有放弃,我再次尝试了我的运气,并查看了应用程序的页面源代码,以发现任何有趣的东西,因为 web 应用程序正在处理 AJAX 请求(AJAX 允许 web 页面通过与后台 web 服务器交换数据异步更新)。这意味着可以在不重载整个页面的情况下更新网页的部分内容.当用户单击忘记密码时,页面上没有进程或重新加载,用户只是得到一个带有一组惟一令牌的密码重置链接。一个普通的用户将不知道在那里发生了什么。

Pic 2: AJAX Working Process 图2: AJAX 工作流程

As there was an endpoint in the XMLHttpRequest which be like:

因为在 XMLHttpRequest 中有一个端点,类似于:

https://company.com/api/REDACTED/resetPasswordToken/

The response looked somewhat like this:

回答看起来有点像这样:

Forgot Password API Endpoint
Pic 3: Response of Vulnerable Endpoint

Then I intercepted the Request of Reset password page again:

然后我又拦截了重置密码请求页面:

https://company.com/api/REDACTED/resetPassword<username>

https://company.com/api/redacted/resetpassword

I intercepted the Reset password request again and this time I focused on the response received for the following POST request and the response was something which I was not expecting and I was like Daaaummm !!!!

我又一次拦截了重置密码请求,这次我集中于接收到的下一个 POST 请求的响应,这个响应出乎我的意料,我就像 Daaaummm! ! !https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fgiphy.com%2Fembed%2F102h4wsmCG2s12%2Ftwitter%2Fiframe&display_name=Giphy&url=https%3A%2F%2Fmedia.giphy.com%2Fmedia%2F102h4wsmCG2s12%2Fgiphy.gif%3Fcid%3Decf05e47hvtbi91nd8kv86gf8lf04qfud2y92955dhbsso4u%26rid%3Dgiphy.gif%26ct%3Dg&image=https%3A%2F%2Fi.giphy.com%2Fmedia%2F102h4wsmCG2s12%2F200.gif&key=a19fcc184b9711e1b4764040d3dc5c07&type=text%2Fhtml&schema=giphyPic 4: Reaction after successful exploit图4: 成功开发后的反应

The Response Looks like this:

回应看起来像这样:

Pic 5: Password Reset Token in Response( Developer was high on grass that day)

{
“id”: 11077,
“token”: “4PjLzn7fyLU<Redacted>f1h1P2F”,
“stamp”: 1628796031082,
“username”: “test13337”
}

{“ id”: 11077,“ token”: “4PjLzn7fyLU < redacted > f1h1P2F”,“ stamp”: 1628796031082,“ username”: “ test13337”}

Due to some misconfiguration on the server-side, the Server leaks the token in response for any user who is requesting it for any valid existing username. But now the question is how we can use this disclosure of tokens to perform an Account Takeover of any user? so it’s pretty easy.

由于服务器端的一些错误配置,服务器泄漏令牌以响应任何为任何有效的现有用户名请求令牌的用户。但现在的问题是,我们如何使用这种令牌公开来执行对任何用户的帐户接管?所以很简单。

The Reset URL Format looks somewhat like :

重置 URL 格式看起来有点像:

https://www.company.com/#/changePassword/<username>/<token&gt;

https://www.company.com/#/changepassword/

We are halfway there. Let’s craft a password Reset link here, as the response of the request leaks the “username” and “token” so all we have to do is to replace the values with the above-mentioned URL.

我们已经走了一半了。让我们在这里建立一个密码 Reset 链接,因为请求的响应会泄漏“用户名”和“令牌”,所以我们所要做的就是用上面提到的 URL 替换这些值。

The Final reset token would be

最终重置令牌将是

https://www.company.com/#/changePassword/test13337/4PjLzn7fyLU<Redacted>f1h1P2F

1h1p2f https://www.company.com/#/changepassword/test13337/4pjlzn7fylu

Performing the above steps the attacker can successfully takeover any valid user’s account and perform any suspicious activities or can also Divert the payments to his crypto address which was a critical issue.

执行上述步骤,攻击者可以成功地接管任何有效用户的帐户并执行任何可疑活动,或者也可以将付款转移到他的加密地址,这是一个关键问题。

I immediately went ahead and reported this vulnerability and The team validated and triaged the issue within 10 minutes of my submission and I was rewarded with a huge $5000 bounty for this finding.

我马上报告了这个漏洞,团队在我提交报告的10分钟内验证并分类了这个问题,我因为这个发现获得了5000美元的奖励。

Pic 7: Reward for Vulnerability 图7: 脆弱的奖励

Tips:

Be creative and think out of the box, easy, isn’t it 😉

要有创造力,跳出思维定势,这很容易,不是吗

Timeline:

Issue found: Aug 16th, 2021 9:30 PM IST

发行日期: 2021年8月16日下午9:30

Issue Reported: Aug 16th, 2021 10:00 PM IST

2021年8月16日10:00 PM IST

Issue Triaged: Aug 16th, 2021 10:10 PM IST (Quick tho)

发行分流: 2021年8月16日10:10 PM IST (Quick tho)

Rewarded: Aug 16th, 2021 10:30 PM IST with $5000 Bounty

奖励: 2021年8月16日10:30 PM IST 与5000赏金

Fixed: Aug 17th, 2021 9:41 AM IST

修正: 2021年8月17日上午9:41

It was really fun hunting on this program and I’ll be publishing more write-ups in the upcoming days so stay tuned.!

这是真正有趣的狩猎在这个节目,我会出版更多的写作在未来几天,所以请继续关注。!

Hope you guys enjoyed it! and Feel free to reach me out on Twitter.

希望你们喜欢它! 欢迎在推特上联系我。

Until then take care, stay safe and keep grinding.

在那之前,要小心,保持安全并继续研磨。

Cheers..!

干杯!

发表评论

Fill in your details below or click an icon to log in:

WordPress.com 徽标

您正在使用您的 WordPress.com 账号评论。 注销 /  更改 )

Google photo

您正在使用您的 Google 账号评论。 注销 /  更改 )

Twitter picture

您正在使用您的 Twitter 账号评论。 注销 /  更改 )

Facebook photo

您正在使用您的 Facebook 账号评论。 注销 /  更改 )

Connecting to %s