Contents:
Log4j 2 is a Java logging library that is open source and extensively used in a variety of software applications and services throughout the world. The flaw gives threat actors the potential to take control of any Java-based, internet-facing server and launch Remote Code Execution (RCE) attacks.
What Happened?
Proof-of-concept exploits for a significant zero-day vulnerability discovered in the widely used Apache Log4j Java-based logging library were distributed online, exposing both home users and businesses to continuing remote code execution assaults.
The vulnerability, officially tagged as CVE-2021-44228 and called Log4Shell or LogJam, is an unauthenticated RCE vulnerability that allows total system takeover on systems running Log4j 2.0-beta9 through 2.14.1.
An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.
On November 24, Alibaba Cloud’s security team reported it to Apache. CVE-2021-44228 also affects the default setups of several Apache frameworks, including Apache Struts2, Apache Solr, Apache Druid, Apache Flink, and others.
Vulnerability exploitation does not require a special configuration. After verification by the Alibaba Cloud security team, Apache Struts2, Apache Solr, Apache Druid, Apache Flink, etc. are all affected.
Alibaba Cloud Emergency Response Center reminds Apache Log4j2 users to take security measures as soon as possible to prevent vulnerability attacks.
Following the release of the first proof-of-concept attack on GitHub yesterday, threat actors began searching the Internet [1, 2] for systems vulnerable to this remotely exploitable security hole that does not need authentication.
CERT NZ has issued a security advisory warning of active exploitation in the wild as well:
The widely-used java logging library, Log4j, has an unauthenticated RCE vulnerability if a user-controlled string is logged. This could allow the attacker full control of the affected server.
Reports from online users show that this is being actively exploited in the wild and that proof-of-concept code has been published.
Log4j 2.15.0 has been upgraded by Apache to solve the highest severity CVE-2021-44228 RCE issue.
In prior releases (2.10 and later), the problem may also be avoided by changing the system property “log4j2.formatMsgNoLookups” to “true” or deleting the JndiLookup class from the classpath.
Those who use the library are recommended to upgrade to the most recent version as soon as possible since attackers are already looking for susceptible targets.
A “Vaccine” Has Been Created
Researchers from cybersecurity firm Cybereason have created a “vaccine” that can be used remotely to neutralize the major ‘Log4Shell’ Apache Log4j code execution vulnerability that is wreaking havoc on the Internet.
The script, or “vaccine”, takes advantage of the vulnerability to disable a setting in a remote, susceptible Log4Shell instance. The vaccination, in essence, resolves the issue by abusing the vulnerable server.
This project, dubbed ‘Logout4Shell,’ leads you through the process of configuring a Java-based LDAP server and contains a Java payload that disables the ‘trustURLCodebase’ set in a remote Log4j server to mitigate the issue.
What Are the Malware Payloads Exploiting Log4j
When a remotely exploitable remote code execution vulnerability is published, malware distributors are generally the first to exploit it, according to BleepingComputer.
Cryptominers
As soon as the vulnerability was made public, we observed threat actors use it to execute shell scripts that download and install multiple cryptominers, as demonstrated below.
The threat actors behind the Kinsing backdoor and cryptomining botnet are heavily exploiting the Log4j vulnerability by sending Base64 encoded payloads to the susceptible server, which downloads and executes shell scripts.
This shell script will remove competing malware from the vulnerable device before downloading and installing the Kinsing malware, which will begin cryptocurrency mining.
Mirai & Muhstik Botnets
According to Netlab 360 the threat actors are exploiting the vulnerability in order to install the Mirai and Muhstik malware on vulnerable devices, as they are able to put to use IoT devices and servers into their botnets and use them to deploy cryptominers and perform large-scale DDoS attacks.
The Log4j vulnerability that came to light at the end of the year can undoubtedly be considered a major event in the security community. Honeypot and botnet are our bread and butter, and we have been concerned about which botnets would be exploiting this since the vulnerability was made public. This morning we got the first answers, our Anglerfish and Apacket honeypots have caught 2 waves of attacks using the Log4j vulnerability to form botnets, and a quick sample analysis showed that they were used to form Muhstik and Mirai botnets respectively, both targeting Linux devices.
Cobalt Strike Beacons
According to the Microsoft Threat Intelligence Center, the Log4j vulnerabilities are also being used to drop Cobalt Strike beacons.
The vulnerability allows unauthenticated remote code execution, and it is triggered when a specially crafted string provided by the attacker through a variety of different input vectors is parsed and processed by the Log4j 2 vulnerable component. The bulk of attacks that Microsoft has observed at this time has been related to mass scanning by attackers attempting to thumbprint vulnerable systems, as well as scanning by security companies and researchers.
Cobalt Strike is a genuine penetration testing toolset in which red teamers install agents, or beacons, on “compromised” machines in order to do remote network surveillance or execute additional instructions.
Threat actors, on the other hand, frequently deploy cracked versions of Cobalt Strike as part of network breaches and ransomware assaults.
Scanning and Exfiltrating Information
In addition to installing malware, threat actors and security researchers are employing Log4Shell vulnerabilities to scan for vulnerable servers and exfiltrate data from them.
Researchers utilize the attack to cause susceptible servers to view URLs or conduct DNS queries for callback domains, as seen below. This enables researchers or threat actors to assess if the server is susceptible and utilize it for future assaults, study, or bug bounty claims.
Some researchers may be going too far by utilizing the vulnerability to steal server data from environment variables such as the host’s name, the user name the Log4j service is running under, the operating system name, and the OS version number.
Staying Safe with Heimdal™
Heimdal™ Security has acknowledged the presence and inherent risk of using the log4j logging technology. As a result, we would like to reassure our customers and business partners who use Heimdal™ web-based services that the log4j vulnerability has no influence on the quality of our service, data integrity, or the client’s privacy.
Heimdal™’s web-facing services are PHP-reliant, meaning that the exploit cannot be used against our userbase. Furthermore, since log4j is endemic to the Java programming language and with no discernable connection between the two languages in terms of syntax, it’s highly unlikely for the exploit to be leveraged in compromising PHP-based web services.
We remind our customers and business partners that the log4j vulnerability is regarded as one of the most critical design flaws discovered in the last decade. Discovered on Friday and earmarked CVE-2021-44228e, log4j or log4Shell can enable threat actors to run arbitrary (and malicious code) on vulnerable, Apache-curated web servers for the purpose of exfiltrating sensitive data.
Preliminary telemetry has revealed that the zero-day flaw affects LDAP servers running Apache version 2.14.1 or below. Remediation is available in the form of a hotfix. In addition, we strongly recommend you update to the latest log4j version.
Heimdal™ client security and privacy are preserved. In addition, our company has begun monitoring the issue in order to identify compromised infrastructures, determine threat groups, and seek solutions that could aid compromised hosts, clients, or networks.
Did you enjoy this article? Follow us on LinkedIn, Twitter, Facebook, Youtube, or Instagram to keep up to date with everything we post!
Dora is a digital marketing specialist within Heimdal™ Security. She is a content creator at heart - always curious about technology and passionate about finding out everything there is to know about cybersecurity.
