

Two "WontFix" vulnerabilities in Facebook Connect - homakov
http://homakov.blogspot.com/2014/01/two-severe-wontfix-vulnerabilities-in.html??

======
arice
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...](https://developers.facebook.com/docs/facebook-
login/security/)

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

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

Sums it up pretty well.

Great job as always Egor :)

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

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

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

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

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

~~~
loceng
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?

~~~
forgottenpass
[http://cve.mitre.org/cgi-
bin/cvekey.cgi?keyword=facebook](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?

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

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

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

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

------
grrowl
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](http://egorhomakov.com/post/72088934127/year-2013)

~~~
homakov
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 :)

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

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

~~~
homakov
Yes, it is = user interaction

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

~~~
reubenmorais
Yes,
[https://www.facebook.com/settings?tab=applications](https://www.facebook.com/settings?tab=applications)

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

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

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

