It has not been long since theannouncement of the Log4j vulnerability that shook the entire IT world but in the meantime there have been many updates that have followed one another at a rapid pace. First of all, the release of a new patch since the previous one was exploitable for a new vulnerability . In addition, the first reports of attacks that exploit lateral movement between systems to succeed in targeting organizations. A disturbing picture that causes a lot of concern given the enormous diffusion of the Java library all over the world and in any system. Let's proceed step by step, starting with the following vulnerabilities to the original.
Patches following the first Log4j vulnerability
The original vulnerability, calledCVE-2021-44228 , was discovered on 10 December. Its presence allows, in some versions of the Log4j library, to execute remote code. The cause is a misconfiguration in JNDI , a component of Java required for directory browsing that does not adequately protect against LDAP server-based attacks. In fact, the attacker may be able to inject portions of code that, once logged in, cause remote execution of (potentially malicious) software.
The first solution was to disable this feature or upgrade to version 2.15. However, a new vulnerability appeared soon after,CVE-2021-45046 , also quite serious (9 out of 10 and therefore defined as critical). In fact, from the analyzes carried out, the fix introduced with version 2.15 for the previous vulnerability was still unstable and could generate, where appropriately exploited in some configurations, loss of information and still remote execution of malicious code .
And here is the release of version 2.16 which completely disables the message lookup and access to JNDI. But there is no end to the worst. On December 20, the vulnerabilityCVE-2021-45105 , of type Denial of Service and classified as high risk, was published. In fact, version 2.16 which fixed the two previous vulnerabilities did not handle the uncontrolled recursions generated by lookups that called themselves. This can generate a Stack Overflow error that causes the process to abort, causing a denial of service (DoS) . Apache has released version 2.17 of the library but the attention is still high and it is not certain that there may be further vulnerabilities.
Side attacks and risks for companies (and not only)
Naturally, the great attention on the subject has led researchers and hackers to find all possible attack models. In fact, if at first there seemed to be problems only with vulnerable servers, it was later discovered that the vulnerability can also be exploited in contexts inside the network such as machines that have services running on localhost . For example, this new attack vector exploits the use of websockets which are difficult to identify especially when open to localhost. If the services running locally have the Log4j vulnerability (ie an unpatched library) it is possible to perform a full attack with remote execution of malicious code.
Alongside the new viral vectors , an attack line is widely developing that will likely try to exploit Log4j in combination with a ransomware . Although there is still no evidence, there are many reports of attacks that use Log4j to make lateral movements in the affected systems. For example, the Conti research group said they used Log4j to reach and take possession of VMWare vCenter servers. Once this was achieved, they were able to move freely around the corporate network by attacking other connected systems.
In conclusion, Log4j is proving to be an important Achilles heel for modern computing by creating an extremely broad and widespread base for hackers around the world. Solving the problem will probably take a long time and it is not certain that you will be able to completely secure all systems.