Skip to Content

uPortal 4.0.11.1

 

Overview

This is a security fix release of a vulnerability in all versions of uPortal 4 and dependent products, i.e., all versions of modern SSP and of uMobile.

The default configuration sets the CAS client library's acceptAnyProxy to true. That configuration is never appropriate for production use. In a typical environment, this configuration allows any CAS-using application to itself log into the portal as any user who CAS-authenticates to that application.

Nature of the vulnerability

This is an illicit proxy vulnerability wherein other applications using the same CAS server as the portal may be able to themselves access the portal as the end user, and then are able to do anything the end user would have been able to do through the portal.

This is not a privilege escalation vulnerability, in that illicit proxies can illicitly proxy only as users who use CAS to log in to them. They cannot arbitrarily become other users or escalate privileges beyond those of the user as whom they're illicitly accessing the portal.

Your portal doesn't need to accept proxy tickets

Your portal almost certainly doesn't need to accept proxy tickets at all. The acceptAnyProxy or authorized proxy chain configuration is not required for your portal to itself obtain proxy tickets for presentation to portlets or for proxying to other services, such as the CAS server ClearPass endpoint or a CASified IMAP server for the email preview portlet.

How likely is this to affect real production implementations?

Very likely to be exploitable; unlikely to have been exploited.

Spot checking actual real production implementations suggests that acceptAnyProxy has not been typically turned off in institution-local implementation processes where uPortal is implemented using CAS for login.

However, exploiting this illicit proxy vulnerability requires access to another application using that CAS server to operate as the illicit proxy. Ideally CAS-using applications will not have been compromised or abused, or if they were, the adversary won't have hit upon this particular way to abuse.

Remediation

Blocking this vulnerability as deployed

Local implementations of uPortal and dependent products (uMobile, SSP) can immediately block this illicit proxy opportunity by removing theacceptAnyProxy configuration from web.xml and restarting the servlet container to ensure the change takes effect.

Delete

<init-param>
  <param-name>acceptAnyProxy</param-name>
  <param-value>true</param-value>
</init-param>

That is, for example, in uPortal 4.0.11, in web.xml,

<filter>
  <filter-name>CAS Validate Filter</filter-name>
  <filter-class>org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter</filter-class>
  <init-param>
    <param-name>casServerUrlPrefix</param-name>
    <param-value>${environment.build.cas.protocol}://${environment.build.cas.server}/cas</param-value>
  </init-param>
  <init-param>
    <param-name>serverName</param-name>
    <param-value>${environment.build.uportal.protocol}://${environment.build.uportal.server}</param-value>
  </init-param>
  <init-param>
    <param-name>proxyCallbackUrl</param-name>
   <param-value>${environment.build.uportal.protocol}://${environment.build.uportal.server}${environment.build.uportal.context}/CasProxyServlet</param-value>
  </init-param>
  <init-param>
    <param-name>proxyReceptorUrl</param-name>
    <param-value>/CasProxyServlet</param-value>
  </init-param>
  <init-param>
    <param-name>acceptAnyProxy</param-name>
    <param-value>true</param-value>
  </init-param>
</filter>

Should instead be:

<filter>
  <filter-name>CAS Validate Filter</filter-name>
  <filter-class>org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter</filter-class>
  <init-param>
    <param-name>casServerUrlPrefix</param-name>
    <param-value>${environment.build.cas.protocol}://${environment.build.cas.server}/cas</param-value>
  </init-param>
  <init-param>
    <param-name>serverName</param-name>
    <param-value>${environment.build.uportal.protocol}://${environment.build.uportal.server}</param-value>
  </init-param>
  <init-param>
    <param-name>proxyCallbackUrl</param-name>
   <param-value>${environment.build.uportal.protocol}://${environment.build.uportal.server}${environment.build.uportal.context}/CasProxyServlet</param-value>
  </init-param>
  <init-param>
    <param-name>proxyReceptorUrl</param-name>
    <param-value>/CasProxyServlet</param-value>
  </init-param>
</filter>

For SSP deployments, this web.xml file is located at {tomcat}/webapps/ssp-platform/WEB-INF/web.xml. In some real-world SSP deployments, the entire CAS Validate Filter config block has already been commented out. Even in those cases, we recommend deleting the acceptAnyProxyconfig block.

Fixing in source

Besides modifying the web.xml in place as deployed in the servlet container, adopters should also apply this change to their source code and source control such that re-building and re-deploying their uPortal will result in a web.xml that does not set acceptAnyProxy to true. Implementation details of how to apply this change to source control will vary by adopter.

For SSP, each known deployment builds uPortal ("SSP-Platform") from source and maintains that source code in a fork of the Jasig uPortal Git repository. To apply the proposed change in such a fork ahead of the availablility of an upstream patch:

%> cd {platform-src}
# edit ./uportal-war/src/main/webapp/WEB-INF/web.xml to remove the `acceptAnyProxy` config block, then:
%> git add ./uportal-war/src/main/webapp/WEB-INF/web.xml
%> git commit -m "NOJIRA Remove acceptAnyProxy config"
%> git push <remote-name> <branch-name>
# Stop tomcat, backup the current contents of {tomcat}/webapps/, then:
%> ant "-Dmaven.test.skip=true" "-Denv={usual-filter-file-prefix}" clean deploy-war
# Start tomcat, if there are any problems, delete {tomcat}/webapps/ and restore from your backup

Selectively accepting proxy tickets

If a deployer actually needed their portal to accept proxy tickets, (1) they are likely mistaken because that would be an uncommon use case, but (2) this is easily accommodated by configuration of authorized proxies, also in web.xml, in an init-param replacing acceptAnyProxy.

Saving Graces

  1. Not all uPortal implementations use CAS. Implementations disabling CAS authentication in favor of another approach to login (e.g., Shibboleth) will have disabled the CAS client library configuration thereby blocking the illicit proxy opportunity.

  2. This is an illicit proxy vulnerability, requiring a proxy to operate illicitly. This is a vulnerability exploitable only by applications using CAS (not merely by an end user in a browser). In order to exploit this vulnerability, the adversary must control an application using the same CAS server. The adversary might control such an application by being its legitimate operator, by compromising such an application, or by making use of a CAS server that does not restrict services.

  3. This is an illicit proxy vulnerability, requiring a proxy to operate illicitly. In particular, the illicit proxy must be able to obtain CAS proxy tickets. Some CAS adopting environments use the service registry to curtail which services are able to obtain proxy tickets. Applications precluded from obtaining proxy tickets will be unable to exploit this vulnerability. (However, in many CAS environments the default configuration of all services are able to obtain proxy tickets is retained).

  4. This is an illicit proxy vulnerability, requiring a proxy to operate illicitly. In particular, a given end user must have actually logged into an abusive or compromised application using CAS in order to enable that application to illicitly proxy into the portal in his or her name (or have logged into a (chain of) CAS-using application(s) that then presented a proxy ticket to the illicit proxy -- any application in the proxy chain could operate as an illicit proxy).

  5. Some of the affected uPortal versions predated the adoption of Maven build filtering such that adopters were more likely to directly inspect and configure web.xml and may have fixed this in local configuration when doing so.

Affected software and versions

  • uPortal 4.0.0 and later, and software that depends on this, namely:
  • uMobile (all versions)
  • SSP(all versions)

Here's the commit adding the vulnerable configuration:

https://github.com/Jasig/uPortal/commit/af70a09cef5c875b2801c1953f99ba25dca1176f

Determining whether the vulnerability has been exploited in a particular environment

It will be difficult to determine whether this vulnerability has been exploited in a particular environment. CAS audit trail logging does not include sufficient detail to determine which services obtained proxy tickets for authentication to which other services (the obvious resulting CAS audit trail logging RFE will be added once this vulnerability advisory is made public). CAS server application logging and uPortal application logging could conceivably offer enough detail, but in the typical implementation will not be configured to log at this level of detail in production.

In environments where proxy tickets use the PT rather than ST prefix, whether proxy tickets have been presented for login to uPortal will be obvious on inspection of a container access log for the ticket parameter on requests for the uPortal login path, typically /Login . However, the Jasig CAS server product version 3 and later uses the ST prefix for both service tickets and proxy tickets, such that these tickets will be indistinguishable in access logs.

A nuance on when acceptAnyProxy is appropriate for production use

(This is a pedantic aside that can be safely ignored.)

acceptAnyProxy might be appropriately set to true in a production environment where something downstream of the CAS client library applies access control considerations to the proxy chain. Indeed, acceptAnyProxy is intended to allow disabling the simple access control rules available in the Java CAS Client library to prevent their getting in the way of applying more sophisticated rules downstream.