VULNERABILITY ALERT
-------------------

Vulnerability:       COSIGN-VULN-2007-002
Application:         cosign
Affected Versions:   2.0.2 and previous, excluding 1.9.4b
Vulnerability Type:  Authentication bypass, remotely exploitable
Severity:            Critical
Software Website:    http://weblogin.org/ 
Contact:             cosign@umich.edu
Dates:               2007-03-07 (discovered); 2007-03-28 (public disclosure)


OVERVIEW
--------

A remotely exploitable vulnerability has been discovered that allows attackers
who are already authenticated via cosign to assume the identity of an
arbitrary user on a cosign-protected service.  Organizations that run their
own central cosign weblogin server should upgrade their weblogin server to
cosign 2.0.2a, cosign 1.9.4b, or back-port the patch available at
http://weblogin.org/download.html to the version of cosign they are running.

cosign 2.0.2a, 1.9.4b, and the patch also strengthen input validation for the
Apache HTTPD cosign filters.  Although no exploitable vulnerability is
currently known for the Apache HTTPD cosign filters, the cosign developers
recommend that all cosign-protected web servers that run mod_cosign for Apache
HTTPD 1.3.x or 2.x should be upgraded to the latest version of the filters.


BACKGROUND
----------

cosign is a web single-sign-on system.  Written at the University of Michigan,
cosign is an open source software project and a part of the National Science
Foundation Middleware Initiative (NMI) EDIT software release.  cosign is
deployed extensively at the University of Michigan and at educational
institutions and other organizations around the world.
 
cosign consists of two primary components:  the central weblogin server and
cosign-protected web servers.  The central weblogin server consists of a
cosign CGI (logs users in and out), the cosign daemon (manages information
about the state of the session for each authenticated user), and various
administrative scripts.  Each cosign-protected web server runs a filter
which communicates with the daemon via a text-based protocol to assure that
users who access protected areas of the web site are authenticated.  Users
must authenticate to CGI on the central weblogin server before they are
permitted access to a protected service. 

Additional background details are available at
http://weblogin.org/overview.html


TECHNICAL DETAILS
-----------------

Attackers who are already authenticated via cosign can assume the identity of
an arbitrary user on a cosign-protected service by sending a specially-crafted
malicious POST request to the CGI running on the central weblogin servers.
For sites that run cosign/Friend, a Friend account created by the attacker is
sufficient to launch the attack against a regular user's identity.

When an authenticated user attempts to access a service they have not
previously accessed during the login session, the cosign CGI will associate
the user's cosign login cookie ("cosign=X") with a cosign service cookie
("cosign-servicename=Y"), by issuing the following command to the cosign
daemon:

REGISTER cosign=X 1.2.3.4 cosign-servicename=Y

where 1.2.3.4 is the user's IP address and "servicename" is the name of the
cosign-protected service which the already-authenticated user is trying to
access.  X and Y are the values assigned to the cookies by cosign -- these
are strings of 128 random base64 characters generated by cosign.

Normally, the user's browser would be automatically redirected to the CGI
by the cosign-protected service that the authenticated user is trying to
access.  The service name would be passed as a part of the query string
in this scenario.  However, since the attempt to access the service may
trigger re-authentication and/or require the user to present additional
authentication factors, the CGI also keeps track of the service name in
a hidden form field.  When the user submits the form with their password
(or other factors), this data is sent to the CGI via an HTTP POST request.

An attacker who is already authenticated can take advantage of insufficient
input validation of the POST data by crafting a malicious POST request in
order to assume the identity of an arbitrary user:

POST /cosign-bin/cosign.cgi HTTP/1.0
Host: weblogin.example.com
Cookie: cosign=X
Content-Type: application/x-www-form-urlencoded
Content-Length: N

required=&ref=https%3A%2F%2Fweblogin.example.com%2F&service=cosign-servicename=Y%0DLOGIN cosign=X2 1.2.3.4 username%0DREGISTER cosign=X2 1.2.3.4 cosign-servicename=Y2&login=test&password=pass&passcode=&doLogin=Log+In

In the example above, weblogin.example.com is the name of the central cosign
weblogin server, X is the value of the attacker's cosign cookie (assigned to
them by cosign when they authenticated), N is the length of the POST data
body, servicename is the name of the service the attacker wishes to access as
another user, Y is a cosign service cookie value generated by the attacker
(any string of 128 base64 characters will work), 1.2.3.4 is the attacker's
IP address, username is the username of the user whose identity the attacker
wishes to assume, and X2 and Y2 are two additional strings of 128 base64
characters, each, generated by the attacker.  Any "+" characters in Y, X2,
and Y2 need to be escaped as "%2B" when sent as a part of the POST request.

When processed by the CGI, the value of the service field is interpreted as

cosign-servicename=Y\rLOGIN cosign=X2 1.2.3.4 username\rDREGISTER cosign=X2 1.2.3.4 cosign-servicename=Y2

Where \r represents a carriage return (the single byte 0x0D).

The CGI then attempts to execute the command

REGISTER cosign=X 1.2.3.4 cosign-servicename=Y\rLOGIN cosign=X2 1.2.3.4 username\rDREGISTER cosign=X2 1.2.3.4 cosign-servicename=Y2

The embedded carriage returns are treated as command separators and the
following commands are executed:

REGISTER cosign=X 1.2.3.4 cosign-servicename=Y
LOGIN cosign=X2 1.2.3.4 username
REGISTER cosign=X2 1.2.3.4 cosign-servicename=Y2

The first REGISTER command, sent by the CGI, instructs the daemon to
associate the service cookie cosign-servicename=Y with the cookie cosign=X
for IP address 1.2.3.4.  This authenticates the attacker to the service,
servicename, as themselves, although the attacker does not care about this.

The LOGIN command, injected by the attacker, (falsely) asserts that the CGI
has successfully authenticated the attacker as username and instructs the
daemon to associate username with the cookie cosign=X2 at IP address 1.2.3.4.

The second REGISTER command, injected by the attacker, instructs the daemon to
associate the service cookie cosign-servicename=Y2 with the cookie cosign=X2
for IP address 1.2.3.4.

The attacker can then pass the cookie "cosign-servicename=Y2" as a part of any
request to the cosign-protected service that identifies itself using
servicename.  The filter running on the cosign-protected service will check
the cookie provided by the attacker with the daemon, and the daemon will
respond with the username provided by the attacker in the LOGIN command
above.  The attacker is thus able to access servicename as username without
having to authenticate as username.

NOTE: The information above is intended as a description of the vulnerability
and not as a test for use in determining whether a weblogin server is
vulnerable.  The attack described above may require tweaking in order to be
used against an actual cosign installation.

Although cosign can be configured to use multiple factors for authentication
(regular passwords, SecureID one-time password generation tokens, and so on),
the attack above bypasses all authentication checks for username.



ADDITIONAL INFORMATION
----------------------

cosign 2.0.2a, cosign 1.9.4b, and the patch available at
http://weblogin.org/download.html fix the vulnerability by rejecting any
POST data supplied to the CGI that contains any characters other than the ones
which are expected.

Since the cosign filters for Apache HTTPD 1.3.x and 2.x share some code with
the cosign CGI, the new versions of cosign and the patch above include
stronger cookie input validation for the Apache filters.  Note, however, that
the attack cannot work against the cosign filters, as they do not accept POST
data.  Still, even though no exploitable vulnerability is currently known for
the Apache HTTPD cosign filters, the cosign developers recommend that all
cosign-protected web servers that run mod_cosign for Apache HTTPD 1.3.x or 2.x
be upgraded to the latest version of the filters.

The cosign developers are immediately beginning a code review of the entire
cosign distribution, including both the IISCosign and JavaCosign filters, in
order to identify and remove any other security vulnerabilities which might
exist.  Fixes for any further vulnerabilities that may be discovered will be
released on the cosign-announce and cosign-discuss mailing lists.  Patches
and suggestions submitted by members of the cosign community will also
gratefully be accepted.

The cosign developers deeply regret that this vulnerability was present in
cosign, and that it got past all previous code reviews as well as the
independent audit performed on the cosign code in 2005.  All possible efforts
will be made to ensure that no further vulnerabilities exist so that users
of cosign can once again trust it.

Organizations that have questions regarding cosign, or that need assistance
with upgrading cosign to a non-vulnerable version or back-porting the patch
to an older version, can contact the cosign development team at
cosign@umich.edu.


TIMELINE
--------

2007-03-07  cosign development team informed of the vulnerability by Jon
            Oberheide of the University of Michigan.

2007-03-12  Initial patch developed and deployed on University of Michigan
            test weblogin servers for testing.

2007-03-19  Patch deployed on University of Michigan production weblogin
            servers for testing.

2007-03-21  cosign 2.0.2a, cosign 1.9.4b, and final patch released.

2007-03-21  Private disclosure to non University of Michigan members of the
            cosign-announce and cosign-discuss mailing lists, to permit them
            to address the vulnerability on their weblogin servers before
            public disclosure of the vulnerability.

2007-03-28  Public disclosure.


ACKNOWLEDGMENTS
---------------

Thanks to Jon Oberheide from the University of Michigan for discovering and
reporting the vulnerability.  This vulnerability alert is largely based
upon Jon's original report.