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

[André DeMarre <[e-mail]>]

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 <[e-mail]> wrote:
> Should this be added to the security model document? Is it already addressed there?
>
> EHL
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth