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

[[e-mail]]

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