Yeah. Think about what sites you may have worked on in the past, then ask yourself, "Did I use Facebook Connect to handle authentication?" about each one.
Actually, with this vulnerability you wouldn't be able to check that page for the results of this attack because the attacker would have connected his Facebook account to your account at another website.
The attacker never linked your personal Facebook account to anything.
Wouldn't it be valuable for a public website to list these? Surely the people who want to take advantage of these vulnerabilities already have these lists and circulate them - why not allow people in general to see them and who has them, and allow them the choice to use the services or not?
CVE database is really really bad. Mitre says their limited funding means they are unable to fit all vulnerabilities into the database. There are MANY MANY MANY vulnerabilities that are not in the CVE database. NVD, CVE, BugTraq, PacketStorm, OSVDB, etc.etc. they can't catch them all.
I think it's very difficult these days to browse the web with noscript. A lot of sites are heavily dependent on JS without a fallback plan. It's only going to get worse as per Atwood's law.
Hopefully more JS CDNs will get blocked by parental filters (https://news.ycombinator.com/item?id=7129604), and suddenly there will be a delightful reversal of the current sad trend of not building sites that degrade gracefully in the absence of javascript.
nice work, although it would be nice to have an end to end example (what i, the user, do at each step, and what the hacker is doing) and what the final result of the hack will be. in particular, the practical meaning of these two sentences:
> Now to all OAuth flows Facebook will respond with Attacker's profile information and Attacker's uid.
> as long as attacker can replace your identity on Facebook with his identity and connect their Facebook account to victim's account on the website just loading CLIENT/fb/connect URL.
It wasn't to me either. I think it has something to do with the 302 redirect. I've never used FB Connect though, so maybe the 302 involves the fb/connect url? Replace your FB url with the victim's, and since you've already authenticated with FB, the web site will accept your token as authorization to the victim's account?
302 redirects preserve the URL's hash, which contains the access token in the JS SDK.
Thus, if a site has URLs that can be constructed to make a 302 to an attacking site, like https://www.google.com/redirect?url=http://www.example.com/, it's possible to craft a redirect URL that would take you to the authentication dialog but return the token to a redirect URL which will in turn pass the token to the attacker.
- User wants to create a new account at website.com
- website.com has been compromised to inject the attackers facebook login
- User chooses to create an account by linking with facebook. They click Link with Facebook and are redirected back to website.com logged into their new account
- Attacker can now access User's account on website.com by logging in with the injected facebook credentials
It seems like the attacker would need to somehow generate a unique facebook login for each exploited user though. I think if you try to "connect with facebook" with a website that already has an account for the facebook login it often logs you in rather then creates an additional account.
issue 1: when victims visits attacker's page, I relogin them in my facebook and load /fb/connect URL, which boils down to attaching my facebook to victim's website account = hijacking.
I don't think I understand the first one. The flaw is that you can force someone to login to Facebook as someone they're not? It looks like you're saying that you can pass a custom username and password to the FB connect button and it'll log in as that user.
It's the other way around. You force someone to log onto another site as your Facebook account, so you can then access all their content on the other site.
The security being breached is on the other site, not Facebook (perhaps why they are less concerned about it).
This is great work by Egor, as usual. I work on Facebook's security and thought I'd add a bit more clarity here on the mitigation steps available to developers. Awareness here is important.
The first issue manifests itself if 1) an account has been previously registered on a client site, 2) that site offers the ability to "link" that existing account with a Facebook account, and 3) the action that performs the linking on the client site is vulnerable to CSRF. If you're a developer implementing conditions 1 & 2, make sure the linking action is protected by your anti-CSRF framework. Requiring explicit consent prior to linking accounts is a good idea for a number of reasons beyond this attack.
The second issue builds on what Egor refers to as "OAuth's Achilles' Heel": if the client site contains Open Redirect or XSS vulnerabilities, those vulnerabilities can often be leveraged to compromise the OAuth credential. To greatly reduce the likelihood of this attack, you should restrict which endpoints on your domain are capable of participating in the OAuth flow. See Facebook's Best Practices for Login Security guide[1], specifically the "Specify a whitelist of OAuth redirect URLs" section. Of course, you probably want to fix any Open Redirect & XSS vulnerabilities as well.
Egor privately contacted my little site a couple weeks ago to let us know we had a vulnerability with the redirect issue. At first, we didn't quite understand it, but once we dug deeper, it is a pretty major issue.
Simply put, we use ElasticEmail to send out email from our service. They have a feature called 'custom tracking domain' where you can setup tracking.your_domain.xyz to enable link tracking of emails you send out. This is great except that the url is something like this: tracking.your_domain.xyz?redirect=urlencode(some other domain) <- EE will then do a redirect to whatever is specified in there.
Because we offer facebook connect authentication on our site, this created a security hole for us based on what Egor has discovered. In other words, because we setup some simple configuration of some 3rd party service that happens to allow for redirects, we are now exposing our users auth tokens. Doh!
The solution to fix this is to simply not enable tracking.your_domain.xyz, but now that we've turned that off, old links in emails are broken. If EE had tinyurl'd the links they send out, this wouldn't have been an issue because it wouldn't be an open redirect service. The emails would have to go through them, get rewritten and then they would store the unique ID to do the redirect. Yes, we've contacted EE about it and they are looking into it, but probably not seriously since it isn't really their bug per se. In a way, this is similar to what FB is saying to Egor (not our issue), but the fact is that a simple bit of configuration by people using these systems can really cause a lot of problems.
In the end, it all really means that you have facebook connect on your site, you absolutely need to do an audit of your code and 3rd party systems and make 100% sure that you don't have any open redirects on your domains. This is a lot harder than it sounds.
As time goes on, I really hope we move to systems like Persona which haven't had these sorts of issues (so far). We also support Persona login on our site (as well) and it has been excellent. Being an open standard and allowing for multiple identity providers makes the chances of 'wontfix' a lot less of an issue.
Can some of the risk be mitigated by sending the user an email to confirm the connection? If the user has a verified email address on file before the connection is attempted, the facebook profile information (in this case the information of the attacker) could be sent to them asking them to confirm the connection.
Sadly, Egor (who found this vulnerability) mentioned he's moving away from exclusively white-hat security since he "[tried to do] responsible disclosures but it gave me 0 profit. So now i will play with “gray” methods and see if it’s reasonable."
It's sad to see a researcher so talented and committed be pushed to the dark side simply because companies decide their bugs aren't "worth it"
I edited the post because i changed my mind. I was simply disappointed with my results and wanted more. Later I realized - "more" will come later, just keep working! No dark side :)
Awesome! It can be frustrating sticking to your morals but not getting the results you feel you deserve, but (I'm hoping) it pans out to greater rewards in the end, even apart from money. Good luck and stay strong.
38 comments
[ 2.2 ms ] story [ 140 ms ] threadSums it up pretty well.
Great job as always Egor :)
BAM! You now know what sites you have used it on.
The attacker never linked your personal Facebook account to anything.
The closest thing we have right now is the EFF https://www.eff.org/
I don't use CVE much, just know about it's existence. Are there properties of this database that make it less than what you're pitching?
> Now to all OAuth flows Facebook will respond with Attacker's profile information and Attacker's uid.
> as long as attacker can replace your identity on Facebook with his identity and connect their Facebook account to victim's account on the website just loading CLIENT/fb/connect URL.
was not clear to me.
Thus, if a site has URLs that can be constructed to make a 302 to an attacking site, like https://www.google.com/redirect?url=http://www.example.com/, it's possible to craft a redirect URL that would take you to the authentication dialog but return the token to a redirect URL which will in turn pass the token to the attacker.
- User wants to create a new account at website.com
- website.com has been compromised to inject the attackers facebook login
- User chooses to create an account by linking with facebook. They click Link with Facebook and are redirected back to website.com logged into their new account
- Attacker can now access User's account on website.com by logging in with the injected facebook credentials
It seems like the attacker would need to somehow generate a unique facebook login for each exploited user though. I think if you try to "connect with facebook" with a website that already has an account for the facebook login it often logs you in rather then creates an additional account.
The security being breached is on the other site, not Facebook (perhaps why they are less concerned about it).
The first issue manifests itself if 1) an account has been previously registered on a client site, 2) that site offers the ability to "link" that existing account with a Facebook account, and 3) the action that performs the linking on the client site is vulnerable to CSRF. If you're a developer implementing conditions 1 & 2, make sure the linking action is protected by your anti-CSRF framework. Requiring explicit consent prior to linking accounts is a good idea for a number of reasons beyond this attack.
The second issue builds on what Egor refers to as "OAuth's Achilles' Heel": if the client site contains Open Redirect or XSS vulnerabilities, those vulnerabilities can often be leveraged to compromise the OAuth credential. To greatly reduce the likelihood of this attack, you should restrict which endpoints on your domain are capable of participating in the OAuth flow. See Facebook's Best Practices for Login Security guide[1], specifically the "Specify a whitelist of OAuth redirect URLs" section. Of course, you probably want to fix any Open Redirect & XSS vulnerabilities as well.
[1] https://developers.facebook.com/docs/facebook-login/security...
Egor privately contacted my little site a couple weeks ago to let us know we had a vulnerability with the redirect issue. At first, we didn't quite understand it, but once we dug deeper, it is a pretty major issue.
Simply put, we use ElasticEmail to send out email from our service. They have a feature called 'custom tracking domain' where you can setup tracking.your_domain.xyz to enable link tracking of emails you send out. This is great except that the url is something like this: tracking.your_domain.xyz?redirect=urlencode(some other domain) <- EE will then do a redirect to whatever is specified in there.
Because we offer facebook connect authentication on our site, this created a security hole for us based on what Egor has discovered. In other words, because we setup some simple configuration of some 3rd party service that happens to allow for redirects, we are now exposing our users auth tokens. Doh!
The solution to fix this is to simply not enable tracking.your_domain.xyz, but now that we've turned that off, old links in emails are broken. If EE had tinyurl'd the links they send out, this wouldn't have been an issue because it wouldn't be an open redirect service. The emails would have to go through them, get rewritten and then they would store the unique ID to do the redirect. Yes, we've contacted EE about it and they are looking into it, but probably not seriously since it isn't really their bug per se. In a way, this is similar to what FB is saying to Egor (not our issue), but the fact is that a simple bit of configuration by people using these systems can really cause a lot of problems.
In the end, it all really means that you have facebook connect on your site, you absolutely need to do an audit of your code and 3rd party systems and make 100% sure that you don't have any open redirects on your domains. This is a lot harder than it sounds.
As time goes on, I really hope we move to systems like Persona which haven't had these sorts of issues (so far). We also support Persona login on our site (as well) and it has been excellent. Being an open standard and allowing for multiple identity providers makes the chances of 'wontfix' a lot less of an issue.
It's sad to see a researcher so talented and committed be pushed to the dark side simply because companies decide their bugs aren't "worth it"
Original post (now edited): http://egorhomakov.com/post/72088934127/year-2013