ZF2014-02: Potential security issue in login mechanism of ZendOpenId and Zend_OpenId consumer
Consumer component of
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.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,
assoc_handle, and, if present in
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
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.identity=http://victim.myopenid.com/, and additionally
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.
We have made the following changes to
- During the
verify()method of the consumer, if the
openid_op_endpointvalue 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_sigparameter, we check that the required parameters (as noted in the assertion section of the OpenID specification) are all present in the
The following releases contain the fixes:
- Zend Framework 1, version 1.12.4
- ZendOpenId, version 2.0.2
The Zend Framework team thanks the following for identifying the issues and working with us to help protect its users:
- Christian Mainka (Christian.Mainka@rub.de) and Vladislav Mladenov (email@example.com) researchers at the Ruhr-University Bochum for alerting us to the issue and for the suggestions on how to fix it;
- Enrico Zimuel (firstname.lastname@example.org) for implementing a solution.