Re: [OAUTH-WG] Phishing with Client Application Name Spoofing

André DeMarre <andredemarre@gmail.com> Mon, 16 January 2012 23:20 UTC

Return-Path: <andredemarre@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 4100521F86BE for <oauth@ietfa.amsl.com>; Mon, 16 Jan 2012 15:20:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 kXyHx47C42kK for <oauth@ietfa.amsl.com>; Mon, 16 Jan 2012 15:20:04 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5E88021F86AF for <oauth@ietf.org>; Mon, 16 Jan 2012 15:20:04 -0800 (PST)
Received: by iaae16 with SMTP id e16so10194064iaa.31 for <oauth@ietf.org>; Mon, 16 Jan 2012 15:20:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hfshg++KyPmJOT/JedZc1/AucjhNd9lVgK8hJNu0RfU=; b=tQeLjqgG9omM2xbQr7+rM2sQra546Gxr4uvA03yNU2lw7SADHMWSW+C+M+4wpVDqdB IY3TFXmADHOdxOXl+eHwwYiiQJdpaQkU9dTWI+GnNOm7OQnJdiLEeSdSJE/yFkOduwLm rAJUm5vsESVr+0WD7/9eu4UFfspnNqBEMZJF4=
MIME-Version: 1.0
Received: by 10.42.29.6 with SMTP id p6mr11848268icc.44.1326756002210; Mon, 16 Jan 2012 15:20:02 -0800 (PST)
Received: by 10.42.224.5 with HTTP; Mon, 16 Jan 2012 15:20:02 -0800 (PST)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453A754C534@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <CAEwGkqDscS5ke4KmoVUF3nDjS-1b+SuT_hCb59+rCuokmhPOVQ@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723453A754C534@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Mon, 16 Jan 2012 15:20:02 -0800
Message-ID: <CAEwGkqDV8qdYPyHYNtBF-SXLGA0CDxOgbCszafhp4ejuVwuT_w@mail.gmail.com>
From: André DeMarre <andredemarre@gmail.com>
To: Eran Hammer <eran@hueniverse.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Phishing with Client Application Name Spoofing
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: Mon, 16 Jan 2012 23:20:05 -0000

Eran,

Yes; I think a section should be added to the security model doc.

On 2011-12-16 Mark Mcgloin agreed and suggested we call it "Client
Registration of phishing clients":
http://www.ietf.org/mail-archive/web/oauth/current/msg08061.html

I'm happy to propose the text; it might be one or two days though.

Regards,
Andre DeMarre

On Mon, Jan 16, 2012 at 10:30 AM, Eran Hammer <eran@hueniverse.com> wrote:
> Should this be added to the security model document? Is it already addressed there?
>
> EHL
>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of André DeMarre
>> Sent: Tuesday, October 04, 2011 11:33 AM
>> To: OAuth WG
>> Subject: [OAUTH-WG] Phishing with Client Application Name Spoofing
>>
>> I've not seen this particular variant of phishing and client impersonation
>> discussed. A cursory search revealed that most of the related discussion
>> centers around either (a) client impersonation with stolen client credentials
>> or (b) phishing by malicious clients directing resource owners to spoofed
>> authorization servers. This is different.
>>
>> This attack exploits the trust a resource owner has for an OAuth
>> authorization server so as to lend repute to a malicious client pretending to
>> be from a trustworthy source. This is not necessarily a direct vulnerability of
>> OAuth; rather, it shows that authorization servers have a responsibility
>> regarding client application names and how they present resource owners
>> with the option to allow or deny authorization.
>>
>> A key to this exploit is the process of client registration with the authorization
>> server. A malicious client developer registers his client application with a
>> name that appears to represent a legitimate organization which resource
>> owners are likely to trust. Resource owners at the authorization endpoint
>> may be misled into granting authorization when they see the authorization
>> server asserting "<some trustworthy name> is requesting permission to..."
>>
>> Imagine someone registers a client application with an OAuth service, let's
>> call it Foobar, and he names his client app "Google, Inc.". The Foobar
>> authorization server will engage the user with "Google, Inc. is requesting
>> permission to do the following." The resource owner might reason, "I see
>> that I'm legitimately on the https://www.foobar.com site, and Foobar is
>> telling me that Google wants permission. I trust Foobar and Google, so I'll
>> click Allow."
>>
>> To make the masquerade act even more convincing, many of the most
>> popular OAuth services allow app developers to upload images which could
>> be official logos of the organizations they are posing as. Often app
>> developers can supply arbitrary, unconfirmed URIs which are shown to the
>> resource owner as the app's website, even if the domain does not match the
>> redirect URI. Some OAuth services blindly entrust client apps to customize
>> the authorization page in other ways.
>>
>> This is hard to defend against. Authorization server administrators could
>> police client names, but that approach gives them a burden similar to
>> certificate authorities to verify organizations before issuing certificates. Very
>> expensive.
>>
>> A much simpler solution is for authorization servers to be careful with their
>> wording and educate resource owners about the need for discretion when
>> granting authority. Foobar's message above could be
>> changed: "An application calling itself Google, Inc. is requesting permission to
>> do the following" later adding, "Only allow this request if you are sure of the
>> application's source." Such wording is less likely to give the impression that
>> the resource server is vouching for the application's identity.
>>
>> Authorization servers would also do well to show the resource owner
>> additional information about the client application to help them make
>> informed decisions. For example, it could display all or part of the app's
>> redirect URI, saying, "The application is operating on example.com" or "If you
>> decide to allow this application, your browser will be directed to
>> http://www.example.com/." Further, if the client app's redirect URI uses TLS
>> (something authorization servers might choose to mandate), then auth
>> servers can verify the certificate and show the certified organization name to
>> resource owners.
>>
>> This attack is possible with OAuth 1, but OAuth 2 makes successful
>> exploitation easier. OAuth 1 required the client to obtain temporary
>> credentials (aka access tokens) before sending resource owners to the
>> authorization endpoint. Now with OAuth 2, this attack does not require
>> resource owners to interact with the client application before visiting the
>> authorization server. The malicious client developer only needs to distribute
>> links around the web to the authorization server's authorization endpoint. If
>> the HTTP service is a social platform, the client app might distribute links using
>> resource owners' accounts with the access tokens it has acquired, becoming
>> a sort of worm. Continuing the Google/Foobar example above, it might use
>> anchor text such as "I used Google Plus to synchronize with my Foobar
>> account." Moreover, if the app's redirect URI bounces the resource owner
>> back to the HTTP service after acquiring an authorization code, the victim will
>> never see a page rendered at the insidious app's domain.
>>
>> This is especially dangerous because the public is not trained to defend
>> against it. Savvy users are (arguably) getting better at protecting themselves
>> from traditional phishing by verifying the domain in the address bar, and
>> perhaps checking TLS certificates, but such defenses are irrelevent here.
>> Resource owners now need to verify not only that they are on the legitimate
>> authorization server, but to consider the trustworthyness of the link that
>> referred them there.
>>
>> I'm not sure what can or should be done, but I think it's important for
>> authorization server implementers to be aware of this attack. If
>> administrators are not able to authenticate client organizations, then they
>> are shifting this burden to resource owners. They should do all they can to
>> educate resource owners and help them make informed decisions before
>> granting authorization.
>>
>> Regards,
>> Andre DeMarre
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth