Hijacking OpenID Enabled Accounts
Sun, 03 Feb 2008 16:08:49 GMT
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.
Archived Comments
sal-eHi 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.
Huh? Isn't this by design? OpenID isn't for identity verification. It's like saying that a registration form e-mail address is for identity verification and that it is vulnerable because it (correctly) accepts arbitrary domains, which may be under the control of the attacker.
Hi,
Check this out, which came in v2 before Christmas? http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-01.html
I am not a security expert, but clearly users are free to pick their providers. Personally I have no idea why people buy Ford motor cars - but they do. You may lecture people about the cost benefit analysis of buying another car brand X. But in the main they'll always pick the cheapest, not looking at the MTBF stats.
With OpenID, people may choose the ease of the use a username and Password pair - it's understood, accepted, and the slightly more tricky two-factor authentications overhead will be chosen by the educated. People effectively wishing to pay more.
I think it's our job (geeks) to educate John Doe to make better security choices?
So whilst you may see problems with OpenID, it would be good if you highlighted the plus points to the security which has already been discussed and put forward for the protocol?
Cheers Mark
Interesting. Thinking more generically, I wonder if this method could be used to change user passwords on your typical agile Web 2.0 site?
What this means is that you can register, and authenticate without need to supply anything except the URL. I don't know wordpress so does this form add OpenID account for currently logged in user account ? Meaning attacker tricks user into submitting the form, and if user is logged in the wordpress instance, it will add attacker's OpenID url to his account?
too many comments for the night :) let me cover each one by one:
sal-e,
1. I need to visit site controlled by attacker and I have to decide to use my OpenID.Incorrect! The idea is that because OpenID enabled sites treat the OpenID technology as a captcha of some sort, ignoring the fact that the OpenID authentication and authorization stages can be completely automated by a simple OpenID identity provider server written in python or any other language, when the identity management page of the OpenID enabled device is vulnerable to CSRF, attackers can add their own identity there and use that to get access to the account. Since they use their own identity and their own identity provider, they don't need credentials.
My question is the MyOpenID approach will prevent the problem you have describedNo, the problem is unrelated to the way MyOpenID handles the authentication or authorization processes.
bugmenot, OpenID is exactly for identity verification rather then authorization although it has been widely used for that in general.
Mark,
So whilst you may see problems with OpenID, it would be good if you highlighted the plus points to the security which has already been discussed and put forward for the protocol?Point taken. Although I brag about OpenID security far too often, I am personally a big fan of the concepts and technologies involved. The simple fact is that your OpenID identity provider can be secured pretty well, like for example by using RSA tokens, etc. Using this identity for all your online presence will be far more secure then using individual passwords, from password management prospective only. Though, there are a bunch of other things which come into place that needs to be taken into consideration. One of the main things is that if OpenID makes it so easy to login anywhere you want, most people will be logged in all the time. And from Web security point of view, with all these XSS and CSRF attacks popping everywhere, it is a really bad idea.
James,
yes, it can be used though most Web2.0 sites learned the lesson and they ask you for the current password in order to reset it. This effectively demobilizes CSRF issues that may occur in this area.
rattus, correct!
FYI - Drupal seems to protect against this type of attacks using an uniform Forms API, which adds hidden random tokens for each form generated using this API.
As I've just looked, the "Add OpenID identity" form in "Edit My Account" contains the anti-CSRF token.
rattus & pdp
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.
kravietz, cheers for the info
Michael, I am not sure whether you understand the concepts of the attack. Because OpenID is nothing but a URL the attacker can register their own OpenID service. It is very simple really. All you need is a dynamic DNS name and a python script that consists of 5 lines of code. Through CSRF the attacker can add his/her OpenID URL from the dynamic DNS server. Once the attacker's OpenID url is tied to the victim's account, the game is over. Now he/she can login without authentication because he/she is running/controls the malicious OpenID identity service.
Hi pdp,
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
yes, the vulnerability is within a popular PHP OpenID library. However, it does not mean that it is used by Drupal. In fact, I have no idea what Drupal is using. The library can be fixed as well you can add some extra precocious steps to guarantee that the request cannot be forged.
I don't see how this attack is specific to OpenID, or caused/addressable in the OpenID library.
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
Hi,
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?
Oliver, why shouldn't they? OpenID is an open technology which means that I can become my own OpenID provider.
Hi pdp,
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.
Oliver, I can see your point, which is very good btw. But this is how it is. You can tighten up the service that uses OpenID only to support a certain number of OpenID providers, but there is nothing within the protocol to enforce that. So yes, you can implement it yourself, but the specs wont help you. And in general, you will loose a portion of the user base.
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.
Hi Oliver,
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.
I mentioned this article in my blog post: http://adblockplus.org/blog/vulnerability-or-feature
Wladimir, I am surprised that you still don’t understand the point of the article even after reading the comments where I personally responded to everyone who has doubts about it. Let’s get back to the key sentences from the post:
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?
Wow, I must say I'm a bit surprised by where this conversation has gone... questioning the security of OpenID in general.
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.)
Will, this is how we go in the security field. We start with something and we end up with something completely different. But that's the fun and most valuable part which most people don't realize.
Don't know if this is the right place, and maybe I just didn't grok OpenID completely, but I see a another problem - not for the OpenID user but for people deploying OpenID support in their website.
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.
Otze,
My short experience with OpenID is that I don't have to come with new combination of username/password for each site I decide to sign-on. The issue you are taking is how to establish trust between the site and the user. The current 'standard' by sending the activation key works with OpenID. Here is how:
1. The user request access with its OpenID.
2. The site connects with you OpenID provider and asks confirmation.
3. You will be asked by you OpenID provider to approve the request and select you 'persona'. The persona contains all information that you want to share with requesting site. The site can send the minimum level of information like: username, e-mail, full-name and etc.
4. Once you approve the request the website sends you an activation key to your e-mail and from here process is very familiar for every one.
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! :)
So, I need to know:
a. I need to provide a good Single Sign On system for WP, can I use OpenID or as it seems not to be so secure I should avoid it ?
b. If there are so much security problems with OpenID, is there anything else, easy to implement and more robust in security terms ?
c. Will you advise me on HOW to implement such system with a very SECURE configuration so I could forget about hackers and attackers ?