Security Advisory

ZF2014-02: Potential security issue in login mechanism of ZendOpenId and Zend_OpenId consumer

Using the Consumer component of ZendOpenId (or Zend_OpenId in ZF1), it is possible to login using an arbitrary OpenID account (without knowing any secret information) by using a malicious OpenID Provider. That means OpenID it is possible to login using arbitrary OpenID Identity (MyOpenID, Google, etc), which are not under the control of our own OpenID Provider. Thus, we are able to impersonate any OpenID Identity against the framework.

Moreover, the Consumer accepts OpenID tokens with arbitrary signed elements. The framework does not check if, for example, both openid.claimed_id and openid.endpoint_url are signed. It is just sufficient to sign one parameter. According to https://openid.net/specs/openid-authentication-2_0.html#positive_assertions, at least op_endpoint, return_to, response_nonce, assoc_handle, and, if present in the response, claimed_id and identity, must be signed.

How the attack works

To realize the attack, we set up a malicious OpenID Provider (e.g. "http://openid.evil.com") that is able to generate valid OpenID tokens containing arbitrary openid.identifier and openid.claimed_id values. At that point, we can successfully authenticate with the issued identity controlled by our Identity Provider, e.g. "http://openid.evil.com?identity=bob". This confirms that our Identity Provider works correctly. Then we log out. Afterwards, we start the same login procedure, i.e. we submit the same Identity again ("http://openid.evil.com?identity=bob"). According to the OpenID specification, we are redirected to our Identity Provider ("http://openid.evil.com"). But this time, we configure our Identity Provider to ignore the requested identity ("http://openid.evil.com?identity=bob") and instead use a victim's identity (e.g. openid.claimed_id=http://victim.myopenid.com/, openid.identity=http://victim.myopenid.com/, and additionally op_endpoint=http://www.myopenid.com/server).

All other openid.* parameters are used as requested. Note that our Identity Provider is not authorized to issue tokens in the name of other Identity Providers (such as MyOpenID, Google, etc.). However, the token is accepted by the framework. In this manner we could impersonate other users/identities without knowing any credentials and secrets.

Action Taken

We have made the following changes to ZendOpenId\Consumer\GenericConsumer and Zend_OpenId_Consumer classes:

The following releases contain the fixes:

Other Information

Acknowledgments

The Zend Framework team thanks the following for identifying the issues and working with us to help protect its users:

back to advisories