How to Fix Joomla 3.2 to 3.4.4 Core – SQL Injection vulnerability
October 23, 2015
Tool to Detect SQL injection vulnerability in Joomla 3.2 to 3.4.4 versions!
October 26, 2015

October 24, 2015

Most of the time when it comes to web application penetration testing, I like to initiate the foreplay with “Forgot Your Password” feature. Sometimes it is easy to take over the account by abusing password reset features in the applications. From an attacker’s perspective, there are few cases that can be used to abuse password recovery feature. And usually developers don’t have the slightest of idea about this while creating the password reset module code.

Few of the companies had this password reset vulnerability like Etsy, Hotmail, Slack, Paypal, Microsoft Career, Ebay , Facebook, again Facebook. You will find lot of companies, that are vulnerable to account takeover using password reset vulnerability. If you would like to contribute, you can provide the detailed technical link. You can comment on the blog post, to keep all forgot password reset bugs on single page.

password reset vulnerability

Password Reset Weak Common Approach

Let’s go through various test-cases to get a clearer picture. When attacker requests for the new password from password reset feature, it fetches the secret token value from the database to perform the password reset on victim’s account. Attacker has to visit

The attacker uses the following approach to reset password

  1. ?accessToken=MTIzNA==
  2. &userID=1337

If the token value matches with the following string user.validateAccessToken($decodedBase64AccessToken) and user.Exist($userID), the attacker will be able to successfully change the password. FYI: access token will get reset after 6 hrs, viz. periodical reset feature dah!!.

Testcase 1 : First, the attacker resets the targeted user password. According to the logic of password reset module, we can regenerate accessToken if it has only four digits within the given token reset time frame. However, we don’t know the userID. Applying the same logic, we can check for all random user ID or sequentially brute force accordingly.

Testcase 2 : Second, the attacker will test for access token. Attacker will try to use the same accessToken for all registered users ID. For example: ?accessToken=MTIzNA==&userID=any_random_userID. Now, if accessToken can be used for all users, then the attacker will be able to easily change the password for any registered random user.

In general, there are plenty of other test-cases that are available to test security of password recovery module. Sometimes we find bugs easily, at other times we have to trick the HTTP request to get the output we desire.

Enable Notifications OK No thanks