Two days ago, we wrote a post about the Log4j vulnerability that is currently wreaking havoc on the cyberthreat landscape. The flaw stands for an open-source Java logging library. By exploiting this vulnerability present in software apps and services worldwide, being part of the Apache Logging Service, hackers can perform remote code execution attacks (RCE).
What Is Log4j and How Has It Been Addressed?
The Log4Shell vulnerability is a JNDI injection exploit. The JNDI API provides discovery and lookup of resources by name and returns the result in the form of serialized Java objects. JNDI provides a Service Provider Interface (SPI) for flexible implementation of the backend naming and directory service protocols. To select the service provider, JNDI follows a URI format allowing provider and name to be specified during the request. (…) Exploiting the Remote Command Execution (RCE) is not as seamless compared to many known RCE that allow shell code to be injected directly into HTTP requests. An attacker will need to trigger log4j to query a remote service, which in turn will need to return the location of a malicious Java object that will result in command execution upon deserialization.
Following the exploitation of this vulnerability