[security] OpenID identity leaks

Andris Atteka andris.atteka at gmail.com
Mon Dec 30 14:11:50 UTC 2013 

Hi Johnny,

yes, mandatory RP discovery would help here, however as you correctly
pointed out, it's not widely used.

I'll try to explain the issue I'm raising more detailed:

Browsers preserve URL fragment across HTTP redirects, e.g.
https://www.google.com/search?btnI&q=allinurl%3A%2F%2Flva.lv#fragment

If fragment identifier is included in the return_to, OP will attach OpenID
parameters only after the fragment identifier (and these will be preserved
across the redirect to a malicious site). So to exploit this, attacker
would have to find an open redirector in RP's domain.
Of course the same can be achieved with an XSS in RP's domain. Open
redirectors however are much more common and not even considered a security
issue by some.

I was just wondering why so many OPs allow fragment identifier in return_to
(e.g. here's another one - https://pip.verisignlabs.com/)? Is there some
intended functionality?

Regards,
Andris


On Wed, Dec 25, 2013 at 11:52 PM, Johnny Bufu <johnny.bufu at gmail.com> wrote:

> Andris this looks exactly like the realm/return URL spoofing described on
> the OpenID wiki page. I tried the link and the Google OP prompted me that a
> Google RP wants my email address, then I ended up at your (I assume)
> non-google RP - where I was told I shouldn't have trusted the Google RP.
> User interaction & approval at the OP was required.
>
> There is a mitigation option for this, however it is not widely adopted.
> RPs can publish their "RP identity" discovery information, and OPs can
> chose to only interact with RPs that published discovery information, and
> only respond to requests for which the return URL matched the RP's
> discovery information.
>
> http://openid.net/specs/openid-authentication-2_0.html#rp_discovery
>
> This feature however is not widely deployed to my knowledge, and an OP
> choosing to adopt this policy would have quite a few interoperability
> issues.
>
> Johnny
>
>
> On 13-12-21 02:35 AM, Andris Atteka wrote:
>
>> Hi Bart,
>>
>> Thanks for your response, however this case is a bit different from what
>> you are describing.
>> If you try the link I sent out, you'll notice that identity is leaked
>> before any user action.
>>
>> Regards,
>> Andris
>>
>>
>> On Sat, Dec 21, 2013 at 12:07 PM, Bart van Delft <bartvandelft at yahoo.com
>> <mailto:bartvandelft at yahoo.com>> wrote:
>>
>>     Hi Andris,
>>
>>     What you suggest sounds a bit like realm spoofing? In that case it
>>     is a known vulnerability of OpenID:
>>     http://wiki.openid.net/w/page/12995216/OpenID_Phishing_Brainstorm
>>
>>     Best regards,
>>
>>     Bart van Delft
>>
>>
>>     On 2013-12-21 10:12, Andris Atteka wrote:
>>
>>>     Hi Everyone,
>>>
>>>     Google's Security Team suggested to ask this question here.
>>>
>>>     Attacker can perform the following steps:
>>>     1) Find an open redirect in some major website that leads to
>>>     attacker's website (and append fragment identifier to this URL)
>>>     2) Craft a URL and set redirect_url to the open redirect
>>>     3) Trick the victim into visiting the URL
>>>     As the URL belongs to a major website, most likely victim will
>>>     accept the RP and his identity will be leaked to attacker's site.
>>>
>>>     Here's an example (Google itself has some nice open redirects):
>>>     https://www.google.com/accounts/o8/ud?openid.claimed_
>>> id=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_
>>> select&openid.ext0.mode=fetch_request&openid.ex
>>>     t0.requ
>>>     ired=email&openid.ext0.type.email=http%3A%2F%2Faxschema.
>>> org%2Fcontact%2Femail&openid.identity=http%3A%2F%2Fspecs.openid.net
>>> %2Fauth%2F2.0%2Fidentifier_select&openid.mode=checkid_setup&openid.ns=
>>> http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.ns.ext0=
>>> http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0&openid.ns.ui=http%3A%2F%
>>> 2Fspecs.openid.net%2Fextensions%2Fui%2F1.0&openid.realm=https%3A%2F%
>>> 2Fwww.google.com%2F&openid.return_to=https%3A%2F%2Fwww.google.com
>>> %2Fsearch%3FbtnI%26q%3Dallinurl%253A%252F%252Flva.
>>> lv%23aaa&openid.ui.icon=true&openid.ui.lang=en-US&openid.
>>> ui.mode=popup&third_party_login=false
>>>     <https://www.google.com/accounts/o8/ud?openid.claimed_
>>> id=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_
>>> select&openid.ext0.mode=fetch_request&openid.ext0.required=
>>> email&openid.ext0.type.email=http%3A%2F%2Faxschema.org%
>>> 2Fcontact%2Femail&openid.identity=http%3A%2F%2Fspecs.
>>> openid.net%2Fauth%2F2.0%2Fidentifier_select&openid.
>>> mode=checkid_setup&openid.ns=http%3A%2F%2Fspecs.openid.net%
>>> 2Fauth%2F2.0&openid.ns.ext0=http%3A%2F%2Fopenid.net%2Fsrv%
>>> 2Fax%2F1.0&openid.ns.ui=http%3A%2F%2Fspecs.openid.net%
>>> 2Fextensions%2Fui%2F1.0&openid.realm=https%3A%2F%
>>> 2Fwww.google.com%2F&openid.return_to=https%3A%2F%2Fwww.
>>> google.com%2Fsearch%3FbtnI%26q%3Dallinurl%253A%252F%
>>> 252Flva.lv%23aaa&openid.ui.icon=true&openid.ui.lang=en-
>>> US&openid.ui.mode=popup&third_party_login=false>
>>>
>>>
>>>     This can even be extended so that user doesn't have to accept RP.
>>>     For this attacker would have to find an open redirect that shares
>>>     domain with some valid OpenID consumer (some major sites actually
>>>     do this). In this case user wouldn't even notice the identity leak.
>>>
>>>     Is this only a bug in Google's OpenID implementation or a bug in
>>>     the OpenID spec itself?
>>>
>>>     I do see the OpenID spec talking about normalization of
>>>     identifiers (including removal of fragment and fragment
>>>     identifier). Does the same apply to redirect_url? If not, would it
>>>     be reasonable to include this in the spec?
>>>
>>>     Regards,
>>>     Andris Atteka
>>>     andrisatteka.blogspot.com <http://andrisatteka.blogspot.com>
>>>
>>>
>>>
>>>
>>>
>>>
>>>     _______________________________________________
>>>     security mailing list
>>>     security at lists.openid.net  <mailto:security at lists.openid.net>
>>>     http://lists.openid.net/mailman/listinfo/openid-security
>>>
>>
>>
>>     _______________________________________________
>>     security mailing list
>>     security at lists.openid.net <mailto:security at lists.openid.net>
>>
>>     http://lists.openid.net/mailman/listinfo/openid-security
>>
>>
>>
>>
>> _______________________________________________
>> security mailing list
>> security at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-security
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20131230/ef4b13a8/attachment.html>

More information about the security mailing list