Threat level 5/5 -An easily exploitable critical RCE vulnerability in Apache module log4j

An easily exploitable critical RCE vulnerability in Apache module log4j released publicly.

SUMMARY

The security team of VIETTEL, the largest state-owned Vietnamese telco, shared in a blogpost published on January 28 that they presumably identified past attacks in DNS logs leveraging Log4Shell as early as September 2021, and possibly even in August 2021.

That’s 3 months BEFORE the first in the wild exploitation currently known. No other organization publicly confirmed as of now their claims, which thus remain uncertain at this stage. If these allegations are true, it means you may decide to hunt for possible Log4Shell attempts further back in time than expected until today (August vs. November).

The Vietnamese ISP revealed a few details about the 10 targets they managed to identify so far, that are from multiple countries around the world and in various sectors.

ATTACKS

The researchers explain they identified a specific DNS pattern in some JNDI exploitation attempts inside passive DNS logs. Some targets contacted by Viettel have confirmed they actually saw these scanning attempts in their own DNS logs. No final payload behind this attack campaign was identified though so far.

At least 10 targets from around the world have been found by Viettel, including large organizations from different sectors such as government, finance, technology, entertainment, gambling, etc.

The attacks are mentioned to have continued to this date, even if the company contradicts itself a bit, as it did set up a trap server on January 10 that did not receive the scanning attempt yet. This may mean this specific campaign stopped in December or early January, or did not reach this “honeypot”.

VIETTEL nevertheless recommends to look for DNS outbound requests with pattern “1c47a43da7028a2ed315” in logs, from beginning of August 2021 onward if possible. Our Managed Detection Services will hunt for this possible threat against DNS logs of clients if collected in this timeframe.

BlackBerry also published recently a blog post about ongoing attacks against VMware Horizon servers (as reported already in previous updates), that they attributed to a specific threat actor called Prophet Spider (by CrowdStrike). The evidences tying it to this specific group are quite limited, but we confirm some Initial Access Brokers are indeed trying to compromise Horizon servers for the benefit of ransomware gangs. This threat actor’s TTPs were detailed last year by CrowdStrike.

ATTRIBUTION

We don’t believe the claims from “AgainstTheWest” hacktivism group, reported in our previous update, to be true. No new information is available on this topic as of now.

Updated on : 2022-01-20 13:14:50

SUMMARY

The global threat level has not dramatically changed in the last weeks, as no massive exploitation through the log4j v2 vulnerabilities usually called together log4shell has been detected. However, the cybersecurity community remains cautious and ready for any possibly bad outcome. In particular since multiple VMware Horizon servers were compromised since December 25th. Moreover, some vendors did not issue their security patch yet or just won’t in the short term, because their application is still in (unsupported anymore) version 1.2. The problem is that three additional serious vulnerabilities were found affecting this end-of-life version 1.x of log4j .

VULN

On January 18th, Apache has disclosed some details of three more critical vulnerabilities impacting Log4j 1.2, which is not supported anymore since August 2015. None of these new flaws will thus get ever fixed:

• CVE-2022-23302 : a remote authenticated attacker could exploit it to launch a JNDI request that could lead to remote code execution,
• CVE-2022-23305 : a remote attacker could exploit it via queries containing specially-crafted SQL attributes in order to access or alter database information,
• CVE-2022-23307 : a remote attacker coult exploit it via specially crafted requests to execute arbitrary code.

These vulnerabilities (and the others already known for log4j version 1.x) should definitely convince developers to switch to another secure logging component, such as the latest version of Log4j version 2, as using End-of-Life code represents a high risk of being compromised. Fortunately, no exploitation code is yet readily available online for these vulnerabilities at this time.

ATTACKS

On January 10th, CISA held a briefing on Log4shell explaining that there are still hundreds of millions of individual devices affected but they have not seen the vulnerability leveraged in significant intrusions. Yet, several cybersecurity companies have stated that nation-state actors are developing attacks leveraging this vulnerability including the Iranian-based subgroup UNC788 (Mandiant) / TA453 (ProofPoint), sometimes referred to as APT35. According to CheckPoint, APT35 started widespread scanning and attempts to leverage Log4shell in publicly facing systems only four days af ter the vulnerability was disclosed. The threat actor leverages this vulnerability to distribute a new modular PowerShell toolkit called CharmPower (named GhostEcho by ProofPoint).

Moreover, on January 19th, Microsoft announced it has discovered a vulnerability on SolarWinds product Serv-U that was being weaponized by threat actors to launch attacks leveraging the Log4j flaw. Tracked as CVE-2021-35247, this input validation vulnerability could allow attackers to build a query given some input and send that query over the network without sanitation. SolarWinds issued an advisory and fixed the vulnerability on January 18th with Serv-U version 15.3.

More ransomware gangs have also begun exploiting this vulnerability, including the Night Sky ransomware group, a new gang which was recently spotted by cybersecurity researchers.

ATTRIBUTION

An anonymous Twitter account called CyberKnow has shared additional information about the presumed origin of the Log4j vulnerability. This source interviewed a Europe-based hacktivist group nicknamed “AgainstTheWest” (ATW) which targets Chinese organizations, including Alibaba Cloud in October 2021, in retaliation for cyberespionage attacks conducted by China against Western organizations. ATW released on November 12th on a hackers’ forum called RaidForums data stolen to the Chinese cloud giant during this attack, thus long before the public disclosure of the Log4j flaw. The hacker collective claims having ta rgeted Alibaba using this vulnerability, and that the vendor then disclosed it to Apache in November 2021. For now, we do not confirm or deny these allegations based solely on these hacktivists’ claims. It could be an attempt to get undue credit for the log4shell discovery.

Updated on : 2022-01-05 11:32:31

VULN

No new vulnerability was identified since last week and the unjustified warning regarding a new RCE in version 2.17 (which turned out to be highly exaggerated, see our Update n° 11).

But with the huge attention that log4shell got all over the world, it’s nevertheless somewhat concerning to see that log4j versions prior to 2.15, thus vulnerable to the main critical vulnerability, keep being downloaded (possibly up to 40% as shown in this Sonatype dashboard). We recommend you remind (and ideally prevent technically and/or through a policy) your developers to rely on those old, unsecure, log4j versions (without management approval at least).

ATTACKS

The scanning attempts (legitimate and malicious) have started decreasing since Christmas. But Microsoft shared they still see ongoing exploitation attempts activity in their latest update yesterday. Only a few victims have so far been publicly confirming log4shell as the initial vector of the attack, including for example:

• ONUS, a Vietnamese crypto-trading platform, was attacked and its users data stolen. Cybercriminals asked the victim for a $5 million ransom (that was not paid). Thus the attacker tried afterwards to sold the stolen data on a prominent underground forum;
• A prominent unnamed academic institution was hit through a vulnerable VMWare Horizon Tomcat according to CrowdStrike on December 29. This incident involved a Chinese-related APT group called Aquatic Panda (presumably also called Bronze University or TAG-22). This threat actor is active in cyberespionage against academia, and has ties with the bigger Chinese APT nexus known as APT41 / Winnti. It relies heavily on Cobalt Strike and uses a downloader tracked by some researchers as Fishmaster;
• During the first week, an unknown number of HP 9000 servers running AMD EPYC processors were also hacked to mine a specific cryptocurrency called Raptoreum;
• But RaaS are now suspected of relying on log4shell too. Conti was the first publicly mentioned, but an AvosLocker affiliate may have recently targeted a Russian company through a vulnerable vCenter.

The US Federal Trade Commission advised yesterday all organizations to remediate log4j vulnerabilities and threaten to pursue the ones that would “fail to take reasonable steps to protect consumer data from exposure as a result of log4j” (sic).

TOOLS

Yet another scanner was publicly released by Google on December 28. Like a few others, it is fast and written in Go (but doesn’t requires you to install the Go language environment on the scanned devices). On top of finding vulnerable assets, it gives the opportunity to update (i.e. mitigate) the found .jar files directly. This doesn’t go without risks on live production environments. Dozens of different scanning tools were released so far. A short benchmarking between the major scanners available can be found here. Unfortunately, it’s not up-to-date anymore and don’t even include the ones from CISA or Google for example.

Furthermore, a detection tool called OpenHandleCollector.exe Microsoft added to their Defender for Endpoint solution raised numerous false positives alerts for their clients, as this EDR identified it as suspicious, possibly since December 23th and until Microsoft fixed it on December 30th as explained here.

ANSSI shared on the same day within the French infosec community 24 different Suricata rules for IDS/IPS solutions. Our Managed Detection services thus our clients do benefit from them since they were received.

Finally, ThinkstCanary, provider of free canary tokens used by a lot of security experts, lost their database on New Year’s eve. That means the tokens you may have configured to try to identify some vulnerable assets, won’t trigger anymore (thus need to be recreated), even if your logs are processed later in a scheduled operation. This “third party” detection opportunity remains highly hypothetical anyways, and should not be your best bet (vs. active internal scanning actions for example).

Updated on : 2021-12-29 09:41:37

VULN

As anticipated, Apache did release version 2.17.1 yesterday evening to fix the vulnerability reported by CheckMarx that will now be tracked as mentioned as CVE-2021-44832. The CVSS score for it is only at 6.6 out of 10. And we confirm it’s a low risk flaw, even if announced initially as an RCE. In fact, it turns out not to be an RCE, but an “Arbitrary Code Execution” one, located in the “JndiManager.isJndiJdbcEnabled()” function.

Furthermore, the conditions to exploit it are really limited and specific to custom configurations that may be used in some organizations. Indeed, a non default configuration must be set and permissions for the attacker to modify your logging configuration file (which is game over already actually). In this -edge- case, attacker can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI, which can execute remote code. Also, only applications using log4j-core JAR file are vulnerable, not when using only log4j-api without -core.

Apache backported this fix on previous log4j branches, into new versions 2.3.2 and 2.12.4 (for the applications not running on Java 8 in particular). Our Vulnerability Intelligence Watch service already covered this bug in this specific advisory. We don’t anticipate most third party vendors will include a fix for it, as it is even considered by many as not a real vulnerability, and a strong backlash occured against the researcher’s attempt to get fame for his “finding”.

Actually, the issue is the same as another debated vulnerability (CVE-2021-42550) that impacted logback, a fork from log4j version 1.x. In this case disclosed 2 weeks ago, the vulnerability was also considered of low probability thus risk and maybe even not a vulnerability.

As an abundance of caution, you can again upgrade to this latest version of log4j, but we advise you to treat this vulnerability as any other minor bug in your patch management lifecycle. And keep your focus on the daunting tasks related to the original log4shell vulerability:

• investigate attacks that may have targeted you,
• detect the ones currently happening,
• identify your attack surface (in house applications and third party solutions),
• prevent compromise by patching (or mitigating the risks against) your infrastructure.

Updated on : 2021-12-28 18:06:40

VULN

3 weeks after the history-making log4j vulnerability was disclosed publicly by Alibaba, new information keep popping up every day.

Today, according to a tweet from a researcher from code analysis vendor CheckMarx, yet another RCE vulnerability in latest version of log4j (2.17.0) will soon be revealed by the Apache Foundation. This means another CVE number (CVE-2021-44832) will soon be disclosed and another security update might be needed. Log4J version 2.17.1 is already about to be released and will probably cover it, unless it is postponed in yet another later version. Rumors mention this new RCE can only be triggered un der specific, limited non default edge cases. So the real impact of this new vulnerability will remain lower in our opinion than log4shell (CVE-2021-44228).

CISA’s Director said log4shell is the most serious vulnerability ever recorded according to her, even if it hasn’t yet directly impacted as many systems as Wannacry, Conficker, or the legendary Morris worm in the past. Furthermore, some early reports of nation-state actors leveraging it have been since heavily criticized by experts in the security community. Even if those threat actors may indeed be currently improving their arsenal, some mistakes and assumptions were made in a few reports. For example, an IP address used by a threat intellig ence vendor scanning vulnerable hosts were reported as if linked to a Chinese APT group by SecuritySecoreCard.

PRODUCTS

The list of impacted solutions keeps growing with some products from big groups such as Huawei or NVIDIA and smaller ones like Snow or Wallix. Vendors with a broad product range make almost daily updates, like IBM which is keeping track records here.

TOOLS

CrowdStrike shared publicly on GitHub a few days ago a fast log4j scanner written in Go they called CAST, along with a PowerShell script to deploy it more easily. But as explained already, the log4j code could be embedded in transitive dependencies or in compiled code. JFROG found that 2/3 of the packages containing log4j identified on the famous Maven (MVN) repository didn’t include a separated, specific .jar file, and 1/3 didn’t mention it in the transitive dependencies list.

Microsoft released a consolidated dashboard to help centralize remediation efforts against log4shell inside their Microsoft 365 Defender portal. They for example will list the identified vulnerable container images within Azure and on a Kubernetes cluster. Or when found through the Inventory scanning features from Defender for Cloud. And Microsoft also now moves to the trash the exploitation attempts sent by email identified by Microsoft Defender for Office365.

Updated on : 2021-12-23 14:05:10

ATTACKS

The critical Apache Log4j vulnerability named Log4Shell is actively exploited by two new named malicious actors, a ransomware gang and a banking trojan operator.

The new ransomware that uses the Log4Shell vulnerability is the TellYouThePass gang. This is a ransomware that has been dormant since the summer of 2020, but it is regularly used when a new large vulnerability is discovered in order to attack multiple targets, this was for example the case with EternalBlue last year. The TellYouThePass ransomware attacks were discovered by security researcher Heige from the KnownSec 404 team and confirmed by Curated Intelligence. It is important to note that TellYouThePass does not operate as a RaaS (R ansomware-as-a-Service).

The second actor exploiting this vulnerability uses Dridex malware or Metasploit attack payload called Meterpreter (that provides an interactive shell from which an attacker can explore the target machine and execute code). Dridex was originally a banking trojan developed to steal victims’ online banking credentials. However, over time, the malware evolved into a malware loader. In particular, it is used to carry out ransomware attacks from operations allegedly linked to the Evil Corp hacker group. These ransomware infections include BitPayme r, DoppelPaymer, WastedLocker and possibly other ransomware variants.

These attacks were discovered by the cybersecurity research group Cryptolaemus.

VICTIMS

Among the latest victims, the Belgian Ministry of Defense has confirmed a cyberattack on its networks involving the Log4j vulnerability. Although they did not specify if it was a ransomware attack, they explained that “quarantine measures” were quickly put in place to “contain the infected elements”. So it’s safe to assume that they suffered an attack of this type. Unfortunately, apart from this information, the Belgian Ministry of Defense has released little details, thus we do not know the causes and consequences of this attack for now. For these reasons, we cannot estimate the criticality of this attack.

RESPONSE

Recently, CISA released a scanner on GitHub to identify web services impacted by Apache Log4j remote code execution vulnerabilities. This scanner is a derivative of scanners created by other members of the open source community. This tool is intended to help organizations identify potentially vulnerable web services affected by log4j vulnerabilities.

CISA highlights the following features on the log4j-scanner project page:

• URL list support
• Fuzzing for more than 60 HTTP request headers (not just 3-4 headers like the tools seen previously).
• Fuzzing for HTTP POST and JSON data parameters.
• Supports DNS callback for vulnerability discovery and validation.
• WAF bypass payloads.

Fuzzing (or random data testing) is a technique for testing software. The idea is to inject random data into the inputs of a program. If the program fails (e.g. by crashing or generating an error), then there are flaws to be fixed.

GEOPOLITICS

Following Alibaba Cloud’s revelation about Log4Shell, China’s Ministry of Industry and Information Technology (MIIT) has sanctioned the cloud computing company. The government announced that it will suspend its partnership with Alibaba Cloud. This sanction is justified by a breach of duty as recently a new law has been introduced in the Chinese jurisdiction requiring national companies to first inform the government when they discover a vulnerability. Yet, Alibaba Cloud disclosed the flaw to the vendor first.

Updated on : 2021-12-20 09:23:39

VULN

On December 17, Apache released version 2.17.0 of Log4j. This version protects against uncontrolled recursion of self-referential searches. It therefore protects against the vulnerability that allows an attacker to realize denial of service (DOS) attacks.

To do this, it carries out various modifications noted below:

• Require components that use JNDI to be enabled individually via system properties.
• Remove LDAP and LDAPS as supported protocols from JNDI.

In addition, Apache has assigned a new CVE to the previously mentioned vulnerability. Identified as CVE-2021-45105, it affects all versions from 2.0 to 2.16.0. It is therefore necessary to update the log4j framework to version 2.17. Log4j version 2.17 requires at least Java 8 to be generated and executed.

Apache has also released mitigations for systems that cannot realize the upgrade. These are available on the VIW bulletin.

ATTACKS

The Blumira security team has released a report on a new alternative attack vector in the Log4j vulnerability. It relies on a WebSocket JavaScript connection to trigger RCE on unpatched internal and locally exposed Log4j applications.

WebSocket is a web standard that designates a network protocol to create bi-directional communication channels for web browsers. It allows you to execute the following tasks:

• Notification to the client of a change in server status
• Sending data in “push” mode from the server to the client, without the latter having to make a request.

WebSocket has been part of most common browsers for the past 10 years and is used for a number of tasks during user browsing. Unfortunately, WebSockets connections are not limited by policies of the same origin as an http request because the server itself validates the request. Furthermore, the use of this protocol does not include many security controls to limit their use. It is therefore easier for an attacker to send a malicious request to a device via this protocol. Finally, it is possible to send requests to a vulnerable local host or to local network servers that have not been exposed to the Internet itself via WebSocket.

For these reasons, this vector significantly expands the attack surface as it can impact services running as local hosts that are not exposed to the network.

In parallel, Blumira has also published a POC showing how to use this new attack vector.

Finally, the security company has also proposed several mitigations to combat this one.

• Review and update or implement exit filtering to ensure that callbacks fail in many cases
• Detect when .*/java.exe is the parent process of cmd.exe/ powershell .exe – this is potentially very noisy.

Temporary:

Implement NoScript on untrusted sites to prevent javascript from randomly loading and initiating WebSockets.

Updated on : 2021-12-17 16:57:10

VULN

On December 16th, Apache has raised the severity of the vulnerability tracked as CVE-2021-45046 to “Critical” and the CVSS score to 9. Apache explained that security experts found additional exploits against the Log4j 2.15.0 release, that could lead to information leaks, RCE (remote code execution) and LCE (local code execution) attacks. It is now confirmed that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. Indeed, according to the vendor, when the logging configuration uses a non-default Pattern Layout with a Context Lookup, attackers with control over Thread Context Map (MDC) input data can craft malicious input data using a JNDI Lookup pattern, resulting in an information leak and remote co de execution in some environments.

Other insufficient mitigation measures are :

– setting system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases >= 2.10

– modifying the logging configuration to disable message lookups with %m{nolookups}, %msg{nolookups} or %message{nolookups} for releases >= 2.7 and <= 2.14.1.

We thus discovered that these measures only limit exposure while leaving some attack vectors open. In order to be safe, all users are advised to upgrade to release 2.16.0. or remove the JndiLookup class from the log4j-core JAR.

A Proof-of-Concept has been released on Twitter by researcher Marcio Almeida. while Alvaro Muñoz of GitHub Security Lab has shared a similar claim.

Moreover, Apache has disclosed a new DoS vulnerability in log4j, affecting all versions up to and including 2.16.0. The vendor explains that this flaw will be fixed with the release 2.17.0 while no date for its release has been communicated. Even though this flaw is not as critical as a remote code execution vulnerability, a Denial of Service flaw can be a precious tool for an attacker.

ATTACKS

According to cybersecurity company AdvIntel, Conti, one of the most prolific ransomware group has begun to exploit the Log4j vulnerability in its attacks. The Russian-speaking threat actor is the first documented sophisticated ransomware gang to exploit it. This doesn’t come as a surprise as we expected ransomware gangs to try to exploit this vulnerability which offers them the ability to target many valuable entities. AdvIntel adds that the Conti ransomware gang was looking for new attack vectors since early November. On December 13th, the malicious actor started scanning activity for initial access with Log4j, then two days later has launched attacks against VMware VCenter networks for lateral movement.

Juniper Networks researchers have noticed that some threat actors exploiting the Apache Log4j flaw have switched from LDAP callback URLs to Remote Method Invocation (RMI) or even used both in a single request for maximum chances of success. For now this process was observed on malicious actors looking to hijack resources for Monero mining, but others could adopt it at any time. LDAP requests are tightly monitored by defenders so some threat actors are looking for alternatives. While RMI API is subject to additional checks and constraints, some JVM (Java Virtual Machine) versions do not feature stringent policies, and as such, RMI can sometimes be a more effortless channel to achieving RCE (remote code execution) than LDAP.

Updated on : 2021-12-16 10:27:40

Update 6, 16/12/2021, 11h CET

VULN:

Researchers at security company Praetorian warned of yet another security weakness in Log4j version 2.15, that can “allow for exfiltration of sensitive data in certain circumstances”. The vulnerability seems to expand on the medium severity flaw discussed yesterday (CVE-2021-45046, presumably only able to enable local DoS, and patched in 2.16.0). But additional technical details have only been disclosed to Apache in order to prevent further exploitation. For now we still don’t know if this issue was already addressed in version 2.16.0, but it’s highly probable, thus we encourage you to upgrade to this latest version when possible.

However, Guillaume Poupard, head of French ANSSI, has explained that despite this vulnerability being “serious”, we “will probably less talk about it in one month”. But he added that he was worried this flaw had been already exploited in the wild before. Cloudflare confirmed the prior-to-public-disclosure attempts they mentioned happening on December 1st were just tests.

PRODUCTS:

More than 300 products are already considered vulnerable on the Dutch government CERT public list, and we still think 500 ones could be before next week.

ATTACKS:

Some researchers including Kevin Beaumont have spotted a decrease in Log4j raw attack volume since yesterday, which he interpretated as a sign that many organizations have patched their devices. However, we believe many attacks will be still launched, even if less “wild scanning” will probably happen indeed. We also don’t believe most organizations were able to patch all their solutions yet, considering the complexity in the discovery phase and criticality of some of the vulnerable assets (internet-facing applications, used for security, authentication, scada, etc.)

Cloudflare provided a good overview of the current attack trends here. They notice attackers are now better at evading WAF rules, and try to extract sensitive information such as in one case:

• user,
• home directory,
• Docker image name,
• details of Kubernetes and Spring,
• passwords for the user and databases,
• hostnames and command-line arguments.

Furthermore, according to Netlab 360, more than 10 families of malware (mostly dedicated to DDoS and cryptomining) had already been detected exploiting Log4j on December 13th:

• Mirai
• Muhstik
• Elknot
• m8220
• SitesLoader
• xmrig (Windows)
• xmrig (Linux)
• 3 previously unknown malware families.

​But the Khonsari ransomware discussed previously might not be a real attack, as a possible kind of “joe job” is suspected against a US person.

​RESPONSE:

Many False Negatives (and some False Positives obviously) seems to happen using the open source or commercial remote vulnerability scanners. But our recommandations remain the same for the Identification/Discovery phase: use as many means as possible, including:

• existing list of vulnerable products (for the third party solutions),
• remote and local scanning (and relaunch with up-to-date signatures),
• inventories,
• attack surface management solutions,
• EDR products deployed with scanning capabilities,
• custom discovery attempts (canarytokens/checkers),
• analysis of your detections (i.e. which application responsible for outbound/egress exploitation attempts logged by your SIEM)
• …

Update 5, 15/12/2021

You may access to this World Watch report on the Threat Defense Center Extranet portal by following the below link :
https://portal.cert.orangecyberdefense.com/worldwatch/577502.

——————————————————————————————

11/12/2021

The Chinese researcher from Alibaba Cloud team that published the details of the vulnerability yesterday shared it with Apache already 10 days ago (November 24th, 2021). 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.

Threat level 5/5 -An easily exploitable critical RCE vulnerability in Apache module log4j