LOG4j New Attack Vector Exploited

Researchers devised a new attack vector that relies on a JavaScript WebSocket connection to exploit the Log4Shell vulnerability on internal and locally exposed unpatched Log4j applications.

This new attack vector significantly expands the attack surface and can impact services even running as localhost which were not exposed to any network. The good news is that at this point, there is no proof of active exploitation of this technique.

WebSockets is a computer communications protocol, providing full-duplex communication channels over a single TCP connection.  WebSockets are commonly used for applications like chat and alerts on websites. They are not restricted by same-origin policies as a normal cross-domain HTTP request, and they expect the server itself to validate the Origin of the request. They also introduce a fair amount of risk as they do not include many security controls to limit their utilization.

The researchers published a PoC attack that uses a JNDI exploits that is triggered via a file path URL using a WebSocket connection to a machine with an installed vulnerable Log4j library.

Once the page loads, it will initiate a local WebSocket connection, hit the vulnerable listening server, and connect out over the identified type of connection based on the JNDI connection string utilizing RMI (default port 1099), and other custom ports used. Iterating through all available listeners was the easiest path to successful RCE as noted previously. Specific patterns should not be expected as it is easy to trigger traffic passively in the background.

WebSockets allow for connections to any IP enlarging the surface of attack of vulnerable systems. When an open port to a local service or a service accessible to the host itself is found, it can then drop the JNDI exploit string in path or parameters to force the vulnerable host to contact the exploit server loads the attacker’s class and executes it with java.exe as the parent process.

To mitigate the risk, all local development efforts, internal applications, and internet-facing environments should be updated to the latest Log4j 2.17 as soon as possible.