Security Advisory: ZF2014-02

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:

During the verify() method of the consumer, if the openid_op_endpoint value is different from the previous server, related to the same openid_assoc_handle, we return false, reporting an error.
Before the signature validation of the openid_sig parameter, we check that
the required parameters (as noted in the assertion section of the OpenID specification) are all present in the openid_signed list.

The following releases contain the fixes:

Zend Framework 1, version 1.12.4
ZendOpenId, version 2.0.2

Other Information

Acknowledgments

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

Christian Mainka and Vladislav Mladenov, researchers at the Ruhr-University Bochum, for alerting us to the issue and for the suggestions on how to fix it;
Enrico Zimuel (enrico@zend.com) for implementing a solution.

Released 2014-03-06

Back to advisories

Have you identified a security vulnerability?

Please report it to us at zf-security@zend.com

Security