[OAUTH-WG] Phishing with Client Application Name Spoofing

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

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