Home / vulnerabilities cosign-vuln-2007-001.txt
Posted on 12 April 2007
Source : packetstormsecurity.org Link
VULNERABILITY ALERT
-------------------
Vulnerability: COSIGN-VULN-2007-001
Application: cosign
Affected Versions: 2.0.1 and previous, excluding 1.9.4a
Vulnerability Type: Authentication bypass, remotely exploitable
Severity: Critical
Software Website: http://weblogin.org/
Contact: cosign@umich.edu
Dates: 2007-02-19 (discovered); 2007-03-28 (public disclosure)
OVERVIEW
--------
A remotely exploitable vulnerability has been discovered that allows attackers
to bypass cosign weblogin server authentication and 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.
Both the CGI as well as the filter on each cosign-protected web server set
their own cookie in users' browsers for the purpose of uniquely identifying
the user's session. These cookie values are random strings.
Additional background details are available at
http://weblogin.org/overview.html
TECHNICAL DETAILS
-----------------
An unauthenticated web user can inject arbitrary commands to the cosign daemon
by passing a malicious cookie to the cosign CGI as a part of an HTTP POST
request. The CGI fails to properly validate the characters that comprise
the cookie and passes it to the daemon, which executes the protocol commands
injected by the attacker.
A cosign CGI cookie normally has the form
cosign=X
where X is a base64 string consisting of 128 random characters generated by
the cosign CGI.
A malicious cookie has the form
cosign=X
LOGIN cosign=X 1.2.3.4 username
REGISTER cosign=X 1.2.3.4 cosign-servicename=Y
where X represents any base64 string of 128 characters chosen by the attacker,
represents a carriage return (the single ASCII character 0x0D), 1.2.3.4
represents the attacker's IP address, username represents the user id of the
user the attacker wishes to impersonate, servicename represents name by which
the cosign-protected service the attacker wishes to access identifies itself
to the central weblogin server, and Y represents a second base64 string of 128
characters chosen by the attacker. The attacker can easily determine the
service name by examining the cookie set by a cosign-protected web server.
In order to determine whether the user is authenticated, the CGI will pass the
command "CHECK cookie" to the daemon, where cookie represents the cookie
name=value pair. Due to the improper validation of the characters that
comprise the cookie, the malicious cookie, above, results in the following
command being sent to the daemon:
CHECK cosign=X
LOGIN cosign=X 1.2.3.4 username
REGISTER cosign=X 1.2.3.4 cosign-servicename=Y
The embedded carriage returns are treated as command separators and the
following commands are executed:
CHECK cosign=X
LOGIN cosign=X 1.2.3.4 username
REGISTER cosign=X 1.2.3.4 cosign-servicename=Y
The CHECK command, sent by the CGI, determines whether the user with the
cookie cosign=X has authenticated; this command returns a negative answer,
which does not affect the rest of the attack.
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=X at IP address 1.2.3.4.
The REGISTER command, injected by the attacker, instructs the daemon to
associate the service cookie cosign-servicename=Y with the cookie cosign=X
for IP address 1.2.3.4.
The attacker can then pass the cookie cosign-servicename=Y 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.
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.
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
cookie 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 against the CGI will not work even against the unpatched filters,
as the daemon will not accept LOGIN or REGISTER commands from the filters.
Also, 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-02-19 Report describing the vulnerability written by Jon Oberheide of
the University of Michigan.
2007-02-21 cosign development team informed of the vulnerability.
2007-02-22 Initial patch developed and deployed on University of Michigan
weblogin servers for testing.
2007-02-25 cosign 2.0.2, cosign 1.9.4a, and final patch released.
2007-02-26 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 the
vulnerability and working with Professor Honeyman from the University of
Michigan Center for Information Technology Integration (CITI) to bring the
vulnerability to our attention. This vulnerability alert is largely based
upon Jon's original report.
