[German]The log4j vulnerability CVE-2021-44228 keeps sending shockwaves through the IT scene. Latest reports say that a majority of companies have not patched the vulnerability in their software. In addition, a new DoS vulnerability has been found in the library, for which there is no patch yet. Meanwhile, attacks continue to run to new highs. Here's an overview to close out the week.
Advertising
100,000 attacks blocked/minute
For cybercriminals, the log4j vulnerability CVE-2021-44228 is a found food. Within a few hours, the exploits were used to infect vulnerable systems. According to the following tweet, scans reached new highs on December 16, 2021. Over 100,000 Lock4Shell attacks were blocked per minute.
I have received updated attack figures from CheckPoint. In less than a week, Check Point has recorded more than 1.8 million attempts to exploit the Log4J vulnerability.
- In Germany, 53 percent of all corporate networks tracked by Check Point have now been attacked.
- In Austria, the figure is already 57 percent, and in Switzerland, 47 percent.
- Worldwide, the average is now 46 percent, and 51 percent in Europe.
- Resellers and system integrators are the most affected globally, at 59 percent.
According to this tweet, which links to a Juniper blog post, attackers are changing their strategy. Instead of conducting log4j attacks via LDAP (Lightweight Directory Access Protocol), try attacks via RMI (Remote Method Invocation). RMI is a mechanism that allows an object residing in one Java Virtual Machine (JVM) to access or invoke an object running on another JVM.
No log4j patches in many companies
Although the vulnerability has been known for a week, many larger companies have not yet managed to protect their software with patches to close the log4j vulnerability. That's according to this Reuters article, referenced in the following tweet.
Advertising
Cisco Systems, IBM, VMware and Splunk were among the companies that had several flawed software products in use on Thursday that did not have patches available for the Log4j vulnerability, according to a summary released by the U.S. Cybersecurity and Infrastructure Security Agency. Kevin Beaumont, security threat analyst who helped compile the list for CISA, comments:
Many vendors do not have security patches for this vulnerability. Software vendors need to keep better and publicly available records of open source software use so it's easier to assess the risk – both to themselves and to their customers..
As of Thursday, the CISA list included about 20 Cisco products that are vulnerable without an available patch. Among them are Cisco WebEx Meetings Server and Cisco Umbrella, a cloud security product. At VMware, security advisories are constantly updated, and there are dozens of affected products. Has nothing to do with log4j, but anyone using VMware Workspace ONE UEM should look at security advisory VMSA-2021-0029, dated 12/16/2021. There, there is an SSRF vulnerability CVE-2021-22054, which has a CVSSv3 value of 9.1. Attackers can grab sensitive information without authentication (see also).
CISA guidance for analysis
From the US security agency CISA there is this guidance for companies and authorities how to deal with the analysis of the log4j vulnerability CVE-2021-44228. Will Dormann points to this document in the following tweet.
Remedial actions were also described here by CheckPoint. Meanwhile, government actors are also attacking vulnerable systems. Cybercriminals are trying to inject ransomware or cryptominer into systems.
Security vendor Vectra sees vulnerabilities like Log4j as further drastic evidence that prevention and patching are not enough. Vectra's Andreas Riepen argues:
- 1. It is impossible to patch everything with urgency: The attack surface is very large. The affected module of Log4j is used by a wide range of software and products. It is already difficult to find out where it is used! Not to mention trying to patch it. Also, companies depend on vendors to provide them with patches for their products. For some, they will have to wait a very long time and probably never reach 100 percent.
- 2. EDR (Endpoint Detection & Response) cannot stop the first exploit, nor can it provide complete coverage: All EDR vendors talk about looking for exploit after download or behavior. Moreover, this affects a wide range of tools and products on which EDR cannot be installed – routers, switches, security products, Linux servers, etc.
- 3. SIEM () is not suitable to search for it: It is not guaranteed that every application logs the fields where the exploit string can be seen. Also, not all logs from every application get into the SIEM. You can't search what you can't see.
- 4. Rapid evolution: The attack is evolving rapidly. Attackers will take advantage of this in many ways. There are already attempts at obfuscation that bypass basic signatures to look for the exploit string.
Riepen therefore advises companies to "assume systems are compromised and be prepared to detect and respond to the attack in real time. Close the EDR gap and reliably monitor every connection from the network to the cloud. Recall and stream data can help quickly detect any attempt to exploit this. Modern AI models for cybersecurity are designed to detect the methods attackers would use after a compromise. Furthermore, an AI-based monitoring approach can most quickly detect and mitigate the threat of exploiting this vulnerability. For the reasons stated above, this cannot be accomplished with either prevention or patching. For organizations looking to secure themselves and mitigate risk, automated and continuous data flow monitoring is the best investment they can make." Here's another blog post about it.
New insights every day, new vulnerability
The life time of existing findings is often hours. While it was originally said that older JAVA versions of log4j were not affected, this is outdated by new exploit. The colleagues from Bleeping Computer have published this article, which explains why you should not use log4j version 2.15.0 anymore and have to use log4j version 2.16.0. Trend Micro has released this article with the latest advices.
Just came a couple of hours across the above tweet claiming a new vulnerability for log4j that allows DoS attacks. But here it is unclear whether this is exploitable. And apache has released Log4j 2.17.0 for Java 8 an up (see also).
Similar articles:
0-day CVE-2021-44228 in Java library log4j puts many projects at risk
log4j vulnerability CVE-2021-44228: Patch your Minecraft
VMware products threatened by log4j vulnerability CVE-2021-44228
log4j FAQ and Repository
Advertising
