Adblock Plus and (a little) more

Vulnerability or feature? · 2008-02-06 15:50 by Wladimir Palant

pdp over at GNUCITIZEN claims to have found a vulnerability in some common OpenID libraries. And I really tried hard to understand what he means and how it is related to the title of the article. In the end, I got the impression that he simply explains in a lengthy way that anybody could run an OpenID server and use it to log into OpenID-enabled services without having to register. Now isn’t this the whole purpose of OpenID?

Apparently, I wasn’t the only one who got this impression — while the first commenter totally misinterpreted the article (which wasn’t hard), the second comment was already: “Isn’t this by design?” And pdp answered confirming that my interpretation of his article was correct, the point being really about authentication with OpenID being easier than registration (no captcha and the like). So why didn’t he just tell that, in one simple sentence rather than 7 (seven!) paragraphs of text? Why talk about CSRF, OpenID libraries or hijacking when apparently none of them have anything to do with the issue? Why providing a meaningless piece of code only to obfuscate the meaning even further?

I am very disappointed having wasted too much time on this article. While GNUCITIZEN occasionally comes up with interesting findings, this kind of “we have nothing to tell but let’s make an article out of it and give it some unrelated but catchy title” is happening way too often. On several occasions valid behavior has been misinterpreted as a security vulnerability or analysis of a security vulnerability has been incorrect (e.g. something has been called XSS despite only one domain being involved). Time for me to stop reading it again. Is there anybody else worth reading on the topic of web application security? Apart of ha.ckers of course.

Update: Apparently, there actually was some deeper meaning to that article — and a valid point. See pdp’s comment below for details.

Tags: security off-topic

Comment [8]

pdp · 2008-02-06 16:13 · #

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?

Reply from Wladimir Palant:

Nothing new here. I already understood what your article is about, you can cut it down to one sentence: “Registration usually has captcha or similar protection mechanism, authentication via OpenID has similar effect but usually no such protection.” Which has absolutely nothing to do with CSRF (you are not forging a request, you are misusing a valid request). Neither does it have anything to do with hijacking – you are not hijacking any existing accounts, you are creating a new one (which is yours and yours only). And it isn’t really a library issue – it is just that services accepting OpenID have to use the same standard for it as for registration (e.g. requiring a captcha to be filled out first time a particular OpenID URL is used or treating OpenID users like unregistered users). It might be that this hasn’t been communicated well enough, but you did a very poor job bringing attention to this issue.

Sorry, but seeing a comment here that only repeats all the same points in the same unintelligible way I only get the impression that you have trouble singling out the important facts.
pdp · 2008-02-06 16:26 · #

oh, i wrote about this blog post on our blog over here:

http://www.gnucitizen.org/blog/hijacking-openid-enabled-accounts#comment-110685
Toe · 2008-02-06 16:29 · #

I’m much more concerned about how incredibly easy phishing attacks are with OpenID.

http://marcoslot.net/apps/openid/

To me, OpenID just seems like a pretty terrible idea all around.

Reply from Wladimir Palant:

You are right, this sort of attack is very disconcerting. And it might very well become the most important reason against OpenID. However, I am not discussing OpenID here, only the one bogus vulnerability report about it.
pdp · 2008-02-06 16:37 · #

Well, I think that it is a matter of convenience. I personally feel that OpenID is the best thing since sliced bread that has happened to the Web. There are advantages and disadvantages. The advantages are that as a responsible user, I can make everything possible to ensure that the integrity of my identity stays intact and secure (think about it, I can now login via my own server with as many factor authentication I want, RSA tokens? why not?). The disadvantages are that I may stay logged online longer then usual which will result in raise of CSRF attacks, exactly what I am outlining in my post. Also, if someone manages to compromise my identity they will have access to any resource my online persona has.
pdp · 2008-02-06 17:14 · #

Wladimir, no offense but it seems that you don not understand the essence of the attack. Let me put it in bullet points:

1. Wordpress users are authorized by usernames and passwords
2. OpenID plugin provides easy login via URL
3. Users have the option to choose to login either through (username and password) or (URL via OpenID)
4. Users can have as many URLs associated with their account as possible
5. Example user like Joghn can have 3 URLs associated with his account, i.e. john.example.com, acme.com/john, google.com/john.
6. The form that is responsible for associating users with URLs is vulnerable to CSRF
7. Attackers can add a new URL for John: evil.com/hacker
8. Now attackers can login as John by using URL evil.com/hacker
9. CSRFable form is generated by library not by plugin
10. Other systems that use this library may also be vulnerable to the same CSRF

This is the reason why the post have the word HIJACKIGN in the title. Because the developers are not completely aware of what OpenID is, simple mistakes like this one can lead to big problems.

Reply from Wladimir Palant:

Now that’s interesting – the important point being number 6. But that’s exactly the one point that I cannot see in your article. Ok, now that you mentioned it I can see the part where you apparently meant to tell about it.

As your conclusions go – most developers (especially the kind that writes plugins to popular software) are simply ignorant about CSRF, and that’s the main issue. Most of the time you can change just about any configuration option via CSRF, and the result won’t be pretty. Not really an OpenID issue IMO.
Tom · 2008-03-12 20:18 · #

Wladimir –

PDP’s original explanation was perfectly clear to me. If you in fact do understand CSRF I can’t see how you wouldn’t understand.
Diabolik · 2008-03-16 17:59 · #

I disregard and ignore people that use long complex ways to say nothing – just empty words, it’s noting else but wasted time to write and read. Such streched materials, let use many words to say nothing new, are really big annoyance.

I greet and appreciate people who say things directly, simply and shortly.
haldia · 2010-01-11 20:40 · #

Nice article…….Thanks for sharing this one with us.
Have a great new year.

Skip all the worthless 642-825 tutorials for passing the Cisco 642-825 exam and download 642-825 exam materials with realistic questions and answers and a price too unbelievable to pass up. Act now and download your Actual Tests today.
Pass-Guaranteed also offers you 642-845 test exam , 642-892 practice question, 642-901 practice exam and many more. Pass-Guaranteed is the safer, easier way to get Cisco certifications.

Commenting is closed for this article.