Previously, one assumption about the 10 out of 10 Log4j security vulnerability was that it was limited to exposed vulnerable servers. We were wrong. The security company Blumira claims to have found a new, exciting Log4j attack vector. ZDNet reports: According to Blumira, this newly-discovered Javascript WebSocket attack vector can be exploited through the path of a listening server on their machine or local network. An attacker can simply navigate to a website and trigger the vulnerability. Adding insult to injury, WebSocket connections within the host can be difficult to gain deep visibility into. That means it’s even harder to detect this vulnerability and attacks using it. This vector significantly expands the attack surface. How much so? It can be used on services running as localhost, which are not exposed to a network. This is what we like to call a “Shoot me now” kind of problem. Oh, and did I mention? The client itself has no direct control over WebSocket connections. They can silently start when a webpage loads. Don’t you love the word “silently” in this context? I know I do.
In their proof-of-concept attack, Blumira found that by using one of the many Java Naming and Directory Interface (JNDI) exploits that they could trigger via a file path URL using a WebSocket connection to machines with an installed vulnerable Log4j2 library. All that was needed to trigger success was a path request that was started on the web page load. Simple, but deadly. Making matters worse, it doesn’t need to be localhost. WebSockets allow for connections to any IP. Let me repeat, “Any IP” and that includes private IP space.
Next, 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. The researchers saw the most success utilizing Java Remote Method Invocation (RMI). default port 1099., although we are often seeing custom ports used. Simply port scanning, a technique already in the WebSocket hacker handbook, was the easiest path to a successful attack. Making detecting such attacks even harder, the company found “specific patterns should not be expected as it is easy to trigger traffic passively in the background.” Then, an open port to a local service or a service accessible to the host is found, it can then drop the JNDI exploit string in path or parameters. “When this happens, the vulnerable host calls out to the exploit server, loads the attacker’s class, and executes it with java.exe as the parent process.” Then the attacker can run whatever he wants. Blumira suggests users “update all local development efforts, internal applications, and internet-facing environments to Log4j 2.16 as soon as possible, before threat actors can weaponize this exploit further,” reports ZDNet.
“You should also look closely at your network firewall and egress filtering. […] In particular, make sure that only certain machines can send out traffic over 53, 389, 636, and 1099 ports. All other ports should be blocked.” The report continues: “Finally, since weaponized Log4j applications often attempt to call back home to their masters over random high ports, you should block their access to such ports. “
Read more of this story at Slashdot.