Re: [OAUTH-WG] Report an authentication issue

Francisco Corella <> Fri, 15 June 2012 20:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 01AB111E809C for <>; Fri, 15 Jun 2012 13:35:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MMbNrs1cHggw for <>; Fri, 15 Jun 2012 13:34:58 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 5680C11E8088 for <>; Fri, 15 Jun 2012 13:34:58 -0700 (PDT)
Received: from [] by with NNFMP; 15 Jun 2012 20:34:57 -0000
Received: from [] by with NNFMP; 15 Jun 2012 20:34:57 -0000
Received: from [] by with NNFMP; 15 Jun 2012 20:34:57 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 58113 invoked by uid 60001); 15 Jun 2012 20:34:57 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1339792497; bh=KZu2T6TuFheiA6m/Sjxp/5JPsRZwIInlulZ6NmPjZ+Q=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=QmUF+vS9RF7K2iGGvxFTEuwQnmjo4rnB8mnnGQR99/Gh4UVcwcdP9sPm/MUQvgRd1rBsHU5kUAsjn89KcMAwA2QEM4Jnl1KerzsyYcV0mdCCLKISc02cEzVL7d0hnEWacigdYkZPG7VaIwNG10XtqxlT6lRO4c2/WkBEJIvopTE=
X-YMail-OSG: Nj3CzHwVM1kbNMV.igK0MT4rkuNtcPuGpuadlwE0cDWoLU5 kfn89x7.MrrQhKWkvQ4wp.GDgeSaKBl2AQmFUexB72gCmvjPlGGUq_NFoeyU mifhcSCO4yL01V27jl4X3CTDkNwN6RMpiHayGAdu1HlQkm7b8dgslXF2xrVS x55pNYig9mmR7shfzzWUTNIf_O4QZxEDWVZQwl3P.At52S3J1DWqhQlIOAY8 RQzUVd4mk_HuaqXbIZYmC6XsMucFnQXxBtt6PySQWbgoUJrr2BYTX1zJPy16 G.Q4.7g1hC588OhfEwidRYeetLZTOdcgtlnSFn2SJC1HdB6oafWnopyLCkN_ aMS879wob3tbWQ.uhsKXr.2cg0KqQXiwdk4F8c_z9o5RGS8HdN1YDgvdlKdQ WPoikhz3RU0RTmalmBHrWTVHj6UQTx2D7MwtMzdgLmXtzN8tUAb92Pw6czAF 4JZhUiL1JhYarQrAylDizoizLeB6DZpGOuY7NUbkTGXBSq.h.r14SEg4eJR_ DxrAHkT9Ria7NTaeton65jW7tkICPrBO0rGLeQuXqOwvEH9vGmRlVa6e1Che hyxZ5FvqV4OMl1ZA7unRz_83iOaWlTZPrMd2mlwjQdAwrzdz_AVOHcmi27O1 5zEI4zqb19h6Na.CTtzlztot0UoXa9KUHKAqJleZtCjKcqgenISiHSHXSHTk 4CEqbfA5ArhHO28HuDS3gx94HSYa.5aU86WqVdxpK.UCihU2vmSD3lfG1q6y e8T25FDUz0ioHZlA5HxAJpPfttmRN0wIkQX1eSS2zv.DvIAmt0ZtnkzcbipJ ectJyGi39KzT4X25OKwFoM7f74rlfjoSu1KEckko4yi664vz4GO.vhp1B6y3 oXLYe_VmbuAQapfR4HMSNHYN4LDj1HscJuVv8W5rkQEY5slhyfzxcR1q8pt4 -
Received: from [] by via HTTP; Fri, 15 Jun 2012 13:34:56 PDT
X-RocketYMMF: francisco_corella
X-Mailer: YahooMailWebService/
References: <> <>
Message-ID: <>
Date: Fri, 15 Jun 2012 13:34:56 -0700
From: Francisco Corella <>
To: Nat Sakimura <>, rui wang <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="329289550-1816854462-1339792496=:52712"
Cc: matake nov <>, Yuchen Zhou <>, oauth <>, "Shuo Chen (MSR)" <>
Subject: Re: [OAUTH-WG] Report an authentication issue
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Francisco Corella <>
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 15 Jun 2012 20:35:00 -0000

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
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


> From: Nat Sakimura <>
>To: rui wang <> 
>Cc: matake nov <>; Yuchen Zhou <>; oauth <>; Shuo Chen (MSR) <> 
>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:
>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. 
>On Fri, Jun 15, 2012 at 2:18 AM, rui wang <> 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. (
>>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 ( 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
>Nat Sakimura (=nat)
>Chairman, OpenID Foundation
>OAuth mailing list