OpenAM security advisory #201203

Security issues have been discovered in OpenAM. These issues are present in versions of OpenAM from 9.0 to 9.5.4, 10.0.0 and also previous versions released under alternate names, such as OpenSSO. A straightforward workaround is available for all deployments.

NOTE: These problems are not present in the DAUI (Distributed Authentication User Interface, aka DAS), therefore if the only end-user access is via a DAUI/DAS you will not be vulnerable to these specific external attacks.

These issues are rated as Critical. Where security precautions have been taken, such as not running OpenAM as the root user (on Unix-like OSs), or applied the Security Best Practices, risk is limited but this should still be considered a serious issue for immediate attention.

ForgeRock has fixed these vulnerabilities in the project trunk and these updates are available in today’s nightly build. We are working to provide updates (9.5.5 and 10.0.1) as well as patches for recent earlier versions of OpenAM and will post details in this notice as soon as these are available.

Deployers should take immediate steps as outlined in this advisory and apply the relevant update(s) at the earliest opportunity.

Issue# 201203-01: XXE/SSRF vulnerability on OpenAM endpoint

Product: OpenAM
Version: 10.0.0, 9.5.4 and previous
Component: OpenAM Core Server, OpenAM Server-Only
Severity: Critical
JIRA ID OPENAM-1649

Technical details and mitigation

OpenAM is vulnerable to eXternal XML Entity inclusion/Server Side Request Forgery (XXE/SSRF) attacks which could reveal internal operating system information.

Upon receiving a well constructed XML, the /openam/authservice endpoint can generate content that might contain information about external resources and expose internal infrastructure.

To be able to use this exploit, the OpenAM end point must be exposed to the external attacker. If you have implemented the OpenAM Deployment Security Best Practices the risk is minimized.

 

Vulnerable endpoints:
/openam/authservice
/openam/loggingservice
/openam/namingservice
/openam/policyservice
/openam/profileservice
/openam/sessionservice

 

Workaround

Until OpenAM 9.5.5 (ETA 23rd Nov 2012) or 10.0.1 are released, filter external requests to the vulnerable endpoints using a reverse proxy or equivalent networking device. If agents are externally deployed they might need to connect to this endpoint for authentication, in such cases an ACL in the reverse proxy allowing the access to the specific IP address of the agent should be added.

Issue# 201203-02: XSS/CSRF on Debug.jsp

Product: OpenAM
Version: 10.0.0, 9.5.4 and previous
Component: OpenAM Core Server, OpenAM Server-Only
Severity: Critical
JIRA ID OPENAM-1870

OpenAM is vulnerable to cross-site scripting/cross-site request forgery (XSS/CSRF) attacks which could reveal internal operating system information.

By creating a specialized page an attacker can change OpenAM’s debug level (through frames/img tags). Note that this vulnerability requires that an admin has an active session on OpenAM, and visits this malicious site.

Workaround

Until OpenAM 9.5.5 (ETA 23rd Nov 2012) or 10.0.1 are released, delete the Debug.jsp file from your OpenAM deployment.

Resolution

Replace your current Debug.jsp file with the provided patched version http://www.forgerock.org/security/Debug.jsp.zip (contains Debug.jsp).

Issue# 201203-03: Information leakage on /openam/webcli

Product: OpenAM
Version: 10.0.0, 9.5.4 and previous
Component: OpenAM Core Server, OpenAM Server-Only
Severity: Critical
JIRA ID OPENAM-1871

This legacy interface may leak information about the file-system content. With deliberately constructed input it will tell whether a given file exists on the server or not (or it’s an actual directory).

Workaround

Until OpenAM 9.5.5 (ETA 23rd Nov 2012) or 10.0.1 are released, remove the following section from WEB-INF/web.xml:

<servlet-mapping>
<servlet-name>WebCLI</servlet-name>
<url-pattern>/webcli</url-pattern>
</servlet-mapping>

After performing this change you need to restart your container. Some containers might require re-bundling of the modified content and redeployment of the resulting new WAR.

©2019 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?