After the waveofOAuthbugs reported recently, It’s my turn to present a just as serious (but slightly less complicated) issue.
On the Facebook App Center, we have links to numerous different apps. Some have a “Go to App” button, for apps embedded within Facebook, and others have a “Visit Website” button, for sites which connect with Facebook. The “Visit Website” button submits a POST request to ui_server.php, which generates an access token and redirects you to the site.
The form is interesting in that it doesn’t present a permissions dialog (like you would have when requesting permissions via /dialog/oauth). This is presumably because the request has to be initiated by the user (due to the presence of a CSRF token), and because the permissions required are listed underneath the button.
During testing, I noticed that omitting the CSRF token (fb_dtsg), and orig/new_perms generates a 500 error and doesn’t redirect you. This is expected behaviour.
However, in the background, an access token is generated. Refreshing the app’s page in the App Center and hovering over “Visit Website” shows that it is now a link to the site, with your access token included.
Using this bug, we can double-submit the permissions form to gain a valid access token. The first request is discarded - the token is generated in the background. The second request is sent after a specific interval (in my PoC I’ve chosen five seconds to be safe, but a wait of one second would suffice), which picks up the already generated token and redirects the user.
The awesome thing about this bug is that we don’t need to piggy-back off an already existing app’s permissions like in some of the other bugs, we can specify whatever ones we want (including any of the extended_permissions).
When the user is sent to the final page, a snippet of their FB inbox is displayed, sweet! In a real-world example, the inbox would obviously not be presented, but logged.
Facebook has fixed this issue by redirecting any calls to uiserver.php without the correct tokens to invalid_request.php
Back in October, I found a couple of issues in Etsy, which when combined could be used in a click-jacking attack.
Incorrect Error Handling
Pretty much all forms on Etsy have a token attached to prevent CSRF attacks. Failing to provide, or providing an incorrect token will result in the form not being processed, and an error page will be displayed.
If we submit a POST to the search page, the request is (correctly) not processed. But, rather than showing the generic error page, we get the homepage instead.
This isn’t that interesting, nor very useful. However, this combined with…
Bypassing X-Frame-Options with a Referrer
The value of the X-Frame-Options header across Etsy is SAMEORIGIN, meaning that only pages from the same domain will load in a frame, else a blank screen is displayed, thus thwarting click-jacking attacks.
The value of the Referer header is checked, and if the domain is etsy.com, the response back is ALLOW, rather than SAMEORIGIN. Luckily, in the previous issue, when the homepage is returned, no X-Frame-Options header is sent!
So now that we can successfully frame the home-page, all we need to do is get a user to click links on the framed page, and we have a way of framing any page on the site.
Of course, this requires a user to click multiple times (since there isn’t any sensitive actions that can be performed with one click on the homepage). The best way is to turn it into some sort-of game (my creativity is lacking, hence the simplicity).
We use setTimeout to change the position of the iframe after a x seconds (to give the page enough time to load), and entice the user to click the stopwatch (which contains each link underneath).
We use the pointer-events: none; CSS value to pass the click through the image and to the link.
The user has now successfully deleted their wedding registry! Ouch.
Regrettably I didn’t take any screenshots when I reported this issue, and now that it’s fixed my only option is to photoshop them (which I won’t do). So you’ll have to take my word for some of it.
The fix was done in two stages. Firstly, the CSRF token was removed from the search form, presumably because there aren’t any modifications being made to user data, so it’s pointless. Secondly, the referrer checking was removed and SAMEORIGIN was enforced across all pages.
The second fix took longer to deploy, presumably due to the scale and amounts of testing required.
On eBay, the My World section allows users and businesses to construct a profile, with shipping information, returns policies, and also blocks of arbitrary text specified by the user.
All of the input boxes have a note below saying that you can’t add HTML, so I was interested to see how it checks/prevents you from entering any.
I tried adding in some tags, <a>, <span>, <script>, however they’re all filtered out. In addition to this, you can’t use double quotes (so you can’t break out of attributes). However, it turns out they use a blacklist of HTML tags. I tried a deprecated tag, <plaintext>, and to my surprise it passed through fine.
I don’t like the plaintext tag, as it caused the rest of the page to render horribly (as expected), so I tried a few more. <fn> and <credit> both passed through too.
Now we have a way to inject HTML, I added an onhover event to the injected element. Without the use of quotes, we can use the String.fromCharCode function and eval to load an external script - this is necessary as the character limit on the textbox is 1k.
From this point onwards, it is trivial to weaponise this into a working worm. We get the username from the element #gh_uh, construct a form post to the bio page and add ourselves to the logged in users bio.
There is no CSRF protection on this form, which makes it even easier as we don’t need to scrape a token from anywhere.
In addition to this, all of the cookies are stored under *.ebay.com, and they’re not using HTTPOnly so we can steal this too.
eBay responded by encoding all HTML entities on output.
Everyone knows by now that you should use unique, random passwords for each of your online accounts, to prevent the probability that it’ll be cracked in the event that hashes are leaked, and to limit the damage caused if your plain text password is discovered.
I, like many people, use a password manager to store each of these, and on a login form I’ll copy and paste the password into the field.
Now, I could stop this redirect using developer tools in Chrome, but an easier way is to run the following to remove the event handlers on the element. A workaround, but a workaround that shouldn’t be needed in the first place.
This is reminiscent of the disable right-click “security” implemented in the 90s.
I’ve sent Vodafone an email, hopefully they’ll respond with an explanation and maybe (not holding my breath) a fix.
On most, if not all websites, there will be a need for a way to redirect users to other areas on the site after an action is performed.
If a user clicks on a link which redirects them to a login page, they will expect to be sent back to the page they were previously on.
One technique is to store this URL as a session variable, however, there are times when this is not practical, so the URL must be passed in the request.
This method is perfect for any malicious users who wish to perform a phishing attack - the bad URL is hidden behind the legitimate one.
There are many methods to allow only specific values - encrypting the value (which in my opinion is over-kill), using an ID to map it against allowed values, or using a MAC. The simpliest is to check the URL that has been given, and ensure it matches our domain, if not, throw an error or ignore the value.
This is the approach employed on a lot of sites, Google being a good example, and Etsy being another. This post was spurred on by finding a loop-hole in the way Etsy checks the URL. They allow two types - either an absolute path (http://www.etsy.com/sell), or relative (/sell). The benefit of allowing relative is that providing that the URL starts with a slash, and that the value is escaped, we don’t care what’s in it - it will always resolve relative to http://www.etsy.com.
The variable from_page is (presumably) checked against a regex, and if the value doesn’t match, it’s reset.
However, the value isn’t checked for two leading slashes, so we can break out of the link being relative to the domain, and link to wherever we want!
Passing in a bad value
A link asking the user to continue is then displayed.
The resulting link, before the fix
Etsy (very quickly, might I add) fixed this by removing any extra slashes at the start of the string.
The resulting link, after the fix
If our domain is example.com, we can use the following regex to ensure we only allow redirects to our sites.
Line 2 we check for absolute URLs, or URLs with a relative protocol, that match our own domain.
Line 3 we make sure that the string either ends, or has a slash, to prevent attacks a la TimThumb.
Line 4 we check for relative URLs, that have only one leading slash.
For sites with multiple sub-domains, the regex is left as an exercise to the reader.