*From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On
Behalf Of *Kristofor Selden
*Sent:* Saturday, June 16, 2012 11:33 AM
*To:* nov matake; oauth
*Cc:* Yuchen Zhou; Luke Melia; Shuo Chen (MSR)
*Subject:* Re: [OAUTH-WG] Report an authentication issue
Nov demonstrated the problem to us at Yapp and we used solution 4
(because the solution is server side and our app was in the app store).
FB Connect is authentication /and/ authorization, where OAuth 2 is
concerned only with authorization -- I'm not sure that app developers
appreciate this subtlety.
With OAuth 2 you authorize an app to use a protected resource. With
FB Connect, you do that, but /also/ authenticate with the app you are
authorizing.
So the access_token protects not just the FB resources but the auth
end point of the authorized app (very common with apps that use the
iOS SDK). So now the app needs a way to verify that it was the app
that was authorized to FB.
Solution 4 explanation: on FB you can register a iPhone app and a
server app with the same client_id and get a client_secret for use on
the server. The server side API posts the access_token, client_id,
and client_secret to https://graph.facebook.com/app
<https://graph.facebook.com/app?access_token=YOUR_TOKEN> to verify
that the bearer token actually belongs to the app that is being
authenticated before assuming they are authorized to the app's
protected resources.
Kris
On Jun 15, 2012, at 8:22 PM, nov matake wrote:
There are 4 ways to fix this issue.
1. Use response_type=token%20code (It's not in OAuth 2.0 Core, but
seems best way for interoperability)
2. Use singed_request (or some signed token like JWT)
3. Use grant_type=fb_exchange_token (Facebook custom way)
4. Access to https://graph.facebook.com/app?access_token=YOUR_TOKEN
(Facebook custom way, moreover undocumented API)
Two iPhone app developers I reported this issue fixed it by using (4).
I also tried to use (1) for my own iPhone app implementation, but
unfortunately it doesn't work when using authorization codes obtained
via FB iOS SDK.
So I'm using (3) in my case.
nov
On 2012/06/16, at 9:16, Nat Sakimura wrote:
As to how the fix was done, Nov can provide more detail, but ...
1. Properly verify the signature/HMAC of the "signed_request". This
will essentially audience restricts the token.
2. There is an undocumented API for Facebook which returns to whom the
token was issued. This also audience restricts the token.
The service that fixed took these measures. Note that none of the
above is defined in OAuth.
The same facility was called "id_token" and "check ID endpoint" for
OpenID Connect.
The scale of the impact is large, too large to disclose the actual
names in the public list, though, eventually, we would publish them in
a paper.
Nat
On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella
<fcore...@pomcor.com <mailto:fcore...@pomcor.com>> wrote:
Hi Nat and Rui,
Rui, you say that the vulnerability that you found was due to a
"common misunderstanding among developers", but the attack you
describe can be carried out against any app that uses the OAuth
"implicit grant flow", which Facebook calls "client-side
authentication". No misunderstanding seems necessary. What
misunderstanding are you referring to? I followed the link in your
message to the Sophos post, and from there the link to the article in
The Register. The article in The Register says that Facebook had
"fixed the vulnerability promptly". How did they fix it? The
instructions that Facebook provides for implementing "Client-side
authentication without the JS SDK" at
https://developers.facebook.com/docs/authentication/client-side/#no-jssdk
still allows the attack.
Nat, I agree that the blog post by John Bradley that you link to
refers to the same vulnerability reported by Rui. You say that some
apps have issued a patch to fix it. Could you explain what the fix
was?
Francisco
------------------------------------------------------------------------
*From:*Nat Sakimura <sakim...@gmail.com <mailto:sakim...@gmail.com>>
*To:* rui wang <ruiwangw...@gmail.com <mailto:ruiwangw...@gmail.com>>
*Cc:* matake nov <n...@matake.jp <mailto:n...@matake.jp>>; Yuchen
Zhou <t-yuz...@microsoft.com <mailto:t-yuz...@microsoft.com>>;
oauth <oauth@ietf.org <mailto:oauth@ietf.org>>; Shuo Chen (MSR)
<shuoc...@microsoft.com <mailto:shuoc...@microsoft.com>>
*Sent:* Thursday, June 14, 2012 1:50 PM
*Subject:* Re: [OAUTH-WG] Report an authentication issue
This is a fairly well known (hopefully by now) issue. We, at the
OpenID Foundation, call it "access_token phishing" attack these
days. See:
http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html
Nov Matake has actually built the code on iPhone to verify the
problem, and has notified bunch of parties back in February
including Facebook and Apple. We have the code that actually runs
on a phone, and we have successfully logged in to bunch of apps,
including very well known ones. They were all informed of the
issue. Some immediately issued a patch to fix it while others have
not.
The problem is that even if these apps gets fixed, the problem
does not go away. As long as the attacker has the vulnerable
version of the app, he still can impersonate the victim. To stop
it, the server side has to completely disable the older version,
which means the service has to cut off many users pausing business
problems.
Nat
On Fri, Jun 15, 2012 at 2:18 AM, rui wang <ruiwangw...@gmail.com
<mailto:ruiwangw...@gmail.com>> wrote:
Dear Facebook Security Team and OAuth Standard group,
We are a research team in Microsoft Research. In January, 2011, we
reported a vulnerability in Facebook Connect which allowed
everyone to sign into Facebook-secured relying parties without
password. It was promptly fixed after reporting.
(http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/)
Recently, we found a common misunderstanding among developers of
mobile/metro apps when using OAuth (including Facebook's OAuth)
for authentication. The vulnerability resulted from this
misunderstanding also allows an attacker to log into a victim
user's account without password.
Let's take Soluto's metro app as an example to describe the
problem. The app supports Facebook Login. As an attacker, we can
write a regular Facebook app. Once the victim user allows our app
to access her Facebook data, we receive an access_token from the
traffic. Then, on our own machine (i.e., the "attacker" machine),
we run the metro app of Soluto, and use a HTTP proxy to insert the
victim's access_token into the traffic of Facebook login. Through
this way, we are able to log into the victim's Soluto account from
our machine. Other than Soluto, we also have confirmed the same
issue on another Windows 8 metro-app Givit.
The Facebook SDK for Android apps
(https://developers.facebook.com/docs/mobile/android/build/#sdk)
seems to have the possibility to mislead developers too. At least,
the issue that we found is not clearly mentioned. In the SDK, we
ran the sample code called "Hackbook" using Android Emulator
(imagine it is an attacker device). Note that we have already
received the access token of the victim user from our regular
Facebook app. We then inject the token to the traffic of Hackbook.
Through this way, Hackbook app on our own machine recognizes us as
the victim. Note that this is not a convincing security exploit
yet, because this sample code does not include the server-side
code. However, given that we have seen real server-side code
having this problem, such as Soluto, Givit and others, we do
believe that the sample code can mislead mobile/metro developers.
We also suspect that this may be a general issue of many OAuth
implementations on mobile platforms, so we send this message to
OAuth Standard group as well.
We have contacted the vendors of the two vulnerable metro-apps,
Soluto and Gavit.
Please kindly give us an ack when you receive this message. If you
want to know more details, please let us know.
Best Regards,
Yuchen Zhou, Rui Wang, and Shuo Chen
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
