Techies wake up to discover new security breaches most days. The recent one was the Log4j (log4shell) vulnerability which was reported by Alibaba Cloud Security team’s Chen Zhaojun. This particular vulnerability was assigned as CVE-2021-44228 and the proof of concept exploits was published on GitHub on 9th December 2021. This vulnerability earned a severity score of 10 which is the most critical designation.
The log4j library
There are two versions of the log4j library Version 1.x and Version 2.x. According to the information received so far, ‘version 1’ is not vulnerable to log4shell vulnerability. But there are other vulnerabilities that are not as critical as this. The vulnerability was originally introduced to log4j2 in version 2.0 to beta9, a very popular library used by Java developers for logging.
In version 2.x a new JNDI lookup plugin was added and this is said to be the root source for all problems. This particular plugin was a lookup plugin that allows a developer to take the data that is being logged by the log4j library.
The issue here is in a very specific lookup called JNDI lookup. JNDI stands for Java Naming and Directory Interface. This is a mechanism or an API which allows a Java program to actually perform lookups to objects. This particular API supports a number of other protocols as well. This includes LDAP (Lightweight Directory Access Protocol), RMI(Java Remote Method Invocation), DNS, and a lot of other mechanisms.
The Encounter
In log4 shell vulnerability is really an input validation vulnerability, in this particular case, the vulnerability exists in log4j code which will parse any input that is being received by the users. Any lookup that ends up in a vulnerable log4j library can potentially be used as an exploit.
The issue encountered was that the log4j library will treat input as a kind of format string. This way it will try to lookup in input which will start with characters –
After colon, we can specify the protocol that will be used. So this is the lookup string that the library tries to and after it successfully parses such a lookup string it will perform a lookup action.
In order to exploit this, an attacker must somehow submit a lookup query that will point to the attacker’s server.
When an application that uses a vulnerable log4j library, it encounters this string and this string gets parsed. This will try to connect to the LDAP server running on ‘attacker.com’ on tcp port 1234. Here an attacker can modify the payload as he needs, and make it receive a shell.
Defending this vulnerability?
The number one solution or method to defend from this vulnerability is patching vulnerable systems. If that is not possible to patch, disabling remote lookups and making a proper firewall rules to remote calls to unexpected servers may help to prevent from log4shell vulnerability.
Current patched version of log4j is 2.17.0.
log4j version 2.17.0 patches this vulnerability in which JNDI is fully disabled, support for Message Lookups is removed, and the new DoS vulnerability CVE-2021-45046 is not present.
Took me time to learn all of the comments, however I actually enjoyed the article. It proved to be very helpful to me and Im certain to all of the commenters right here! It is all the time nice when you cant only be informed, but in addition engaged! Im positive you had joy writing this article. Anyway, in my language, there will not be much good source like this.