Hijacking OpenID enabled Accounts
It has been a long time since I last spoke about OpenID. Today I would like to draw your attention to a tiny problem, which I found among several OpenID solutions. The problem is indeed tiny but the overall outcome is concerning.
CSRF – It comes very handy. It seams that no matter how much you talk about it, very few pay attention on the problem. And it is not a problem that you can afford to have. And among the XSS issues, which most OpenID libraries have, CSRF (Cross-site Request Forgery) seams to be the most pervasive form of attack.
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. As you probably know, the OpenID authentication stage happens over two channels: one hidden from the user, and one top (visible) channel for authorization purposes mainly. Because the process seems to be kind of obscured, CSRF issues are often taken very lightly and widely ignored.
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. However, keep in mind that I am trying to outline a widely-spread issue rather then to disclose a bug. Therefore, you can safely assume that this form of attack is also applicable to many other systems. This is how it goes.
Once you login into the WordPress OpenID plugin user page, you can add an OpenID url for the current user login. This URL can be used later to login into the WordPress instance, without typing your username and password, bur rather using a 3rd party server, your OpenID provider, to verify who you are. Unfortunately, the user administration form is vulnerable to CSRF attack. Saying that, attackers can easily, add their own OpenID url and as such authenticate without the need for credentials. Let’s examine the form structure:
<form method="post">Add identity:
<input id="openid_url" name="openid_url" />
<input type="submit" value="Add" />
<input type="hidden" name="action" value="add_identity" >
</form>It is obvious that there is nothing there to prevent CSRF attacks. 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.
I hope that you understand the impact of this issue as it is one of the main things you will see when you deal with OpenID enabled systems. OpenID does make life easier bur if you don’t implement the infrastructure properly, you are asking for some serious trouble. 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.
bugmenot 
James 
rattus 
Johnny Bufu 
otze 
Albert
Hi pdp,
I’d like to make sure that I understand correctly the problem you bringing to our attention. In order this vector of attack to succeed the following conditions have to be met:
1. I need to visit site controlled by attacker and I have to decide to use my OpenID.
2. The attacker’s web site should redirect me to fake site that works like my OpenID provider site. (Very similar to phishing attack). In order to still my username and password for my OpenID account.
When I discover OpenID some time ago I had the same idea. My research back then proved that most of OpenID providers are vulnerable for this type of attack. I have found that only MyOpenID.com is taking this problem seriously and they have implemented some features to address the problem.
For example you can enable ‘secure mode’ that will force you to open new and connect directly to MyOpenID site in order to get authenticated. This should protect you in most cases. Unfortunately this is not the end of the story because if you workstation is compromised (or your router) and the hacker has change your DNS server you still going to end up on attackers OpenID server. Against this problem MyOpenID has setup authentication by pre-exchanged certificates instead of username/password.
My question is the MyOpenID approach will prevent the problem you have described?
And the main conclusion is that risk never disappears. Using OpenID protects you against the problem of using the same username/password on many websites, but at the same time moves the risk to you OpenID provider. So it become important to select good OpenID provider that takes this issues very seriously.