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

Torsten Lodderstedt <torsten@lodderstedt.net> Sat, 13 May 2017 10:07 UTC

Return-Path: <torsten@lodderstedt.net>
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 C403C129494 for <oauth@ietfa.amsl.com>; Sat, 13 May 2017 03:07:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.1
X-Spam-Level:
X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMBo9cRIr7Hb for <oauth@ietfa.amsl.com>; Sat, 13 May 2017 03:07:44 -0700 (PDT)
Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3333129B0F for <oauth@ietf.org>; Sat, 13 May 2017 03:05:39 -0700 (PDT)
Received: from [80.187.102.33] (helo=[10.155.159.117]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from <torsten@lodderstedt.net>) id 1d9Tvd-0003A2-0F; Sat, 13 May 2017 12:05:37 +0200
Content-Type: multipart/signed; boundary=Apple-Mail-D582D64D-F9F5-4337-8109-B2F6F12145CD; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
X-Mailer: iPhone Mail (14E304)
In-Reply-To: <CAEwGkqCjDf7EC6PSUEdwK_Y3hK_iayY0MU8R4XdZFEhFn-ebYA@mail.gmail.com>
Date: Sat, 13 May 2017 12:05:36 +0200
Cc: OAuth WG <oauth@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <18AE7BC9-1EAE-4012-BD38-94412328EBCD@lodderstedt.net>
References: <CAEwGkqDscS5ke4KmoVUF3nDjS-1b+SuT_hCb59+rCuokmhPOVQ@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723453A754C534@P3PW5EX1MB01.EX1.SECURESERVER.NET> <CAEwGkqDV8qdYPyHYNtBF-SXLGA0CDxOgbCszafhp4ejuVwuT_w@mail.gmail.com> <OF5C384B1A.F3404884-ON80257988.0041A466-80257988.00427E0B@ie.ibm.com> <CAEwGkqCjDf7EC6PSUEdwK_Y3hK_iayY0MU8R4XdZFEhFn-ebYA@mail.gmail.com>
To: =?utf-8?Q?Andr=C3=A9_DeMarre?= <andredemarre@gmail.com>
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/09CWSfkcBWhfPOPbS6XgaVQZNmk>
Subject: Re: [OAUTH-WG] Phishing with Client Application Name Spoofing
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 13 May 2017 10:07:48 -0000

two days can last for a very long time ;-) I will add this threat to the list to be covered by our new security draft.

> Am 10.05.2017 um 23:15 schrieb André DeMarre <andredemarre@gmail.com>;:
> 
> I see there is a new security considerations document being drafted. There is an old issue that I've recently been reminded of.
> 
> Should text about phishing conducted through the authorization dialog be added to the new security document? This kind of attack made headlines last week with a widespread Gmail / Google Docs phishing worm (https://security.googleblog.com/2017/05/protecting-you-against-phishing.html).
> 
> Five years ago, I was encouraged to propose text about this for the Threat Model and Security Considerations document, but I never did; sorry. Original thread in the mail archive: https://www.ietf.org/mail-archive/web/oauth/current/msg07625.html
> 
> This concerns both authorization dialog design and client registration, and as far as I know it's not really covered in any published documents. I'm not entirely sure what mitigations should be recommended, but I think authorization server implementers need to be more cognizant of this attack.
> 
> Regards,
> Andre DeMarre
> 
>> On Tue, Jan 17, 2012 at 4:06 AM, Mark Mcgloin <mark.mcgloin@ie.ibm.com>; wrote:
>> Andre
>> 
>> Please feel free to propose text, perhaps with a better title than I
>> suggested. During our discussion on section 4.1.4 (End-user credentials
>> phished using compromised or  embedded browser), we have decided on the
>> countermeasure below, albeit for a different threat - phishing client as
>> opposed to client name spoofing. Your's can be a variant of this with
>> different validation recommendations.
>> 
>> 
>> 2. Client applications could be validated prior to publication in an
>> application market for users to access. That validation is out of scope for
>> OAuth but could include validating that the client application handles user
>> authentication in an appropriate way
>> 
>> 
>> Regards
>> Mark
>> 
>> André DeMarre <andredemarre@gmail.com>; wrote on 16/01/2012 23:20:02:
>> 
>> >
>> > To:
>> >
>> > Eran Hammer <eran@hueniverse.com>; 16/01/2012 23:22
>> >
>> 
>> >
>> > Re: [OAUTH-WG] Phishing with Client Application Name Spoofing
>> >
>> > 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
>> >
>> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth