Re: [OAUTH-WG] Report an authentication issue

Nat Sakimura <sakimura@gmail.com> Thu, 14 June 2012 20:50 UTC

Return-Path: <sakimura@gmail.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 C359D21F855F for <oauth@ietfa.amsl.com>; Thu, 14 Jun 2012 13:50:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 mD7a84VPdwW3 for <oauth@ietfa.amsl.com>; Thu, 14 Jun 2012 13:50:51 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 621C221F8551 for <oauth@ietf.org>; Thu, 14 Jun 2012 13:50:51 -0700 (PDT)
Received: by bkty8 with SMTP id y8so2064146bkt.31 for <oauth@ietf.org>; Thu, 14 Jun 2012 13:50:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+HsvMlYiUPLQRgADTRdLaDKcGFmnncQB84D79Ni3hmo=; b=RKHm2oiEiA/viPJ+bo7h7O+FPSV+x1K6sdpNoEnj8ONCbD07Rg0lDyRNc24Y1M4IDy 6LGj2Rpkg9uo91Kcjn2Qi3I3dqP1n/Lui9MsG1IrLAQ5qJsaw1vUq/r65Eej8g3N3DqB 5lMkWbPQQ5bhUrGw/MQv0Me+g/H6kxUrDzsMImdhe+gNT08O5KlX06RYhfCQ0SzKsGhb UljEgBKokRNq89XQCe9nqHcx5cf32ZbACPU4KOAV/FfeA5D/NjA0B04i5lVGc4FMKolI fHZ2nvTB01lUPyv5gwyYviG0PAZvf9x2jjp70gTxvQYtswNF5z6BACs3HllB4btCOwXA zyvw==
MIME-Version: 1.0
Received: by 10.204.151.200 with SMTP id d8mr1902990bkw.82.1339707050284; Thu, 14 Jun 2012 13:50:50 -0700 (PDT)
Received: by 10.204.240.143 with HTTP; Thu, 14 Jun 2012 13:50:50 -0700 (PDT)
In-Reply-To: <CAEEmcpEcNqNHwfVozD-NtfkruiB-v0MTszwNL4cob2rL=QQTSA@mail.gmail.com>
References: <CAEEmcpEcNqNHwfVozD-NtfkruiB-v0MTszwNL4cob2rL=QQTSA@mail.gmail.com>
Date: Fri, 15 Jun 2012 05:50:50 +0900
Message-ID: <CABzCy2BZLff7EZoWaU+vmCWCgXUSSxn3x-evm-FwzKdnx7QeMA@mail.gmail.com>
From: Nat Sakimura <sakimura@gmail.com>
To: rui wang <ruiwangwarm@gmail.com>
Content-Type: multipart/alternative; boundary="0015175cba84d5d91b04c274da51"
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
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: Thu, 14 Jun 2012 20:50:52 -0000

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