Log4j Vulnerability Remediation from a Practitioner's Perspective .....

Ever since unauthenticated remote code execution vulnerabilities in widely used Apache Log4j library came to fore, we have seen a flurry of activities and CVE reports. This is primarily because the impact is pervasive given cross-spectrum use of the library. A number of articles / guidance is available online regarding remediation of these vulnerabilities in any organization.

I opine that organizations should raise a highest priority incident ticket to get all the concerned internal/ external stakeholders together for remediation effort on a daily cadence. The incident logs would also provide action/ change records and record minutes of deliberations. In addition, it is advisable to establish a tracker to monitor all affected assets/ third party risks and update it as you go about remediating the Log4j vulnerability. I am summarizing various controls which could be put in place for minimizing the impact of Log4j vulnerability on an organization. I am summarizing these recommendations from a practitioner's perspective along the lines of functional area.?

1. IN-HOUSE DEVELOPED APPLICATIONS

1.1 Basic Security Controls for Log4j

• Web Application Firewall could help protecting prod applications against malicious JNDI injections (DNS, LDAP, LDAPS, RMI)?
• Reduce attack surface by implementing geolocation-based restriction for application access.
• Would provide details about remediation of application related vulnerability in a separate article.

1.2 Control Gaps

• Depending upon the implementation, internal access from enterprise endpoints including AWS workspaces / Az VDIs to applications may not be screened by WAF.
• There could be instances of use of Log4j in code base. Application team is required to remediate the risk.
• Non employment of Software Composition Analysis may expose an org to transient risks due to open-source code snippets embedded in code base.?
• Application related flaws could potentially be exploited to side-step WAFs security controls.

2. INFRASTRUCTURE AND SERVERS

2.1 Basic Security Controls for Log4j

• Deploy IPS signature for Log4j attack on perimeter firewalls. Screen and drop all inbound and outbound traffic for JNDI strings (LDAP, LDAPS, DNS, RMI and IPOP). Would protect against JNDI injection attacks.
• National Cyber Security Centre (NCSC) Netherlands had complied a list of malicious IPs trying to exploit Log4j vulnerability. Refer https://github.com/NCSC-NL/log4shell/tree/main/iocs . These 3200+ IPs should be blocked on perimeter firewall for both in-bound/out-bound traffic.
• Analyze your SIEM environment for IPs scanning your environment for the Log4j vulnerability. Add these IPs to the blocklist after reputation check.?
• These bad IPs should also be added to EDR/ XDR. Configure EDRs to monitor execution of scripts on systems.
• Ask your internal SOC/ outsourced MSSP to monitor your environment.
• Screen your internal systems with behaviour of interest for any IoCs/ compromise.
• Scan your environment with any good vulnerability scanner like Qualys/ Nessus etc.,. This would enable you to ascertain your exposure and guide remediation effort.

2.2 Control Gaps

• Perimeter security controls would not protect you against malicious/ compromised endpoints.
• Any JVM/application server which has this library enabled could be targeted by internal hosts for execution of malicious code/ launching local DoS.

3. ENDPOINTS (DESKTOPS/ LAPTOPS/ SMARTPHONES/ TABLETS ETC.)

3.1 Basic Security Controls for Log4j

• Register malicious IPs on EDR for blocking. The EDR based controls would protect the endpoint even while the system is not connected to corporate VPN.
• EDR should be configured to monitor attempts related to execution of malicious scripts/ vulnerability scanning. These alerts should being investigated properly and closed.
• SOC/ MSSP should be asked to monitor the org environment for deviation against established baseline for any anomalous behavior.
• Microsoft TVM / SCCM, if available, should be used for scanning for Log4j vulnerability wrt endpoints and guide remediation effort.

3.2 Control Gaps

• Many endpoints are likely to carry vulnerable libraries/ JVMs. Identification and remediation of these vulnerabilities may not be easy and/ or may take time as it requires dialogue with the concerned user to avert breaking up of application functionality.
• If any of the endpoint gets compromised, then the perimeter controls would become ineffective.

4. THIRD PARTY/ SUPPLY CHAIN RISKS

4.1 Basic Security Controls for Log4j

• Create an inventory of third-party applications (SaaS/on-prem) in use in your organization. Refer https://github.com/NCSC-NL/log4shell/tree/main/software?
• Be in constant communication with the vendors and remediating the concerned applications as per their advisory.?

4.2 Control Gaps

• There would be transient risks to your org while your vendor readies a fix/workaround for its affected product.