Ok. Are you recommending specific changes that should be made to the group?
Phil On 2012-06-15, at 17:30, Nat Sakimura <[email protected]> wrote: > No. You do not need the sniffing in an unsecured connection. > > But I am not sure if I should disclose the detail of the attack here in the > public list as that will open up a much more serious attack vector than > leaked passwords hash in recent incidents. > > OAuth is not an authentication protocol. It is an access delegation protocol. > The fact that one has an authorization to access an API does not mean that he > is the subject. > There are bunch of assumptions that have to be fulfilled for OAuth to act as > an entity authentication. > If you pass a token from a client to another, e.g., from an APP to the server > side component, the assumption is violated. > And, this is not only the condition, but there are others as well. > > That's why we have been creating OpenID Connect. OpenID Connect adds bunch of > restrictions on OAuth 2.0. They are the things you have to do before you can > use OAuth 2.0 as an authentication protocol. > > Best, > > Nat > > On Sat, Jun 16, 2012 at 7:58 AM, Phil Hunt <[email protected]> wrote: > I am a bit confused. > > It sounds like you are sniffing a bearer token from an unsecured connection > to a resource server and then letting another client use that token. > > Is this correct? > > Phil > > @independentid > www.independentid.com > [email protected] > > > > > > On 2012-06-15, at 3:06 PM, rui wang wrote: > >> 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 > > > _______________________________________________ > 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
