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!

*** This is a Security Bloggers Network syndicated blog from Fluid Attacks RSS Feed authored by Jason Chavarría. Read the original post at: https://fluidattacks.com/blog/sap-critical-vulnerability/