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\rLOGIN cosign=X 1.2.3.4 username\rREGISTER cosign=X 1.2.3.4 cosign-servicename=Y where X represents any base64 string of 128 characters chosen by the attacker, \r 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\rLOGIN cosign=X 1.2.3.4 username\rREGISTER 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.