I'm now going into my second year in application security, and as I learn more and more, my favorite attacks are still some of the things I learned when I first began here in SpiderLabs. For example, using an application's "forgot password" functionality to hijack user accounts and be very rewarding and oftentimes yields critical information.
So let's dive in. Here's an example of how I might retrieve your password when I've "forgotten" it.
This is by far the most common mistake I see.
On the surface, this looks pretty good. You're not sending the user their password in plaintext. They have to use the forgot password form to generate an e-mail with a tokenized link. Using an invalid token will render the page useless, and maybe it even only has a 30-minute time limit before the token expires.
My general approach is to self-register an account as User1, and then send myself a forgot password e-mail. However, while the token must be valid, what is oftentimes overlooked is whether or not the token has been specifically tied to my user. Let's say I copy the URL and make a slight modification:
And here we are, it now asks me to set a new password for User2. I change the password to 'password1', submit, and proceed to login to my new account.
Another variation of this is even more interesting. Let's say after modifying the URL, I receive this page:
While this big, scary error message may deter some, I've seen instances where the application recognizes that something is amiss, but still allows an attacker to continue.
This looks bad. But if I try my new password…
There are a few steps we could take to remediate this vulnerability. First, the developers can tie the token to the user account. The error message implied that the developers started to do that, but didn't enforce it properly. The developers should also remove the username from the process altogether, by sending a link that only includes a token and matches it to the correct username on the server-side. Lastly, while error messages can serve many purposes, security should not be one of them. Double-check your code to make sure that it's not only verifying that the two parameters match, but that the process is stopped if they do not. Any good attacker, or pentester, will follow the process through regardless of what the application tells him or her, just to see what happens.
One of my favorite things about hijacking user accounts is that vulnerabilities present in user-management portions of the application suddenly become critical issues. If your application doesn't mask a user's credit card number or SSN on a "My Account" page, it's bad practice. If I can log into your account, it becomes a serious vulnerability. Even if information is masked properly, if the application allows you store your billing information, I don't need it in order to buy myself something nice. A wealth of other information is also suddenly opened up to an attacker if they can hijack user accounts. Your customer's names, addresses, phone numbers, purchase histories, and possibly even medical information, are suddenly available for the curious and malicious alike.
