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

[Eran Hammer <[e-mail]>]

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