Re: [OAUTH-WG] vulnerability in OAuth 2.0/ 1.0/ WRAP leading to DDOS attacks

[Oleg Gryb <[e-mail]>]

The concern is valid, but proposed solution would be hard to implement: 
everybody who has implemented at least one crypto system where symmetric keys 
need to be distributed between external parties would tell you that, let alone 
OAuth use cases where you can have many web server clients dynamically added to 
existing service providers. If you add a requirement of periodic key  rotation 
that is very common nowadays then implementation will become even more 
difficult. 


PKI would be a better approach in my view: Authz Server would need to sign using 
a a private key and web client will use a public key to verify the signature, 
but again in case of key rotation, an automatic key exchange mechanism would 
need to be involved.

I think there is some kind of automatic client registration protocol under way. 
It will handle new clients registration and initial key distribution, but AFAIK 
it's not governed by IETF's OAuth group.



----- Original Message ----
> From: "[e-mail]" <[e-mail]>
> To: [e-mail]
> Cc: Dawn Song <[e-mail]>; John Mitchell 
><[e-mail]>; Peifung Eric Lam <[e-mail]>; Devdatta 
>Akhawe <[e-mail]>; Adam Barth <[e-mail]>
> Sent: Fri, November 12, 2010 5:47:35 PM
> Subject: Re: [OAUTH-WG] vulnerability in OAuth 2.0/ 1.0/ WRAP leading to DDOS 
>attacks
> 
> Hi,
> 
> We are a group of university researchers and have been applying a  formal
> approach to analyze web security protocols. Devdatta gave a talk at  IIW at
> Mountain View last week about our work, and a summary of our  earlier
> results can be found  at
> http://theory.stanford.edu/~jcm/papers/browsermodel-csf-2010.pdf  .
> 
> While analyzing OAuth specifications (2.0/1.0/WRAP), we found that  a
> vulnerability exists that can be exploited to carry out DDOS
> attacks.  Under the current specifications, such attacks are difficult to
> differentiate  from legitimate and non-malicious connections, so
> rate-limiting based on user  identities or machine fingerprinting are
> likely to be ineffective. A  tentative solution is proposed at the end of
> this email. Any feedback is  welcome!
> 
> Best,
> 
> Peifung Eric Lam
> 
> =====
> 
> In the OAuth  2.0 and the OAuth WRAP specifications, we found that in the
> Web Server/Web  App profile, an attacker can send an HTTP request to the
> redirect URI of a  client web application (with an arbitrary authorization
> code), causing the  client to issue an HTTPS request to the OAuth
> Authorization Server. The  revelant sections in OAuth 2.0 Draft 10 are
> 1.4.1(C), and sections 3 and 4. A  slightly modified attack can be mounted
> against OAuth 1.0 as specified in RFC  5849.
> 
> From our initial analysis, this feature of OAuth can be exploited  by
> attackers to launder requests through trusted OAuth clients and launch  a
> DDOS attack on the Authorization Server. Under the current  specifications
> such attacks are difficult to differentiate from legitimate  and
> non-malicious connections, so rate-limiting based on user identities  or
> machine fingerprinting are likely to be ineffective.
> 
> Specifically,  an attacker can bombard the redirect URIs of the web
> application clients,  causing a flood of HTTPS connections to the OAuth
> Authz Server. This can lead  to depletion of resources on the Authz Server
> and prevent HTTPS connections  carrying legitimate payload from reaching
> the Authz Server. During such an  attack, all that the Authz Server learns
> (based on the 1.0,  2.0, and  WRAP specs), is that a) each request comes
> from a registered web site which  may have legitimate business making such
> a request, and b) the tokens  conveyed in each request. However, as the
> attacker can issue authorization  codes that are just (pseudo-) random bit
> strings not tied to any end-user  identity, the Authz Server has learned
> little information regarding the  attacker or its machines causing such
> frivolous connections.
> 
> A large  number of web application clients integrated with the Authz Server
> can help  the attacker obfuscate its sources of attack and make information
> collection  for DDOS defense more difficult. From statistics released by
> popular websites  (such as Facebook), we expect the number of clients can
> be as high as a  million.
> 
> It seems that if we require the authorization code to be signed  by the
> Authz Server (or HMAC'ed using a shared key between the Authz Server  and
> the Client), and the client verifies the signature or HMAC code  first
> before connecting to the Authz Server, then the above DDOS attack can  be
> largely foiled.
> 
> Please let us know if you would like to discuss  this issue further so that
> we can devise a clean solution to this  problem.
> 
> 
> Eran Hammer-Lahav <[e-mail]>  wrote:
> >
> > The right place to bring this up for discussion is the  IETF OAuth
> mailing list: [e-mail].
> >
> >  Thanks!
> >
> >  EHL
> 
> 
> _______________________________________________
> OAuth mailing  list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>