Log4Shell Gives Open Source Community a Wakeup Call

It began with a flaw.

Right after Black Friday in the U.S., a Chinese security researcher alerted the Apache Software Foundation about a flaw inside a Java-based library called Log4j.

Coders use the Log4j software development logging package for programming APIs. It allows them to log messages, control at “runtime” how these messages are formatted and manage where they are reported.

It’s popular; so much so that most web services use this Java library — from Minecraft (where the vulnerability was found) to the Mars 2020 helicopter. Most Java-based programs use it, and its popularity made it a global problem. You can find the complete list here.

“Java still is one of the most popular programming languages to build web applications, and more than 90% of Java applications use Log4j directly or indirectly (meaning they use another open source library that also includes Log4j). This is why the problem is so widespread,” Lawrence Crowther, Snyk’s head of solutions engineering in APJ, explains further.

But the nightmare does not end there. Experts call the vulnerability (known as Log4Shell) a “pre-authentication” exploit. It essentially means the attacker does not need to sign in.

“Correct, any web page, API, or service that uses Log4j and takes user information is susceptible whether or not you are logged in or not,” says Crowther.

Into the belly of the beast

To first understand Log4Shell, CISOs need to know how Log4j works. One feature is calling out to a remote server to get additional information while logging data from the application.

“It is from this that a hacker can pass in a malicious string containing an address to their own ‘evil’ server and then pass back some ‘evil’ code to be executed on the application server directly,” says Crowther.

So, how will you know you’ve been hacked or compromised? Unusual remote calls from Java applications to an unknown server not in the company's network is a telltale sign.

If there are such remote calls, CISOs need to act fast. And the next step depends on whether they are looking for Log4j in their homegrown applications and products or in products they have purchased, says Sandy Carielli, Forrester’s principal analyst.

“For homegrown products and applications, software composition analysis (SCA) will help find known vulnerabilities in open source software like Log4j and help you remediate. For products that you purchased, vulnerability scanning will help with detection, and if vendors have provided a software bill of materials, that is a faster way to see which products even have Log4j,” she explains.

Crowther notes that CISOs also have to track all the non-direct dependencies from other popular Java open source projects that include the Log4j library. This includes the likes of Apache Struts, Apache Solr, and Apache Camel.

Getting any SCA tool will not be enough. “A lot of SCA tools on the market will not report on the ‘indirect dependencies,’ so the choice of tool is critical for the CISO and developers to keep their business protected,” Crowther explains.

Time to get serious about DevSecOps

For Crowther, a DevSecOps approach can help CISOs do the heavy lifting needed with these types of vulnerabilities.

“Using a DevSecOps approach, i.e., scanning code, libraries, and containers, throughout the whole SDLC in an automated way with CI/CD will ensure complete coverage and reduce the risk of these vulnerable packages being released to production,” says Crowther.

It will allow, for example, developers to find the top-level (parent) libraries that need updating and with which versions “without breaking the applications.” The approach also allows automated fixes to be issued from the system in the form of pull requests (PRs), “so a developer needs only accept or reject and can move on with other more important work,” he explains.

Whatever the approach, DevOps teams need to audit their code for Log4j fully. Carielli notes such an effort is especially important today as many employees are observing WFH measures or working remotely, making their laptops vulnerable for exploitation.

We’ll never see open source the same way

Log4j is changing the conversations in open source communities.

“Log4Shell is said to be the worst and most widespread open source vulnerability to date. The reason why it is so bad is that hackers can execute any arbitrary code (RCE - Remote Code Execution) on the victim's machine to collect information, navigate around their network or destroy infrastructure,” says Crowther.

This makes it a global problem because any open source library can arbitrarily call other systems without first checking the validity of the string or payload so they should be used with caution.

CISOs, realizing that keeping their open source libraries up to date is not enough, are also beginning to question whether their vendors are doing the same.

“Log4j uses a system called JNDI (Java Naming and Directory Interface) to look up resources and is where the vulnerability [is found]. Any other system using this feature in Java should be monitored for similar attacks and potentially reworked to avoid the risks,” explains Crowther.

Concurrently, open source communities are asking companies that use their work for revenue-generating products to give back in terms of resources and funding, observes Carielli.

“The vulnerability has also re-ignited conversations about software bill of materials, about better support for open source developers, and runtime protection. These are all important conversations. The thing to remember is that there is no single solution or protection — the industry will need to pursue these initiatives in parallel,” she adds.

It’s not over either; not for a long while.

“Log4j is so ubiquitous that it was a little surprising to find software vendors that weren’t impacted. Many vendors responded well, with quick and transparent statements about if and how they were impacted and provided a quick patch turnaround. But there is a long tail that we’re going to have to keep an eye on,” Carielli warns.

Winston Thomas is the editor-in-chief of CDOTrends and DigitalWorkforceTrends. He’s a singularity believer, a blockchain enthusiast, and believes we already live in a metaverse. You can reach him at [email protected].

Image credit: iStockphoto/style-photography