Date: Fri, 08 Aug 2008 09:17:51 -0400
From: Gerald Beuchelt <beuchelt@....com>
To: Ben Laurie <benl@...gle.com>
Cc: bugtraq@...urityfocus.com, security@...nid.net,
	OpenID List <general@...nid.net>, cryptography@...zdowd.com,
	full-disclosure@...ts.grok.org.uk
Subject: Re: [OpenID] OpenID/Debian PRNG/DNS Cache poisoning advisory

We have been following up on Ben Laurie's advisory and have replaced the 
faulty certificate with a new one. In addition we created an advisory 
for our users that outlines some general precautions they should take:

http://blog.beuchelt.org/2008/08/07/Some+Security+Advice+For+Our+OpenID+Users.aspx). 


While these measure cannot guarantee safety, they can help improving the 
situation. In addition, Robin Wilton has documented what happened here:

http://blogs.sun.com/racingsnake/entry/one_factor_trust_multi_factor

We are continuing to monitor the situation and might make additional 
changes to the service.

I would like to use this opportunity to thank Ben again for approaching 
us upfront and working with us while preparing his advisory.

Best,

Gerald Beuchelt

Ben Laurie wrote:
> Security Advisory (08-AUG-2008) (CVE-2008-3280)
> ===============================================
>
> Ben Laurie of Google's Applied Security team, while working with an
> external researcher, Dr. Richard Clayton of the Computer Laboratory,
> Cambridge University, found that various OpenID Providers (OPs) had
> TLS Server Certificates that used weak keys, as a result of the Debian
> Predictable Random Number Generator (CVE-2008-0166).
>
> In combination with the DNS Cache Poisoning issue (CVE-2008-1447) and
> the fact that almost all SSL/TLS implementations do not consult CRLs
> (currently an untracked issue), this means that it is impossible to
> rely on these OPs.
>
> Attack Description
> ------------------
>
> In order to mount an attack against a vulnerable OP, the attacker
> first finds the private key corresponding to the weak TLS
> certificate. He then sets up a website masquerading as the original
> OP, both for the OpenID protocol and also for HTTP/HTTPS.
>
> Then he poisons the DNS cache of the victim to make it appear that his
> server is the true OpenID Provider.
>
> There are two cases, one is where the victim is a user trying to
> identify themselves, in which case, even if they use HTTPS to "ensure"
> that the site they are visiting is indeed their provider, they will be
> unable to detect the substitution and will give their login
> credentials to the attacker.
>
> The second case is where the victim is the Relying Party (RP). In this
> case, even if the RP uses TLS to connect to the OP, as is recommended
> for higher assurance, he will not be defended, as the vast majority of
> OpenID implementations do not check CRLs, and will, therefore, accept
> the malicious site as the true OP.
>
> Mitigation
> ----------
>
> Mitigation is surprisingly hard. In theory the vulnerable site should
> revoke their weak certificate and issue a new one.
>
> However, since the CRLs will almost certainly not be checked, this
> means the site will still be vulnerable to attack for the lifetime of
> the certificate (and perhaps beyond, depending on user
> behaviour). Note that shutting down the site DOES NOT prevent the
> attack.
>
> Therefore mitigation falls to other parties.
>
> 1. Browsers must check CRLs by default.
>
> 2. OpenID libraries must check CRLs.
>
> 3. DNS caching resolvers must be patched against the poisoning attack.
>
> 4. Until either 1 and 2 or 3 have been done, OpenID cannot be trusted
>    for any OP that cannot demonstrate it has never had a weak
>    certificate.
>
> Discussion
> ----------
>
> Normally, when security problems are encountered with a single piece
> of software, the responsible thing to do is to is to wait until fixes
> are available before making any announcement. However, as a number of
> examples in the past have demonstrated, this approach does not work
> particularly well when many different pieces of software are involved
> because it is necessary to coordinate a simultaneous release of the
> fixes, whilst hoping that the very large number of people involved
> will cooperate in keeping the vulnerability secret.
>
> In the present situation, the fixes will involve considerable
> development work in adding CRL handling to a great many pieces of
> openID code. This is a far from trivial amount of work.
>
> The fixes will also involve changes to browser preferences to ensure
> that CRLs are checked by default -- which many vendors have resisted
> for years. We are extremely pessimistic that a security vulnerability
> in OpenID will be seen as sufficiently important to change the browser
> vendors minds.
>
> Hence, we see no value in delaying this announcement; and by making
> the details public as soon as possible, we believe that individuals
> who rely on OpenID will be better able to take their own individual
> steps to avoid relying upon the flawed certificates we have
> identified.
>
> OpenID is at heart quite a weak protocol, when used in its most
> general form[1], and consequently there is very limited reliance upon
> its security. This means that the consequences of the combination of
> attacks that are now possible is nothing like as serious as might
> otherwise have been the case.
>
> However, it does give an insight into the type of security disaster
> that may occur in the future if we do not start to take CRLs
> seriously, but merely stick them onto "to-do" lists or disable them in
> the name of tiny performance improvements.
>
> Affected Sites
> --------------
>
> There is no central registry of OpenID systems, and so we cannot be
> sure that we have identified all of the weak certificates that are
> currently being served. The list of those we have found so far is:
>
> openid.sun.com
> www.xopenid.net
> openid.net.nz
>
> Notes
> -----
>
> [1] There are ways of using OpenID that are significantly more secure
>     than the commonly deployed scheme, I shall describe those in a
>     separate article.
> _______________________________________________
> general mailing list
> general@...nid.net
> http://openid.net/mailman/listinfo/general
>   

Powered by blists - more mailing lists