CAS Threat Modeling

Information Disclosure

An ST sent over http may be intercepted by an attacker and then sent to CAS to retrieve the attributes for that user as well as the PGTIOU and the proxies.

Hardening guide to include dangers of including http services in service manager uri patterns.

Change Service Manager default configuration to not generate and ST for a http based service. The current default has http://* in the list of valid services.

Validate server identity using a client Cert sent in the serviceValidate call. Or make it an option in the services manager to require a client cert. Other methods could be used such as basic auth (using a shared secret) or else IP filtering. This is less secure but easier to set up.

Warning in the service manager that http is dangerous. Perhaps warning in the log file.

Tool to look for more misconfigurations.

An ST sent over http may be intercepted by an attacker and then sent to a service to spoof the client.

An attacker may probe for a misconfigured CAS server by asking for service ticket for various services at /login or at /serviceValidate until it finds a URI that should not be able to get tickets, but can if it can take over that URI.

At /serviceValidate, ensure that if the ticket is not valid, then the response is always the same and does not reveal anything about the service registry.

At the login URI, only disallow the call for an "invalid" service, once a user supplies a password, so that at least only authenticated users can do this probing. Or lock down an account that makes too many login calls with an invalid "service".

It maybe that this cannot be mitigated because you have to support gateway access: https://secure.example.com/cas/login?gateway=true&service=https://myfishing

It is easy to write bad patterns in the services registry when using ant patterns (this info needs validation).

Here is a possible example :

If you define the following service : http://example.*/myService to match http://example.com/myService and http://example.fr/myService, it's a bad idea as it can be tricked by http://example.hostattacker.com/myService.

Default to using regexp or other pattern matching that is not prone to failure.

Document the pitfalls of ant matching in the security guide.

An attacker could construct a odd, but legal URI to trick the services pattern matching. See http://static.springsource.org/spring-security/site/docs/3.2.x/reference/springsecurity-single.html#request-matching for what spring security does. Here is an example of an odd, but legal path in a uri: /secure;hack=1/somefile.html;hack=2

Write a security/hardening guide for CAS clients which contains all the needed advice for writing a secure CAS client in one place.

Information Disclosure

Always use HTTPS for proxy callbacks. Hopefully, this is the default in the CAS server.

Never log the GET parameters on the proxy callback url. Though, it might be not sufficient.

Should we change the CAS protocol in the next revision (v4.0) to POST these parameters ?

A map with all pgtIou and pgtId must be saved to be able to associate the user's identity (and the pgtIou from /serviceValidate url for example) and PGT.

Sending a lot of proxy callback calls with fake pgtIou and pgtId can fill the memory and cause the web application to crash.

Don't use default memory implementation.

Use more advanced cache systems if they have been implemented to store pgtIou and pgtId.

Information Disclosure

If HTTPS is not used, the PGT can be stolen, which is extremely critical as it represents a SSO identity.

Always use HTTPS for /proxy url.

Never log the GET parameters on the /proxy url. Though, it might be not sufficient.

Should we change the CAS protocol in the next revision (v4.0) to POST these parameters ?

Information Disclosure

Attack on network :

For memcached/database (whatever the number of nodes) or Ehcache/JBoss cache (on multinodes), data are transfered between nodes using TCP.

These data can be intercepted and scanned to know which TGT is linked to which identity.

Add an entry to the hardening guide to indicate that single node CAS deployments should prefer to use Ehcache since the communication between CAS and Ehcache will be internal to the JVM. Also, disk persistence should preferably turned off to avoid saving the sensitive data to the disk.

Add an entry to the hardening guide to indicate that the ehcache/jboss replication or the external database/memcached should either be restricted to a private network, or else run over SSL/TLS to protect the data in transport

Encryption/hashing scheme:

• TGT should have a hashed TGTID; other aspects of the TGT should be encrypted with the TGTID.
• ST should have a hashed STID; other aspects of the TGT (e.g. the attributes) should be copied to the ST and encrypted with the STID.
• This will not allow back-channel SLO to work on ticket expiration (see CAS-686).

Attack on disk :

For database/Ehcache cache storage on disk, an attacker can read the content of the stored files and find the identities and their associated TGT.

Add an entry to the hardening guide to indicate that for single node CAS, disk persistence should preferably turned off to avoid saving the sensitive data to the disk.

Add an entry to the hardening guide to indicate that the any disk based memory should either be restricted to a private storage, or else encrypt data on disk.

Should we really use Ehcache to store data on disks : not really performant and secure ?

For database, some encryption mechanism can be enabled on disk stored data.

Attack on memory:

Various tools can scan the memory of other processes. We should try to do things to protect the data in memory and hash and encrypt data as soon as possible. This may involve interactions with the garbage collector, including removing sensitive data in the clear so that the young garbage collector can handle this sensitive data rather than relying on the full garbage collection to remove this data.