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

[Mark Mcgloin <[e-mail]>]

Andre

Please feel free to propose text, perhaps with a better title than I
suggested. During our discussion on section 4.1.4 (End-user credentials
phished using compromised or  embedded browser), we have decided on the
countermeasure below, albeit for a different threat - phishing client as
opposed to client name spoofing. Your's can be a variant of this with
different validation recommendations.


2. Client applications could be validated prior to publication in an
application market for users to access. That validation is out of scope for
OAuth but could include validating that the client application handles user
authentication in an appropriate way


Regards
Mark

André DeMarre <[e-mail]> wrote on 16/01/2012 23:20:02:

>
> To:
>
> Eran Hammer <[e-mail]> 16/01/2012 23:22
>

>
> Re: [OAUTH-WG] Phishing with Client Application Name Spoofing
>
> 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
>