

How we hacked Facebook with OAuth2 and Chrome bugs - maccman
http://homakov.blogspot.com/2013/02/hacking-facebook-with-oauth2-and-chrome.html

======
gdeglin
This is clever. The Chrome team likely made a major oversight when they made
the decision to introduce the 1;mode=block value for the X-XSS-Protection
header.

Interesting to see that Facebook responded by disabling the XSS protection
header altogether.

Most likely the reason Facebook didn't just set it to X-XSS-Protection: 1 is
because a similar technique could then be used to defeat Javascript based
clickjacking protection.

~~~
JohnLBevan
It seems strange that you can use a browser bug to get into a site. Since the
browser's outside of FB's control (i.e. theoretically anyone could write their
own, including one which said it was Chrome but had been created for malicious
purposes) any security protocol should not rely on browser implementations.

~~~
mimiflynn
This isn't unprecedented. IE6 has been used to attack websites in the past.
[http://www.theregister.co.uk/2010/02/01/ie6_microsoft_uk_gov...](http://www.theregister.co.uk/2010/02/01/ie6_microsoft_uk_government/)

~~~
at-fates-hands
Max Butler is famous for using the HTML application in IE to harvest credit
card information way back in 1999.

------
jxf
For people interested in "reducing OAuth2's attack surface", as Egor proposes,
you should check out his post for suggestions on improving the spec (which he
calls "OAuth 2.a"):

[http://homakov.blogspot.com/2012/08/saferweb-oauth2a-or-
lets...](http://homakov.blogspot.com/2012/08/saferweb-oauth2a-or-lets-just-
fix-it.html)

His two most important suggestions are (1) make redirect_uri an exact
whitelist instead of allowing pattern-matching and a single domain, and (2)
scopes should be set by the user via the provider.

These are both very reasonable adjustments, and could likely be accommodated
without too much headache by existing providers. However, they are technically
spec-breaking, so this would be more like OAuth 3 than 2.a.

~~~
boucher
Supporting a dynamic redirect_uri is optional in the spec, so you could
eliminate that without breaking.

------
aaronbrethorst
I'm rather surprised Egor is still an indie. Is this by his choice? He seems
quite talented.

edit: Ahh, I should've looked more closely. This is just his hobby:
<http://homakov.blogspot.com/p/service.html>

~~~
homakov
not really. I decided to switch to security researching finally. It's almost a
year after a github hack. I changed my mind. I love it.

~~~
homakov
BTW, shame on me but: Yes, you can hire me for an audit :)

~~~
ShaneOfAllTrade
I would love a read on how to think like you!

------
nicholassmith
Interesting to see Homakov having a pretty solid run with some very
interesting exploits after the GitHub exploit, I thought that he may have been
burned by the experience and put off from active research. Apparently you
can't keep a good security researcher down.

Definitely interesting with OAuth2 having a 'huge attack surface', I'd love to
hear some more about that given how many companies have started using it for
securing API access amongst other things.

~~~
martinced
Regarding OAuth2 it should be noted that one person quit the OAuth2 board/spec
in disgust saying how lame and insecure the whole thing was.

And nobody listened to him. And he was right.

Some things are too complex to ever be secure and OAuth2 seems to be one of
these things.

~~~
6cxs2hd6
> one person

The lead author and editor, Eran Hammer.

[http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-
hell...](http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/)

------
jtheory
The chief problem with OAuth2 is that you can do almost anything and call it
"OAuth2" -- the spec is ridiculously flexible, and allows all kinds of options
that are explicitly stated within the spec as not advised.

I'm fairly sure most of the flexibility is there to help migrating enterprise
and legacy apps to OAuth2. It's not a great approach, though -- enough
security disasters and the problems of migrating will simply go away, because
the poor rep of the mechanism will mean no migrations are happening.

I'm using OAuth2 for an API, but a small subset of it that doesn't seem to
permit the abuse Egor covers -- though I'm going over it with a fine-toothed
comb now. XSS vulnerabilities are more subtle than most other hacks, and so
the dangers aren't as obvious in a simple review.

~~~
homakov
but root of insecureness is OAuth2 spec, why would someone implement
response_type as a parameter? Aha, spec says so! Why would anyone set
redirect_uri dynamic, not static? Spec allows! Scope as a parameter, not a
setting? Hi, spec!

~~~
jtheory
Implementing the spec, you pick & choose.

I don't support alternative response_types; I don't support dynamic
redirect_uri (at the moment, it's completely static; in future we may offer
the list option), and the allowed scope for a given client is set during setup
-- you can't then request a scope you aren't authorized for, given your client
id.

I'm not breaking the spec -- it offers all of these paths as options. You
don't have to implement all of the possibilities the spec covers.

The bad thing about the spec is that some of the possible paths are indeed
less secure (it even says so in the spec in places...), so the security of
your OAuth2 implementation is purely up to your judgement.

The nice thing about _good_ specs is that you benefit from the presumably-
better judgement of the folks designing the spec....

------
thepumpkin1979
Seems like homakov is making a name for himself, it's always interesting to
see what he finds out. Can anybody recommend me other blogs with even more
info about security holes in known platforms?

~~~
reginaldo
Some blogs I like (most are not updated very frequently, though):

Billy Rios (discovered GIFAR) <http://xs-sniper.com/blog/>

Michal Zalewski (one of the top security researchers in the world, wrote "The
Tangled Web", a must-read) <http://lcamtuf.blogspot.com>

Neal Poole: <https://nealpoole.com/blog/>

Nir Goldshlager: <http://www.nirgoldshlager.com/>

Michael Brooks: <https://sitewatch.me/en/Blog>

Nils Jünemann: <http://www.nilsjuenemann.de/>

Stefano di Paola (Minded Security): <http://blog.mindedsecurity.com/>

Root Labs: <http://rdist.root.org/>

------
josh2600
Cute.

I'm really looking forward to the next article. I've heard talk of OAuth2 as
an enterprise authentication mechanism and it's stuff like this that helps
keep everyone honest.

That being said I'd much rather be the guy who has 10000 folks banging away at
his stack than the one who is never tested. It's hard to know which buckets
are leaking until you fill them.

------
hakaaaaak
This is why you shouldn't rely on third-party auth. Everyone using their own
auth may be more trouble for the user, but SSO through a private third-party
that the largest portion of users already use, is just asking for it. Don't
get me wrong, SSO is not bad. But, the bigger the subject, the more resources
will try to hack it. This can make the subject stronger and more secure over
the long-term, potentially, but in the meantime, you have to live with being
hacked much more frequently. Why not learn from others' mistakes rather than
be their victim, when it comes to security?

~~~
cmwright
Fair but sometimes it's unavoidable when you're trying to use third party APIs
such as Facebook or Google. The only option is to allow some sort of external
login (be it oauth or something similar)

~~~
shurane
Is there a solid alternative to OAuth that's third-party and not roll it your
own?

------
Tloewald
"In "real world" exploit we would use 100-200 most popular Facebook
applications and just gather all the available tokens. It would be awesome."

Highly entertaining (and illuminating) article.

------
instakill
Please get a book deal. I am absolutely positive it would do very well.

------
daemon13
Egor,

what you will do after you discover and disclose all vulnerabilities [or at
least the major ones]?

~~~
homakov
go to miami beach

------
daemon13
Can someone explain in plain language to a non-developer:

1\. I have web site

2\. I do not have FB app

3\. I have FB page

4\. I enable for users "Login with your FB account"

5\. I have FB Like button on the web site

Am I vulnerable and if yes, what's the vector/consequences?

Edit: formatting

~~~
capsule_toy
I'll take a shot at this, but I only did a cursory reading of the article.

To begin with, I don't believe you are vulnerable through this exploit any
more. Facebook has fixed this by changing the response in OAuth so that it
would no longer trigger the block redirect. In particular: "Facebook had '1;
mode=block' header. Now it's 0; because of us"

Every site using Facebook's OAuth was vulnerable. I don't believe the basic FB
like button actually uses OAuth, but using FB as a way to login to your site
would.

The vulnerability takes advantage of Chrome's handling of the above response
from the server. When it sees that response, it loads a separate page to
prevent the request from going through. The problem is this particular page
has details about the request, like OAuth credentials in the response, and
allows a third party script to have access to details about the request. Once
an attacker has access to OAuth credentials, they basically have access to the
login credentials for that user (ie as if the user's username and password
were compromised)

Any user that is logged in to FB can have their OAuth app credentials
compromised if they visited a site running this malicious code.

~~~
daemon13
Thank you!

------
xnxn
Really looking forward to that OAuth2 post.

------
AbhishekBiswal
You have a new fan here.

------
lazyjones
Complex designs and protocols suck, why do we put up with them?

~~~
yxhuvud
Because we have too many problems to solve.

~~~
lazyjones
We come up with these problems too and most of them aren't important. And how
are these things solutions, when they're always broken? OAuth 1.0, OAuth 2.0,
OpenID - all have their issues, none of them is a sensible solution, perhaps
the problem they pretend to solve is only a result of other bad designs?

------
kunil
isciurus' page is nsfw

------
joeblau
Does enabling 2 factor auth help stop this attack?

~~~
eric970
No.

------
afshinmeh
You rock buddy.

