Pierluigi Paganini
December 20, 2021
Researchers from cybersecurity firm Blumira 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.
Experts pointed out that 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.
“However WebSockets are accompanied by security risks that are largely unseen. WebSockets are not restricted by same-origin policies like a normal cross-domain HTTP request and they expect the server itself to validate the Origin of the request. While they are useful, they also introduce a fair amount of risk as they do not include many security controls to limit their utilization.” states the analysis published by the experts.
The researchers published a proof-of-concept attack that uses a Java Naming and Directory Interface (JNDI) exploits that is triggered via a file path URL using a WebSocket connection to a machine with an installed vulnerable Log4j library.
“As 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. We saw the most success utilizing RMI (default port 1099), although we are often seeing custom ports used. However, 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.” continues the experts.
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, experts recommend updating all local development efforts, internal applications and internet-facing environments to the latest Log4j 2.17 as soon as possible.
Admins should also look closely at your network firewall and egress filtering to restrict the callback required for the actual exploit to land.
Make sure that only certain machines can send out traffic over 53, 389, 636, and 1099 ports. All other ports should be blocked.
Follow me on Twitter: @securityaffairs and Facebook
| [adrotate banner=”9″] | [adrotate banner=”12″] |
(SecurityAffairs – hacking, Log4Shell)
[adrotate banner=”5″]
[adrotate banner=”13″]
