In the paper titled “Signing Me onto Your Accounts through Facebook and Google: a Traffic-Guided Security Study of Commercially Deployed Single-Sign-On Web Services“, Rui Wang, Shuo Chen, XiaoFeng Wang reported the “vulnerability” in some OpenID 2.0 implementations. The vulnerability they listed can probably be named as “OpenID Signature Check Failure” and “OpenID Data Type Confusion”. I would really like to thank these researchers for finding them, but at the same time, I would like to point out some confusions in the research paper. [1]
1. OpenID Signature Check Failure
In section 4.1, the authors points out that although the RP requests the parameters to be signed with openid.ext1.required, since the request is not signed, the openid.ext1.required can be manipulated and thus the response in the openid.signed would not include all of what was in the openid.ext1.required[2].
This interpretation of openid.ext1.required is wrong.
This parameter is defined in OpenID Attribute Exchange 1.0 as follows:
openid.ax.required
Value: an attribute alias, or a list of aliases corresponding to the URIs defined by “openid.ax.type.<alias>” parameters. Multiple attribute aliases are separated with a comma, “,”.
By requesting attributes using this field, a hint is sent to the OP about the RP’s requirements for offering certain functionality and should be used by the OP to help the user decide what attributes to release. RP’s requirements should not be enforced by the OP.
The RP should offer, out of band of attribute exchange, an alternate method of collecting the attributes it needs, if they weren’t obtained via attribute exchange.
As you can see, it has nothing to do with signing. Thus, the claims that was made by the authors are actually false and Figure 8 marking “protected by openid.sig” is wrong. [3]
This does not mean that there was not a vulnerability at Smartsheet. Indeed there was, but the cause is not this one. The root cause is that the Smartsheet used a mail address as the user identifier to log in the user. This is wrong. OpenID Authentication 2.0 mandates the RP to identify the end-user with openid.claimed_id. This is always signed by the IdP, and this is a un-recyclable identifier unlike an email address. If the Smartsheet was implementing the specification properly, this vulnerability did not arise. Indeed, this is an implementation vulnerability and not a protocol vulnerability.
The authors goes on to say:
Broader impacts. We further discovered that the problem went far beyond Smartsheet. Google confirmed that the flaw also existed in open source projects OpenID4Java (an SDK that Google authentication had been tested against) and Kay Framework. In OpenID4Java, the function for an RP to verify BRM3 is verify(). The source code showed that it only checked whether the signature covered all the elements in the openid.signed list, so a “verified” BRM3 does not ensure authenticity of the elements that the RP required the IdP to sign.
As I wrote above, the “required” parameter is not indicating parameters to be signed. There is no parameter to request the response parameters to be signed in the OpenID Authentication 2.0. It is up-to the IdP to decide what is to be signed besides mandatory parameters such as claimed_id, identity, etc. Therefore, OpenID4Java implementation is actually correct. Therefore, the authors’ claim “we examined other popular websites Yahoo! Mail, zoho.com, manymoon.com and diigo.com. They were all vulnerable to this attack. ” cannot be verified without other evidences.
2. Data Type Confusion
In section “4.5. OpenID’s Data Type Confusion “, the authors identify a problem of RPs interpreting openid.ext1.value.email as email without respect to the value of openid.ext1.type.email. Of course, this is a non-compliant behavior by the RP. Type of openid.ext1.value.email is determined by the value of openid.ext1.type.email. If openid.ext1.type.email= http://schema.openid.net/contact/street2, then openid.ext1.value.email contains the second line of the street address. It is not email address.
Moreover, it is utterly wrong to identify the user with whatever the value of openid.ext1.value.email is.
The correct behavior is to identify the user using openid.claimed_id. Other parameters MUST NOT be used to identify the user. If RP uses any other parameter to identify the user, then it is a security hole. This is the root of problem.
3. Problem of not reading the specification and the importance of the deployment testing
There is one thing that paper revealed clearly though. People do not read the spec. In this case, both the implementers at Smartsheet etc., nor the authors of this paper read the OpenID Authentication 2.0 and OpenID Attribute Exchange 1.0. It clearly shows how difficult it is to have the implementers read and implement the specs correctly.
Changing the popele’s behavior is one of the hardest thing to achieve, and the formal specification languages is not an easy read. I do not expect the situation to improve much in the coming days.
Then, what can we do to help the situation?
Test tools!
In this respect, for OpenID Connect, test tools has been developed by Andreas Åkre Solberg and Roland Hedberg. Hopefully, the situation will be better for the OpenID Connect. [4]
[1] It is kind of unfortunate that I did not have time to review the paper in detail till now.
[2] In page 6, the authors states: “Particularly, openid.signed contains the list from openid.ext1.required on BRM1, an element that describes which elements the RP requires the IdP to sign, such as email, firstname and lastname, as shown in the popup by the mouse cursor in Figure 8. However, since openid.signed (BRM3) can be controlled by the adversary through openid.ext1.required (BRM1), there is no guarantee that any of the elements that the RP requires the IdP to sign will be signed
by the IdP (i.e., protected by openid.sig) in BRM3. ”
[3] Actually, Figure 8 is very misleading. The authors omits vital information by replacing with [WORD] and [LIST]. In OpenID Attribute Exchange 1.0, the key names like openid.ext1.type.email mean nothing. It may as well mean an address or age or anything. Omitting the value part of the key=value pair makes the figure very misleading.
[4] In fact, the paper is in a way demonstrating the usefulness of the black box deployment testing. I believe this kind of methodology should be widely deployed. I highly value the paper in this respect.
Response from the authors
The authors of the paper kindly provided me an response to the above article shortly after I have posted it.
Here is the response. I would like to take this opportunity to thank them deeply.
Dear Nat,
Thank you for writing the post and forwarding the link to us.
I think we are on the same page about technical natures of the two vulnerability cases. However, we feel that you misunderstood the purpose of the paper: we never claimed that the problems we discovered actually are caused by OpenID protocol; we just point out the vulnerabilities in the websites that integrate (sometimes customized) OpenID schemes. Following are the details of our points:
(1) Again, the paper is about how securely real-world websites deploy SSO schemes. This emphasis is hopefully clear in the title, the abstract and the introduction. We took an end-to-end view about the studied websites, and examined their security as a whole. Given an end-to-end vulnerability, we mainly described the facts, but didn’t take a position about whether it was RP’s fault or IdP’s, or whether it was a protocol bug or an implementation one.
(2) Specifically about one of your paragraphs in the post:
| In section 4.1, the authors points out that although the RP requests the parameters to be signed with openid.ext1.required, since the request is not signed, the openid.ext1.required can be manipulated and thus the response in the openid.signed would not include all of what was in the openid.ext1.required.
This interpretation of openid.ext1.required is wrong. |
Please understand that we did not try to interpret openid.ext1.required in the paper, but simply stated a fact: the openid.signed would not include all of what was in the openid.ext1.required.
(3) Regarding “Figure 8 marking ‘protected by openid.sig’ is wrong,” the paragraph above figure 8 gives the context of this figure. The trace shown in figure 8 was the trace that we actually collected from the website. In such a trace, the indicated elements were indeed protected by openid.sig. Again, we were stating a fact about the specific trace, but didn’t imply that “the openid spec requires such a signature coverage for all traces.”
(4) About the “broader impacts” section: similarly, we just stated the fact that “The source code showed that it only checked whether the signature covered all the elements in the openid.signed list, so a “verified” BRM3 does not ensure authenticity of the elements that the RP required the IdP to sign.” We didn’t attempt to say whether it was OpenID4Java’s fault.
(5) You wrote in the post that “Therefore, the authors’ claim ‘we examined other popular websites Yahoo! Mail,zoho.com, manymoon.com and diigo.com. They were all vulnerable to this attack.’ cannot be verified without other evidences.” Actually these are all RP websites. The sentence we wrote was to state the fact that we checked these websites, and they were vulnerable in the same way. You seem to indicate that we made such a claim based on the fact of OpenID4Java. No, there is no such inference. It is an independent evidence to show that the same vulnerability might be quite common among many websites.
(6) Regarding your paragraph about the data type confusion case, again, we were describing our observations, and the fact that we found on a number of end-to-end vulnerable websites. We didn’t say whether it was due to the openid spec.
I think that the biggest difference here is that we have different angles about the same set of technical understanding. This paper mainly states concrete facts about how real-world websites deployed SSO schemes, and your angle is mainly about what the specs say and how they should do. We didn’t discuss how they should do until section 5.
Please feel free to let us know how you think. If you agree with the above comments, we will really appreciate if this can be reflected on your blog.
Thanks,
Rui
(updated May 1, 2012)