Category Archives: Security

Shibboleth IDP File Permissions

The Future of Shibboleth SP

Shibboleth IDP File Permissions

In light of recent developments in the thread landscape involving JNDI, and Java library vulnerabilities such as Log4Shell (CVE-2021-44228), we note the critical importance of file permissions to the Shibboleth deployment.

Note: This document currently discusses only Linux-based deployments of Shibboleth IDP. We believe that the Windows installation handles permissions specific to that system automatically when performing an MSI-based installation procedure outlined by the wiki. We are investigating best practices for Windows installations and will update this document accordingly with our findings.

Linux Service Privileges

For a proper, secure installation of Shibboleth IDP, you should configure the servlet container (Jetty) to run as a non-root user. The proper configuration for this depends upon the servlet container of choice, i.e. for Eclipse Jetty (the recommended container):

Linux Filesystem Permissions

The most critical element of the file system permissions is to ensure that the user which runs the servlet container does not have write permissions for the IDP configuration files, except in select circumstances.

Below you'll find a small shell script to set appropriate permissions for a "standard" deployment, meaning:

  • all files are by-default owned by root,
  • select permissions are provided to the user account under which the servlet container runs, i.e. jetty,
  • Shibboleth is installed in the default location: /opt/shibboleth-idp, and
  • the $JETT_BASE directory of the Jetty installation is /opt/jetty-base
#!/bin/sh
chown -R root:jetty /opt/shibboleth-idp/;
chown -R jetty:jetty /opt/shibboleth-idp/{credentials,logs,metadata};
find /opt/shibboleth-idp -type d -exec chmod 750 {} \;
find /opt/shibboleth-idp -type f -exec chmod 640 {} \;
chmod -R 750 /opt/shibboleth-idp/bin;
chmod -R u-w /opt/shibboleth-idp/credentials;
chown -R root:jetty /opt/jetty-base/;
chown -R jetty:jetty /opt/jetty-base/{logs,tmp};
find /opt/jetty-base -type d -exec chmod 750 {} \;
find /opt/jetty-base -type f -exec chmod 640 {} \;

Essentially, the jetty user requires read-access to most files within the IDP installation directory, hence we set root to own those files and jetty as the group, with permissions for the owner (root) to be allowed to edit those files, and the group (jetty) permission to read. Other users have no access.

jetty needs to own the credentials, logs, and metadata directories, with write permissions only for logs and metadata. If jetty doesn't own credentials it's unable to unlock the cryptographic keys required for SAML, and will not start. We remove the jetty users permissions to write to those files separately (chmod -R u-w /opt/shibboleth-idp/credentials).

Likewise, jetty needs to be able to write to the logs and tmp directories from $JETTY_BASE.

Essentially, the goal is to allow the jetty user to have the absolute minimal permissions to run the IDP software.

N.B. With this goal in mind, we note that if you do not leverage any <MetadataProvider> elements which fetch metadata from external locations, you shouldn't even need to allow write access for the metadata directory. One option is to ensure that you specify a backingFilePath to a directory other than <IDP-HOME>/metadata, i.e. something like /var/cache/shibboleth. Then only that directory needs write access for jetty.

Need help assessing a security issue? Contact us to discuss your needs. IDM Engineering is a team of dedicated, honest SSO support engineers that are standing by to help!

Log4j Remote Code Execution Vulnerability

The Future of Shibboleth SP

Log4j Remote Code Execution Vulnerability

CVE-2021-44228 is a vulnerability identified with the Apache Log4j package that is classified under the highest severity (10 out of 10). This vulnerability allows an attacker to execute arbitrary code by injecting data into a logged message.

This post is an attempt to provide an analysis of the vulnerability and a discussion of potentially affected Identity Management products.

For details from the Apache Foundation regarding the Log4j package specifically, view the CVE details here: https://logging.apache.org/log4j/2.x/security.html

Vulnerability Description

This vulnerability, known colloquially as "Log4Shell" since it provides unhindered access to execute code on the compromised machine, affects one of the most popular logging libraries in the Java ecosystem ("over three billion devices run java").

A logger is supposed to just record details of an even to a file, database, or send it to another server to store it. But in the case of log4j, there are a few things that are performed before writing anything. One of the things it does is look for patterns like ${something} and will try to replace it with additional information, i.e. ${date} could be replaced by the date of the error.

The problematic issue is that there are messages logged including strings like:

${jndi:...

Logback tries to replace the data, invoking another mechanism that loads a resource from another computer... anywhere on the internet.

This data can be a malicious code.

Due to the nature of Java the malicious code is automatically run on the computer that used log4j, which means that at the attacker can make the targeted computer do (almost) anything. All that it takes for that code to execute is for the attacker to get the string to be logged.

If your java web server, for example, is logging what urls are accessed it could be as simple as including the malicious code in an HTTP request to the server.

Generic Mitigation Strategies

Adding log4j2.formatMsgNoLookups=true as a JVM property to any vulnerable application's Java Virtual Machine will remediate the issue.

External mitigation is also available via a Web Application Firewall (WAF). We recommend reaching out to your WAF vendor regarding mitigation for this vulnerability, and blocking some of the known prefixes such as:

${jndi:ldap://
${jndi:ldaps://
${jndi:rmi://
${jndi:dns://

Auth0

Auth0 cloud identity services are not vulnerable. See: https://twitter.com/auth0/status/1470086301902721024


Apereo CAS

CAS versions 6.3+ is vulnerable and requires immediate mitigation. Deployers can immediately mitigate by updating to the latest versions (at the time of writing) of each branch of CAS:

6.3.x

Modify your CAS overlay to point to the version 6.3.7.2.

6.4.x

Modify your CAS overlay to point to the version 6.4.4.

Alternative Mitigation

For users that can’t upgrade, another option is to set the log4j2.formatMsgNoLookups system property to true, e.g.

java -Dlog4j2.formatMsgNoLookups=true -jar cas.war

See: https://apereo.github.io/2021/12/11/log4j-vuln/ for additional details.


F5 BigIP

F5 BigIP products themselves are not vulnerable.

F5 provides guidance for deployers of F5 load balancers to block incoming traffic asserting the problematic JNDI strings here: https://support.f5.com/csp/article/K19026212


ForgeRock

The only ForgeRock product that utilizes Log4j is Autonomous Identity. ForgeRock Autonomous Identity is vulnerable, however all other ForgeRock products are not vulnerable.

As of December 13, 2021 a patch is unavailable, and as such ForgeRock recommends using the following setting:

log4j2.formatMsgNoLookups=true

for the Java Virtual Machine running Autonomous Identity.

For further details see: https://backstage.forgerock.com/knowledge/kb/book/b21824339#a39102625


Keycloak

Keycloak is not vulnerable unless you are using JMSAppender (non-standard; if you are using JMSAppender Keycloak recommends disabling that for now).

See: keycloak/keycloak#9078


Okta

Two on-premises Okta products (RADIUS Server Agent and On-Prem MFA Agent) are vulnerable. The mitigation for these products is to update to the latest version available from the Okta admin console.

Okta cloud-based identity solutions are not vulnerable.

See: https://sec.okta.com/articles/2021/12/log4shell


PingIdentity

PingFederate, PingAccess, PingCentral and PingIntelligence are vulnerable.

Maintenance releases that permanently resolve this issue will be made available soon, however in the meantime Ping recommends to mitigate in various ways depending upon your version and product. See: https://support.pingidentity.com/s/article/Log4j2-vulnerability-CVE-CVE-2021-44228 (Note: requires account, free from here.)


Shibboleth

Identity Provider

Shibboleth Identity Provider is not vulnerable using the default configuration. Shibboleth leverages SLF4j and Logback, not Log4j. Shibboleth IDP does ship with a Log4j bridge, however, leveraging this feature would require specifically enabling the functionality.

See: http://shibboleth.net/pipermail/announce/2021-December/000253.html for information provided by Shibboleth lead developer Scott Cantor.

You can read SLF4j's discussion of the Log4j issue here: http://slf4j.org/log4shell.html

In effect, you may be vulnerable if your specific configuration loads Log4j, so you should validate what libraries you are using for logging. Adding the startup string -Dlog4j2.formatMsgNoLookups=true to the JVM will provide protection if you are uncertain of what logging facility your server is using.

Service Provider

Shibboleth Service Provider is not vulnerable as it is not a Java-based product.


WSO2

The following WSO2 products are vulnerable:

  • WSO2 Identity Server 5.9.0 and above
  • WSO2 Identity Server Analytics 5.7.0 and above
  • WSO2 Identity Server as Key Manager 5.9.0 and above
  • WSO2 API Manager 3.0.0 and above
  • WSO2 API Manager Analytics 2.6.0 and above
  • WSO2 Enterprise Integrator 6.1.0 and above
  • WSO2 Enterprise Integrator Analytics 6.6.0 and above
  • WSO2 Micro Integrator 1.1.0 and above
  • WSO2 Micro Integrator Dashboard 4.0.0 and above
  • WSO2 Micro Integrator Monitoring Dashboard 1.1.0 and above
  • WSO2 Stream Processor 4.0.0 and above
  • WSO2 Stream Integrator 1.0.0 and above
  • WSO2 Stream Integrator Tooling 1.0.0 and above
  • WSO2 Open Banking AM 2.0.0 and above
  • WSO2 Open Banking KM 2.0.0 and above

WSO2 provides a shell script that can be executed from the application's base directory to locate the remove/update vulnerable classes: wso2/security-tools#169

See: https://docs.wso2.com/pages/viewpage.action?pageId=180948677 for additional details.

Need help assessing a security issue? Contact us to discuss your needs. IDM Engineering is a team of dedicated, honest SSO support engineers that are standing by to help!