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

From: [email-masked]
Date: Fri, 19 Nov 2010 04:27:37 -0800 (PST)

Thanks, Oleg, for the note.

I agree that key distribution has been a difficult problem. Since the
OAuth draft 10 section 2.1 provides a mechanism for the client to
authenticate to the Authz Server using some shared symmetric secret, I
think the MAC scheme can be built on the presumably available shared
secret. It appears that the DDoS vulnerability stated below could be
addressed if we require the authorization code to be accompanied by a MAC
(using a key derived from some secret shared between the Authz Server and
the client), and the client validates the MAC and the freshness of the
authorization code before sending it to the Authz Server.

> 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.

Do you have a link to the current draft of the registration protocol? I
would be very interested to read it as this is a non-trivial problem.

As an aside, I have received some very good critique in private from a few
other people. I will summarize the discussion in a separate posting,
later.

Best,

Eric

On Thu, Nov 18, 2010 at 1:32 AM, Oleg Gryb <[email-masked]> wrote:

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: "[email-masked]" <[email-masked]>
> To: [email-masked]
> Cc: Dawn Song <[email-masked]>; John Mitchell
><[email-masked]>; Peifung Eric Lam <[email-masked]>;
Devdatta
>Akhawe <[email-masked]>; Adam Barth <[email-masked]>
> 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 <[email-masked]>  wrote:
> >
> > The right place to bring this up for discussion is the  IETF OAuth
> mailing list: [email-masked].
> >
> >  Thanks!
> >
> >  EHL
> _______________________________________________
> OAuth mailing  list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Oleg Gryb <[email-masked]>
Date: Fri, 19 Nov 2010 10:24:47 -0800 (PST)

I agree that there should be mitigation controls in place on web server clients: 
it would alleviate  Authz Server task of blocking fraudulent traffic and make 
the whole solution more scalable. Using signatures looks like a good idea, but 
key distribution needs to be automated in this case.

Here is a link to the protocol that I've mentioned before: 
https://github.com/mrtopf/UMA-Specifications/blob/master/draft-oauth-client-registration.txt

It looks like the ownership has moved from UMA to IETF. The main purpose is to 
dynamically register Authz Server clients (both resource servers and "enhanced" 
OAuth clients).

I'm not sure if "enhanced" clients include web server clients that we've 
discussed here. It would be great if somebody can clarify. It would be great 
also if somebody can comment on key distribution and key rotation: will it be 
covered by the protocol?

Is the secret that initially given to an enhanced OAuth client a key? What kind 
of key? I didn't see too many details in the current draft. Probably it was made 
this way on purpose to keep all options open.

----- Original Message ----
> To: Oleg Gryb <[email-masked]>
><[email-masked]>; [email-masked]; Devdatta Akhawe 
><[email-masked]>; [email-masked]; Adam Barth <[email-masked]>
> Sent: Fri, November 19, 2010 4:27:37 AM
> Subject: Re: [OAUTH-WG] vulnerability in OAuth 2.0/ 1.0/ WRAP leading to DDOS 
>attacks
>