Super-rare bug class discovered in open source microservices framework
The maintainers of the Micronaut project have issued a fix to protect developers against a rare bug class that, if left unchecked, could leave their microservice applications open to server-side request forgery (SSRF) attacks.
As outlined in a GitHub advisory last week, independent security researcher Jonathan Leitschuh discovered that Micronaut was failing to properly neutralize carriage return line feed (CRLF) sequences in HTTP headers.
On its own, CRLF simply describes the action that’s performed by pressing enter on a keyboard: i.e. moving the cursor to the beginning of the next line.
However, in a web security context a CRLF injection vulnerability can spell disaster, as it allows an attacker to break out of syntax and inject new lines into the HTTP header request.
“Micronaut’s HTTP client is vulnerable to HTTP Request Header Injection due to not validating request headers passed to the client,” the advisory reads.
As a result of this bug, Leitschuh found that a specially crafted payload could force the client to make multiple attacker-controlled HTTP requests.
“The attacker is able to control the entirety of the HTTP body for their custom requests,” the advisory states. “As such, this vulnerability enables attackers to perform a variant of server-side request forgery.”
CWE reassessment
Micronaut is a JVM-based, full-stack framework for building modular, easily testable microservice and serverless applications.
The CRLF injection vulnerability has been patched in the micronaut-http-client versions 1.2.10 and 1.3.1 and above.
Leitschuh, a security researcher who rose to prominence after discovering a vulnerability impacting the Zoom video conferencing app last year, said the Micronaut bug was fixed through GitHub’s CodeQL initiative, which allows researchers to query code as though it were data.
There are limitations to the attack, with Leitschuh explaining that the exploit would only work against the host the Micronaut HTTP client has already connected to.
“You can’t control the socket connection because you don’t control the URL, but you control everything else from any subsequent request, so you can spoof the request to a different host, stuff like that,” Leitschuh told The Daily Swig.
Interestingly, however, the security pro said his latest research may encourage an amendment to the Common Weakness Enumeration (CWE) entry for CRLF injection attacks.
“Most of the time [the vulnerability] leads to HTTP response splitting, but in this case it leads to HTTP header injection,” he explained.
“If you look up the CWE that exists for ‘CRLF Injection’, it only mentions HTTP response splitting – it doesn’t handle this server-side request forgery version.
“Because this vulnerability leads to SSRF instead of HTTP response splitting, this vulnerability might actually warrant a different CWE.”
He added: “There have been other cases of this. For example, the Python2 HTTP client was vulnerable to CRLF injection. Here’s another example covered by Snyk, and a similar vulnerability in GoLang.
“If you want to see the true impact of CRLF injection in client code, here’s an excellent example. Due to improper CRLF injection protections, Orange Tsai was able to inject memcached commands to achieve remote code execution in GitHub.”
YOU MIGHT ALSO LIKE AV Oracle: New hacking technique leverages antivirus to steal secrets
