Log4j has been tagged by security vendor Tenable as the “single biggest, most critical vulnerability of the last decade.” MITRE rated the vulnerability as critical and assigned a CVSS score of 10/10. News about the Log4j zero-day vulnerability (CVE-2021-44228, CVE-2021-45046) has been trending since early December. This remote code execution (RCE) vulnerability allows attackers to execute arbitrary code and take full control of vulnerable devices. Here are six things resilient CIOs and CISOs can do to mitigate risks from Log4j.
- Do a complete audit and assessment
The Log4j vulnerability is widespread and impacts enterprise Java-based applications like Cisco WebEx, and custom, in-house developed applications. It is imperative for CISOs and security leaders to do a complete assessment of their assets to gauge the impact of this exploit and identify which systems are affected. This audit should extend to home users and endpoint devices (including home routers) used on the enterprise network. Don’t forget to audit third-party applications from vendors and cloud-based services too. Special attention and priority should be given to systems that store sensitive information such as customer data, transactional and operational data, and intellectual property.
- Understand your risk exposure
In what ways have your systems been compromised? What did the hackers do? Did they change passwords? Did they drop a malware payload? Did they change configuration settings? Did they introduce another backdoor? You need to check your entire network and examine all copies of Log4j. After completing this audit, apply remedial steps (patches, mitigation strategies) to minimize risk from associated threats such as botnets, Trojans, and ransomware. Botnets like Mirai and Muhstik and ransomware variant Khonsari already exploited this vulnerability.
Read more about risk exposure in a Gartner article.
- Patch immediately
Apply the Apache patch Log4j 2.15.0 immediately. CISA advises affected organizations that have already applied Log4j 2.15.0 to upgrade to Log4j 2.16.0 to protect them against both CVE-2021-44228 and CVE-2021-45046.
- If you can’t patch, then apply mitigation strategies
It takes some time to update Java libraries and patch every system. If you are unable to do this immediately, then certain mitigation strategies can be applied.
A researcher at Sophos demonstrated some of these mitigation strategies.
Most apps have a script that starts a Java program. You can adapt your Java applications to suppress remote code execution and data exfiltration. Format your message to disable lookups (format message =true).
Another mitigation strategy recommended by Sophos is to block the Java Naming and Directory Interface (JNDI) from making requests to untrusted servers. If you are using Log4j 2.10.0 or later, you can set certain configuration values that prevent LDAP and similar queries from getting out.
Restrict egress (outbound) connectivity. Each subnet, server, and workload should be allowed to connect only to the endpoints that are required by the business. All other destinations should be blocked. Configure Access Control Lists too.
Read more on how to mitigate risks from Log4j on the Sophos blog here.
- Create an incident response plan
Outline the measures your organization will take to deal with this vulnerability. Update your security policies and communicate your plan to employees across all levels in the organization. C-suite and board members should be apprised of the incident and informed as to how to respond to external communication with shareholders and partners. Employees must be vigilant and should be encouraged to report any unusual behavior with their applications or endpoint devices. IT support teams should guide users to update and patch applications on endpoints, just as system administrators patch server-side applications. Remember, everyone is responsible for the organization’s information security.
- Don’t trust data that arrives from outsiders
It seems coders place too much trust on untrusted data. Leaving open doors in the code is an invitation for hackers to devise ways to exploit vulnerabilities and manipulate the software. When coding, do not provide options based on assumptions, for functions that users might want to use (and rarely use), because someone with malicious intentions will eventually find and misuse those options. Is your server accepting untrusted data into the log? This is where the zero-trust model and zero-trust architecture should be applied. Software should be designed to never permit untrusted or unauthorized users to use untrusted data to manipulate how that very data gets handled.
Also see:
