This weekend, the Defenders will be busy beavers once more: An alternate attack vector for the widely exploited Log4j flaw is drive-by compromise, which uses a simple Javascript WebSocket connection to cause remote code execution (RCE) on local servers.
Researchers reported that “Anyone with a vulnerable Log4j version can be abused through the path of a listening server on their system or local network through navigating to a website, and activating the vulnerability.”
WebSockets allow communication between a web browser and web applications, such as chat rooms and website alerts. They’re mostly used to allow the browser to communicate data fast back and forth to these apps, but they’re also used for host fingerprinting and port scanning.
In his blog article, Warner noted that WebSockets is also a security issue.
“Unlike a conventional cross-domain HTTP request, WebSockets are not prohibited by same-origin restrictions . They anticipate the server validating the request’s origin. While they are valuable, they also pose a significant risk because they lack many security measures that would limit their usage.”
Jake Williams, Co-founder and CTO of BreachQuest explained in an email,” WebSockets have already been utilised for port-scanning internal systems. However, none of this should sway anyone’s opinion on vulnerability management. Patching should be prioritised, and organisations should mitigate by prohibiting outbound connections from potentially susceptible services where patching is not possible”.
To identify where Log4j is used within local environments, there are publicly available scanning scripts, researchers noted, to identify the libraries used locally. Here are two:
- Windows PoSh – https://github.com/N-able/ScriptsAndAutomationPolicies/blob/master/Vulnerability%20-%20CVE-2021-44228%20(Log4j)/get-log4jrcevulnerability.ps1
- Cross platform – https://github.com/hillu/local-log4j-vuln-scanner/releases
To properly eliminate the risk, businesses should update all local development activities, internal applications and internet-facing environments, including any bespoke apps, to Log4j 2.16 as soon as possible.
In the interim, users can use egress filtering to limit the callback required for the real exploit to land, and applications like NoScript Java-blocker to prevent Javascript from starting WebSocket connections on untrusted external sites.
Finally John Bambenek, lead threat hunter at Netenrich, Concluded that “this news does suggest that depending on web application firewalls, or other network defences, is no longer an effective mitigation. The single most critical move an organisation can do is patching.”
–-For more Cyber security news in crisp content . Please follow our site via twitter handle @cyberworkx1, Linkedin handle @linkedin
CyberWorkx 