CAS Security Issues

Introduction

In the Fall of 2014 several security issues directly or indirectly affecting CAS server and clients (applications) have come to light. This page summarizes some of these issues and suggests mitigation steps to take or test with your CAS client application. For questions and comments about any of these issues, please see the Resources section below.

Issues

Issue 1: CVE-2014-4172 CAS clients

Background

There is an important security vulnerability that allows URL parameter injection due to improper URL encoding at the back-channel ticket validation step of the CAS protocol in some CAS clients. See CAS Client Security Vulnerability CVE-2014-4172 for more details.

Mitigation

Update vulnerable CAS clients as described in the announcement cited above.

Date: 2014-10-27
Client testing and validation of the servlet filter CAS Server Security Filter in auth-test.b.e begins. Please report any issues noted when configuring your test CAS client applications to use auth-test.b.e for validation of this CAS server-side security filter.

Date: 2014-11-10
The servlet filter is deployed to the auth.b.e cluster. At that time, please report any issues noted for production CAS client applications.

This servlet filter is only a partial mitigation for CVE-2014-4172. Please update vulnerable CAS client applications for complete mitigation of this issue.

Issue 2: CVE-2014-3566 SSLv3 vulnerability (POODLE)

Background

This vulnerability for the SSLv3 protocol allows a man-in-the-middle attacker to decrypt ciphertext using a padding oracle side-channel attack. See, for example, POODLE: SSLv3 vulnerability (CVE-2014-3566) for more details.

Mitigation

Disable SSLv3 in CAS clients (applications). Refer to vendor documentation such as the RedHat article cited above addressing this issue.

Date: 2014-11-03
Client application testing and validation of the CAS servers (auth-test.b.e) with SSLv3 disabled begins. Please report any issues noted when configuring your test CAS client applications to use auth-test.b.e as the CAS server. This will help us to validate correct operations without SSLv3 enabled in the CAS server.

Date: 2014-12-01
The CAS servers (auth.b.e) are configured with SSLv3 disabled. Please report any issues noted for production CAS client applications.

Date: 2015-03-09
The CAS second-level servers (auth-key.b.e) are configured with SSLv3 disabled. Please report any issues noted for production CAS client applications.

Known issues reported

Error report 1

We are using the Perl AuthCAS module. As of yesterday, we began getting the error: error IO::Socket::INET configuration failed error:00000000:lib(0):func(0):reason(0) unable to connect https://auth-test.berkeley.edu:443/ when trying to connect to auth-test using AuthCAS.

Analysis

Seen in the CAS server logs for the auth-test cluster are many service tickets being created for the redacted.berkeley.edu URL, but no ticket validations. There are no other errors in the logs related to this URL. This is consistent with a failure of the CAS client to contact the application to do the service ticket validation step because the lower-level communications are failing.

A simple test one can try against auth-test using OpenSSL on your hosts is the following:

echo Q | openssl s_client -connect "auth-test.berkeley.edu:443" -ssl3

vs.

echo Q | openssl s_client -connect "auth-test.berkeley.edu:443" -tls1

If the latter succeeds, then your OpenSSL libraries are working correctly and it's likely a matter of configuring your CAS client to request using the equivalent to the -tls1 option used with s_client. Another suggestion seen is to wrap the SSL client app in stunnel as a proxy so that the client doesn't need to know anything about TLS, but that seems fairly complex for a production setup.

Solution

We got AuthCAS to work by adding "SSL_version=>'TLSv1'" to the instantiation: my $CAS = new AuthCAS(casUrl => $CAS_SERVER, CAPath => $CALNET_CERT_PATH, SSL_version=>'TLSv1');

Error report 2

After recent changes to the CAS service on auth-test.b.e, I can't CAS authenticate using Coldfusion 9 (developer edition)-based applications anymore.

Solution

You were correct on Java libraries needing updating. I just updated the Java used in Coldfusion Developer Edition Server 9 to Java 1.7.0_71 from 1.6.xx and that solved the problem with the CAS service.

Error report 3

Aaron Russo reports:

I've discovered that the versions of openssl that ship with RHEL5 do not work with mod_auth_cas out-of-the box, and needs a simple patch to work.   I'm [append]ing the patch needed, in case you have customers still struggling with this issue. This has been tested against mod_auth_cas 1.0.9.1 on RHEL5.   In short, this patch forces TLSv1 for all connections to the CAS server.   I've built an RPM for people who would be better served by that, but would prefer to work with anyone needing that until I've got a larger install base than just my group to ensure it doesn't break anything.

Patch for mod_auth_cas on RHEL 5.x:

From: Aaron Russo Date: Mon, 1 Dec 2014 16:55:48 -0800 Subject: [PATCH] force curl to use tls1 for older openssl libraries --- src/mod_auth_cas.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git src/mod_auth_cas.c src/mod_auth_cas.c index 4d3e4fe..18d48cd 100644 --- src/mod_auth_cas.c +++ src/mod_auth_cas.c @@ -1623,6 +1623,9 @@ static char *getResponseFromServer (request_rec *r, cas_cfg *c, char *ticket) curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, (c->CASValidateServer != FALSE ? 1L : 0L)); + // workaround for openssl < 1.0 which don't negotiate tls1 properly + curl_easy_setopt(curl, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1); + if(apr_stat(&f, c->CASCertificatePath, APR_FINFO_TYPE, r->pool) == APR_INCOMPLETE) { ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, "MOD_AUTH_CAS: Could not load CA certificate: %s", c->CASCertificatePath); return (NULL); -- 1.7.1

Error Report 4

Using the rubycas-client 2.3.9, SSL connections to auth.b.e fail.

Solution

Monkey-patch for rubycas-client in config/initializers/patches.rb:

require 'casclient/client' CASClient::Client.class_eval do def https_connection(uri) Net::HTTP.ssl_context_accessor('ssl_version') https = Net::HTTP.new(uri.host, uri.port) https.use_ssl = (uri.scheme == 'https') https.verify_mode = (@force_ssl_verification ? OpenSSL::SSL::VERIFY_PEER : OpenSSL::SSL::VERIFY_NONE) https.ssl_version = :TLSv1 https end end

Error Report 5

Another Perl fix when using the LWP::UserAgent module as part of a CAS client is to update some key Perl modules using cpan if necessary. If cpan is broken due to previous updates, get PathTools (Cwd and File::Spec* modules) from a host where cpan works, then copy to the broken system. First reconfigure cpan to prevent future overwrites, then update the key modules:

cpan o conf makepl_arg INSTALLDIRS=site o conf commit   cpan -f -i LWP cpan -i Bundle::Net::LDAP cpan -f -i HTTP::Message

Update calls found in the CAS client code using LWP::UserAgent to explicitly use TLSv1:

my $ua = LWP::UserAgent->new(ssl_opts => { SSL_version => 'TLSv1' });

Issue 3: Need to replace SHA-1-based certificates

Background

The common signing algorithm SHA-1 is less secure than newer SHA-2 algorithms now available. Several browser vendors and certificate authorities have announced accelerated time lines for the deprecation of SHA-1-based certificates which will cause browser warnings or failures for these older certificates as time passes. See the article Important change announcement - deprecation of SHA-1 from Comodo for more details. Comodo issues the certificates used for the CalNet InCommon-Comodo Certificate Service.

Mitigation

Update server and intermediate CA certificates using SHA-1 signatures with the longest expiration dates first. Root CA certificates are not affected. Refer to the CalNet InCommon Certificate service FAQ cited above for requesting certificate renewals.

Date: 2015-03-31
New SSH-2-based certificate is deployed for the off-site CAS server (cas-p4.calnet.b.e) and the auth-test.b.e cluster. Next up, the auth.b.e cluster: see CAS TLS Certificates

Resources

Please send comments and questions to  Other discussions and announcements can be found on the calnet-developers@lists.berkeley.edu and ucb-security@lists.berkeley.edu email lists (please subscribe to post to and to follow these e-mail lists).