Java’s implementation of ECDSA signature validation deviated from the algorithm in two distinct ways that could allow any attacker to craft a valid signature for any key.

There are two issues at play:

1.The r and s values provided in signature were not checked to ensure they were in-range (greater than 0 and less than the order of the curve.

1. Mathematically there is no defined multiplicative inverse for 0, however the Java implementation returned 0 as the inverse of 0.

These two issues combine such that a signature with an r and s of 0 will return as a valid signature for any private key. As this ultimately resolves to multiplication by 0 in calculating the “real” signature.

We previously covered this same issue in the Stark Bank library for Python

AWS provided a hot-patching service that would patch Java binaries against the Log4Shell vulnerability but that introduced a container escape.

To do this it would look for any process named java, and then try to execute the binary, first just to get the version, then again to actually perform the patch. The problem here being that it would execute java in a fairly privileged context. It would use the containers namespace, but otherwise invoke it with all Linux capabilities and without other isolation mechanisms in play.

An attacker could craft a malicious java binary that would take advantage of being run with these privileges to escape the container.

Another case of different normalization routines resulting in smuggling a request to an endpoint blocked by a reverse proxy.

In this case we have the apple domain https://rampadmin.apple.com. All endpoints on this domain were protected by Apple’s single sign-on serivce except the /healthcheck endpoint. It appears that this login process was enforced by a front-end reverse proxy server that would either redirect to the login if they were not logged in, or proxy the request to the desired endpoint if they were. There was a difference in how the reverse proxy and the target server handled ..;/in the path however.

So by providing a request to a domain like /healthcheck/..;/some/real/endpoint the request would pass through the login check thinking its a request destined for the healthcheck, but then the application server would perform the directory traversal and serve up the real endpoint’s content.

For some UIBean tags the name field was vulnerable to a double OGNL evaluation when there was no corresponding value field which could lead to remote code execution.

For first, a brief bit about double OGNL evaluation as I don’t think we’ve covered it before, or its been awhile. Even if you’re not familiar with OGNL, the idea of double evaluation is pretty simple. Imagine you have any sort of variaible expansion expression. So in a template language you might write <b>{{username}}</b>. And expect {{username}} to be expanded into the actual username variable. Double evaluation is when the result of that expansion is evaluated again. So maybe the username, being attacker controlled was something malicious like {{PRIVATE_KEY}} then the first expansion would fill in the username, replacing it with {{PRIVATE_KEY}} and then evaluating it again, would potentially leak a sensitive value.

OGNL is more powerful than that, it is capable of navigating through Java object properties and performing method calls. So a double evaluation of an OGNL expression can lead to code execution within OGNL sandbox at least.

Returning the the vulnerability here double evaluation is a known issue with Struts so they avoid it in general. What was found here was a bit of an edge case, where the name field would be evaluated as expected. And normally the value field would be fetched independently, when it was missing however in some UIBean classes the value field would be filled in with the name, and if it was an expression, reevaluated as long as it wasn’t recursive. Creating a path to gain code execution.

The post also dives into the full RCE chain to popping calc.exe and breaking out of the OGNL sandbox.

BlueZ would identify bluetooth controllers based purely on their self-reported BD_ADDR (the bluetooth version of a MAC address). A malicious device could identify with an existing BD_ADDR and obtain the link key for that device.