aTrust WebVPN Arbitrary Service Access and Non-Rotating Token

Report Information

1. Overview

Sangfor aTrust's ALLWEB resources publish internal web applications to remote users through the WebVPN gateway. With a valid gateway session, the client establishes a session for the target application via the exchange chain of verify → sdpAppCode application callback → original application URL, and ultimately holds the sdp_user_token cookie applicable to the target application.

Two issues were identified during reproduction:

1. The gateway lacks restrictions on the target address: as long as the gateway session is valid, an attacker can use the WebVPN gateway to access arbitrary HTTP services, not just the authorized published applications. The gateway does not perform allowlist validation on the target Host, path, or internal address ranges, effectively acting as a session-protected open HTTP proxy (SSRF / unauthorized access).
2. Token is not rotated during keep-alive: as long as the session is continuously kept alive, sdp_user_token and related gateway credentials are not refreshed. Credentials remain valid far beyond the expected period, allowing leaked tokens to remain usable for a long time and making it difficult to mitigate through rotation.

When combined, an attacker only needs to steal a single valid token to access internal HTTP services at will over a long period.

2. Affected Versions

3. Technical Background

3.1 Token Exchange Mechanism

The token exchange chain is as follows:

Application URL → verify → application callback with sdpAppCode → original application URL

sdpAppCode is the bridging parameter from the gateway-side verification result to the application entry. The final application cookie is sdp_user_token, with its scope determined by the actual Set-Cookie. The exchange is considered complete when: the final request reaches the intended application, the response succeeds, and a non-empty sdp_user_token with an applicable scope exists in the cookie store.

Below, gateway.example.com denotes the gateway, app.example.com denotes an authorized published application entry, and internal-http.local denotes the original address of an unauthorized internal HTTP service.

3.2 URL Conversion Mechanism

WebVPN converts the original target URL into an encoded hostname under the gateway's published domain, following these rules:

http://A    ⇒  https://A.example.com
http://A:0  ⇒  https://A-0-p.example.com
https://A   ⇒  https://A-s.example.com
https://A:0 ⇒  https://A-0-p-s.example.com
http://A.B  ⇒  https://A-B.example.com
http://A-B  ⇒  https://A--B.example.com

This encoding can express HTTP targets of any protocol, host, and port. By constructing the corresponding *.example.com hostname according to these rules, an attacker can direct requests to any HTTP service, which forms the basis for exploiting Vulnerability 1.

4. Vulnerability 1: Gateway Can Access Arbitrary HTTP Services

4.1 Description

When forwarding requests, the WebVPN gateway only validates "whether a valid gateway session / valid token exists", and does not validate "whether the target address belongs to an application resource authorized for the current user". With a valid session, an attacker can rewrite the request target from an authorized application to any HTTP service (internal applications, loopback addresses, cloud metadata addresses, etc.), and the gateway will forward the request and return the response as usual.

ALLWEB resource publishing does not establish a target address allowlist at the gateway layer, turning the gateway into a session-protected arbitrary HTTP proxy.

4.2 Reproduction Steps

Prerequisite: a valid gateway session has been obtained (the exchange chain in Section 3 can be completed normally, and the authorized application app.example.com is accessible).

1. Log in following the normal flow and establish a gateway session. Record the gateway session cookies and the authorized application's sdp_user_token.
2. Following the rules in Section 3.1, encode an arbitrary HTTP target into a *.example.com hostname. For example, to access the internal http://internal-http.local:

   GET / HTTP/1.1
   Host: internal--http-local.example.com
   Cookie: <applicable gateway session cookies>

   When the target is HTTPS or has a port, append -s or -<port>-p according to the rules, which can also be expressed.
3. Observe the response: the gateway returns the response content and status code of the target service internal-http.local, rather than 403/404 or an "unauthorized resource" message.
4. Change the target to other internal HTTP services, loopback addresses, or metadata addresses. Encode them following the same rules and repeat the requests; responses are obtained in all cases, proving that the target address is not subject to an allowlist.
5. Compare with authorized applications: accessing an authorized application and accessing an arbitrary HTTP target behave identically at the gateway's authentication layer; the only difference is the target address, indicating that the gateway does not perform resource-level authorization.

5. Vulnerability 2: Token Not Rotated During Keep-Alive

5.1 Description

Under normal circumstances, subsequent responses may rotate the token, but as long as the session is continuously kept alive, sdp_user_token (and the gateway session credentials) are not refreshed for a long time. The token may only change when the session naturally expires and is re-exchanged.

1. A leaked token remains valid throughout the keep-alive period and cannot naturally expire through "rotation".
2. An attacker can maintain an idle session with periodic keep-alive requests, keeping stolen credentials usable indefinitely (unless an absolute expiration is hit or the server proactively revokes them).

5.2 Reproduction Steps

1. Complete the exchange chain in Section 3 and record the full value of sdp_user_token (record a fingerprint after masking).
2. Access authorized application resources at fixed intervals (e.g., every 5 minutes) to keep the session active; each time, record the response Set-Cookie and the current token value.
3. Observe continuously for a sufficiently long period (recommended ≥ 24 hours, spanning any possible rotation window):

Conclusion: as long as keep-alive is uninterrupted, the token value remains identical to the initial value and continues to be valid, with no rotation occurring.

6. Combined Impact

7. Remediation Recommendations

7.1 Gateway Target Address Restriction

1. Establish a target address allowlist (protocol, Host, port, path prefix) for each ALLWEB resource, and enforce matching before forwarding.
2. Validate the request Host and reject Hosts inconsistent with published resources.
3. Filter loopback addresses, link-local addresses, cloud metadata addresses, and unauthorized targets within private network segments.
4. Bind the scope of sdp_user_token to the target resource, and directly reject cross-resource requests.
5. Perform independent resource-level authorization checks on forwarding targets; do not rely solely on "session validity".

7.2 Token Rotation

1. Introduce periodic rotation: force tokens to expire after a fixed validity period, even while actively kept alive.
2. Introduce post-use rotation: issue a new token after sensitive operations or important resource access, with the old value immediately invalidated.
3. Keep-alive requests should also trigger credential updates, or force re-exchange when keep-alive reaches a threshold.
4. Provide a proactive revocation mechanism for leaked credentials, with all derived tokens immediately invalidated upon revocation.

7.3 Detection and Monitoring

1. Log the target addresses and access frequency of WebVPN forwarding, and alert on abnormal targets and abnormal frequencies.
2. Audit and alert on long-period reuse of the same token and cross-resource access.

8. Timeline