Jan 4, 2022
Coming just before 2021 Christmas, Log4J had become every IT and security team’s nightmare, and organizations are still reeling from the impact, mitigating and patching Log4J vulnerabilities this 2022. Called Log4J, Log4Shell, or LogJam, it is a wake-up call for the cybersecurity world. With its discovery during the closing of the year 2021, Log4J brought to attention the vulnerability that severely impacted companies and components across the globe, enough that it even got its own meme page.
Credited to @PingForEffect, from Log4Jmemes.com
How Is Log4J Distributed?
Malicious threat actors will scan the internet for vulnerable servers. They will then deliver malicious payloads that will query the servers to trigger log messages, mostly through remote code execution (RCE) and using instructions in the form of Log4J processes.
These triggers or instructions will then create a reverse shell, allowing the attacker to remotely control the targets. They can either gain sensitive information from the server or set the targets as part of a botnet for future attacks.
The codes will be executed via calls to the Java Naming and Directory Interface (JNDI). Several network services are supported by JNDI, commonly the Lightweight Directory Access Protocol (LDAP), Domain Name Service (DNS), and Java’s Remote Interface (RMI).
The initial flaw occurred due to Log4J not sanitizing URLs passed in the strings referencing the JDNIS resources in the configuration sources, log messages, and parameters. The strings may contain a URL calling back to malicious remote servers and come from requests crafted by attackers. In web applications, the string could be part of an HTTP communication that would be logged, formatted as a substitution command that refers to the malicious server, commonly in the form of ${jndi:[protocol]://[remote server and code address]}.
In these exploits, it is found that the LDAP protocol is the one used in the majority of the traffics, with some using DNS and RMI protocols, using obfuscation techniques to evade rules searching. Obfuscation is used in a variety of ways to prevent scanning and exploitation detection, including the use of nested strings to invoke the JNDI interface.
How Is the Log4J Being Exploited?
There’s an abundance of exploits that can be done once a vulnerable server is remotely accessed successfully. It can be used to mine cryptocurrency, be held ransom through ransomware, embed with a backdoor, be part of a botnet army to conduct DDoS attacks.
Several prominent cybersecurity vendors had reported seeing this vulnerability being used for Khonsari (ransomware affecting Windows systems), Orcus (remote access trojan RAT), crypto miners, and automated botnets such as Mirai and Tsunami.
What Are The Impact of the Log4J Vulnerabilities?
Where to begin?
Unless you’re a developer or system admin, Log4J is a foreign term. But, put it this way: Almost all software includes logging as a standard feature. From web applications and cloud services to software development and security tools themselves. That’s how vital Log4J is in the software ecosystem.
Some of the high-profile IT service companies and tech vendors are also affected by the code vulnerability including Oracle (the one who built Java), LinkedIn, Cisco, Fortinet, VMware, and IBM.
For a more extensive list, you can check the affected components here, and other affected manufacturers here.
In terms of sectors affected, according to the statistics by Checkpoint, a whopping 45.9% in manufacturing, 33.4% in transportation, and 38.7% in the utilities sector are affected by Log4J.
To quote Glen Pendley, Deputy Chief Technology Officer of Tenable’s words in CISO Mag, “Everything across heavy industrial equipment, network servers, down to printers, and even your kid’s Raspberry Pi is potentially affected by this flaw. Some affected systems may be on-premises while others may be hosted in the cloud, but no matter where they are, the flaw is likely to have an impact.”
How To Detect and Mitigate Log4J Vulnerabilities?
There are numerous detection and mitigation methods provided by security researchers and cybersecurity vendors. Below are some detection and mitigation methods that can be used by your security team. To note, affected versions of Log4j are:
- Log4J 1.x is not impacted by this vulnerability.
- Log4J 2.x: Yes. Implement one of the mitigation techniques available or patch to version 2.16.0 and newer.
- Java 8 (or later): users should upgrade to release 2.16.0.
- Only the Log4J-core JAR file is impacted by this vulnerability. This vulnerability does not impact applications using only the Log4J-API JAR file without the Log4J-core JAR file.
How to Detect Vulnerable Log4J
Linux
In your Linux systems, run the following command:
grep -r ‘org/apache/logging/Log4J/core/lookup/JndiLookup.class’ /
If the output is “binary file matches,” the relevant files are using the Log4J library.
Windows
For Windows systems, you can use online test tools from the Huntress Labs repository.
Alternatively, you can run the command below, courtesy of @CyberRaiju :
gci 'C:\' -rec -force -include *.jar -ea 0 | foreach {select-string "JndiLookup.class" $_} | select -exp Path
How to Mitigate Once a Log4J Vulnerability Is Found
Patches had been provided by Apache to mitigate the vulnerability. If it is not applicable, the alternative remediation steps provided by their advisory include:
- (Log4J 2.10 or higher) Add -DLog4J.formatMsgNoLookups=true as a command line option or add Log4J.formatMsgNoLookups=true to the Log4J2.component.properties file on the classpath to prevent lookups in log event messages.
- (Log4J 2.7 or higher) specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event messages.
- Consider blocking LDAP and RMI outbound traffic to the internet from vulnerable servers.
- Remove the JndiLookup and JndiManager classes from the Log4J-core jar.
The best would be to implement patch 2.16, which disable JNDI by default and fixes CVE-2021-44228 and CVE-2021-45046. For vendor-specific actions, you can refer to the Blue Team Cheat Sheet here.
How to Prevent Exploitations Like This?
Believe it or not, it is possible to prevent such exploits, using a defence-in-depth approach.
An example of a defence-in-depth approach could be compared to a collection of concentric circles or layers, with the data to be protected located at the centre. These layers of security provide multiple levels of resistance to an attack and can provide useful information on how the attack was carried out to improve the security of the system in the future.
For security professionals, it means to not only apply the CIA (confidentiality, integrity, availability) to the system as a whole but to apply them on every layer to optimize their security.
Defense-in-depth framework, courtesy of Kudelski Security, sourced from Securing Industrial Control Systems: A Holistic Defense-In-Depth Approach
What Is Recommended For Each Layer?
Application and Data Security
The “Defense-in-Depth” structure places data at its most inner section. Data is usually what attackers are after during an attack. A cybersecurity plan must map the types, and the locations, of storage to work effectively. The information you store should be kept in a place that has additional security controls applied to its data layer
Additionally, a fundamental part of security integration is application development. For an application to be secure, developers must adopt a secure development life cycle and integrate security controls throughout the process. It is also important the details of the logging information be sufficient to gain insights for both the developers and the security team, as it is the part, used for investigation and analysis (bugs, issues, activities, communication).
Host Security
To minimize exposure to security problems, physical and virtual hosts should be secured, systems should be patched and updated, and lastly, antivirus and memory protection should be in place, covering any vulnerabilities that might bypass the patches and updates. This is also considered as the host-level security.
Network Security
Communications between resources (networks, systems, applications, and databases) should be restricted to an as-needed basis and must be documented to justify traffic permissions. Firewalls should be updated with rules from time to time to reduce false positives and interruptions (inbound, outbound, denied). IDS / IPS should be installed within the system, and DDoS protection to protect from attacks.
Physical Security
Talking about cybersecurity, many focus on network and digital-centric, neglecting the physical aspect of security. Examples of physical security are installing security cameras within the area and ensuring the environment is suitable for machine operations (i.e. safe from natural disasters). This may seem insignificant but is important as a form of deterrent.
Policies and Procedures
While it is more convenient to just leave the security responsibility on the security team, this is a shared responsibility. Thus, it is important to have clear policies, procedures and cybersecurity programmes, from the top to the bottom, involving all from the developers to the security teams. For example, developers should follow secure coding practices, and the environment should be approached secure-by-design in collaboration between the IT architects, the network team, and the security team.
All in all, this serves as a reminder to not overlook auditing your operations security environment and neglect flaws in the current system. An important factor in any security posture is to identify the vulnerabilities in the system and put in place the prevention or mitigation methods in proper documentation. For more information on the defense-in-depth implementation, reach out to our industrial cybersecurity experts.
