- Status Closed
-
Assigned To
cbay - Private
Opened by anshumanbaghel - 23.04.2024
Last edited by cbay - 24.04.2024
FS#49 - Vulnerability Report: Lack of Rate Limiting on Password Reset Links Summary
The website does not implement rate limiting on password reset links, allowing an attacker to repeatedly request password reset links for any account. This could lead to account takeover through brute-force attacks.
Description When an attacker gains access to a target account's email address, they can repeatedly request password reset links without any rate limiting in place. This allows them to flood the target's email inbox with reset links, making it difficult for the legitimate user to identify and use the valid reset link. Additionally, the attacker can automate this process, increasing the efficiency of the attack.
Impact Account Takeover: Attackers can potentially take over user accounts by flooding their email inbox with reset links, making it easier to intercept a valid reset link and gain unauthorized access.
User Disruption: The flood of reset links can disrupt the user's ability to use their email normally, causing inconvenience and potential confusion.
Recommendations Implement rate limiting on password reset requests to prevent brute-force attacks.
Limit the number of password reset links that can be requested per minute per IP address or account.
Implement CAPTCHA or other mechanisms to distinguish between automated and legitimate requests.
Steps to Reproduce 1- Go To This Link https://admin.alwaysdata.com/login/ Enter your Email Click On Forget Password
2- intercept burp and send request to intruder
3- make payload and start attack
Supporting Material/References
OWASP Password Reset Best Practices
Impact Account Takeover
User Disruption
Proof of Concept N/A (Describe how you were able to successfully exploit the vulnerability.)
Remediation
Implement rate limiting on password reset requests to prevent brute-force attacks. Limit the number of password reset links that can be requested per minute per IP address or account. Implement CAPTCHA or other mechanisms to distinguish between automated and legitimate requests.
Supporting Material/References
OWASP Password Reset Best Practices
Impact Account Takeover
User Disruption
Proof of Concept SS ATTACHED REQUEST** (BY USING BRUP SUITE)
POST /password/lost/ HTTP/2
Host: admin.alwaysdata.com
Cookie: REACTED
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:125.0) Gecko/20100101 Firefox/125.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://admin.alwaysdata.com/password/lost/ Content-Type: application/x-www-form-urlencoded
Content-Length: 116
Origin: https://admin.alwaysdata.com Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Te: trailers
csrfmiddlewaretoken=8GNhIyHjyRaBHSlBRaaN9gMWKaksiJR3Py8S3TJoW8zb7tq5gU4JzRA1cMEp0VHl&email=alexdoppler29%40gmail.com
SS LINK - https://drive.google.com/file/d/1a0vqAOB6u6ayQSNX4ktQuUOWIAgNQjAR/view?usp=sharing
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
Hello,
I don't see how flooding the victim with password reset emails can help the attacker gain access. Can you explain?
Kind regards,
Cyril
Hello Cyril,
I appreciate your question. The attack scenario described in the report involves flooding the victim's email inbox with password reset emails to create confusion and make it harder for the victim to identify the legitimate password reset link among the flood of emails.
In this scenario, the attacker's goal is not to directly gain access to the victim's account through the flood of emails. Instead, the attacker aims to increase the likelihood that the victim will use a reset link sent by the attacker, which may lead to the victim inadvertently resetting their password using a link controlled by the attacker. This can enable the attacker to take over the victim's account.
I hope this clarifies the concept. Let me know if you have any further questions.
Best regards,
Anshuman
How is the link controlled by the attacker? It's alwaysdata who sent the emails, so the link is valid and not controlled by the attacker.
Hello Cyril,
I appreciate your question. The attack scenario described in the report involves flooding the victim's email inbox with password reset emails to create confusion and make it harder for the victim to identify the legitimate password reset link among the flood of emails.
In this scenario, the attacker's goal is not to directly gain access to the victim's account through the flood of emails. Instead, the attacker aims to increase the likelihood that the victim will use a reset link sent by the attacker, which may lead to the victim inadvertently resetting their password using a link controlled by the attacker. This can enable the attacker to take over the victim's account.
Regarding the absence of rate limiting, this vulnerability falls under Bugcrowd’s Vulnerability Rating Taxonomy as a P4 issue. This means it is classified as a lower priority issue but still poses a potential risk to the security of the application.
I hope this clarifies the concept. Let me know if you have any further questions.
Best regards,
ANSHUMAN
I can't see how a victim receiving a flood of unsollicited password change emails would be *more* likely to click on a fake email among them than if the victim only received a single fake email.
The main concern with the absence of rate limiting on password reset links is the potential for abuse by an attacker to flood a victim's inbox, causing disruption and potentially making it more difficult for the victim to identify and respond to legitimate emails, including legitimate password reset emails. This can create a nuisance for the victim and may also impact the overall usability of the email service
I agree it can be a nuisance, not a security vulnerability though.
I am writing to inquire about the classification and eligibility for a potential vulnerability that I have identified in your system.
The vulnerability involves the absence of rate limiting on password reset links, which allows an attacker to flood a victim's inbox with unsolicited password reset emails, potentially causing disruption and impacting the usability of the email service. This issue aligns with Bugcrowd’s Vulnerability Rating Taxonomy as a P4 concern.
I would like to confirm if this vulnerability falls within your scope and if it qualifies for a reward. I believe that addressing this issue can enhance the security and usability of your system, and I am committed to providing any additional information or assistance you may require.
For us, a security vulnerability implies gaining access to something you shouldn't have access to, or tricking a victim into doing something they wouldn't have done.
A mere nuisance is not something we consider a vulnerability.
Keep in mind we're a web hosting company with a free tier. If you want to flood a victim with emails, you can do so trivially with a one-line script anyway.
Thank you for clarifying your definition of a security vulnerability. I understand your perspective and appreciate the information about your company's free tier and the ease of flooding a victim with emails.
If flooding a victim's inbox with emails is not considered a security vulnerability, I will focus on identifying and reporting more substantial security issues that align with your criteria. If you have any specific areas of focus or types of vulnerabilities you would like me to prioritize, please let me know.
Thank you for your time and guidance on this matter. you can close this report