| 4 min read
Table of contents
It looks like this is going to be a promising year for vulnerability research. Although the discovery of high and critical severity vulnerabilities may leave some biting their nails down to the nub, perhaps also understandably fascinated, it should lead to reinforcing application security.
Case in point: Last year, cybersecurity and compliance solutions specialist Onapsis dived into HTTP response smuggling. This is when attackers abuse interpretation and parsing discrepancies in different HTTP agents to inject malicious content that evades security controls. Fast forward to the beginning of this month, it looks like the firm struck gold. They shared that they found several vulnerabilities allowing the aforementioned kind of attack in a common component of German software multinational SAP's applications. One of the vulnerabilities is rated critical. Luckily, the coordinated actions of Onapsis and the SAP Product Security Response Team led to a patch release along with the public disclosure the same day, February 8.
We're dedicating this post to communicate what the recent critical vulnerability in SAP is about.
What's the bug deal?
Organizations use SAP applications to manage critical business processes. These include enterprise resource planning and customer relationship, product lifecycle and supply chain management. Some SAP applications are SAP NetWeaver, SAP Content Server and SAP Web Dispatcher. The thing is: These three, for instance, have a component by default called Internet Communication Manager (ICM). What it does is it provides a working HTTP(S) server to enable the products to connect to the Internet. It also enables them to talk to each other via HTTP(S). And what happens when there are vulnerabilities in this component? Chaos ensues.
The problem affecting the ICM concerns its memory handling mechanism. To understand this, we ought to know how this component works.
ICM does things typical of a server; that is, it "listens on a connection for a request, parses each message received, interprets the message semantics in relation to the identified request target, and responds to that request with one or more response messages." It does this in the shared memory of the operating system by placing the message on a buffer by means of Memory Pipes (MPI), that is, a group of data structures and functions.
Let's say the message is parsed; then the ICM lists the HTTP handlers that will process it, the last one being the back-end (e.g., Java/ABAP application) invoker that, sharing the same memory space with ICM, receives the message through the MPI buffers. These buffers have all the same, small capacity and, depending on its size, a message could take up more than one buffer.
This is where things get ugly. The size of the HTTP message can be made intentionally too big, especially if it has malicious content attached. Assuming there's a proxy in place (i.e., an intermediary hub between the user and the ICM), the message will be forwarded to the ICM, but the latter will have to split it, affecting the response queue of the connection, handling one part and storing the extra portion. The researchers at Onapsis refer to this issue as HTTP desynchronization.
Exploiting the critical vulnerability in SAP, an unauthenticated attacker can smuggle a complete request that would alone produce an extra response. If this happens, again, the proxy would issue one request but receive a split response from the ICM, as a part is left in queue on a different MPI buffer. Now is when the victim steps onto the stage, sending, for example, a login request. When they send the message to the proxy, it will be forwarded by the proxy as one request but also get split in the ICM, which will store the extra response in queue for later. The attacker would then send another request and, leveraging HTTP desynchronization, receive back the sensitive information originally intended for the victim, such as their session cookies or token created after the login request. Thus, they would be able to hijack the victim's session.
Session hijacking is kind of tame compared to poisoning the proxy's web cache, which is another possibility described by Onapsis. It's the same mechanism, but the attacker's original message may contain malicious JavaScript concatenated with the URL they want to mess with. The payload is stored in the cache as the response of the URL. When the victim requests the system for the poisoned URL, the proxy returns the malicious response. This attack could persist and would compromise every single user and potentially the entire SAP application.
The bug has been squashed!
The vulnerability we just described was assigned the ID CVE-2022-22536 and rated critical with the highest possible CVSSv3 score of 10.0. As this score communicates straightforwardly, no privileges are required to exploit this vulnerability and it poses a critical threat to confidentiality, integrity and availability. Further, its ubiquity and low complexity (i.e., it's easy to exploit!) make it a major threat to cybersecurity.
A CISA advisory lists how exploitation of this vulnerability could impact organizations if left unpatched. Namely, "theft of sensitive data, financial fraud, disruption of mission-critical business processes, ransomware, and halt of all operations."
As mentioned at the beginning of this post, this poisonous bug was already patched, along with two other vulnerabilities in SAP. So, everyone is urged to go and patch their SAP applications asap!
FYI, Fluid Attacks' research team has kept busy too finding zero-day vulnerabilities. And our red team also looks for them in the systems of our clients using our Continuous Hacking service. Take a look at our advisories page to find out what we've been up to!
Table of contents
Share
Recommended blog posts
You might be interested in the following related posts.
