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.