In the context of the Log4Shell vulnerability, the main danger corresponded to the combination of different risk factors. We will review the most important of them:
1. This Java security flaw comes from the logging library.
At first glance, a logging library such as Log4J may seem rather innocuous. Just like an authentication or encryption library, however, it should not be neglected.
2. Java is very popular.
Uniquely for a language and environment, Java can run on virtually any platform. Therefore, the Log4Shell vulnerability concerns a very large number of programs and services. In addition, Java is sometimes integrated into embedded systems (routers, devices from the Internet of Things, etc.), that is to say, it can be present on private cameras and other home automation devices.
3. A whole set of technologies is involved.
This security issue is linked to the concatenation of several technologies. The combination of Log4J, JNDI, an LDAP server, and string substitutions favors this vulnerability and allows hackers to attack.
4. Exploits seep down to deeper levels.
In the best-case scenario, if a vulnerability affects only the targeted system, the damage can remain localized. Imagine, however, that a web interface receives and logs a chain of exploits. This chain of exploits can then be communicated to other underlying systems, without activating before being evaluated there.
5. Chains of exploits are hard to detect.
Since the possible substitutions are very complex, there are many options open to hackers wishing to conceal malicious code. For this reason, it is possible to nest certain substitutions. Chain ${${lower:j}ndi} does not directly contain the character string jndi and therefore cannot be automatically filtered. Chain ${jndi} is only created at the time of resolution. Additionally, it is possible to hide some parts of the code using Base64 encoding. Chain ${base64:SGVsbG8gV29ybGQhCg==} therefore corresponds to « Hello World! » « .
