An HTTP Request Smuggling vulnerability in Pulse Secure Virtual Traffic Manager could allow an attacker to 'smuggle' an HTTP request through an HTTP/2 header.
In particular, customers whose security relies upon the traffic manager blocking certain requests from certain backends should upgrade as soon as possible.
Customers wanting to know whether they have been impacted are advised to examine access logs on back-ends. For example (and note that other attacks are possible with other configurations), if there is a custom Trafficscript rule such as:
|
$path = http.getPath();
$ip = request.getRemoteIP();
if (string.startswithi ($path, "/admin") &&
!string.ipmaskmatch ($ip, "1.2.3.4")) {
http.sendResponse("403 Denied", "", "", "");
}
|
which restricts requests for /admin to only IP 1.2.3.4, then the vulnerability means requests for /admin could be allowed from IP addresses other than 1.2.3.4. The X-Cluster-Client-IP header (with the client’s original IP) that vTM adds to normal requests by default is not added to the smuggled requests, and due to the nature of the vulnerability, it is possible that the X-Cluster-Client-IP header on the outer request isn’t recognized by the backend as part of the outer request, hence isn’t logged either. Hence, requests logged without the X-Cluster-Client-IP header that are supposed to have it may be suspicious.
Whether or not there is anything unusual in vTM’s Virtual Server request logs depends on which particular header is used (attacker chosen) and if the configured log format includes logging that header.
This issue is applicable to Pulse Secure Virtual Traffic Manager. No other Pulse Secure products are currently known to be affected by this vulnerability.
| CVE | CVSS Score | Product
Affected |
|
CVE-2021-31922
| 7.5 High
3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N | Virtual Traffic Manager |
