There has been a lot of talk on the net about the vulnerability in Log4J that allows an attacker to trigger arbitrary code execution remotely if you have the ability to send data to an application that uses the log4j library to log the event.
This attack can be done without being authenticatedFor example, by leveraging an authentication page that logs authentication errors.
This flaw has put companies specializing in cybersecurity to work on the event and indicates that the number of attacks that take advantage of this flaw is increasing.
Members of Apache Software Foundation have developed a patch in order to correct the vulnerability and it is version 2.15.0, in addition to the fact that possible solutions have also been made known to reduce the risks.
What is Apache Log4j? How serious is the fault?
For those who still do not know how serious the problem is, I can tell you that On December 9, a vulnerability was discovered in lto record library log4j Apache.
This library widely used in application development projects Java / J2EE as well as standard Java / J2EE-based software solution providers.
log4j includes a search mechanism that could be used to query via special syntax in a format string. For example, it can be used to request various parameters such as the version of the Java environment via $ {java: version} etc.
Then specifying the jndi key in the string, the search mechanism use the JNDI API. By default, all requests are made with the prefix java: comp / env / *; however, the authors implemented the option to use a custom prefix using a colon in the key.
This is where the vulnerability lies: sijndi: ldap: // is used as the key, the request goes to the specified LDAP server. Other communication protocols such as LDAPS, DNS, and RMI can also be used.
Therefore, a remote server controlled by an attacker could return an object to a vulnerable server, which could lead to arbitrary code execution on the system or confidential data leakage.
All an attacker has to do is send a special string Through the mechanism that writes this string to a log file and is therefore managed by the Log4j library.
This can be done with simple HTTP requests, for example those sent through web forms, data fields, etc., or with any other type of interactions using server-side registration.
Tenable characterized the vulnerability as "the most important and critical vulnerability of the last decade."
The proof of concept has already been published. This vulnerability is now actively exploited.
The severity of the vulnerability is A maximum of 10 on the CVSS scale.
Here is the list of affected systems:
- Apache Log4j versions 2.0 to 2.14.1
- Apache Log4j versions 1.x (obsolete versions) subject to special configuration.
- Products using a vulnerable version of Apache Log4j - European national certs maintain a complete list of products and their vulnerability status
CERT-FR recommends conducting a thorough analysis of the network logs. The following reasons can be used to identify an attempt to exploit this vulnerability when used in URLs or certain HTTP headers as user-agent
Finally it is worth mentioning that it is strongly recommended to use log2.15.0j version 4 as soon as possible.
However, in case of difficulties migrating to this version, the following solutions can be temporarily applied:
For applications that use versions 2.7.0 and later of the log4j library, it is possible to protect against any attack by modifying the format of the events that will be logged with the syntax% m {nolookups} for the data that the user would provide.
This modification requires modifying the log4j configuration file to produce a new version of the application. Therefore, this requires redoing the technical and functional validation steps before deploying this new version.
For applications using versions 2.10.0 and later of the log4j library, it is also possible to protect against any attack by changing the configuration parameter log4j2.formatMsgNoLo