CVE-2021-33037: What bad can be done with HTTP request smuggling

Jens Kisters __SeibertSolutions

Hi,

im struggeling to understand how exactly this could be exploited.

Our instances in question have some CORS rules as the only security measures on the (HTTPS) reverse proxy level.

What risks come with this vulnerability, could an attacker hijack a user session?

What else could an attacker do?

Cheers

Jens

Jens Kisters __SeibertSolutions

On another channel i received this from Tobias Theobald from re:Solution

 

Disclaimer: this is based on my understanding of the issue. I am unfamiliar with this particular issue, but have a good knowledge about security in general.

I understand it could be used to bypass security measures that are enforced by a reverse proxy.

Yes. The issue arises by the backend application (e.g. Jira) and the reverse proxy (e.g. nginx or AWS ELB) interpreting the request differently from one another.
This specific issue seems to be about the Transfer-Encoding header specifically. So by exploiting this vulnerability, an attacker might be able to send a request such that if effectively bypasses the security checks implemented at the reverse proxy level because the reverse proxy thinks it's one request and Tomcat thinks it's two requests.This means that if your reverse proxy has any rules to block a request, it might be tricked to allow it past because it interprets the body differently from what Tomcat (among other things the HTTP framework Jira uses) does.That is basically it if you look purely at this vulnerability. Unless you do anything filtering or transformations at the Reverse Proxy level, you're probably fine.The example 2 on the CWE page you're referring to is assuming that page.asp allows remote code execution (RCE, on purpose or as a vulnerability) and that such an attack would be filtered by a reverse proxy. By bypassing that filter on the reverse proxy, an attacker could chain those exploits together to "get to" the RCE exploit.The request smuggling alone does not allow for RCE, unless your backend application either allows for it and depends on the reverse proxy for access control or has a vulnerability that you're trying to protect against using the reverse proxy.To give a real world example:Let's say you have a service that is vulnerable to the log4j vulnerability revealed last month. You didn't want to patch it for some reason and just configured a filter on the reverse proxy to filter out any requests containing ${jndi for example. This is a bad way of doing things since this can be circumvented in other ways, but let's assume you did that.This request smuggling vulnerability could now be used in such a case to "hide" the exploiting request in a benign one, circumvent this filter because the reverse proxy only sees the benign one and gain RCE by smuggling the request containing the malicious string past the reverse proxy filter and triggering the log4j vulnerability.Another possible example is if your service was offering a restricted area under a certain path and that restriction was enforced by reverse proxy rules. Those could be circumvented.But since Jira has its own authentication, I think we should be fine. Every reverse proxy configuration I can think of for Jira either has no such filters or filter all traffic based on certain rules (e.g. to hide Jira completely behind SSO) (Although take that with a grain of salt since I don't get in touch with customers much)So yeah, all in all, I think this attack will, in my opinion and according to my understanding, generally not be problematic for Atlassian's line of server and data center products unless customers have unusual configurations in their reverse proxies.