Hi Rui, my fault about the Sophos link. I hadn't read your message carefully
enough, otherwise I would have realized that it was unrelated. - Francisco
>________________________________
> From: rui wang <[email protected]>
>To: Francisco Corella <[email protected]>
>Cc: Nat Sakimura <[email protected]>; matake nov <[email protected]>; Yuchen
>Zhou <[email protected]>; oauth <[email protected]>; Shuo Chen (MSR)
><[email protected]>
>Sent: Friday, June 15, 2012 3:06 PM
>Subject: Re: [OAUTH-WG] Report an authentication issue
>
>
>Hi, Francisco
>
>Thank you for your reply. Here is our response for your questions.
>
>Ø the attack you describe can be carried out against any app that uses the
>OAuth "implicit grant flow", which Facebook calls "client-side authentication".
>
>The main concern we raised here is not about attacking client-side apps. We
>don’t think it is a meaningful security consequence when a client-side
>application (e.g., a Win8 Metro app, iPhone/iPad app) on the attacker’s tablet
>misidentifies the user as the victim user. Therefore, you are right about
>“this kind of attack can be carried out against any app using the OAuth
>‘implicit grant flow’”. In fact we won’t even call this consequence as an
>attack.
>The real problem is that in multiple occasions, we found that the server-side
>authentication logic takes an access token from the client app, then queries
>the user's profile data from the IdP in order to "authenticate" the user into
>the server. We have confirmed that the servers for Soluto Metro App, Givit
>Metro App and EuroCup2012 Metro App make this mistake. These are apps in the
>official Windows 8 App Store. We only sampled a small portion of the available
>apps, but believe this is a vulnerability pattern due to a common
>misunderstanding of the usage of the access token.
>
>Ø 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.
>
>I am very sorry for the confusion. The link to Sophos has nothing to do with
>this problem. It is about another issue we reported last year. I mentioned
>this because the email yesterday was sent to Facebook and the OAuth mailing
>list at the same time. I was trying to let the Facebook team know we had
>previous communication before. I should have removed this part in the version
>sent to OAuth. Again, sorry for not removing this reference. Please ignore it.
>
>Thanks,
>Rui
>On Fri, Jun 15, 2012 at 1:34 PM, Francisco Corella <[email protected]> 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 <[email protected]>
>>>To: rui wang <[email protected]>
>>>Cc: matake nov <[email protected]>; Yuchen Zhou <[email protected]>; oauth
>>><[email protected]>; Shuo Chen (MSR) <[email protected]>
>>>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 <[email protected]> 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
>>>>[email protected]
>>>>https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>
>>>
>>>
>>>--
>>>Nat Sakimura (=nat)
>>>Chairman, OpenID Foundation
>>>http://nat.sakimura.org/
>>>@_nat_en
>>>
>>>_______________________________________________
>>>OAuth mailing list
>>>[email protected]
>>>https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>
>
>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
