Riverbed NPM : Detect Log4shell/Log4J (CVE-2021-44228) vulnerability in your network

Solution Number:
S35655
Last Modified:
2021-12-17
Issue

A recently-discovered vulnerability in the Java logging utility Log4J (CVE-2021-44228) enables remote code execution exploits in a variety of common software. This happens through the download and execution of malicious code embedded in the Java utility, sometimes nested in such a way making it difficult to identify.

Compared to a more directed malware campaign, this vulnerability has many potential exploits. However, Microsoft is maintaining a list of IPs believed to be taking advantage of this vulnerability as detected in their Azure service. Keep in mind, though, that because these bad actors are also scanning systems that are not vulnerable, we should be careful to examine positive indicators closely. The scanners are looking for vulnerable systems, and so receiving an incoming communication from them is not as conclusive as an outgoing communication would be.

Because this vulnerability can affect so many systems, it’s very important to examine network history immediately. We can use Riverbed NetProfiler to identify flows and hosts affected by this threat both now and in the past, and we can use Riverbed AppResponse to analyze web application traffic to identify the vulnerability in action. Alerts and notifications can be setup on both of these products to notify via Email, SNMP, Syslog etc.

Solution

Log4J Threat Hunting with NetProfiler and AppResponse11

 

Using NetProfiler

 

Using NetProfiler with the Advanced Security Module, we can go back in time to verify exposure to the Log4J vulnerability. NetProfiler uses a frequently updated threat feed as its source for vulnerability information including the specific criteria to run against newly captured and stored flow data.


In the graphic below, notice that we can select Log4Shell Known Exploits from the threat feed and run a report to see if we are impacted, when it first appeared on the network, and which hosts are affected.

Notice in the graphic below we’re running a report for the last week.



Traffic Report showing a week’s worth of traffic. New Connections can be suspicious traffic.
 
Some experts believe this vulnerability first appeared around December 1, so we can extend our search further back in time. In the graphic below we’re searching back to December 1.



Extending our Traffic Report back to Dec. 1 when Log4J is thought to have started.
 

Using AppResponse11

The Web Transaction Analyzer module, or WTA, within AppResponse 11 allows us to search for the Log4J vulnerability from an application perspective using byte patterns to search the HTTP header and payload.

 

In the graphic below, notice that within WTA we can use some custom variables to search within the body, URL, and header of application traffic and report back if any of the conditions are true. Here we’re looking specifically for the JNDI lookup since it’s a key part of the exploit mechanism used by the vulnerability. These conditions could be extended to exclude certain source IPs that are legitimately running vulnerability scans as part of your security posture.



For ease of copy and paste the Key above is  \$\{jndi: for Custom Regex of Request Body, URL and Request Header.

Here’s the Insight: Web Apps View for our new web app definition above, showing various details about the clients sending the mangled HTTP header and / or body unique to the log4j-shell exploit.  You can easily download the packets for these connections for further analysis with Wireshark or Transaction Analyzer.





Mitigation recommendations: 

 After a thorough scan using NetProfiler and AppResponse, also consider the steps below to protect the network from the Log4J vulnerability.

  • Frequently look for evolving mitigation recommendations from trusted 3rd-party security authorities.

  • Enable application layer firewalls such as AWS WAF which would significantly reduce the risk by protecting cloud-based and some SaaS applications

  • Block outbound LDAP to the public internet

  • For log4j versions greater or equal to 2.10 set log4j2.formatMsgNoLookups to true

  • And of course, always remember to install the latest patches in both internet-facing and internal systems.

     

A short video showing the AR11 process and results is available below:
Environment
Log4j
Log4Shell
CVE-2021-44228
NPM
Attachments
NOTICE: Riverbed® product names have changed. Please refer to the Product List for a complete list of product names.
Can't find an answer? Create a case