The Home of the Security Bloggers Network
Home » Security Boulevard (Original) »
Earlier this week there was a report of a Log4j worm found in the wild that exploits the Log4Shell vulnerability. Thankfully, the worm discovered didn’t actually work. However, this should come as a warning to everyone that patching Log4j is extremely important. A successful Log4j worm could have disastrous consequences to individuals and organizations. Internet-wide worms could infect a large number of vulnerable computers, seek out new vulnerable hosts and may have the side effect of creating a denial-of-service against many services. This added traffic from worms looking for vulnerable Log4j instances could affect any internet-facing services, not just the ones running Log4j. According to Maven Central, one of the most widely used Java package repositories, 41% of recent Log4j downloads were vulnerable versions. This means that nearly half of all Log4j versions downloaded in the last few weeks contain the critical Log4Shell security vulnerability.
We often hear about viruses, ransomware and cryptominers in discussions of computer malware. A worm is a type of malware that hasn’t gotten as much attention in recent years, most likely because we haven’t seen a successful one in quite some time. A worm can actually be more dangerous than other types of malware because once it infects an individual computer, it self-propagates to other vulnerable computers and devices. Once a worm has been let loose, it can be difficult or even impossible to stop on the public internet. In the past, computer worms have been extremely destructive. For example, the Daprosy Trojan worm, which is spread through email campaigns, USB drives and LAN cafes, infects users with key-logging malware. Although first discovered in 2009, Daprosy continues to exist in various forms today, making it one of the most persistent and dangerous worms of the last decade. In today’s world with heavy reliance on the internet, a wide-reaching worm could have far-flung and devastating consequences.
The recent Log4j security vulnerability, named Log4Shell, provides ideal conditions for a computer worm to propagate. The Log4j vulnerability meets three criteria needed for a successful worm—the vulnerability is in software that is widely deployed across the internet, it is reachable from the public internet and it allows an attacker to execute code of their choosing. A worm that targets Log4Shell would have the potential to infect a vulnerable system, then start looking for other systems vulnerable to Log4Shell that can also be infected. The result can be exponential growth of these infections. What the worm does once it’s in the wild is unknown. A worm could exist just to infect as many hosts as possible. It could be used to steal data, or it could be used to mine cryptocurrency. These unknowns are why we have to stay vigilant.
Another aspect of Log4Shell that makes it so insidious is that it can potentially be exploited through a firewall. A worm could hopscotch from internet-facing servers that are not even running Log4j to servers that are deep in highly secure areas of the corporate network and vulnerable to Log4j. Once a worm is inside the firewall, it could spread to other internal systems affected by the Log4j vulnerability.
It’s not hard to imagine that a Log4Shell worm would be extremely damaging given the widespread use of Log4j and the prevalence of the vulnerability. Security and development teams have been working overtime for the past two weeks to remediate systems on top of end-of-year activities and the upcoming holidays. There are some important steps organizations can take now to help prevent a Log4Shell worm from taking hold.
The first step is to understand where you are using Log4j. Many organizations have been focused on this since the vulnerability was discovered, but the data from Maven Central indicates there are still plenty of old versions of Log4j out there. Knowing where you have Log4j is incredibly important. Consider scanning all of your application directories with an open source tool, including applications you wrote as well as commercial applications and libraries from vendors. While many software vendors are reaching out to let customers know which applications are impacted, some vendors may not be as proactive. Two of the easiest, no-cost, open source scanners out there are Syft and Grype. Syft generates a software bill of materials (SBOM) so you can identify which of your applications contain Log4j. Grype scans for vulnerabilities and is able to pick up vulnerable versions of Log4j.
Once you know if you have any vulnerable versions of Log4j, it’s critical to update those libraries as soon as possible. This is always easier said than done, and many security and development teams have been working around the clock to upgrade all the Log4j instances. The Log4j security advisory contains a workaround if upgrading isn’t possible.
Lastly, spread the word about Log4Shell. The data from Maven Central shows that a lot of Log4j users may not be aware of the critical nature of this vulnerability. While many of us have been focused on nothing but Log4j for over a week, we may know someone who needs to take a look at the software they’re using. The more systems that get patched against Log4Shell, the less chance there is of a worm gaining a foothold.
Josh Bressers is the vice president of security at Anchore, a software supply chain security company.
josh-bressers has 2 posts and counting.See all posts by josh-bressers
The Home of the Security Bloggers Network