How the Log4j Grinch stole Christmas (with apologies to Dr. Seuss)
Your cybersecurity team deserves a belated holiday gift, or maybe a few extra days off. While most of us were enjoying the festive year-end season, many cybersecurity professionals were hard at work trying to fix the Log4j vulnerability that became a major issue starting in late November. Instead of riding out the latter part of December in lock-down mode, IT professionals were scrambling to track down the extent of the issue and take all the necessary remediation steps. Lots of sleep and vacation time were lost in the process.
Even if your company wasn’t directly hit with a cyber incident caused by Log4j, it may have been impacted by a third-party vendor that was. Just in time for end-of-year reports, Kronos, which offers Human Resources products, detected “unusual activity impacting UKG solutions using Kronos Private Cloud,” which made the services unavailable.
Log4j, the vulnerability found in Java’s logging package, shows both the importance and weaknesses of open source software. In a warning, the FTC stated, “The Log4j vulnerability is part of a broader set of structural issues. It is one of the thousands of unheralded but critically important open-source services that are used across a near-innumerable variety of internet companies. These projects are often created and maintained by volunteers, who don’t always have adequate resources and personnel for incident response and proactive maintenance even as their projects are critical to the internet economy.”
This particular vulnerability is not an isolated event, nor is it something new. The Equifax breach from several years ago, for example, was also due to an open source vulnerability.
Open source cyberattacks have increased by 650% between 2020 and 2021, and they will continue to increase because open source is relied on more than ever throughout the software supply chain.
Threat actors targeting open source’s popularity
A lot of users are stuck in the mindset that viruses and vulnerabilities are found primarily on Windows machines and in Microsoft software. While this may have been the case a decade ago, we’ve moved past that. And that is thanks to the popularity of Linux and open source, which is where hackers have moved, and now where some of the biggest, most damaging attacks we’re seeing occur, sometimes in the most basic of software modules.
Such as the logging function. It’s a pretty benign piece of code, but Log4j exploits poorly written code in the logging function used across thousands of products and embedded systems running Linux. This isn’t a core element of the application; it creates logs. It is a basic feature that has become a backdoor for threats, taking a usually overlooked piece of code and hijacking it. Now it is everywhere, and thanks to the timing of its discovering, Log4j became the Grinch who stole a lot of Christmases and holiday celebrations.
It needs to serve as a warning of the risks involved in the open source supply chain.
Not all code is created equal
Because open source is a collective software design, developers need to take responsibility for vulnerabilities and security flaws found in the code. That’s the way it is supposed to work, in theory. In reality, not all code is created equal. Code scanners used by developers didn’t identify the logging vulnerability until it was exploited.
The challenge for CISOs and CIOs using open source software within their organization is to come up with a way to put more scrutiny on greater elements of the code, going further into the weeds to find potential problems in unexpected places. The tools that are used need to evolve.
Most computer science grads would rather write their own software than debug or find vulnerabilities in other developers’ code. But it has to be done. CISOs and engineering executives now are going to ask why the logging function didn’t get more scrutiny. After the next exploit of a forgotten code, the same question will come up: “Why didn’t anyone think to look at this and fix it before it became a problem?” (Answer: because everyone wants to work on more interesting problems.)
There needs to be a focus on open source security, at all levels of the code. It should be part of a set of checks and balances developers use to make sure no code is missed. It should also be partly automated, using AI to do the grunt work that humans would rather skip. Both parts, working in tandem, need to be used across all components of open source, especially when open source is used in critical infrastructure.
It’s scary to think that something so basic, such an unimportant piece to the value of the overall product, has the ability to take down entire business operations. Yes, some are convinced open source is more secure than proprietary software because of the millions of people going over the code. Last December, we saw that those million pairs of eyes didn’t see everything. Until the processes are in place for deep scans into the code, open source will continue to be a potential threat.
