DDOS Attacks leveraging LDAP !

21382575392_223304551e_z
photo by Christiaan Colen

Yesterday, DDoS mitigation provider Corero Network Security disclosed a zero-day distributed denial of service attack (DDoS) technique, observed in the wild, that is capable of amplifying malicious traffic by a factor of as much as 55x. Several sites published the story as “Attackers are now abusing exposed LDAP servers to amplify DDoS attacks”.

 

According to Corero, the attacks exploited the Lightweight Directory Access Protocol (LDAP), but reading the details of the press release, it appears that the attackers were using Connectionless LDAP services (CLDAP) .

In this case, the attacker sends a simple query to a vulnerable reflector supporting the Connectionless LDAP service (CLDAP) and using address spoofing makes it appear to originate from the intended victim. The CLDAP service responds to the spoofed address, sending unwanted network traffic to the attacker’s intended target.

Connectionless LDAP  is a very old technical specification, published in 1995 as RFC 1798.  In 2003, this specification was obsoleted by RFC 3352 and moved to historical status. One of the main reason for obsoleting the proposed standard was its insufficient security capabilities.

OpenDJ, the open source LDAP Directory Services in Java, has never supported CLDAP and thus cannot be used in such attack. So, if you are a  ForgeRock customer, you should not worry about this kind of attack. But if you’re running a legacy product, that has CLDAP enabled by default, it is probably time to think about moving to a more recent and up to date directory service, such as OpenDJ.

 

Filed under: Directory Services, security Tagged: ActiveDirectory, attack, ddos, directory, Directory Services, directory-server, ldap, opendj, security

This blog post was first published @ ludopoitou.com, included here with permission.

Identity Disorder Podcast, Episode 4: The Rodeo of Things

identity-disorder-speakers-ep004

In episode 4, Daniel and Chris are pleased to welcome one of ForgeRock’s founders, Victor Ake. Victor gives his insight into the Identity of Things, talking the differences between constrained and unconstrained devices, how IoT brokers work, securing IoT devices using identity standards, and how microservices fit in to the picture. Other topics include airport hotels, wrestling, and–wait for it–the rodeo.

Episode Links:

ForgeRock IoT Page:
https://www.forgerock.com/solutions/devices-things/

ForgeRock Identity Summit in London and Paris
https://summits.forgerock.com/

All upcoming ForgeRock events:
https://www.forgerock.com/about-us/events/

Identity Disorder Podcast, Episode 3

Episode 3: It’s All About The Context

identity-disorder-speakers-ep003

In this episode of the podcast, Daniel and Chris are joined by Andy Hall and Simon Moffatt from ForgeRock product management. Topics include how and why context is important in identity, the recent ForgeRock Identity Summit and Unconference in Australia, the Olympic medal counts, and how Daniel gets into his Australian accent by saying “Bondi Beach.”

Episode Links:

ForgeRock Smart City video
https://vimeo.com/153044373

ForgeRock Privacy video
https://vimeo.com/157651841

DevOps Unleashed webinar replay:
https://go.forgerock.com/DevOps-Unleashed-Webinar_OnDemand.html

ForgeRock Identity Summit in London and Paris
https://summits.forgerock.com/

All upcoming ForgeRock events:
https://www.forgerock.com/about-us/events/

OpenAM Security Advisory #201605

Security vulnerabilities have been discovered in OpenAM components. These issues may be present in versions of OpenAM including 13.0.x, 12.0.x, 11.0.x, 10.1.0-Xpress, 10.0.x, 9.x, and possibly previous versions.

This advisory provides guidance on how to ensure your deployments can be secured. Workarounds or patches are available for all of the issues.

The maximum severity of issues in this advisory is Critical. Deployers should take steps as outlined in this advisory and apply the relevant update(s) at the earliest opportunity.

The recommendation is to deploy the relevant patches. Patch bundles are available for the following versions (in accordance with ForgeRock’s Maintenance and Patch availability policy):

  • 11.0.3
  • 12.0.2-12.0.3
  • 13.0.0

Customers can obtain these patch bundles from BackStage.

Issue #201605-01: Credential Forgery

Product: OpenAM
Affected versions: 11.0.0-11.0.3, 12.0.0-12.0.3, 13.0.0
Fixed versions: 13.5.0
Component: Core Server, Server Only
Severity: Critical

The Persistent Cookie authentication module is vulnerable to credential forgery. In some configurations this may allow an attacker unauthorized access to the system as any user.

Workaround:
Disable Persistent Cookie authentication module instances and require manual authentication, or combine the module with a mandatory second factor.

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201605-02: Insufficient Authorization

Product: OpenAM
Affected versions: 13.0.0
Fixed versions: 13.5.0
Component: Core Server, Server Only
Severity: Critical

Insufficient authorization on a query endpoint allows a non-privileged user to access details of other users on the system.

Workaround:
No workaround available.

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201605-03: Authentication Bypass

Product: OpenAM
Affected versions: 9-9.5.5, 10.0.0-10.0.2, 10.1.0-Xpress, 11.0.0-11.0.3, 12.0.0-12.0.3, 13.0.0
Fixed versions: 13.5.0
Component: Core Server, Server Only
Severity: High

In some configurations a user may be able to bypass additional authentication requirements and login with just username and password.

Workaround:
Ensure all authorization mechanisms and policies enforce all chain/module/service/role requirements have been met after authentication, such as by using OpenAM’s “Authenticated by Module Chain”, “Authenticated by Module Instance” or “Authenticated to Realm” environment conditions in conjunction with a policy agent.

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle and apply the workaround.

Issue #201605-04: Cross-Site Request Forgery (CSRF)

Product: OpenAM
Affected versions: 10.1.0-Xpress, 11.0.0-11.0.3, 12.0.0-12.0.3, 13.0.0
Fixed versions: 13.5.0
Component: Core Server, Server Only
Severity: High

The OAuth2 consent page is vulnerable to a CSRF attack.

Workaround:
No workaround available.

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle and update any customized authorize.ftl template files based on the patch.

Issue #201605-05: Cross Site Scripting (XSS)

Product: OpenAM
Affected versions: 9-9.5.5, 10.0.0-10.0.2, 10.1.0-Xpress, 11.0.0-11.0.3, 12.0.0-12.0.3, 13.0.0
Fixed versions: 13.5.0
Component: Core Server, Server Only
Severity: High

OpenAM is vulnerable to cross-site scripting (XSS) attacks which could lead to session hijacking or phishing. The following endpoints are vulnerable:

  • /openam/cdcservlet
  • /openam/SAMLPOSTProfileServlet

Workaround:
Protect the listed endpoints with the container (for example using the mod_security Apache module) or filter external requests until a patch is deployed.

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201605-06: Credentials appear in CTS access log

Product: OpenAM
Affected versions: 13.0.0
Fixed versions: 13.5.0
Component: Core Server, Server Only
Severity: Medium

OAuth 2 client requests using HTTP Basic authentication may result in the base64-encoded credentials being recorded in the CTS access logs.

Workaround:
Use alternative authentication mechanisms for OAuth2 clients, or protect the OpenDJ access logs for the CTS store.

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201605-07: Content Spoofing Vulnerability

Product: OpenAM
Affected versions: 9-9.5.5, 10.0.0-10.0.2, 10.1.0-Xpress, 11.0.0-11.0.3, 12.0.0-12.0.3, 13.0.0
Fixed versions: 13.5.0
Component: Core Server, Server Only
Severity: Low

Using a carefully crafted request an attacker can cause an alternative image and title text to be displayed on an admin console page.

Workaround:
Block access to the following endpoint:

  • /openam/ccversion/Version

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Data Confidentiality with OpenDJ LDAP Directory Services

FR_plogo_org_FC_openDJ-300x86Directory Servers have been used and continue to be used to store and retrieve identity information, including some data that is sensitive and should be protected. OpenDJ LDAP Directory Services, like many directory servers, has an extensive set of features to protect the data, from securing network connections and communications, authenticating users, to access controls and privileges… However, in the last few years, the way LDAP directory services have been deployed and managed has changed significantly, as they are moving to the “Cloud”. Already many of ForgeRock customers are deploying OpenDJ servers on Amazon or MS Azure, and the requirements for data confidentiality are increasing, especially as the file system and disk management are no longer under their control. For that reason, we’ve recently introduced a new feature in OpenDJ, giving the ability to administrators to encrypt all or part of the directory data before writing to disk.clouddataprotection

The OpenDJ Data Confidentiality feature can be enabled on a per database backend basis to encrypt LDAP entries before being stored to disk. Optionally, indexes can also be protected, individually. An administrator may chose to protect all indexes, or only a few of them, those that contain data that should remain confidential, like cn (common name), sn (surname)… Additionally, the confidentiality of the replication logs can be enabled, and then it’s enabled for all changes of all database backends. Note that if data confidentiality is enabled on an equality index, this index can no longer be used for ordering, and thus for initial substring nor sorted requests.

Example of command to enable data confidentiality for the userRoot backend:

dsconfig set-backend-prop 
 -h opendj.example.com -p 4444 
 -D "cn=Directory Manager" -w secret12 -n -X 
 --backend-name userRoot --set confidentiality-enabled:true

Data confidentiality is a dynamic feature, and can be enabled, disabled without stopping the server. When enabling on a backend, only the updated or created entries will be encrypted. If there is existing data that need confidentiality, it is better to export and reimport the data. With indexes data confidentiality, the behaviour is different. When changing the data confidentiality on an index, you must rebuild the index before it can be used with search requests.

Key Management - Photo adapted from https://www.flickr.com/people/ecossystems/

When enabling data confidentiality, you can select the cipher algorithm and the key length, and again this can be per database backend. The encryption key itself is generated on the server itself and securely distributed to all replicated servers through the replication of the Admin Backend (“cn=admin data”), and thus it’s never exposed to any administrator. Should a key get compromised, we provide a way to mark it so and generate a new key. Also, a backup of an encrypted database backend can be restored on any server with the same configuration, as long as the server still has its configuration and its Admin backend intact. Restoring such backend backup to fresh new server requires that it’s configured for replication first.

The Data Confidentiality feature can be tested with the OpenDJ nightly builds. It is also available to ForgeRock customers as part of our latest update of the ForgeRock Identity Platform.


Filed under: Directory Services Tagged: confidentiality, data-confidentiality, directory-server, encryption, ForgeRock, identity, java, ldap, opendj, opensource, security

How to protect your OpenAM deployment against clickjacking

If you ever seen a security report for one of your web applications, there is a good chance that you have seen a big warning about Clickjacking already. Clickjacking is a certain kind of attack that essentially allows the attacker to trick a victim into performing an operation that most likely they didn’t want to carry out. If you want to learn more about clickjacking then I would recommend having a read of this well detailed page.

The best way to protect against these attacks is actually rather simple: RFC 7034 describes the X-Frame-Options header that needs to be set on the HTTP responses for pages that you wish to prevent from being clickjacked. The X-Frame-Options header has three accepted values:

  • DENY: the browser should never display the contents of the requested content in a frame.
  • SAMEORIGIN: Only display the content in a frame, if the enclosing page(/top level browsing context — see RFC) is in the same origin as the content itself.
  • ALLOW-FROM: Allows you to specify an origin from which it is allowed to display the contents of the requested resource.

How to configure OpenAM?

Since OpenAM 12.0.1 it is possible to utilize a built-in servlet filter to add arbitrary HTTP headers to our responses. The configuration of the filter is quite simple, you just have to add the following snippets to web.xml (obeying the XML schema):

<filter>
  <filter-name>Clickjacking</filter-name>
  <filter-class>org.forgerock.openam.headers.SetHeadersFilter</filter-class>
  <init-param>
    <param-name>X-Frame-Options</param-name>
    <param-value>DENY</param-value>
  </init-param>
</filter>
...
<filter-mapping>
  <filter-name>Clickjacking</filter-name>
  <url-pattern>/XUI/*</url-pattern>
  <url-pattern>/UI/*</url-pattern>
  <url-pattern>/console/*</url-pattern>
  <url-pattern>/oauth2/authorize</url-pattern>
  <dispatcher>FORWARD</dispatcher>
  <dispatcher>REQUEST</dispatcher>
  <dispatcher>INCLUDE</dispatcher>
  <dispatcher>ERROR</dispatcher>
</filter-mapping>

The above url-patterns list is not an exhaustive list of resources that you may wish to protect, however it should serve as a good start. Alternatively you could just change the url-pattern to /* and then you only really need the REQUEST dispatcher in your filter mapping config.

Please keep in mind that there are lots of different ways to set the X-Frame-Options header for your deployment, so feel free to utilize those instead if needed.

OpenAM Security Advisory #201604

Security vulnerabilities have been discovered in OpenAM components. These issues may be present in versions of OpenAM including 13.0.0, 12.0.x, 11.0.x, 10.1.0-Xpress, 10.0.x, 9.x, and possibly previous versions.

This advisory provides guidance on how to ensure your deployments can be secured. Workarounds or patches are available for all of the issues.

The maximum severity of issues in this advisory is Critical. Deployers should take steps as outlined in this advisory and apply the relevant update(s) at the earliest opportunity.

The recommendation is to deploy the relevant patches. Patch bundles are available for the following versions (in accordance with ForgeRock’s Maintenance and Patch availability policy):

  • 11.0.3
  • 12.0.1
  • 12.0.2
  • 13.0.0

Customers can obtain these patch bundles from BackStage.

Issue #201604-01: User Impersonation via OAuth2 access tokens

Product: OpenAM
Affected versions: 11.0.0-11.0.3, 12.0.1-12.0.2, 13.0.0
Fixed versions: 12.0.3
Component: Core Server, Server Only
Severity: Critical

A specific type of request to the /openam/oauth2/access_token endpoint can result in obtaining OAuth2 access token on behalf of any user in the current realm.

Workaround:
Ensure that com.sun.identity.saml.checkcert advanced server property is set to on (default) so that basic certificate validation is being carried out. Additionally, you must verify that the OpenAM keystore does not contain expired and/or untrusted certificates.

If unsure, block all access to the /openam/oauth2/access_token endpoint.

Resolution:
Deploy the relevant patch bundle. Note that as part of the resolution several additional checks have been implemented for the SAML2 OAuth2 grant. After installing a patch you will need to perform the following additional steps:

  • The issuer of the assertion must be configured as a remote IdP
  • The audience of the assertion must be configured as a hosted SP
  • The hosted SP and the remote IdP must be in the same Circle Of Trust
  • The assertion parameter value MUST be Base64url encoded

Issue #201604-02: Open Redirect

Product: OpenAM
Affected versions: 9-9.5.5, 10.0.0-10.0.2, 10.1.0-Xpress, 11.0.0-11.0.3, 12.0.0-12.0.2, 13.0.0
Fixed versions: 12.0.3
Component: Core Server, Server Only
Severity: High

The following endpoint does not correctly validate redirect URLs allowing an attacker to redirect an end-user to a site they control:

  • /openam/idm/EndUser

Workaround:
Block all access to the /openam/idm/EndUser endpoint

Resolution:
Deploy the relevant patch bundle and ensure that at least one whitelist URL is defined for the redirection validation to be applied.

Issue #201604-03: Cross Site Scripting

Product: OpenAM
Affected versions: 9-9.5.5, 10.0.0-10.0.2, 10.1.0-Xpress, 11.0.0-11.0.3, 12.0.0-12.0.2, 13.0.0
Fixed versions: 12.0.3
Component: Core Server, Server Only, DAS
Severity: High

OpenAM is vulnerable to cross-site scripting (XSS) attacks which could lead to session hijacking or phishing.
The following endpoint was found vulnerable:

  • /openam/cdcservlet

Workaround:
Block all access to the /openam/cdcservlet endpoint.

Resolution:
Deploy the relevant patch bundle.

Issue #201604-04: Insufficient Authorization

Product: OpenAM
Affected versions: 11.0.0-11.0.3, 12.0.0-12.0.2, 13.0.0
Fixed versions: 12.0.3
Component: Core Server, Server Only
Severity: High

Due to insufficient authorization checks it is possible to modify arbitrary user attributes for a personal account when using the /json/users endpoint.

Workaround:
Disable the forgotten password feature in all realms:

  • Disable Forgot Password for Users under Legacy User Self Service service (13.0.0)
  • Disable Forgot Password for Users under User Self Service service (12.0.x)
  • Disable Forgot Password for Users under REST Security service (11.0.x)

Resolution:
Deploy the relevant patch bundle.

Issue #201604-05: Information Leakage via Account Lockout

Product: OpenAM
Affected versions: 13.0.0 (and versions with #201601 security patch applied)
Fixed versions: 12.0.3
Component: Core Server, Server Only
Severity: Medium

OpenAM can leak information about password correctness even when OpenAM’s Account Lockout feature is enabled, allowing brute-force attackers to guess passwords for end-users.

Workaround:
Disable Account Lockout in OpenAM, and utilize the underlying Data Store’s account locking capabilities.

Resolution:
Deploy the relevant patch bundle.

Issue #201604-06: Information Leakage

Product: OpenAM
Affected versions: 9-9.5.5, 10.0.0-10.0.2, 10.1.0-Xpress, 11.0.0-11.0.3, 12.0.0-12.0.2, 13.0.0
Fixed versions: 12.0.3
Component: Core Server, Server Only
Severity: Medium

OpenAM can leak details about the home directory of the user running the OpenAM container.

Workaround:
Remove the /openam/nowritewarning.jsp file from the OpenAM WAR file.

Resolution:
Deploy the relevant patch bundle and delete the nowritewarning.jsp file from the OpenAM deployment.

OpenIDM Security Advisory #201602

Security vulnerabilities have been discovered in OpenIDM components. These issues are present in versions of OpenIDM including 3.x and 4.0.x.

This advisory provides guidance on how to ensure your deployments can be secured. Workarounds or patches are available for all of the issues.

The maximum severity of issues in this advisory is High. Deployers should take steps as outlined in this advisory and deploy the recommended workarounds or resolutions as described within each issue below.

Issue #201602-01: Unencrypted Repo JDBC Password

Product: OpenIDM
Affected versions: 3.0.0, 3.1.0, 4.0.0
Fixed versions: n/a
Component: OpenIDM JDBC Repository Server
Severity: High

JDBC Repository passwords are no longer auto-encrypted by OpenIDM when the repository is activated. As a result, the password stored within the repository configuration as well as those written to the JSON configuration files (repo.jdbc.json or datasource.jdbc-default.json) and the OpenIDM log will appear in clear-text.

Workaround:
Manually encrypt the JDBC Repository password using the OpenIDM Command-Line Interface as detailed in the following Knowledge Article: Repository password is not encrypted in OpenIDM 3.x or 4.x log and configuration files.

Resolution:
None.

OpenAM Security Advisory #201601

Security vulnerabilities have been discovered in OpenAM components. These issues may be present in versions of OpenAM including 12.0.x, 11.0.x, 10.1.0-Xpress, 10.0.x, 9.x, and possibly previous versions.

This advisory provides guidance on how to ensure your deployments can be secured. Workarounds or patches are available for all of the issues.

The maximum severity of issues in this advisory is Critical. Deployers should take steps as outlined in this advisory and apply the relevant update(s) at the earliest opportunity.

The recommendation is to deploy the relevant patches. Patch bundles are available for the following versions (in accordance with ForgeRock’s Maintenance and Patch availability policy):

  • 10.0.2
  • 11.0.3
  • 12.0.1
  • 12.0.2

Customers can obtain these patch bundles from BackStage.

Issue #201601-01: Open Redirect

Product: OpenAM
Affected versions: 9.5.5, 10.0.2, 10.1.0-Xpress, 11.0.0-11.0.3, 12.0.0-12.0.2
Fixed versions: 13.0.0
Component: Core Server, Server Only, DAS
Severity: Critical

Due to a bug in the goto URL validation system it was possible to perform Open Redirect attacks by sending the end-users to specially constructed URLs that were considered valid by the goto URL validator.

Workaround:
Enable the XUI, which is not vulnerable to this issue.

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201601-02: Potential Denial of Service attack in multi-site deployments

Product: OpenAM
Affected versions: 9-9.5.5, 10.0.2, 10.1.0-Xpress, 11.0.0-11.0.3, 12.0.0-12.0.2
Fixed versions: 13.0.0
Component: Core Server, Server Only
Severity: High

Multi-site deployments of OpenAM which share the same load-balancer are vulnerable to a Denial of Service attack using carefully crafted requests.

Workaround:
Configure load-balancers to only route requests for a single site and not to re-route any requests for a different site.

Resolution:
Deploy the workaround or update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201601-03: Cross Site Scripting

Product: OpenAM
Affected versions: see below
Fixed versions: 13.0.0
Component: see below
Severity: High

OpenAM is vulnerable to cross-site scripting (XSS) attacks which could lead to session hijacking or phishing.
Affecting 9-9.5.5, 10.0.0-10.0.2, 10.1.0-Xpress, 11.0.0-11.0.3 and 12.0.0-12.0.2:
/openam/federation/* (Core Server)
/openam/saml2/jsp/exportmetadata.jsp (Core Server, Server Only)
/openam/WSFederationServlet/metaAlias (Core Server, Server Only)

Affecting 10.0.0-10.0.2, 10.1.0-Xpress, 11.0.0-11.0.3 and 12.0.0-12.0.2:
/openam/oauth2c/OAuthLogout.jsp (Core Server, Server Only)

Workaround:
Protect the listed endpoints with the container (for example using the mod_security Apache module) or filter external requests until a patch is deployed.

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201601-04: Open Redirect

Product: OpenAM
Affected versions: 9-9.5.5, 10.0.0-10.0.2, 10.1.0-Xpress, 11.0.0-11.0.3, 12.0.0-12.0.2
Fixed versions: 13.0.0
Component: Core Server, Server Only
Severity: High

The following obsolete ID-FF federation endpoints did not correctly validate redirect URLs allowing an attacker to redirect an end-user to a site they control:
/openam/consentHandler
/openam/federation

Workaround:
Block access to the listed endpoints with the container (for example using the mod_security Apache module) or filter external requests until a patch is deployed.

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201601-05: Business Logic Vulnerability

Product: OpenAM
Affected versions: 12.0.0-12.0.2
Fixed versions: 13.0.0
Component: Core Server, Server Only
Severity: High

If more than one realm is configured in OpenAM it is possible for a user in one realm to generate security tokens for a different realm via the REST STS.

Workaround:
Block access to the following URI:
/openam/rest-sts/*

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201601-06: Business Logic Vulnerability

Product: OpenAM
Affected versions: 12.0.0-12.0.2
Fixed versions: 13.0.0
Component: Core Server, Server Only
Severity: High

If more than one realm is configured in OpenAM it is possible for an OAuth2 client in one realm to obtain an OAuth2 access_token for a different realm.

Workaround:
Block access to the following URI:
/openam/oauth2/access_token

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201601-07: Open Email Relay

Product: OpenAM
Affected versions: 11.0.0-11.0.3, 12.0.0-12.0.2
Fixed versions: 13.0.0
Component: Core Server, Server Only
Severity: High

If the self-service interfaces are enabled it is possible for an attacker to send email using the configured email server.

Workaround:
Disable all user self-service interfaces in Configuration > Global > User Self Service and for any realms you have enabled it for in [realm] > Services > User Self Service.

Resolution:
Important Note:
This is a backwards-incompatible change, the forgotPassword and register actions are now utilizing localized messages defined in RestSecurity.properties. To define different subjects and messages per realm, please utilize the new “Localization Bundle” setting in the User Self Service service.
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201601-08: Previous Administrator Password Still Valid

Product: OpenAM
Affected versions: 9-9.5.5, 10.0.0-10.0.2, 10.1.0-Xpress, 11.0.0-11.0.3, 12.0.0-12.0.2
Fixed versions: 13.0.0
Component: Core Server, Server Only
Severity: High

After changing the administrator (amAdmin) password it is possible to log in using the old password until the new password has been used once.

Workaround:
After changing the administrator password, log in once using the new password on each server in the deployment or restart all servers.

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201601-09: Insufficient Authorization

Product: OpenAM
Affected versions: 12.0.0-12.0.2
Fixed versions: 13.0.0
Component: Core Server, Server Only
Severity: High

If the Device ID Match/Save modules are used, it is possible for an attacker to access saved device profiles for another user and use them to spoof that user’s device.

Workaround:
Block access to the following endpoint:
/openam/json/users/*/devices/trusted/
Where * should match any user id.

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle. If you believe that a user’s device profiles may have been compromised then you should disable Device ID Match modules.

Issue #201601-10: Information Leakage

Product: OpenAM
Affected versions: 9-9.5.5, 10.0.0-10.0.2, 10.1.0-Xpress, 11.0.0-11.0.3, 12.0.0-12.0.2
Fixed versions: 13.0.0
Component: Core Server, Server Only
Severity: Medium

It is possible to obtain information about which accounts exist on the system by sending carefully crafted requests to the following endpoints:
/openam/json/authenticate
/openam/identity/authenticate
/openam/identity/xml/authenticate
/openam/identity/json/authenticate

Workaround:
Block access to the following endpoints:
/openam/json/authenticate
/openam/identity/authenticate
/openam/identity/xml/authenticate
/openam/identity/json/authenticate

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201601-11: Open Redirect

Product: OpenAM
Affected versions: 9-9.5.5, 10.0.0-10.0.2, 10.1.0-Xpress, 11.0.0-11.0.3, 12.0.0-12.0.2
Fixed versions: 13.0.0
Component: Core Server, Server Only, DAS
Severity: Medium

If relative goto URLs are added to the redirect URL whitelist an attacker can use a carefully crafted URL to redirect end-users to a different destination.

Workaround:
Ensure that all whitelisted redirect resources are in absolute format, i.e. they have protocol scheme defined.

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201601-12: OATH Replay Vulnerability

Product: OpenAM
Affected versions: 10.1.0-Xpress, 11.0.0-11.0.3, 12.0.0-12.0.2
Fixed versions: 13.0.0
Component: Core Server, Server Only
Severity: Medium

If OATH TOTP authentication is enabled an attacker who is able to intercept a TOTP code may be able to replay it within the same TOTP time step.

Workaround:
Disable OATH TOTP authentication or reduce the time step size to mitigate the vulnerability.

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201601-13: Open Redirect

Product: OpenAM
Affected versions: 9-9.5.5, 10.0.0-10.0.2, 10.1.0-Xpress, 11.0.0-11.0.3, 12.0.0-12.0.2
Fixed versions: 13.0.0
Component: Core Server, Server Only
Severity: Medium

Using a carefully crafted request an attacker may be able to redirect an end-user to a non-validated redirect URL. The attacker must be able to set cookies in the same domain as OpenAM. The following endpoint is vulnerable:
/openam/cdcservlet

Workaround:
Block access to the following endpoint if you are not using CDSSO:
/openam/cdcservlet

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle

Issue #201601-14: Content Spoofing Vulnerability

Product: OpenAM
Affected versions: 9-9.5.5, 10.0.0-10.0.2, 10.1.0-Xpress, 11.0.0-11.0.3, 12.0.0-12.0.2
Fixed versions: 13.0.0
Component: Core Server, Server Only
Severity: Medium

Using a carefully crafted request an attacker can display plain text messages within the content of a valid page.

Workaround:
Block access to the following endpoints:
/openam/validatorFooter.jsp
/openam/validatorWait.jsp

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Issue #201601-15: Password Logging

Product: OpenAM
Affected versions: 9-9.5.5, 10.0.0-10.0.2, 10.1.0-Xpress, 11.0.0-11.0.3, 12.0.0-12.0.2
Fixed versions: 13.0.0
Component: Core Server, Server Only
Severity: Low

If MESSAGE-level debug logging is enabled the SecurID module logs passwords in plain text.

Workaround:
Disable MESSAGE-level debug logging in all production environments.

Resolution:
Update/upgrade to a fixed version or deploy the relevant patch bundle.

Impersonation Authentication module for OpenAM

Introduction

Support for impersonation is useful in the enterprise use cases where designated administrators are required to act on behalf of a user in certain scenarios. By impersonating another user an administrator, if authorized to do so, gains access to a restricted view of the user’s profile in the system. This is helpful in situations involving password reset, request-based access and profile updates. However, the design of such a system must call for controls that actively restrict access to the user’s entitlements at the outset. This can be achieved using step-up authentication for gaining access to private user data, and also by using the OpenAM policy engine for performing advanced resource-based decisioning.

Configuration

An OpenAM custom authentication module was written to enable impersonation support. The module requires input of the username of the end-user being impersonated and the administrator credentials. After submitting the username and password, the admin account is authenticated first and then it is also authorized to complete the impersonation request using REST calls to a specified OpenAM Policy endpoint. This policy can be either local or external as we shall examine further. The impersonated user is also validated for being in active status in the system. If all is okay, the administrator is permitted to impersonate and OpenAM creates a session for the impersonated user. The module can be configured using the following gauges to complete the described functions correctly:

  1. Setup the resource-set you want to check policy for. This resource set its nothing but a special URL that invokes policy evaluation for impersonation
  2. The authentication realm you want the administrator to authenticate in. The authentication module allows for realm-specific authentication
  3. The OpenAM server where the policy resides, the realm where the policy resides, and the policy-set name. The policy does not need to be local and can be on a remote policy host
  4. Check whether you want the administrator to be a member of a local group as well, in addition to the external policy authorization.
A step by step account of the workings of the module follows.

Development

Configuration read from Module Instance

options -> {iplanet-am-auth-check-group-membership=[True], iplanet-am-auth-impersonation-hash-enabled=[true], iplanet-am-auth-authentication-realm=[authn], iplanet-am-auth-impersonation-auth-level=[1], iplanet-am-auth-resource-set=[http://openam:8080/openam/index.html], moduleInstanceName=impersonate, iplanet-am-auth-impersonation-id=[Enter the user id to impersonate?], iplanet-am-auth-impersonation-group-name=[impersonation], iplanet-am-auth-openam-server=[http://openam:8080/openam], iplanet-am-auth-policy-realm=[impersonation], iplanet-am-auth-policy-set-name=[impersonation]}

Authorize the administrator locally

In our test scenario, the ‘user.0’ is really an administrative user that has been granted membership to the group named ‘impersonation’, as configured in the module (see above).

We build an AMIdentity object for the group and validate membership.

[AMIdentity object: id=impersonation,ou=group,o=impersonation,ou=services,dc=openam,dc=forgerock,dc=org]
value of attribute: uid=user.0,ou=People,dc=forgerock,dc=com
userName to check: user.0
match found! admin: user.0 allowed to impersonate user: user.1

Authorize the Administrator

Get the ssotoken for the admin who is trying to impersonate via a policy call, and authenticate the user to the realm specified in the config

json/authn/authenticate response-> {"tokenId":"AQIC5wM2LY4Sfcxokjvdayf3ig0oDuQITXRTWT9B_3hq72A.*AAJTSQACMDEAAlNLABI1ODk0Nzg1NTEyNDUzNzcxNDI.*","successUrl":"/openam/console"}
tokenId-> AQIC5wM2LY4Sfcxokjvdayf3ig0oDuQITXRTWT9B_3hq72A.*AAJTSQACMDEAAlNLABI1ODk0Nzg1NTEyNDUzNzcxNDI.*

 

Build the 2nd policy rest call, and use the resource set, openam server, policy set and policy container from the configuration passed to the module.

stringentity-> {"resources": ["http://openam:8080/openam/index.html"],"application":"impersonation", "subject": {"ssoToken":"AQIC5wM2LY4Sfcxokjvdayf3ig0oDuQITXRTWT9B_3hq72A.*AAJTSQACMDEAAlNLABI1ODk0Nzg1NTEyNDUzNzcxNDI.*"}}
json/impersonation/policies?_action=evaluate response-> [{"advices":{},"actions":{"POST":true,"PATCH":true,"GET":true,"DELETE":true,"OPTIONS":true,"PUT":true,"HEAD":true},"resource":"http://openam:8080/openam/index.html","attributes":{"uid":["user.0"],"cn":["Javed Shah"],"roleName":["timeBoundAdmin"]}}]

Custom response attributes can be passed back to the module for further evaluation if needed. For example, a statically defined roleName=timeBoundAdmin could be used to further restrict this impersonation request within the time window specified in the ‘timeBoundAdmin’ control. This example is only given to seed the imagination, the module currently does not restrict the impersonation session using a time window, but this is possible to do.

Parse the JSON response from Policy Evaluation

jsonarray-> {"resource":"http://openam:8080/openam/index.html","attributes":{"uid":["user.0"],"cn":["Javed Shah"],"roleName":["timeBoundAdmin"]},"advices":{},"actions":{"POST":true,"PATCH":true,"GET":true,"DELETE":true,"OPTIONS":true,"HEAD":true,"PUT":true}}
If the ACTION set returned for GET/POST is TRUE, the admin is permitted to impersonate. This could be extended to include other actions as necessary. Finally, destroy the admin session, now that it is not needed anymore and return the impersonated user as the Principal for constructing an OpenAM session.

Demo

Our short demo begins with the administrator being asked for the username of the user they want to impersonate.
Next, the module asks for the admin credentials.
If the administrator is unable to authenticate, or does not belong to the local group, or fails external policy evaluation, the following error screen is shown.
If all checks pass, the adminsitrator is granted the user’s session and logs into OpenAM.

Source

This article was first published on the OpenAM Wiki Confluence site: Impersonation in OpenAM