Re: [OAUTH-WG] Report an authentication issue

Francisco Corella <fcorella@pomcor.com> Sat, 16 June 2012 00:27 UTC

Return-Path: <fcorella@pomcor.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5892111E807F for <oauth@ietfa.amsl.com>; Fri, 15 Jun 2012 17:27:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TOaQpHLfgvB for <oauth@ietfa.amsl.com>; Fri, 15 Jun 2012 17:27:26 -0700 (PDT)
Received: from nm7-vm2.bullet.mail.ne1.yahoo.com (nm7-vm2.bullet.mail.ne1.yahoo.com [98.138.90.155]) by ietfa.amsl.com (Postfix) with SMTP id 7471511E80CE for <oauth@ietf.org>; Fri, 15 Jun 2012 17:27:26 -0700 (PDT)
Received: from [98.138.90.53] by nm7.bullet.mail.ne1.yahoo.com with NNFMP; 16 Jun 2012 00:27:23 -0000
Received: from [98.138.88.236] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 16 Jun 2012 00:27:23 -0000
Received: from [127.0.0.1] by omp1036.mail.ne1.yahoo.com with NNFMP; 16 Jun 2012 00:27:23 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 273324.78546.bm@omp1036.mail.ne1.yahoo.com
Received: (qmail 31927 invoked by uid 60001); 16 Jun 2012 00:27:23 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1339806443; bh=aVgJ3+Mx/cNQtHExob4AUEVk53Pb5EA0gpHhAd0IpYg=; 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=b8v74m+t2OIFS3xig2QusAtDNIZ0oG4YPL1rpvh/zzv1D25fytOjhjAQxIvl61z8Z1vGrZj5IMO4Y3IyAsIxaFG3xVDkGpvUDmjz5yhB58O2xi0o6bEHgdF26jzvLE1W5zaFdC6qHHSot/jt9ClTgBlKlzvIc4ZQcPTXB+L7xz0=
X-YMail-OSG: bkJVVAMVM1m7u_xGMj4KPqxExQrSQEvqUia5bLhTsy0TaxB 9YL92iXFOhlxaT5JJ299FIsuEYmUNYvoA1sDXi1kr.2XaP51YIuHSjc7BKEO 8XMVpU7WZrnxpSMA9kTdQqWc.WBaPj7p4_de8zx_CoxClVS8L_3GZhG5R4_V fJyGNi.UEe2LR1VrlQGnaPd_UNrZ7k_H_PNctJ9o5cD2fRVHfM2GZCaHzItf P9JiXT1ELLDgapHX5tAkc2CsCb8Nwm8urK0jRnxg4N5_MwlRe7se6rwQMOFl EP1hPRFIw9NX_dqVEID9_ajn9rNTO5Q_TLZze_VAtRgXTgKXnCGGao3LK_P. SkeWXyjWsBHeBGpmQlssuY3wCOwpvHD9nrt1Nz5eGMnwj1MnKvt7qGPpbxy2 N7.nsoE7vHRFI8jGTXN6uVL1PG51RZwB0e6C.5SJv9oO3O8AN9HDtXFo82On vms5CxOZbSEpNDmEaeim6tfWCbRO3VvrzapxDfttM6u8e9iwquwx_jYqWsi8 SN11n2BgFb5PHkzP0H_k8LUJPqG_ezJofTJI9O2c2Ub6NPugt5se1iIwtw4L B4zAPKD4VoCHXYYZYgNOxekrROZ50WpdCMmobfpbYn3HmFsoIfVN9fp32uqo 2bNYDEHJw1dlDf3mwJ0tP.0sGlsV8.CjNN1PgdKZPavD1pHPA3gJO_S66ulR XISoqDofdaBJBPAR4z.xxxlbOgmIIlmZpzoKiFD2c1GEdl00MhFtryjZH2Bq LxhrtLxytMfg3PAihuVrVu_tlN5BthRvg8agSOJZTweNSYpwJ3WmGqyuCYkg bJYXfZgbnjSM9IDZjgSPu6tR9e5T1b5MnIOs3FqMFRS4HWAHjrPIoGZz_rel AEZE2pKGgKl8AcJ.r6BbUWotpEtxCHQtETf_piU2QMdoeyxfHMdtlq8jS.A- -
Received: from [68.8.105.216] by web125505.mail.ne1.yahoo.com via HTTP; Fri, 15 Jun 2012 17:27:22 PDT
X-RocketYMMF: francisco_corella
X-Mailer: YahooMailWebService/0.8.118.349524
References: <CAEEmcpEcNqNHwfVozD-NtfkruiB-v0MTszwNL4cob2rL=QQTSA@mail.gmail.com> <CABzCy2BZLff7EZoWaU+vmCWCgXUSSxn3x-evm-FwzKdnx7QeMA@mail.gmail.com> <1339792496.52712.YahooMailNeo@web125501.mail.ne1.yahoo.com> <CAEEmcpGP=Bz8Ng2tRzEBwtct5C_QD7J_U+rm4Hzdb+b6XUhTGw@mail.gmail.com>
Message-ID: <1339806442.14665.YahooMailNeo@web125505.mail.ne1.yahoo.com>
Date: Fri, 15 Jun 2012 17:27:22 -0700
From: Francisco Corella <fcorella@pomcor.com>
To: rui wang <ruiwangwarm@gmail.com>
In-Reply-To: <CAEEmcpGP=Bz8Ng2tRzEBwtct5C_QD7J_U+rm4Hzdb+b6XUhTGw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-781490481-1738368359-1339806442=:14665"
Cc: matake nov <nov@matake.jp>, Yuchen Zhou <t-yuzhou@microsoft.com>, oauth <oauth@ietf.org>, "Shuo Chen (MSR)" <shuochen@microsoft.com>
Subject: Re: [OAUTH-WG] Report an authentication issue
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Francisco Corella <fcorella@pomcor.com>
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Jun 2012 00:27:28 -0000

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 <ruiwangwarm@gmail.com>
>To: Francisco Corella <fcorella@pomcor.com> 
>Cc: Nat Sakimura <sakimura@gmail.com>; matake nov <nov@matake.jp>; Yuchen Zhou <t-yuzhou@microsoft.com>; oauth <oauth@ietf.org>; Shuo Chen (MSR) <shuochen@microsoft.com> 
>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 <fcorella@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 <sakimura@gmail.com>
>>>To: rui wang <ruiwangwarm@gmail.com> 
>>>Cc: matake nov <nov@matake.jp>; Yuchen Zhou <t-yuzhou@microsoft.com>; oauth <oauth@ietf.org>; Shuo Chen (MSR) <shuochen@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 <ruiwangwarm@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
>>>
>>>
>>>
>
>
>