The Apache Log4j Vulnerability Proves Yet Again – a Cyber Security Paradigm Shift is Crucial
The serious vulnerability in Apache Log4j is continuing to expose some of the world’s most popular applications and services to attack. Here's what you can do against it and similar vulnerabilities.
“By failing to prepare, you are preparing to fail.”
― Benjamin Franklin
The serious vulnerability in Apache Log4j, log4shell is continuing to expose some of the world’s most popular applications and services to attack, and the situation hasn’t improved ever since it came to light last week. Hackers have been exploiting this bug since the beginning of this month, according to researchers from various organizations to steal systems credentials, steal data, install cryptominers and dangerous malwares on compromised system and what not.
What is Log4j?
Log4j in its simplest form is a java library used for recording error messages in applications and it is used ubiquitously across many applications online. The range of impact is so broad because a wide variety of devices and products use Log4j. Any device that leverages versions between 2.0- 2.14.1 and connects to the internet is a victim to this. From the vastly popular PC game Minecraft and PC gaming service Steam, to Apple’s iCloud service that enables iPhone, Mac and iPad users alike to store information in the cloud – all are affected by this vulnerability.
Log4j can perform lookups: map lookups, system properties lookups as well as JNDI (Java naming and Directory lookups). Log4j uses the JNDI API to obtain naming and directory services from several available service providers: LDAP (Lightweight Directory Access Protocol), DNS (Domain Name Service), Java RMI registry (Remote Method Invocation), COS (Common Object Services), etc.
What’s the risk that compromised Log4j presents?
Log4shell vulnerability allows an unauthenticated remote attacker to execute arbitrary code with the privileges of the application using Log4j, owing to the fact that JNDI doesn’t shield against attacker-controlled directory service providers.
All that a threat actor needs to send is a specially crafted string containing the malicious code that gets logged by Log4j version 2.0 or higher, effectively enabling the threat actor to load arbitrary code from an attacker-controlled domain on a susceptible server and take over control.
The Attack narrative
What should you do right now?
Apache has released Log4j version 2.15 which contains a fix for this CVE. Organizations must immediately upgrade to this version.
If you cannot upgrade to the fixed version of Log4j, you can mitigate this vulnerability as follows:
- For versions 2.0 and before 2.10, Apache recommends removing the Jndi Lookup class from the classpath by running zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
- For versions 2.10 and above, set the system property formatMsgNoLookups to true or set the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
- If you cannot do any of the above, you can block all outbound LDAP or RMI connections using Application Identity filters.
Researchers have ascertained that JDK versions 6u211, 7u201, 8u191, 11.0.1 and above are not susceptible to the attack through an LDAP request, which is currently used as a proof-of-concept. Discussions are observed about possible calls to Tomcat functions that could potentially change this picture.
To detect possible abuse, you can search the logging for strings from users such as “Jndi:ldap”. To do this, search the logging of all applications that use the vulnerable Log4j.
How can you protect yourself from the next threat?
Attackers will continue to pull new rabbits out of the hat to discover and exploit as many vulnerable systems as possible. Many organizations won’t even realize their systems are at risk and that is truly the scariest part.
To stay safe and secure, continue to keep an eye out for any new updates from the OS and service providers. IPS rules, WAF rules, firewall rules and web filtering can all help, by blocking malicious CVE-2021-44228 data from outside, and by preventing servers from connecting to unwanted or known-bad sites. But given that there is a myriad of ways these exploit strings can be encoded, the best way is to patch your own systems and if you can’t patch yet, use one of the above-mentioned mitigations.
Shift left your application security
To help mitigate risks of cyber threats and vulnerabilities, Qualitest developed an innovative approach of shifting left application security. This approach introduces security into every phase of your development journey, identifying vulnerabilities early on and significantly reduce the risk of cyber attacks.
Contact our cyber security experts, who can help your organization ensure your SDLC is infused with security, so you can properly prepare for threats and maintain your reputation, while gaining better velocity, quality and costs.