Details about SAP vulnerability CVE-2022-22536 – Request smuggling
Chapters
Share Article
Request smuggling and request concatenation in SAP NetWeaver, SAP Content Server and SAP Web Dispatcher
In the February 2022 SAP patch round, an SAP Security Note 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 patching the SAP kernel executables is often not done promptly, we can expect this vulnerability present in the customer’s systems for quite some time.
As stated in the SAP Note and accompanying FAQ, the vulnerability was discovered by external researchers. It is present when HTTP(S) clients, like web browsers or other system APIs, access the SAP application server or SAP Web Dispatcher through an HTTP gateway that terminates TLS and processes the HTTP requests. An example of such HTTP gateways is the SAP Web Dispatcher, a 3rd party load balancer or reverse proxy. Direct access to SAP application servers does not necessarily lead to vulnerable scenarios.
The following scenarios illustrate the vulnerability of involved SAP components:
But what does “vulnerable” mean in this case? This question is not directly addressed by the SAP Note as it merely states “… 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”.
Delving into the CVE-2022-22536 Vulnerability
In a quest for more information, we found this blog and video by Martin Doyhenard explaining all the possible hacks via this attack vector. Particularly, the concept of HTTP request smuggling via HTTP pipeline desynching is well explained in the provided link. In the case of CVE-2022-22536, attackers could potentially obtain the session cookie from other users, leading to a session takeover for those logged into 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 abuse the above vulnerabilities practically, we found a GitHub repository with a Proof-of-Concept exploit and a repository from the researchers who found the vulnerability. The first GitHub repository did not offer a fully functional exploit but together with the second repository, some additional online research, and trial and error, we managed to obtain the example demonstrated below:
With this result:
To break down the above: a first HTTPS request is sent to the SAP ABAP server. However, within this request, a second request is smuggled in to call 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, zipped, and using SSL, this is how the complete command looks like:
Conclusion
As a member of the Dutch Institute for Vulnerability Disclosure (DIVD), I’m happy that DIVD began scanning for this vulnerability immediately after its release and started notifying owners of potentially vulnerable SAP systems. The aim was to lower the abuse of this critical vulnerability. Shortly after SAP released the patch, owners of potentially vulnerable SAP systems were promptly informed that they needed to act and patch their critical and internet-connected SAP systems.
A proper Vulnerability Management and Threat Detection process should be in place to address and fix these vulnerabilities in a timely, efficient, and effective manner for SAP customers to prevent abuse.
Get in touch with us to learn more about our SAP Security capabilities. We’re here to help! For more SAP security-related news, articles, and whitepapers, please follow us on LinkedIn!
