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 > [EMAIL PROTECTED] > http://openid.net/mailman/listinfo/general > _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
