Access to Information, Duke University, and The Media Trust: Log4j

Background:

Throughout this project the research team at Duke University and the Media Trust has focused on how Third-Party Code interacts with our synthetic Duke and Remote Worker profiles across the web. We have often explored this through the angle of online advertising, an ecosystem that allows easy access for third-party code even when the actual domain visited doesn’t contain any vulnerabilities. However, this is not the only way malicious third-party code can be delivered.

Domain owners face significant resource and time constraints when designing their sites and applications. Rather than develop everything in-house it is often easier turn to third-party code. This borrowed code is ubiquitous across the web with 65 to 95 percent of the average consumer-facing websites including some of this software. Yet relying on outside parties creates the potential for security vulnerabilities, and if a particular portion of third-party code is used by enough organizations it can expose a vast swath of systems all at the same time. While open source software also potentially has security benefits from allowing researchers around the world to test it and find bugs, the potential for broad use of the code creates magnified risks.

The Vulnerability:

Enter Log4j, an open source java logging framework that developers use for tracking within an application. Rather than creating a logging library in-house it is far easier for developers to simply add Log4j to their systems and call it a day. And because of this ease of use it is prevalent across consumer and enterprise systems such as iCloud, Microsoft, Salesforce, and others. Thus when vulnerabilities were discovered in Log4j this past month hundreds of millions of devices became exposed.

The primary vulnerability, commonly dubbed Log4Shell, is even more dangerous because of how easy it is to exploit. The technical details are beyond the scope of this blog, but in essence malicious actors only need to get the system to log a string of code to give themselves remote access. This is easy to achieve in seemingly benign ways and can be essentially automated even for those without much coding experience. Because of Log4j’s pervasiveness this has created the opportunity for a variety of threat actors to target a wide range of potential victims.

Attack Impacts:

The impact of this vulnerability cannot be overstated. CISA Director Jen Easterly referred to Log4j as “the most serious vulnerability that I have seen in my decades-long career,” and government agencies across the world have released advisory notices on how organizations should respond. However, even with the quick response from governments and companies the repercussions of Log4Shell are likely to be severe and ongoing due to a lack of third-party code awareness and long-term attack plans.

Awareness is critical because of how pervasive third-party software is. A large amount of organizations are unaware of all of the programs and software they use because most supply vendors don’t include this information. This makes it extremely hard for them to determine whether they are actually exposed, raising the risk that years down the road we will see threat actors exploiting this vulnerability against unsuspecting organizations who never knew they needed to patch it.

There has been a push on the federal level to make providing these details mandatory. Details of what code is contained in software, referred to as Software Bills of Materials (SBOMs), have become a mandatory request for federal agencies to their supply vendors. This has required a degree of industry standardization as many vendors are loath to disclose every potential vulnerability or elements within their own proprietary data. This standardization process is still in flux, but much of the initial codification of SBOMs was spearheaded by Allan Friedman during his time at the National Telecommunications and Information Agency (NTIA). During Friedman’s tenure NTIA put out guidance on what minimum elements an SBOM must contain and what vulnerabilities must be disclosed, but until these are fully agreed upon by all stakeholders and becomes an industrywide practice it will have a limited effect in preventing large scale attacks such as Log4Shell.

Because Log4j gives remote access there is also a strong possibility that malicious actors are incorporating this into long-term attack plans. Even if an organization quickly patches the vulnerability if an attacker has already used it they may still be present in the system. Thus even the most responsible organizations may find themselves and their users exposed years down the road due to a delayed attack.

Once an attacker has exploited Log4j the potential harms they can cause are numerous. The most common attack detected so far has been the installation of cryptominers on exposed systems as a quick and easy profit method. Other risks to users and organizations include the selling of backdoors to these systems, data theft, DDoS attacks, ransomware, and a variety of malware installations. There is also evidence that nation-state hackers are using this vulnerability to further espionage or other political goals.

Third Party Code:

The scope and potential impact of Log4j exposes just how serious of a crisis this is, one that has arisen due to overreliance on third-party code and lax awareness of its risks.  This code is ubiquitous across the web and puts even organizations who otherwise have very strong security practices at risk. And while Log4j is currently dominating the headlines, other third-party code could also expose organizations without their knowledge.

It is unlikely the widespread use of third-party code will disappear for the vast majority of companies. The costs of developing everything in-house are too high, and thus open source software represents a more efficient option. This does not mean that organizations should accept the risks as inevitable however. Improvements must be made in the software supply chain and this includes elements such as continuing the work on SBOMs to ensure organizations have a better accounting of the third-party code they are running on their systems. The executive order mandating these has very low minimum requirements for SBOMs limiting their utility to prevent further unforeseen breaches. Friedman’s transition from NTIA to the Cybersecurity and Infrastructure Security Agency (CISA) will likely help to codify and raise some of these standards for the Federal Government, but until there is significant industry adoption it will be difficult to truly limit the impact of third-party code.

SBOM’s also fail to address development within legacy systems and thus it is only one necessary element towards limiting vulnerabilities from third-party code. Organizations should also take steps on their own to audit the current presence of this code in their systems including code that may be buried layers deep in other software and programs. They should also do their best to ensure any outside vendors they use are following responsible security practices.

Taking these steps will not completely remove the danger of third-party code. There will always be security risks when relying on outside parties, but responsible companies should reduce this as much as possible. Third-party code should be used deliberately, with a clear idea of where it is coming from and what it contains. Doing so can allow organizations to mitigate the risks of attacks such as Log4j and ensure that they are aware of vulnerabilities when they become public.