Re: [OAUTH-WG] Phishing with Client Application Name Spoofing
Torsten Lodderstedt <torsten@lodderstedt.net> Wed, 02 November 2011 21:27 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 798C91F0CB4 for <oauth@ietfa.amsl.com>; Wed, 2 Nov 2011 14:27:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
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 kOawBzfqonSk for <oauth@ietfa.amsl.com>; Wed, 2 Nov 2011 14:27:13 -0700 (PDT)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5833C1F0C59 for <oauth@ietf.org>; Wed, 2 Nov 2011 14:27:13 -0700 (PDT)
Received: from [87.142.252.185] (helo=[192.168.71.38]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1RLiKz-0001zd-0a; Wed, 02 Nov 2011 22:27:09 +0100
Message-ID: <4EB1B5AB.6020208@lodderstedt.net>
Date: Wed, 02 Nov 2011 22:27:07 +0100
From: Torsten Lodderstedt <torsten@lodderstedt.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: André DeMarre <andredemarre@gmail.com>
References: <CAEwGkqDscS5ke4KmoVUF3nDjS-1b+SuT_hCb59+rCuokmhPOVQ@mail.gmail.com> <CAEwGkqAfvq=rZUMOVTWqrV1H6fuSYGC=EDa=1JW7htP5-dbW_g@mail.gmail.com>
In-Reply-To: <CAEwGkqAfvq=rZUMOVTWqrV1H6fuSYGC=EDa=1JW7htP5-dbW_g@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
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: Wed, 02 Nov 2011 21:27:14 -0000
Hi Andre, how do you think differs the threat you descibed from http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01#section-4.4.1.4? regards, Torsten. Am 26.10.2011 22:44, schrieb André DeMarre: > 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 mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
- [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