Attacking Authentication
Attacking Authentication
Forgot Password: use extra param with updated case
https://anugrahsr.github.io/posts/10-Password-reset-flaws/
CAPTCHAs not being used
This is one of the most common flaws observed in the implementation of the Forgot Password feature. A CAPTCHA is used to stop automated requests generated with the help of bots. In the absence of a CAPTCHA on the Forgot Password page, an attacker would be able to initiate a lot of password reset requests with the help of bots thus performing DoS. https://hackerone.com/reports/209008 https://hackerone.com/reports/206653
Easy-to-answer hint/security questions
common flaw is to allow very simple questions to be set. An attacker might easily guess the answers to these questions or might be able to get the answers using social engineering and thus reset the password of a valid user.
Some examples of bad questions are:
What is your favorite color?
What is the color of your eyes?
What is your favorite sport?
Sending the new password as cleartext to a registered e-mail address
The potential problem in using this approach is that an attacker might be able to sniff the password if the e-mail service is not using SSL.
Allowing the user to set a new password and confirming the same via e-mail
An attacker can visit the Forgot Password page and initiate a password reset request by entering the e-mail ID and new password. A confirmation link would be sent to the user. If, by any chance, the user clicks on this link then his/her password would get reset to the one that was provided by the attacker.
Old password is invalidated as soon as the Forgot Password process is initiated
All an attacker has to do is initiate the Forgot Password feature for a valid user by providing a username or e-mail (whichever is being used) and the valid user’s old password would be invalidated. Even if the attacker is not able to obtain the new password, he has succeeded in performing DoS for the valid user. A user would have to go through the entire process of resetting his/her password to access the account successfully again.
Captcha bypass
https://hackerone.com/reports/206653 https://hackerone.com/reports/210417 https://hackersonlineclub.com/how-to-bypass-captcha-process/
Password reset link not expiring
https://hackerone.com/reports/898841 https://hackerone.com/reports/685007
No rate limiting on password reset |No Captcha or rate limit on Login Page
https://hackerone.com/reports/838572 https://hackerone.com/reports/751604 https://hackerone.com/reports/441161 https://hackerone.com/reports/280534 https://hackerone.com/reports/6697
Denial of service when entering a long password
https://hackerone.com/reports/840598
Password reset token leak via referer
https://hackerone.com/reports/751581 https://hackerone.com/reports/342693 https://hackerone.com/reports/272379 https://hackerone.com/reports/737042 https://medium.com/@rubiojhayz1234/toyotas-password-reset-token-and-email-address-leak-via-referer-header-b0ede6507c6a https://medium.com/@shahjerry33/password-reset-token-leak-via-referrer-2e622500c2c1
Account Takeover Through Password Reset Poisoning
https://hackerone.com/reports/226659 https://hackerone.com/reports/167631 https://www.acunetix.com/blog/articles/password-reset-poisoning/ https://pethuraj.com/blog/how-i-earned-800-for-host-header-injection-vulnerability/ https://medium.com/@swapmaurya20/password-reset-poisoning-leading-to-account-takeover-f178f5f1de87 https://anugrahsr.github.io/posts/10-Password-reset-flaws/
Findout How Password Reset Token is Genrated
Generated based Timestamp
Generated based on the UserID
Generated based on email of User
Generated based on Firstname and Lastname
Generated based on Date of Birth
Generated based on Cryptography
User enumeration via Password reset page
https://hackerone.com/reports/77067
Password reset with manipulating email parameter
https://hackerone.com/reports/1175081 https://vikas25019.medium.com/account-takeover-ato-2851220a47d6
weak cryptography issue
The basic idea is just to find out how password reset token is generated:-
Generated based timestamp
Generated based on cryptography
Generated based on userID
Generated based on email user
Generated based on first name and last name
Generated based on the date of birth
Password reset Poisoining leads to token leak
https://medium.com/@alex.birsan/the-bug-that-exposed-your-paypal-password-539fc2896da9
A developer can mitigate this vulnerability by using $_SERVER['SERVER_NAME'] rather than $_SERVER['HTTP_HOST'] when generating a password reset link.
https://hackerone.com/reports/226659
Response manipulation: Replace Bad Response With Good One
Using Expired Token
Brute Force Password Rest token:https://twitter.com/HusseiN98D/status/1254888748216655872/photo/
Try Using Your Token
Try adding your password reset token with victim’s Account https://twitter.com/HusseiN98D/status/1254888748216655872/photo/1
Denial of Service:
The second vulnerability we can identify is a denial of service abusing the functionality of password recovery because this application changes the actual password of user to a new/randomly generated password (as you can see in the lines 25–28). That way an attacker could create, for example, an automatic script to abuse the functionality by resetting user passwords every 15 seconds and blocking real users from loggin into the application. And, in combination with a username enumeration vulnerability, the severity of this vulnerability increases.
Sensitive Information Disclosure:
The third vulnerability we can identify is sensitive information disclosure because the application sends an e-mail to the user with the newly generated password in clear-text and doesn’t force the user to change his password the next time he logs in. So, if an attacker compromises the e-mail of a user and the user forgets to change their password the next time they log in, the application can be accessed by the attacker using the original e-mail message.
SQL Injection:
The fourth vulnerability we can identify is SQL Injection. User input is not properly validated and directly concatenated to the query string.
Reflected Cross-Site Scripting:
The Fifth vulnerability we can identify, is reflected cross-site scripting. In the reply message provided by the application in line 47, the user input $_REQUEST[‘mail’] is directly concatenated to the response message (without any treatment) when the application finds a valid username in the database.
Password Recovery Message Hijack:
User Input:valid-email@attacker.com%00' or 1=1%23
First SQL becomes (Line 15): SELECT usr_user.id, usr_user.name, usr_user.email, usr_user.password FROM usr_user WHERE usr_user.email = ‘valid-email@attacker.com[null byte char]’ or 1=1#’ ORDER BY id DESC
Second SQL becomes (Line 26): UPDATE usr_user SET password = MD5(trim(‘xxxxxxxxxx’)) WHERE email like ‘valid-email@attacker.com[null byte char]’ or 1=1#’
MIME Header becomes (Line 34): To: John Smith <valid-email@attacker.com[null byte char]’ or 1=1#>
Just like the exploitation of reflected cross-site scripting, the queries 1 and 2 will be valid and will reset the password of all users because doesn’t exists a registered e-mail with ‘valid-email@attacker.com[null byte char]’ and will send a e-mail to John Smith <valid-email@attacker.com[null byte char]’ or 1=1#>. But, as we all know, the e-mail MIME header will be treated as a string and the [null byte] will be considered part of that character string. So, as is also known, the null byte represents the end of a character string and because of this behavior will kill the rest of that string. In this case the MIME header becomes John Smith <valid-email@attacker.com> allowing the attacker to hijack the password recovery message and discover the password generated for all users (because all users passwords are changed in the update query).
Weak Forgot Password implementation:
Invalidate or provide an option to invalidate existing sessions after password has been reset
Invalidate the current session and redirect to login after successful password reset. https://hackerone.com/reports/176116
Response issue: https://voidhat.medium.com/full-account-takeover-via-password-reset-functionality-e1f16d00de9d
Verify current user:
User A starts resetting password of User B.
2. User B receives the reset link and clicks on it.
3. The server now will allow the A user to change the password of User B through this endpoint because the resting URL verification is done. When the user clicks on the password reset. This means to the server that the user has clicked on the reset URL that he requested for but in fact he didn’t, the attacker who is requested the password reset. And after this happens user B can change his password through this endpoint without the need for any authorization tokens.
X-Forwarded-Host: https://vbharad.medium.com/account-takeover-through-password-reset-poisoning-72989a8bb8ea https://medium.com/@abdallah_0x0a/account-takeover-via-password-reset-poisoning-2ec02a9f59eb https://medium.com/@swapmaurya20/password-reset-poisoning-leading-to-account-takeover-f178f5f1de87
update request header with duplicate key with different value
like: Host: orgina. .com Host: attackertemp.com
Forgot Password - OWASP Cheat Sheet Series In order to implement a proper user management system, systems integrate a Forgot Password service that allows the user…cheatsheetseries.owasp.orgAccount Takeover Request password reset to your email address Click on the password reset link Don't change password Click any 3rd party…salmonsec.com
Last updated