1. Kunskap
  2. Nyheter
  3. Vulnerability
  4. Threat level 5/5 -An easily exploitable critical RCE vulnerability in Apache module log4j

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

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

Call our emergency hotline

This post will continuously be updated with new information:

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


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

VULN:

JNDI lookup supports protocols such as LDAP, RMI, DNS, or even IIOP, and we’ve finally noticed exploitation attempts using IIOP today.

Obfuscation of requests reached a new level, with for example latin encoded characters identified in the wild.

A third CVE number was assigned to a vulnerability bypass of the 2.15 version under certains non-default configurations: CVE-2021-45046. Indeed, in some ways, lookups may stil pose a small risk internally, but only of DoS, not RCE at this point. It’s fixed by version 2.16 already, as we discussed yesterday.

But this should not change your focus as of now: quickly identify your attack surface, and mitigate / remediate (i.e. patch) it against CVE-2021-44228. If you haven’t patched yet, you may nevertheless directly update in version 2.16 to be safe.

 

PRODUCTS:

These last 24 hours, another batch of major products published advisories, including:

  • IBM WebSphere Application Server (versions 9.0 and 8.5)
  • Amazon OpenSearch, AWS Glue, S3, CloudFront, AWS Greengrass, and API Gateway
  • Zoho’s ADAudit Plus component for auditing Active Directory changes, which is part of the ManageEngine monitoring solution.

We’ve crossed the 100+ affected products mark in our Vulnerability Intelligence Watch advisory, and anticipate reaching possibly 500 products out of the 5,000 ones we currently monitor, by next week (a milestone we never got since the service launched 15 years ago). This shows if needed the ubiquitous reach of the library.

US CISA finally released their own list of affected products, that tracks already almost 300 products. The Dutch government CERT list remains for no probably the most up-to-date official list of products.

 

ATTACKS:

– Noise generated by “legit” scanners

Researchers (on their own or working for Attack Surface Management service providers) are still heavily scanning the Internet to identify vulnerable assets. Companies such as BinaryEdge or KryptosLogic thus show up in your logs, with malicious queries having hostnames such as:

  • *.kryptoslogic-cve-2021-44228[.]com
  • *.canarytokens[.]com
  • *.world443.log4j.binaryedge[.]io
  • *.world80.log4j.binaryedge[.]io
  • billdemirkapi[.]me

First, this means you managed to identify these (non real) attempts in your systems, which is already a good sign. But the amount of “noise” your SOC teams has to handle may be hard to cope with over time, and could even distract you from investigating the real attacks. Indeed, those hostnames are not malicious per se, i.e. they don’t serve any malicious payload in order to compromise you.

Secondly, many clients indiscriminately block the IOC associated to all the suspicious requests they record. However, that means some visibility is lost for these tools. And they are used to report the vulnerable assets to National CERTs and thus in the end to the CERTs’ constituents i.e. critical infrastructure organizations like you. The “only” scanning organization that didn’t want to add noise to this already crowded “field” is Shadowserver, that only identifies and reports suspicious scanning attempts they received in their own honeypots network.

Those above hostnames can thus be safely considered as NOT harmful, and removed from your blacklists or quickly triaged (as benign) using your prefered SOC process (sighting, comment, tag, score, etc.). Similarly, if you block “nessus.org” (or to a lesser extent “*.burpcollaborator.net” from BurpSuite) that are also seen, this could hinder you from doing relevant scans if you rely on these scanners to probe your network.

– First confirmed ransomware case (and not the last):

Khonsari, a new simple ransomware strain, was seen deployed after a log4j attack according to BitDefender. We’ve created a Yara rule for this new .NET malware family to provide coverage in our P2A online malware sandbox analysis platform. You’ll find it for your convenience in Appendices.

The victim nor its sector wasn’t mentioned though by the AV vendor. This increase in advanced attacks was totally expected and more groups will jump on the bandwagon soon. We indeed start seeing webshells dropped on compromised environments. And Microsoft did mention multiple nation-state actors are now also leveraging the vulnerability, including PHOSPHORUS (linked to Iran government) and Hafnium (a Chinese nation-state threat actor).

– Worm ahead?

There is still only rumors of a soon-to-come worming attacks through log4shell. But this is for now based on not very reliable chats from underground forums. The vulnerability has presumably some capabilities to be wormable. So we’ll keep tracking this.

 

RESPONSE :

-PATCH :

The US Cybersecurity and Infrastructure Security Agency has told federal civilian agencies to patch systems affected by the Log4Shell vulnerability by Christmas Eve, i.e. in less than 10 days. That’s a daunting task ahead for those in the operational teams, in particular, because the December Patch Tuesday from Microsoft (and other vendors such as Adobe or Apple) was released yesterday. 80+ vulnerabilities including 7 critical have also to be prioritized today, hopefully through your automated patching processes (WSUS, etc.).

A security analyst reminded us that if you noticed a product was recently patched against log4shell on your infrastructure, but not by you, this could be bad news and a sign of compromise: some threat groups are indeed fighting each others for compromised servers’ control, thus closing the door “behind them”. Overlooking such a security event could lead to a prolonged hacked network.

We haven’t been able to confirm yet whether the vCenter patch is fully working for all versions. Rumors heard yesterday mention indeed that it could be bypassed in some cases, because of the Jetty package being not included in the workaround posted by VMware. Jetty is a lightweight web server/servlet engine that includes it seems a vulnerable log4j library.

-DETECT/BLOCK:

New Snort rules were again pushed yesterday here by the vendor. Other vendors also updated also their signatures.

 


Update 4, 14/12/2021, 10h CEST

 

EXECUTIVE SUMMARY

Vulnerability affecting version 1.x is confirmed to be not as bad as the one impacting v2.x as it needs specific non default conditions (jmsappender) AND write access by the attacker. It has been assigned a different CVE number (CVE-2021-4104) for tracking it sperately. But the version if EOL anyways and should be updagred if possible to the lateste branch. Apache shipped out a new version, v2.16.0, that disables lookups altogether, but it is not required to protect against LOG4SHELL if you’ve already patched to 2.15.0.

Attacks keep popping-up, but not much effort is still identified to conceal the malicious exploitation attempts. No ransomware driven case is yet confirmed for instance, and a lot of the current “noise” is generated by researchers (and companies working in Attack Surface Management type of services, trying to discover the vulnerable assets online.

 

VULN:

A specific CVE number (CVE-2021-4104) has been issued for the vulnerability that affects v1.x of log4j, under certain (non default) conditions linked to jmsappender sub-component. Even if this vulnerability shares the same origin with CVE-2021-44228, its severity is less high. Having another, dedicated, CVE number helps keep track of this specific flaw affecting the 6-years-old, end-of-life, version of log4j (which will not be updated itself).
Apache launched a new version of log4j, identified as v2.16.0, that will respectively disable JNDI lookups (turned them off by default) and remove them all together. But patching to version 2.15.0 is enough to be protected from LOG4SHELL so far.
Reminder: log4j has been ported in other scripting languages (PHP, Net, Rust, etc.), but those are not impacted directly, as they don’t rely on Java, even if the logic flaw could exist there possibly too.

IMPACTED PRODUCTS:

During a Q&A session yesterday, US CISA mentioned they will soon host a public list of affected products on their website. Some products that were previously thought to be affected turned out to be safe (i.e. Redis). Many vendors have not finished investigating if their products are impacted or not, even if more than 200 already are being considered vulnerable. And many clients are hoping the remaining Cloud giants they share data with such as Salesforce, do come up soon with an answer whether they are impacted or not.
Some solutions embed affected products, which means they could possibly be themselves vulnerable. Externally-facing products such as SiteCore CMS for example use third party search engine Apache Solr. But fortunately, the Solr component should not be exposed by default in this SiteCore XP product.

ATTACKS:

The first known exploitation of the vulnerability dates back from December 1st. Thus the vital hunt to detect in logs past exploitation activities should go back at least to that date. However the vulnerability gained really traction after it was discussed on December 9th. No information about the threat group(s) behind the earliest exploitation is known yet. It’s surprising that such a high-level vulnerability got “burned” against Minecraft users, through simple chat messages for example.
Since then, many new ways to trigger it have been demonstrated. The most prominent technique seen in the wild so far remain HTTP requests (with a User-Agent field for example), but DNS (TXT) queries, tampered email headers, a .txt file hosted on the Web, a string inside a SSL certificate or a specific WiFi SSID, an image or PDF metadata, etc. are some of the other techniques that could leverage the flaw.

For now, we don’t see across our clients base a lot of compromises due to this flaw. Most exploitation attempts are so far rather noisy and blocked by WAF or other network tools (i.e. IPS/IDS) and detected by our Managed Detection services. Indeed, they mostly don’t rely yet on the more advanced techniques (encoding, non-HTTP, etc.) identified.
No official ransomware case following a log4j vulnerability as initial attack vector is yet publicly recorded.
IDENTIFY:

The scripts to detect the presence of log4j based on Java file analysis such as this one, even if checking JAR inside JAR, have often limitations, including permissions, unsupported file compression or simply a protected code base. Furthermore, log4j code might be found on a server but NOT be actually used by the application, because of bad development practices (that consists of adding to disk all libraries, even if not used).
On their end, commercial scanners such as Qualys keep creating new rules (see the latest QIDshere). Contact your OCD Vulnerability Management representative to get us to scan your assets through one of the commercial solutions we support.

DETECT:

Outbound connexions might be detected (or even better blocked) when the request goes back fetch on Internet the malicious Java class to be used. But listing the authorized java class repositories used by a specific application might be doable also by the application’s developers.

When searching in your logs, one of the most comprehensive list of regexes to try to handle the various encoded exploitation attempts might be located here.

Snort/Suricata rules already handle such a use case based on Java class file header. Updated Snort rules were indeed pushed Sunday evening. And actually signatures from most NGFW vendors including Forcepoint, CheckPoint, FortiGate, PAN, F5, Cisco were also released, as tracked here. For ISP or hosting providers in particular, Shadowserver honeypot feed started pushing notifications if scanning is identified coming from your own assets.

We encourage you to update your solutions with the latest signatures, be it WAF, NGFW, IDS or any vulnerability scanner used.

 

RESPOND:

Hotpatching the JVM directly (for those that can’t immediately patch) was proposed since day one by AWS, but doesn’t provide the same coverage as the official Apache fix and/or mitigation, and must be carefully tested before use.


Update 3, 13/12/2021 10h30 CEST

 

EXECUTIVE SUMMARY

 

All operational security teams should now be on high alert because of the LOG4SHELL vulnerability in the ubiquitous log4j component, the worst in terms of number of impacted products since the last 10 years. The aftermath of Friday’s public release of the vulnerability PoC is huge, with more exploitation attempts identified, already multiple compromised servers recorded, on top of more and more additional products confirmed vulnerable every day.

Quebec government even decided to close down 4,000 websites by fear they would get hacked (i.e. not being able to patch them before the attackers could exploit them).

IMPACTED PRODUCTS

Various list of impacted products are maintained online, for example here or here. We encourage you to rely on our Vulnerability Intelligence Watch advisory, where the solutions are listed, as soon as the vendors confirm it officially, along with the official patches of the vendors if any. One other confirmed list of products publicly available is from the Dutch government CERT here. But this list is not exhaustive at all.

Whatever the exact list of impacted products right now, it will keep growing, and new prominent ones are every day confirmed vulnerable, including for example:

  • Okta RADIUS and on-prem MFA (authentication solutions)
  • Fortinet (perimeter security, but only specific solutions)
  • Splunk (but only in some conditions)
  • Some F-Secure or Sophos products (antivirus)
  • Puppet, Graylog or Jitsi (open source solutions)
  • SonarQube, NetApp, etc.

But fortunately, many patches or workarounds were already released the vendors. That’s the case for instance for most of the above and:

  • Elastic,
  • Apache,
  • Oracle,

We expect many more vendors still investigating whether their products are impacted to come up over the next days (or even weeks), with workarounds and/or security fixes. More than 500 vulnerable products could be reached in the end. But a vulnerable product does not mean it might be always remotely exploitable. That’s why we encourage you to focus in top priority on your exposed assets. Then turn to the rest of the solutions that may need attention. If unable to patch in a timely manner, you could decide to isolate some servers from Internet.

 

ATTACKS

Indeed, attacks keep coming from all around the world and keep getting more advanced. Friday saw mostly enumeration attempts of possible targets, but since then, exploitation at scale has started and botnets such as Kinsing (cryptomining) grew thanks to this vulnerability.
Also, second-stage payloads starts being discovered on hacked servers, and Microsoft even noticed an attacker using Cobalt Strike after a log4shell compromise, which means the APT or ransomware threat groups have now started leveraging the vulnerability.
DETECT & RESPOND

 

WORKAROUND:

Reminder: v1.x of log4j is NOT impacted by default, unless the JMSappender sub-component is specifically used.

We want to precise that the workaround mentioned Friday (set log4j2.formatMsgNoLookups to true) is available only for version >=2.10.

For releases from v2.0 to 2.10.0, you may want to remove the LDAP class from log4j completely, by issuing the following command:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

For certain JVM Versions, it is possible to set com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase to false to mitigate the vulnerability. Some JVM versions already have this as default setting.

IOCs:

Various sources of IOCs publicly available are listed by the Dutch government CERT here. We keep recording all relevant IOCs in our OCD Datalake repository, taggued with this World Watch advisory’s ID (#world_watch-577502). Our Managed Threat Intelligence service customers and our internal Managed Detection teams can action those IOCs through this query.

 

DETECTION:

To look for vulnerable instances of log4j, a list of hashes of all versions of log4j was put together here (but you must filter out the 2.15.0 version from it that is included in it).
Also, many vulnerability scanners are proposed online, from Qualys, Rapid7, Tenable (Nessus) up to BurpSuite plugins and custom ones. Locally, you may for example want to rely on the scanner from Logpresso (or another one coded in Go).

On top of the Yara rules already available, the following EGREP searches might help locate non encoded exploitation attempts in uncompressed and compressed log files:

  • uncompressed: sudo egrep -i -r ‘\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+’ /var/log
  • compressed: sudo find /var/log -name \*.gz -print0 | xargs -0 zgrep -E -i ‘\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+’

But as explained above, these are only partial detection opportunities, because of encoding used in most cases. Thus other queries might be needed such as:

  • uncompressed: sudo find /var/log/test/ -type f -exec sh -c “cat {} | sed -e ‘s/\${lower://’g | tr -d ‘}’ | egrep -i ‘jndi:(ldap[s]?|rmi|dns):’”\;
  • compressed sudo find /var/log/test/ -name “*.gz” -type f -exec sh -c “zcat {} | sed -e ‘s/\${lower://’g | tr -d ‘}’ | egrep -i ‘jndi:(ldap[s]?|rmi|dns):’” \;

 

WAF:

Similarly, the WAF rules to block log4shell may be bypassed in some ways, but they remain useful at catching the numerous simple attempts currently going on:

  • Google Cloud Armor
  • Cloudflare (already mentioned saturday and applied automatically)
  • Signal Sciences (Fastly)
  • AWS (non official mitigation)

IDS/IPS:
On top of the Snort already mentioned, Suricata implementations are now also available online for network detection.

IR:
For Incident Responders that want to retrieve the malicious payloads (i.e. java classes referenced in the JNDI malevolent addresses), a tool written in Java was publicly proposed here. We have a Python implementation of this script if needed.


Update 2, 11/12/2021, 19h CEST

 

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 confiremd non-impacted ones.

– Non-impacted products:

Palo Alto will publish updates on a dedicated web page here, 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:

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 (here), 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.

 

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 OCD Datalake repository.

 


Update 1, 10/12/2021, 18h CEST

 

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). 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 identifed more than 100 different attacking IP addresses. All confirmed attacking IP addresses will be added to our OCD Datalake IOC repository used by our Managed Detection services. Clients having direct access to the Datalake platform can get those IOCs with this query.

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.

Initial alert on : 2021-12-10 12:55:13

1.1 Executive summary

A new RCE 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.

 

1.2 What you will hear

An easily exploitable RCE is present on a large number of Apache servers.

 

1.3 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.

 

1.4 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”

2. Appendices :
Updated on : 2021-12-15 09:08:36


Update 5, 15/12/2021

 

Yara rule :

rule Khonsari : malware {

meta: description = “Khonsari Ransomware, .NET < 20kb”

source = “OCD” date = “14/12/21”

researcher = “Alexandre MATOUSEK”

category = “ransom”

strings:

$ = “.khonsari” wide

$ = “\\HOW TO GET YOUR FILES BACK.TXT” wide

$ = “AQAB” wide

$ = “C:\\” wide

condition: all of them }

 

 

 

Initial alert on : 2021-12-10 12:55:13

2.1 OCD VIW

https://portal.cert.orangecyberdefense.com/vulns/48852

2.2 External links

https://github.com/apache/logging-log4j2/pull/608

https://issues.apache.org/jira/projects/LOG4J2/issues/LOG4J2-3201?filter=allissues

https://www.lunasec.io/docs/blog/log4j-zero-day/

https://logging.apache.org/log4j/2.x/changes-report.html#a2.15.0

 

 

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:

Confirmed impacted products

The following vendors already confirmed some products vulnerable for example:

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

Call our emergency hotline

Share