That sounds like the recent Twitter / thunderclap issue (thunderclap collected multiple twitter update tokens on a single server to allow simultaneous tweets to occur from huge numbers of twitter accounts).
If BobApp was previously approved as a client and the SP discovered BobApp was mis-behaving (witness the recent thunderclap twitter scenario), the SP can simply revoke to tokens issued to BobApp. This just demonstrates why a server should never depend on parseable bearer tokens by themselves. SPs should check for token revocation. Phil @independentid www.independentid.com phil.h...@oracle.com On 2012-06-15, at 4:22 PM, Shuo Chen (MSR) wrote: > The attack does not involve sniffing. It is about an app (let’s call it > BobApp) running on victim Alice’s tablet, which is able to get the access > token. > Note that BobApp getting this access token on Alice’s device is NOT a > security issue, but the natural consequence of the design of OAuth. > > However, the real problem we concern about is that server-side authentication > logic takes this 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. This implementation pattern causes the real security problem, because > BobApp could send the token to the attacker Bob, who can now authenticate > into the server as Alice on Bob’s tablet. > > Ø and then letting another client use that token > So “letting another client use the token” is not THE vulnerability, but an > attack step that BobApp voluntarily does to exploit the server-side > vulnerability. > > Thanks, > -Shuo > > From: Phil Hunt [mailto:phil.h...@oracle.com] > Sent: Friday, June 15, 2012 3:59 PM > To: rui wang > Cc: Francisco Corella; matake nov; Yuchen Zhou; oauth; Shuo Chen (MSR) > Subject: Re: [OAUTH-WG] Report an authentication issue > > 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 > phil.h...@oracle.com > > > > > > 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 <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> > To: rui wang <ruiwangw...@gmail.com> > Cc: matake nov <n...@matake.jp>; Yuchen Zhou <t-yuz...@microsoft.com>; oauth > <oauth@ietf.org>; Shuo Chen (MSR) <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> 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 > 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 > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
