Two "WontFix" vulnerabilities in Facebook Connect | Hacker News Reader

Two "WontFix" vulnerabilities in Facebook Connect

homakov.blogspot.com

188 pointshomakov35 comments

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.

[1] https://developers.facebook.com/docs/facebook-login/security...

This is a serious thing Egor is bringing up.

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.

"In my opinion I'd recommend not using Facebook Connect in critical applications"

Sums it up pretty well.

Great job as always Egor :)

I'm addicted to these blog posts, the guy is like some sort of magician.

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.

was not clear to me.

I believe it would work as follows.

- 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.

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.

You would be ASHAMED how many websites and companies with software have "Won't fix vulnerabilities". The list to which I have reported is long....

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?

http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=facebook ?

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?

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.

Thats a genuinely great idea! If that site had decent image/marketing, it could go a long way into shaming companies into secure practices.

The closest thing we have right now is the EFF https://www.eff.org/

They should get a BugTraq ID or go into OSVDB, however, that isn't always the case. These should be reported, and if they are serious, documented.

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).

Yeah, it's breached on the website but it's fb who's in charge.

Not to the button but to create a dummy form. Simple csrf. Relogin leads to identity fixation

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"

Original post (now edited): http://egorhomakov.com/post/72088934127/year-2013

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.

Good on you :)

I'm surprised he hasn't been recruited. Or maybe he just turns down all the headhunters...

I am really not into fulltime job. Doing consulting suits me much more

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.

Yes, it is = user interaction

Any way to find out what sites you have used this on in the past?

Yes, https://www.facebook.com/settings?tab=applications

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.

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.

BAM! You now know what sites you have used it on.

Snarky AND wrong, well done.

Another reason I use NoScript, Disconnect and LightBeam, and also don't use Facebook.

You can be even more secure by not using the web in the first place!

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.

Reply on news.ycombinator.com