Update: Hours after the initial post, facebook patched the vulnerability. It seems that the impact is higher than expected?
Open redirects are security bugs that can easilly be exploited.
An open redirect is an application that takes a parameter and redirects a user to the parameter value without any validation. This vulnerability is used in phishing attacks to get users to visit malicious sites without realizing it.
But what if you have an open-redirect vulnerability that automatically does the social-engineering job itself?
There is a subdomain on facebook, that is called free.facebook.com. It seems that it will be a new service that it is not ready yet.
When someone is browsing the free.facebook.com, he is getting the following response.
So, as we can see there is a hyperlink of facebook.com that points to https://m.facebook.com
The url bar after visiting the site becomes:
The GET parameter "next_uri" is very interesting. Let's try to modify it and observe the responses.
Let's make the following request:
We are getting 500 internal server error with a blank page as response.
Bypassing url redirection filter
There are 2 ways of bypassing the url redirection filter.
The first one relates to redirection to in-facebook urls.
When someone inserts a word without http(s) as nexturi parameter( let's say nexturi=Hacking0is1Art, he will get redirected to the https://m.facebook.com/Hacking0is1Art (my fb page, feel free to like to support my research)
The url that will make the facebook.com hyperlink to point to https://m.facebook.com/Hacking0is1Art is the following:
Notice: The page that is rendered by the web browser remains the same. The user is tricked and when he clicks to get redirected to facebook.com, he gets redirected to another facebook link (https://m.facebook.com/Hacking0is1Art).
The internal link redirection can be maliciously used for e.g. marketing purposes.
Bypassing url redirection filter for external links
How about bypassing the redirection filter with facebook own mechanisms?
It's cool, isn't it?
First, i would like to describe what linkshim mechanism is:
So, how does the linkshim actually work? It's an endpoint accessible at facebook.com/l.php or facebook.com/l/, that takes 2 parameters: (1) The redirect URL, and (2) A user-specific hash. Everything would work just fine without this hash, if we simply redirected to the specified URL assuming it was safe. However, by not including the user-specific hash we'd create a security hole called an "open redirector". Endpoints that redirect to arbitrary URLs can easily be exploited by malicious actors - if someone sees a facebook.com url, they are likely to trust it without regards to the redirect URL itself. To avoid being an open redirector, we generate a hash for each link shim url that's user specific. Then, when the person loads the interstitial link shim page, we check that the hash is valid for her. If it is, we allow her to access the site requested - but if not, we show a warning page like this:
If someone tries to send you a link in order to redirect you to a webpage via facebook, you will get a warning of the redirection (no matter what the link is):
Let's try to use linkshim redirection mechanism for fun and profit!
If we set as nexturi parameter the "https://www.facebook.com/l.php?u=vagmour.eu" string, the whole url will become: http://free.facebook.com/zero/support/ineligible/?nexturi=https://www.facebook.com/l.php?u=http://vagmour.eu
With that way, the user-specific hash is generated automatically. The anchor text of the hyperlink remains facebook.com, while the hyperlink points to
facebook.com hyperlink is pressed, this is the result:
You are getting a redirection to
vagmour.eu without even a warning!
Let's see how the
free.facebook.com page is rendered by the iOS safari:
As we can see, it's very easy for someone to click the facebook.com hyperlink and get redirected to a malicious site.
The impact for that kind of redirection is very high/critical, because it is very easy for a user to click to the facebook.com hyperlink hoping that he will get redirected to the facebook homepage.
The browsers i tested it and the redirection is working without a warning that the user will be redirected to a non facebook page are:
- iOS Safari non-jailbroken iphone last version
- OSX Safari 9.0.1
- Gmail iOS app non-jailbroken iphone last version
Other browsers/apps may act the same as the previous.
Time for POCs
I sent 3 POC videos to facebook security team about the bug.
-The first one shows a person that receives the link on the Gmail app(latest iOS version) and browsing it in iOS and redirecting to my blog without a warning.
-The second one shows browsing the link from Safari OSX 9.0.1 and redirecting to my blog without a warning.
-The third one is demonstrating a phishing attack:
P.S. The third scenario performed only for demonstration of the vulnerability and no other facebook users received the link.
The fact that a facebook.com hyperlink can redirect you to whatever you want, is very important from a security point of view.
Imagine, that a malicious user can redirect a user to
porn sites, phishing sites, browser exploits, black marketing sites and so on.
I don't understand why the facebook security team did not realise the bad things that this vulnerability can cause to its users.
To be honest, i disappointed that facebook didn't recognise the bug as part of bug bounty program as 'no high security impact' from what they said.
From their replies, i understood that they have a url blacklisting mechanism, but that kind of protections is not really helps solving the bug because you can always buy new domains.
Also, how about that facebook blacklist protection can't check private ip addresses like
192.168.1.5? What if a malicious site is hosted on a private ip in a huge organisation?
The scenarios are unlimited on how a malicious user can use and exploit that vulnerability without being picked by the blacklisting protection.
Furthermore, you can always check which user agent visits your site and serve different content to any of them.
I would like to hear your opinion. Please reply to the tweet/thread or email me at vag[d0t]mourikis[@]gmail.com to tell my what you believe about the bug.
Thanks for reading this post.
12th of Nov 2015 | Initial bug report
12th of Nov 2015 | Reply from FB bot that it is false positive
12th of Nov 2015 | Added more clarification for the bug
16th of Nov 2015 | Reply from facebook that they use a blacklist method on their next_uri
16th of Nov 2015 | Sent POC videos of the bug that show the impact of the vulnerability
18th of Nov 2015 | Reply from facebook that i am redirecting to a non blacklisted site
18th of Nov 2015 | Explaining why url blacklisting is not the solution for the specific bug
26th of Nov 2015 | Reply from fb that security impact of this bug is not significant.
6th of Dec 2015 | Public post of the bug