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, lets 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.

Leave a Comment

Your email address will not be published. Required fields are marked *