Log4j Vulnerabilities Unveiled: Safeguarding Your Website in the Age of Cyber Threats
What is the Log4J Vulnerability?
A massive number of systems are affected by the Log4j vulnerability (CVE-2021-44228), also known as “Log4Shell”. This vulnerability is based on a critical logging component that is present in most Apache web application products. It is possible for attackers to leak data or even gain remote code execution (RCE) by exploiting this aspect of a web application.
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.
CVE-2021-44228: https://nvd.nist.gov/vuln/detail/cve-2021-44228
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.
The vulnerability first gained attention when a user on GitHub named “tangxiaofeng7” disclosed it on their repo. This repo has been removed, After the exploit code was released, the issue quickly gained steam and soon flared up across SOCs around the world. Matthew Prince, Cloudflare’s CEO, confirmed exploitation began on Dec. 1, 2021. There is, however, evidence that the exploit was available as far back as March 3, 2021.
Identifying the Log4J Vulnerability
Log4J is a critical component for most Java-based application logging, and thus, it is ubiquitous with nearly all web application instances using the functionality. One key point to remember is that when we say “web application” we are not only referring to applications that are web facing, but also applications that are using web stack technologies (such as LAMP/WAMP stacks, or Linux/Apache/MySQL/Php, Windows/Apache/MySQL/Php). With all of this in mind, it should be clear as to why this vulnerability is so critical: we live in a web application-based world, and thus, it is everywhere in most of the products we use. If you look at the list of impacted vendors and instances in the link section, you will probably see products that surprise you (Tesla, Steam) and products that do not surprise you (Adobe, Cisco), which should illustrate this point fully. And, as we said before, because input can be entered into a web application and go unsanitized, attackers can exploit this vulnerability in a number of ways.
When looking at code for our Java applications, the simplest way to verify if we have the vulnerability is to look at the actual imports for the application. We do not have the java runtime command variable presented; but suffice it to say, if we have access to the code and recursively grep the code base for log4j library imports, we should be able to identify whether we have a potential vulnerability.
If we want to test if the application is vulnerable to CVE-2021-44228 by entering a JNDI lookup payload into the username field. To “catch” the payload, we will open up a terminal window and use a Netcat listener to see if we can get a connection back to our host. Type the following command and note that we are now listening on port 4444.
“Complete Exploitation video will be coming soon”
Log4J Vulnerability Root Cause
The root cause of this vulnerability is due to the acceptance of JNDI strings with variables that can be passed to the message service attribute of Log4J. If the application is importing Log4J logging attributes and does not have the proper parameters declaring a lack of trust for message lookups, the application is vulnerable. However, one of the things that makes this vulnerability so serious is how widely it extends across so many applications. Log4J is a part of the Apache Software Foundation, and it is pervasive across many web stacks and systems.
Log4J Vulnerability Mitigation Options
Luckily, there are a few options for mitigating the Log4J vulnerability. The first option is to patch Log4J to an updated version of 2.17.0 or later.
There have been conversations about a confirmed RCE in 2.17.0 as well. However, it is a fairly common perspective in the offensive community that it is not a “true” RCE, as the attacker would have to control attributes on the system already in order to execute the exploit (read more about this RCE here).
-Dlog4j2.formatMsgNoLookups=TrueA final option to consider, if neither of the above options are available, is to use traditional mitigation aspects such as WAFs and egress filtering. By setting up detection rules which are publicly available, we can attempt to filter input that could be malicious by using the WAF that is protecting a system (see more here). If a string is able to bypass filtering and reach the vulnerable application, you can use egress filtering with a contemporary product or service.