# Log4j
The Log4j Vulnerability (CVE-2021-44228), also known as “Log4Shell”, is a vulnerability impacting a massive number of systems. The vulnerability itself is dependent upon a critical logging component of most Apache web application products. By exploiting this aspect of a web application, attackers are able to leak data or even gain remote code execution (RCE) on systems.

Because the Log4J logging package can enable your system to log activity and put those logs into databases and so forth, it ends up being a connection of sorts to other parts of your system. It also works with something else in Java called the Java Naming and Directory Interface (JNDI) that enables "message lookups" of data in other services and servers like LDAP or RMI, where logging messages provided to the logging functionality could trigger lookups of the variables provided. Log4J's critical vulnerability arises from a lack of input sanitization being done by the JNDI lookups with a special syntax. Because this information was not being validated/sanitized, attacker-provided variables could be resolved (or considered valid), which ultimately resulted in JNDI doing URI queries, or simply termed, web resource queries.

The Log4j Vulnerability was first publicly disclosed on December 9, 2021, with the highest possible CVSS score of 10(!). Due to the absolute minimal access needed to communicate with the system via this vulnerability and the ability to leak valuable data or execute code, the vulnerability was listed as Critical. Typically, for these types of vulnerabilities, patching is recommended. This is because ample time is given by the research team disclosing it to the software vendor, which can then issue a patch. Unfortunately, in this case, the vulnerability was disclosed prior to patching. Thus it was a true “zero-day” (or, zero days since patched) vulnerability.

## Lab Setup
For the studies of this vulnerability, an attacker machine Kali Linux was used, and a target machine Ubuntu LTS 20.04. For both the attacking machine and the target machine, a vulnerable version of jdk must be installed. Additional instructions for setting up the environment and exploiting the vulnerability are detailed in the file "" and "Target"

## Credits and References
Thanks to "Kozmer" for making both the exploit and the vulnerable application available.