- Email: info@clearinfosec.com
- 1800 760 5656
Apache Log4J vulnerability (CVE-2021-44228) commonly known as “Log4Shell,” is a zero-day vulnerability that was first discovered on December 9, has earned a CVSS score of 10 which is the highest possible severity level. Everything from the cloud to developer tools and security devices is affected by the Log4j vulnerability with warnings that it could provide unauthenticated remote code execution and server access.
A Log4j flaw where the Apache Software Foundation produced the library, which is a key Java logging framework. Several national cybersecurity agencies, including the Cybersecurity and Infrastructure Security Agency (CISA) and the UK’s National Cyber Security Centre, have issued warnings since CERT New Zealand announced last week that CVE-2021-44228, a remote code execution flaw in Log4j, was already being exploited in the wild (NCSC)
When using a vulnerable version of Log4J to log untrusted or user-controlled data, your application may be vulnerable to Remote Code Execution (RCE). If Apache Log4J, version 2.0 to 2.14.1, is installed on a device that is connected to the internet, it is vulnerable. According to the NCSC, the affected version of Log4j is used in Apache Struts2, Solr, Druid, Flink, and Swift frameworks.
AWS has outlined how the issue affects its services and stated that it is working on patching its Log4j-based services as well as releasing mitigations for CloudFront. Similarly, IBM stated that it is “actively responding” to the Log4j issue in its own infrastructure and products. Websphere 8.5 and 9.0 are affected, according to IBM. Oracle has also released a fix for the problem. “Organizations should be prepared for a constant stream of downstream advisories from third-party software producers who include Log4j among their dependencies,” said Rapid7.
After days of attempting to patch the first vulnerability, cybersecurity experts discovered a second vulnerability involving Apache Log4j on Tuesday. The CVE description says it could allow the attackers to craft malicious input data to result in a Denial of Service (DOS) attack. When the logging configuration uses a non-default Pattern Layout with either a Context Lookup or a Thread Context Map pattern, this could allow attackers with control over MDC input data to craft malicious input data using a JNDI Lookup pattern, and it results in a denial of service (DOS) attack. Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default.
In some non-default configurations, the fix for CVE-2021-44228 in Apache Log4j 2.15.0 was found to be incomplete. CISA’s main advice is to identify internet-facing devices running Log4j and upgrade them to version 2.16.0, or to apply the mitigations provided by vendors “immediately”. We recommend at least one of the following mitigations for vulnerable versions greater than or equal to v2.10:
Please keep in mind that Log4J v1 is no longer supported and will not be patched for this issue. Other RCE vectors are also vulnerable to Log4J v1, hence we urge that you upgrade to Log4J 2.16.0/2.15.0 as soon as possible.
The Log4j problem has been reported in Australia, New Zealand, Canada, the United Kingdom, Sweden, Germany, Singapore, and other countries. According to the CBC, Canada’s Revenue Agency took some services offline on Friday after learning of the issue. Finally, For mitigating attacks on the Log4j vulnerability, Microsoft has released a set of compromise indicators and guidelines. Installing currency miners, using Cobalt Strike to facilitate credential theft and lateral movement, and exfiltrating data from hacked computers are all examples of post-exploitation that Microsoft has witnessed.
You can find the list of software that is affected by the vulnerability here (Released by Dutch Natural Cyber Security Center) and the attack surface of log4j and list of impacted manufacturers here.
Reference: Rubin, S. (2021, December 14). LOG4J “Log4shell” zero-day vulnerability: Impact and fixes – fossa. Dependency Heaven. Retrieved December 14, 2021, from https://fossa.com/blog/log4j-log4shell-zero-day-vulnerability-impact-fixes/