A cross-platform vulnerability was first reported around Thanksgiving in Apache Log4j, which according to Romanian cybersecurity company Bitdefender, is a popular open-source library written in Java. The zero-day exploit allowed for the injection of arbitrary code, and was tracked by security companies as being involved in several kinds of mischief without being limited to a specific operating system. It was at first believed to be patched on December 9, however another story is unfolding.
The Log4j exploit is known as Log4Shell (also called CVE-2021-44228). According to CVE vulnerability updates, security patches conducted earlier on the weakness in the code may not be complete. American-Japanese multinational cybersecurity firm Trend Micro is urging patches be carried out at this time.
The exploit was first patched on Dec. 9, while the vulnerability was initially reported Nov. 24. According to the CVE record, the exploit was allowing an “attacker who can control log messages or log message parameters” to “execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.”
However, this patch was not enough.
According to the mitre.org CVE report dated December 14, “in certain non-default” situations, the fix to prevent Log4Shell activity in Apache Log4j 2.15.0 was incomplete. In these instances, the incomplete patch allowed a Java Naming and Directory Interface (JNDI) message lookup pattern that was still vulnerable. This meant that affected Apache Log4j code still contained an opening for a DDoS (Distributed Denial of Service) attack.
Success
You are now signed up for our newsletter
Success
Check your email to complete sign up
FURTHER READING:
- IMF Ran a Financial System Cyberattack Simulation the Same Day as Apache Log4j Exploit Exposed
- ‘Digital Pandemic’ Preparation: Supply Chain Attack Simulation To Be Conducted Between World Economic Forum and Russian State-Owned Bank
DDoS attacks are threats that involve an enslaved network of captured end terminals, known as “bots.” These can send large amounts of data capable of overwhelming the resources of a server, service, network or website and can bring functionality to a grinding halt. The enslaved bots, in total, are referred to as a “botnet.”
Fortunately, a new version, Log4j 2.16.0, fixes the DDoS issue by removing support for message lookup patterns and disables JNDI functionality by default.
In other words, early patch activity may have been inadequate to halt certain malicious payloads. The unprotected span of time was a minimum of approximately four or five days.
Attacks observed in the wild by Trend Micro have delivered two varieties of malicious payload, while Bitdefender revealed a third: Mirai (botnets, used for DDoS and spamming), Kinsing coinminer, and Khonsari ransomware. It was DDoS payloads, which were not completely mitigated by the early patch; and Trend Micro points to Mirai as their identified DDoS culprit.
As the well-known cybersecurity company Cloudflare explains, Mirai does not aim to create a botnet of enslaved computer terminals. Instead, Mirai scans the Internet for IoT devices that run on the ARC processor, using a stripped-down version of the Linux operating system, for the purpose of creating an IoT botnet.
This is especially, well, annoying, because IoT – short for Internet of Things – could indicate anything from a security camera to a digital picture frame to a teapot. Or an electrical grid component. Reeling us back from the implications of this, Cloudflare assuages that IoT is “just a fancy term for smart devices that can connect to the Internet.” Leaving the default username and password on an IoT device unchanged is the easiest way to have one’s baby monitor, teapot, tractor, or car turned into an enslaved device.
Trend Micro says that the following are affected: “Apache Struts, Apache Solr, Apache Druid, Elasticsearch, Apache Dubbo, and VMware vCenter.” Bitdefender has mentioned that the “Log4j library is widely used by other frameworks,” which include Elasticsearch, Kafka and Flink. The cybersecurity company further explains that these frameworks are “foundational for many popular web sites and services.” According to the initial vulnerability report, the “vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.”
For those who are curious, Trend Micro has explained that the Log4j vulnerability exploits “the ‘lookup’ mechanism in log4j 2.x.” Somewhat like ET, but far less endearing, Log4Shell attempts to phone home – searching out, via log and via format, the characters ${ in each log. “If these characters are present,” Trend Micro explains, “the ‘lookup’ function will be called to find strings after ${ and the said strings replaced with the real value found before.” It’s kind of like a bait and switch, putting in bad code for safe, normal code.
Observed threat behavior reveals different forms of lookups associated with different kinds of variable retrieval in the JavaScript. According to Trend Micro, some threat actors are obfuscating, or encoding, their attacks, while some are just leaving them in simple form.
Trend Micro has developed a Log4j Tester which can be accessed for free here on their website.
