Request smuggling and request concatenation in SAP NetWeaver, SAP Content Server and SAP Web Dispatcher
In SAP’s patch round of February 2022, an SAP Security patch was released with a CVSS score of 10/10 named “Request smuggling and request concatenation in SAP NetWeaver, SAP Content Server and SAP Web Dispatcher”. This particular type of vulnerability is not common in SAP systems and therefore interesting to look at.
As stated in the SAP note and accompanying FAQ, the vulnerability is discovered by external researchers and is present when HTTP(S) clients (like browsers or other systems) access the SAP application server or SAP Web Dispatcher through an HTTP gateway that terminates TLS and processes the HTTP requests. Examples of such HTTP gateways are SAP Web Dispatcher or a 3rd party load balancer or reverse proxy. Direct access to SAP application servers is not vulnerable.
The following scenarios illustrate the vulnerability of involved SAP components:
|1) HTTP client –> SAP app server||SAP app server is not vulnerable|
|2) HTTP client –> SAP WD –> SAP app server||SAP app server is vulnerable|
|3) HTTP client –> SAP WD1 –> SAP WD2 —> SAP app server||SAP WD2 and SAP app server are vulnerable|
|4) HTTP client –> 3rd party gw –> SAP WD –> SAP app server||SAP WD and SAP app server are vulnerable|
|5) HTTP client –> 3rd party gw –> SAP app server||SAP app server is vulnerable|
But what does “vulnerable” mean in this case? This question is not really answered by the SAP notes as it only states that: “… an attacker can execute functions impersonating the victim or poison intermediary Web caches” and “A successful attack could result in a complete compromise of Confidentiality, Integrity and Availability of the system.”.
In a quest for more information, I found this blog and video by Martin Doyhenard explaining all the possible attacks via this attack vector. Especially the concept of HTTP request smuggling via HTTP pipeline desynching is explained well in the above link. In the case of CVE-2022-22536, the result could be that attackers obtain the session cookie for other users leading to session takeover from those users that are logged on to the application. If these users have high privileges in the SAP system, it effectively means a full compromise of the SAP system.
In a search to practically abusing the above vulnerabilities, I found this GitHub repository with a Proof-of-Concept exploit and this repository from the researchers who found the vulnerability. The first GitHub repo did not offer a fully working exploit but together with the second repository and some online searching and trial and error, I managed to get a fully working exploit (with limited impact) as shown below.
What happens in the above exploit is that a first HTTPS request is sent to the SAP ABAP server in this case, but in this request, a second request is smuggled that calls another URL. In this specific case, the ping service replies that the server was reached successfully.
The original request (with escaped backslashes and quotes) looks like this:
When base64 is encoded and zipped and using SSL the complete command looks like this:
The above example and output show that the exploitation works. In this case, not hijacking users’ sessions, but instead calling a second URL, interestingly by using the localhost (127.0.0.1) from the server, which might open possibilities to bypass HTTP blacklists.
As a member of the Dutch Institute for Vulnerability Disclosure (DIVD), I’m happy the DIVD started scanning for this vulnerability right after its release and started notifying owners of potentially vulnerable SAP systems. This is to lower abuse of this critical vulnerability. Already, after only a few days after SAP released the patch, owners of potentially vulnerable SAP systems were informed that they needed to act and patch their critical and internet-connected SAP systems.
We said it before, but it cannot be stated enough that a proper Vulnerability Management process should be in place to address and fix these vulnerabilities in a timely, efficient and effective manner for SAP customers to prevent abuse.