Note. I have over simplified the steps. In real world OpenID have to make additional steps to work securely and that is what pdp refers as “the process seems to be kind of obscured”.

If OpenID makes process more difficult why anyone wants to use it? Well there is many reasons, but the main advantage in discussed example is that in case you e-mail get compromised you can change it quickly at your OpenID provider and the new e-mail address will propagate to all OpenID enabled sites when you login next time.

ps. I am not security expert and I am just learning about OpenID. So if some one with better knowledge on the subject sees something wrong or incorrect please speak up! :)

As I understand OpenID, it breaks the widely supportet double-opt-in principle. Without OpenID, nearly every forum or other web service validates the given email addresses of new users by sending an email with an activation key.

With OpenID, only the OpenID provider is supposed to check the email address this way, but OpenID-enabled services rely on the information of the provider - which could stand completely under the control of an attacker.

So wouldn’t it be posssible to setup your own OpenID server which doesn’t verify your email addresses and so lie to other web services regarding your email? This way you could easily impersonate other people, maybe to annoy them by registering to various mailing lists. (Or make people think that you don’t verify addresses on your lists.)

Or you could use this for Social Engineering. Just register accounts at other peoples’ blogs or forums with email addresses that belong to people normally trusted by the admin and use this to fake a conversation.

I’m the author of the OpenID implementation in question. It is indeed a bug, but it is in my code, not the JanRain library. It was a minor oversight that didn’t verify that the add_identity request was indeed coming from the correct form. This has been corrected in v2.1.3 by using WordPress’s built-in nonce functionality. (Props to Sam Alexander for showing me this post and providing the simple patch.)

quote 1

When it comes to OpenID, it seams that developers forget about CSRF, or they just don’t want to simply deal with it, mainly because OpenID is not straightforward type of technology.

quote 2

Instead of showing you examples with real, live systems, rather unethical as you may guess, I would like to show you an example of an account hijack technique which is currently present inside one of the few Wordpress OpenID plugins.

quote 3

Once the attacker supplies a URL for the openid_url field, the page will redirect to the OpenID provider specified by that URL, authenticate and return back to the original position. Given the fact, that the OpenID provider is controlled by the attacker, btw. everyone can host their own OpenID provider, the attack is very trivial to pull. Once this URL is stored within the plugin database, the attacker will be able to authenticate with the attacked blog without any sort of authorization whatsoever.

Is it still unclear what is the article all about? And if not, do you mind updating your post to outline that?

OpenID is modeled after the DNS. Every one can select own server to handle the task. I have lost the link for the OpenID presentation, but the author of OpenID clearly stated that the OpenID do not have function of establishing trust like CA. The only function is to id the user. That is way the OpenID providers supports multiple personalities. You can choose how much data you want the OpenID provider to send to each individual site. You have responsibility to select your OpenID provider and it is your responsibility to which site you are sign in with your OpenID and the level of information you want to share with that site. In other words to establish of level of trust! As I understand the goal of the OpenID protocol is to help the user with all those websites that collect information from us and help maintain this information.

After all that I can see your point also. Thank you for raising the issue. I agree that OpenID is not full solution. It provides identification, but not trust. As you say the CA is design for establishing the trust. What I’d like to see from OpenID provider is integration between CA and OpenID. I should be able to upload different public key for each of my personality. Then the web site can accept only data encrypted by private key and this effectively will eliminate a lot of the potential attacks.

SAL-e

p.s. pdp, thank for the info. Over the weekend I’ll try to find out how Drupal is implementing the OpenID and which library is using. Also I will try to contact the author of the OpenID plugin for Drupal and draw his/her attention to our discussion.

However, keep in mind that even if there is a trust mechanism, like the one you pointed out, implemented, the attack that I describe will still work. The reason why I pointed out this CSRF based attack is because I’ve seen in on more then one place. Developers get lost into the complexity and tangled nature of OpenID and forgot to make some basic checks that lead to problems.

I don’t want to get this topic a “Open ID” discusssion, but if the whole concept is based on trusts between the OpenID provider, the relying party and the end user and if the relying party trusts every OpenID provider “per default”, then there is no security benefit. If I think about this concept (and if I get it right), an successfull (CSRF) attack can have a very high impact. I wonder whether the OpenID concept/protocol has no function/process to check whether a OpenID provider can be trusted or not - although it’s a open technology. Strange.

the whole attack scenario/example will only work, if the relying party (in your example Wordpress) will trust each OpenID provider. And this will be indeed a real security problem of the whole OpenID concept.

It can be compared with the PKI world: OpenIDs are like certificates and the OpenID provider acts like a Certificate Authority (CA). If you trust every CA in the world, the whole PKI concept will not be effective. I can’t believe that services like Wordpress or Yahoo will trust every OpenID provider … or do they?

As I understand it, it’s a general CSRF attack against an administrative form; the form’s controller should make sure it’s still talking to the ligitimate user (owner of the username/password) *before* taking any OpenID action.

Johnny

Thank you for clarification. Now I have better understanding of the issue. In your initial post you stated:

BTW, the vulnerability, which I so lightly covered in this post, is not due to a coding mistake within the plugin itself, bur rather then a bug that exists within the main support library, which is one of the most popular OpenID libraries available in the wild.

I am making some assumptions. First you are referring to Wordpress plugin and the second is that you are referring to PHP library supporting OpenID. Based on those assumptions I was about to ask you did you run test on other popular software like Drupal and Joomla. At the same time I saw the comment from kravietz about Drupal. So I am little confused again. If Drupal can protect against this issue, why WP-pluging don’t deploy the same protection?

And can the library be fixed or the OpenID protocol needs to be modified?

Thanks,
SAL-e

The point is how can attacker’s OpenID be added at user’s side. If I were the attacker, even I tell you my OpenID and let you tie it to your WP account, it can’t be done. Because according to my understanding, the authentication does not require nothing but URL, it requires your prove of the ownership to that URL.