Re: [OAUTH-WG] Phishing with Client Application Name Spoofing
André DeMarre <andredemarre@gmail.com> Wed, 26 October 2011 20:44 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 B45FC21F8B82 for <oauth@ietfa.amsl.com>; Wed, 26 Oct 2011 13:44:56 -0700 (PDT)
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 lN+0Pl4VAMG9 for <oauth@ietfa.amsl.com>; Wed, 26 Oct 2011 13:44:55 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B7A1121F8B80 for <oauth@ietf.org>; Wed, 26 Oct 2011 13:44:55 -0700 (PDT)
Received: by iabn5 with SMTP id n5so2721684iab.31 for <oauth@ietf.org>; Wed, 26 Oct 2011 13:44:55 -0700 (PDT)
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=4zezIFM3Ujek1T/vMNDL1gnShuW1F65V9abtpZQhaIk=; b=DMVfcDNYhMBAuWcK2qUiUrcnY+yZx6za0EUCa4Kya/h9lG8T37B5JWHvaK6N1c5NYl jh6yrUpmnJyJ2aq5PxC2dGnaUxWXmmbsAZmMJRgYxIRZqudIV+HIxR9emIE3OjWU/uv9 7IRVssMP+TDxPDncZeHbtyVHk74ElzNo0tef4=
MIME-Version: 1.0
Received: by 10.42.172.194 with SMTP id o2mr53244669icz.15.1319661895430; Wed, 26 Oct 2011 13:44:55 -0700 (PDT)
Received: by 10.42.151.131 with HTTP; Wed, 26 Oct 2011 13:44:55 -0700 (PDT)
In-Reply-To: <CAEwGkqDscS5ke4KmoVUF3nDjS-1b+SuT_hCb59+rCuokmhPOVQ@mail.gmail.com>
References: <CAEwGkqDscS5ke4KmoVUF3nDjS-1b+SuT_hCb59+rCuokmhPOVQ@mail.gmail.com>
Date: Wed, 26 Oct 2011 13:44:55 -0700
Message-ID: <CAEwGkqAfvq=rZUMOVTWqrV1H6fuSYGC=EDa=1JW7htP5-dbW_g@mail.gmail.com>
From: André DeMarre <andredemarre@gmail.com>
To: OAuth WG <oauth@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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: Wed, 26 Oct 2011 20:44:56 -0000
Should a brief explanation of this be added to the Threat Model and Security Considerations document? Or does anyone even agree that this can be a problem? Regards, Andre DeMarre On Tue, Oct 4, 2011 at 11:32 AM, André DeMarre <andredemarre@gmail.com> wrote: > 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-WG] Phishing with Client Application Name … André DeMarre
- Re: [OAUTH-WG] Phishing with Client Application N… André DeMarre
- Re: [OAUTH-WG] Phishing with Client Application N… Torsten Lodderstedt
- Re: [OAUTH-WG] Phishing with Client Application N… André DeMarre
- Re: [OAUTH-WG] Phishing with Client Application N… Mark Mcgloin
- Re: [OAUTH-WG] Phishing with Client Application N… Eran Hammer
- Re: [OAUTH-WG] Phishing with Client Application N… André DeMarre
- Re: [OAUTH-WG] Phishing with Client Application N… Mark Mcgloin
- Re: [OAUTH-WG] Phishing with Client Application N… André DeMarre
- Re: [OAUTH-WG] Phishing with Client Application N… Torsten Lodderstedt