Log4Shell — Developer's Nightmare
Java is one of the most used languages for server-side applications. Everyone loves using java for backend tasks.
On one peaceful night, a CVE got reported with a score of 10/10, for a library called Log4J which was used by Enterprise Java, which is powering around 3 Billion devices on earth and a rampage started.
This vulnerability simply enabled devices to have complete root access remotely to any system in the world.
How does it work?
A central JNDI Server is used to access variables instead of having separate copies of them in.
For example, getting Connection String for SQL Server or some credentials.
JNDI (Java Naming and Directory Interface) is an interface defined by java, used to get code from remote servers using different protocols like LDAP.
So, Log4J provided us with functionality to log variables from remote systems.
But More is the features, More are the Bugs, We can get variables by these features, but the issue no one noticed is instead of variables, we can deserialize java objects too from LDAP Servers, and execute them on our systems.
This is where Remote Code Execution comes into play.
Anyone with a simple JNDI LDAP Server setup can remotely access any server.
he just needs to create a Java class that simply creates a reverse TCP Connection to any Public IP, basically providing a C&C Shell.
How did it all start?
Log4J is a simple library used to log info in any stream. Most of the people who worked with Java know Logger.
- In 2013, a request for JNDI Server Plugin in the Log4J library came, basically, the person wants to fetch variables from a remote server, find it here.
This is when a vulnerability is introduced. - Then in 2014, an issue is raised requesting:
Ability to disable (date) lookup completely, compatibility issues with other libraries like Camel.Basically, the person was unable to log curly brackets, it tries to get the same environment variable.
log.info("${date:now:buhu}");The above code returns some value. instead of logging the same.
Someone fixed and added a code to disable lookups completely.
%msg{nolookups}This disables NSlookups completely.
But by default, it was still vulnerable.
So no one noticed this till 2021 when a researcher exposed this CVE openly, anyone was able to target any server with just a simple JNDI LDAP Server configured with Public IP.
This loss was not due to developers, they tried and created features, but this was the responsibility and failure of Security Researchers who were never able to check this issue, even after a talk about it in Blackhat before CVE was released.
This vulnerability is now patched in new versions, but it caused a lot of loss to many governments as well as private organizations.
References:
LiveOverflow: https://www.youtube.com/watch?v=w2F67LbEtnk
