Brute Forcing the Change Password Feature

As a penetration tester, brute force attacks are something I test for on every application.  Obviously, I test the login forms for this type of security flaw.  There are also other areas of an application that brute force attacks can be effective.  The one I want to discuss in this post is related to functionality inside the authenticated section of the application.  More specifically, the change password screen.

Done right, the change password screen will require the current password.  This helps protect from a lot of different attacks.  For example, if an attacker hijacks a user’s valid session, he wouldn’t be able to just change the user’s password.  It also helps protect against cross-site request forgery for changing a user’s password.  I know, I know, it can be argued with cross-site scripting available, cross-site request forgery can still be performed, but that gets a little more advanced. 

What about brute forcing the change password screen?   I rarely see during an assessment where the developers, or business has thought about this attack vector.  In just about every case, I, the penetration tester, can attempt password changes with a bad password as much as I want, followed by a valid current password to change the password.  What if an attacker hijacks my session?  What if someone sits down at my desk while I have stepped away and I didn’t lock my computer (look around your office and see how many people lock their computer when they walk away)? 

It is open season for an attacker to attempt a brute force attack to change the user’s password.  You may wonder why we need to change the password if we have accessed the account.  The short answer is persistence.  I want to be able to access the account whenever I want.   Maybe I don’t want the user to be able to get back in and fully take
over the account.

So how do we address this?  We don’t want to lock the account do we?  My opinion is no, we don’t want to lock the account.  Rather, let's just end the current session in this type of event.  If the application can detect that the user is not able to type the correct current password three or five times in a given time frame (sounds familiar to account
lockout procedures) then just end the current session.  The valid user should know their password and not be mis-typing it a bunch of times.  An invalid user should rightfully so get booted out of the system.  If the valid user’s session ends, they just log back in, however the attacker shouldn’t be able to just log back in and may have to hijack the session again which may be difficult.

Just like other brute forcible features, there are other mitigations.  A Captcha could also be used to slow down automation.  The key differentiator here is that we are not locking the account, but possibly just ending the session.  This will have less impact on technical support as the valid user can just log back in.  Of course, don’t forget you should be logging these failed attempts and auditing them to detect this attack happening.

This type of security flaw is common, not because of lazy development, but because this is fairly unknown in the development world.  Rarely are we thinking about this type of issue within the application, but we need to start.  Just like implementing lockouts on the login screens, there is a need to protect that functionality on the inside.

James Jardine is a Principal Security Consultant with Secure Ideas.  If you are in need of a penetration test or other security consulting services you can contact him at james@secureideas.com or visit the Secure Ideas – Professionally Evil site for services provided.