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.
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.
We have made the following changes to ZendOpenId\Consumer\GenericConsumer
and
Zend_OpenId_Consumer
classes:
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.openid_sig
parameter, we check thatopenid_signed
list.The following releases contain the fixes:
The Zend Framework team thanks the following for identifying the issues and working with us to help protect its users:
Released 2014-03-06
Have you identified a security vulnerability?
Please report it to us at zf-security@zend.com