Monday, April 19, 2010

Authentication Flaw

During an assessment of a financial web application, I found a serious flaw in authentication. The web security scanners at my disposal gave a "seal of approval" on the unauthenticated surface area of the application. Yet, in a matter of a few hours after getting the go-ahead to test the application, I had fully compromised a user's account. How? Basically, by using my brain as a hacker might. Screen shots proving my authenticated access were probably eye-opening to the customer as they had given me only the URL for the site, not any user credentials.

This was a case of flawed forgot password functionality. For users who had forgotten their password, the application worked as follows:

Step 1 - Enter username
Step 2 - Answer question to personal security question and enter email address
Step 3 - Receive email with a new, system-generated password

Can you find the flaws? First, the application asked for only one piece of data initially: the username. It is not hard to guess a valid username. I found that "jsmith" was a valid username. Second, the application asked the user to enter his email address on the second step. Um, shouldn't this be part of the user's profile and already known to the application? Why trust a value entered by the user? Third, which I didn't actually tell you, is that the application allowed an unlimited number of attempts to answer the personal security question.

It happened to be that jsmith's security question was "What was the name of your first pet?". I fired up Burp Intruder with the 100 most common dog and cat names. Very soon I received an email with jsmith's newly reset password. It turned out that his first pet was named "Rocky" (I'm assuming jsmith is a man here - would a girl naming her pet "Rocky"?).

This is an example where a scanner (and a web app firewall most likely) would not alert you to this security hole. All requests, data, and URLs were perfectly legitimate in my attack. The flaws were caused by poor design decisions.

4 comments:

AppSec,  4/20/2010 1:08 PM  

Using the e-mail address isn't wrong, if done correctly.

For instance, in a previous life, the app I worked on asked for user id and e-mail address in order to not provide information to a potential hacker. If the user id didn't match the e-mail address on record, you never got to the security question.

And even if it did, and you were able to answer the security question, the temporary password was sent to that e-mail address.

Now you could argue that lots of e-mail accounts can be hacked, but our philosphy was we cannot control how one secures an e-mail.. After all, we couldn't control security around one's mailbox or ones phone either (physical vs. virtual arguments understood, just not agreed with).

This is just plan bad.

Dave Ferguson 4/20/2010 9:57 PM  

Asking for email address in addition to username on the first page would have been a good idea. Actually I recommend having the user enter 3 pieces of data on the first page. The app should check that all are correct before showing the user's security question. That is not how it worked however. If the correct answer to the security question was provided, the app sent the new password to whatever email address was specified in that same HTTP request.

Dave Ferguson 4/21/2010 11:52 AM  

I changed the title of this post to "Authentication Flaw" instead of the original "Business Logic Flaw". This was done based on a comment from Jeff Williams I saw on the OWASP Moderated Feed. I thought the "Sheesh" comment from Jeff was unnecessary. A note sent to me personally or a suggestion on the post's comment page would have been nice. Oh well.

jwilliams 4/23/2010 5:58 AM  

You're right and I apologize. Sorry. Jeff.

  © Blogger templates The Professional Template by Ourblogtemplates.com 2008

Back to TOP