An easily exploitable critical RCE vulnerability in Apache module log4j
The Chinese researcher from Alibaba Cloud team that published the details of the vulnerability yesterday shared it with Apache already 10 days ago.
However the patch issued at the time by the Apache team was not fully preventing the issue and was easily bypassed, thus another fix (the current stable version 2.15.0) was issued yesterday.
Version 1.x of log4j may also be vulnerable under certain conditions, but this old, end-of-life, version of the module will most probably never get an update, as it’s not supported anymore. Hundreds of applications are believed to be using this log4j component still today. It’s already confirmed that multiple Apache products were indeed vulnerable, including:
- Apache Solr,
- Apache Struts2,
- Apache Solr,
- Apache Druid,
- Apache Flink,
- Apache Kafka,
- SBT,
- …
Furthermore, Elastic, Redis, Tomcat(?), but also Minecraft, Steam and many other applications relying on java-based components are also confirmed vulnerable. Jira is believed to not be impacted as of now, but this might change in the future.
The rush for discovering the possible vulnerable assets has started, with cryptomining gang and botherders attempting to hack as much servers as possible before they are patched. Minecraft was the first organisation to publicly confirm having been hacked because of the vulnerability that is now sometimes called “Log4Shell”. But numerous other victims will probably be impacted in the coming hours.
More and more attacks are recorded in the wild by honeypots instances accross the world, with most of them coming from Tor exit nodes. GreyNoise for example already identified more than 100 different attacking IP addresses. All confirmed attacking IP addresses will be added to our Orange Cyberdefense Datalake IOC repository used by our Managed Detection services.
You may use a Yara rule such as the one publicly available here in order to detect such exploitation attempts. Some Snort rules released by EmergingThreats might be able to detect the attacks also. A Splunk query can help identify such issues using this specific SIEM. Cloudflare tries to protect its clients with some WAF rules, as they explained here.
Executive summary
A newRCE vulnerability has been discovered in the Apache module, Log4j. Identified as CVE-2021-44228, it allows an attacker to execute code remotely, however, the threat ranges from data confidentiality and integrity to system availability.
It affects all versions of log4j between 2.0 and 2.14.1.
It is worthy to note that the potential impact of this flaw is very important, as countless services using log4j are exposed and at risk of being attacked. According to the search engine Shodan, there are at least 24 million Apache servers in the world. Active exploitation in the wild was already identified in multiple countries.
What you will hear
An easily exploitable RCE is present on a large number of Apache servers.
What it means
Details of a critical vulnerability in the Apache log4j module have been disclosed publicly on December 9th. Identified as CVE-2021-44228, this vulnerability allows an attacker to execute code remotely. Apache Log4j is a Java-based logging utility that allows users to set their own logging levels. Unfortunately, this module is present in several cloud services like Steam, Apple iCloud… This vulnerability is caused by a bad check when a user sends requests to the server. It is therefore possible that an attacker could create specially crafted requests and send them using any remote protocol such as HTTP, TCP, etc. Using these requests, an attacker can easily realize arbitrary code execution, DDOS or compromise data.
Unfortunately, the apache-log4j2 packages provided by Debian Stretch 9, Buster 10 and Bullseye 11 are impacted. Furthermore, there are already several working PoCs in the wild, so it is highly likely that malicious actors have now started using this vulnerability due to its ease and the number of vulnerable assets to target.
Apache Log4j version 2.15.0 fixes this vulnerability, so it is urgent to install this patch to any exposed instance.
We classify this alert at level 5 out of 5, because there is a significant number of devices that may be impacted by this vulnerability. Moreover, it is currently very easy to exploit it with the readily available PoC, and attacks are indeed already happening in the wild, as confirmed by our Managed Detection services.
What you should do
It is strongly recommended to upgrade to version 2.15.0 of Apache Log4j.
It is also possible to achieve the following temporary mitigations:
- Start server with log4j2.formatMsgNoLookups=True
- Add -Dlog4j2.formatMsgNoLookups=true to your JVM args
In order to identify if you are already affected, you might check the log files for any services using vulnerable log4j versions for user-controlled strings, like for example, “Jndi:ldap”
Impacted products
The list of applications impacted by this vulnerability is growing as expected, as this log4j component is widely used within a java environment. The impact review is still ongoing by most of the vendors, with some products already confirmed impacted, some still under investigation and some confirmed non-impacted ones.
Non-impacted products:
Palo Alto will publish updates on a dedicated web pagehere, but they confirmed that no product is affected yet, although this library is listed in their license documentation. F5, Pulse Secure, Check Point also confirmed they are not vulnerable.
Under investigation
Among the vendors that are still being investigating their products, we have for example:
- Cisco
- SonicWall
- Atlassian (not vulnerable, except in specific configurations applied by a client)
- and many more.
Confirmed impacted products
The following vendors already confirmed some products vulnerable for example:
- Oracle
- Redhat
- VMware
As the vendors are still in the process of investigating if their products are affected by this vulnerability, Orange Cyberdefense CERT is engaged to continuously update our Vulnerability Intelligence database, so if you’ve subscribed to our Managed Vulnerability Intelligence Watch service, please ensure that your list of products monitored is up to date.
Attacks
We observed several obfuscation techniques used by hackers to avoid detection mechanisms. Hackers used native functions & encoding format allowed by Log4j to hide the common detection patterns. Currently, WAF rules and detection tools do not match all the possibilities, thus upgrading the log4j library (or use the proposed mitigation) is still the best option.
Moreover, we believe with high confidence that many different threat actors have begun to exploit this vulnerability. Netlab has for instance detected two different waves of attacks using the log4j flaw to extend respectively the Muhstik and Mirai botnets, that both target Linux devices. The IP addresses scanning or exploiting this vulnerability
Our engagement
Orange Cyberdefense teams are strongly committed to help our clients deal with this crisis and conducts necessary investigations if any. Suspected cases are being investigated with our customers already. In case of suspicious events detected by our CyberSOC and CERT team, an alert will be sent to our customers through the existing processes. The new IOCs discovered will be added to our Orange Cyberdefense Datalake repository.