IETF Logo Mail Archive

[OAUTH-WG] Report an authentication issue

rui wang <ruiwangwarm@gmail.com> Thu, 14 June 2012 17:18 UTC

Return-Path: <ruiwangwarm@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 A730E21F8675 for <oauth@ietfa.amsl.com>; Thu, 14 Jun 2012 10:18:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 o-x-f8BVELhD for <oauth@ietfa.amsl.com>; Thu, 14 Jun 2012 10:18:17 -0700 (PDT)
Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEC821F8669 for <oauth@ietf.org>; Thu, 14 Jun 2012 10:18:17 -0700 (PDT)
Received: by ggnc4 with SMTP id c4so1772202ggn.31 for <oauth@ietf.org>; Thu, 14 Jun 2012 10:18:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=YB6XJ0lMzBG0BgYglXm9t/K7BS8APXY08OHmojXRVR8=; b=V832Ih/RjmlZVof5F0zfOLKbISpYBHnLnSPLmnvHxM/BL2TQGbQ2WbCel0nlysEiaB XRhrX/qaX76gNNdt4XcbY1D3zKYnR48NcF+Rz+tX8/10KvnIMejgwQE3AHhZfegMuGW/ Shoq/dCDpwuI2y4wy9UCxSR8wOYUWDCZIRsdnYPTPABYillr239sMowH93H42a+nC7fY NAwnjifIEEYeIBXGeQw3fb4Eo+NseOD57xymGoaIjUT0xxBtPkktlxQeRv1+rHQdGT1L rlpsAgoK20fZMeUTOHbG8g3/4E62RkstKGTQ+ZZDcf44W+IIGKuRujCgVWrZGx1tkhya vqgQ==
MIME-Version: 1.0
Received: by 10.50.160.234 with SMTP id xn10mr13116536igb.61.1339694296856; Thu, 14 Jun 2012 10:18:16 -0700 (PDT)
Received: by 10.43.46.200 with HTTP; Thu, 14 Jun 2012 10:18:16 -0700 (PDT)
Date: Thu, 14 Jun 2012 10:18:16 -0700
Message-ID: <CAEEmcpEcNqNHwfVozD-NtfkruiB-v0MTszwNL4cob2rL=QQTSA@mail.gmail.com>
From: rui wang <ruiwangwarm@gmail.com>
To: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="14dae9340303abf8c004c271e24d"
Cc: Yuchen Zhou <t-yuzhou@microsoft.com>, "Shuo Chen (MSR)" <shuochen@microsoft.com>
Subject: [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 17:19:17 -0000

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

v2.23.0 | Report a Bug | By Email