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

[Torsten Lodderstedt <[e-mail]>]

two days can last for a very long time ;-) I will add this threat to the list to be covered by our new security draft.

> Am 10.05.2017 um 23:15 schrieb André DeMarre <[e-mail]>:
> 
> I see there is a new security considerations document being drafted. There is an old issue that I've recently been reminded of.
> 
> Should text about phishing conducted through the authorization dialog be added to the new security document? This kind of attack made headlines last week with a widespread Gmail / Google Docs phishing worm (https://security.googleblog.com/2017/05/protecting-you-against-phishing.html).
> 
> Five years ago, I was encouraged to propose text about this for the Threat Model and Security Considerations document, but I never did; sorry. Original thread in the mail archive: https://www.ietf.org/mail-archive/web/oauth/current/msg07625.html
> 
> This concerns both authorization dialog design and client registration, and as far as I know it's not really covered in any published documents. I'm not entirely sure what mitigations should be recommended, but I think authorization server implementers need to be more cognizant of this attack.
> 
> Regards,
> Andre DeMarre
> 
>> On Tue, Jan 17, 2012 at 4:06 AM, Mark Mcgloin <[e-mail]> wrote:
>> 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
>> >
>> 
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth