In context: The past week has kept IT organizations scrambling to respond to the Log4j vulnerability impacting systems around the world. As security experts have continued to identify additional bugs in the logging utility, network administrators have worked tirelessly to identify and close off any potential access that that may allow the vulnerability to be exploited. Unfortunately, a newly discovered vector has proven that even isolated systems with no internet connectivity may be just as vulnerable, further complicating the already enormous problem.
Researchers at Blumira have more bad news for the IT community battling Log4j security exploits. While previous findings indicated that impacted systems would require some type of network or internet connectivity, the security firm’s recent discovery now asserts that services running as local host with no external connection can also be exploited. The finding pointed researchers to several more use cases outlining alternative approaches to compromise unpatched assets running Log4j.
A technical post by Blumira CTO, Matthew Warner outlines how a malicious actor can impact vulnerable local machines. Warner states that WebSockets, which are tools that allow fast, efficient communication between web browsers and web applications, could be used to deliver payloads to vulnerable applications and servers with no internet connectivity. This specific attack vector means the unconnected but vulnerable assets could be compromised simply by an attacker sending a malicious request using an existing WebSocket. Warner’s post details the specific steps a malicious actor would take to initiate the WebSocket-based attack.
The newly identified attack vector will result in a greater number of vulnerable assets across already heavily affected industries. According to Check Point Software, over 50% of all government, military, finance, distribution, ISP, and education organizations are currently affected by the Log4j vulnerability.
Warner notes that there are available methods organizations can use to detect any existing Log4j vulnerabilities:
- Run Windows PoSh or cross platform scripts designed to identify where Log4j is used within local environments
- Look for any instance of .*/java.exe” being used as the parent process for “cmd.exe/powershell.exe”
- Ensure your organization is set up to detect the presence of Cobalt Strike, TrickBot, and related common attacker tools
Impacted organizations can update their instances of Log4j to version 2.17 to mitigate the tool’s vulnerability (which keep popping up). This includes any organization that may have applied the previous remediations, versions 2.15 and 2.16, which were later found to include their own set of related vulnerabilities.