Open Source Use in Critical Infrastructure Under Scrutiny

Severe open source software vulnerabilities such as the flaw found in December in the Log4j logging library are likely to pop up in penetration tests for a long time. These bugs don't go away because, despite the availability of patches and solid update advice, administrators aren't always aware of where these open-source components live inside either commercial or homegrown software applications.

This is particularly true in industrial environments, where legacy software continues to dominate, and the criticality of these bugs is further magnified because often downtime is unacceptable, and critical services cannot be easily turned off for software or firmware updates. Instead, organizations are left with few other options other than to apply mitigations—if any are made available—hoping to blunt the impact of a publicly available exploit.

Tomorrow, representatives from a number of cloud service providers, software development companies, and other tech leaders are scheduled to meet at the White House to discuss the prevalence and risks posed by open source software components. Log4j has stirred this reaction within the Biden administration, but this has been brewing for some time.

Open Source 'Key National Security Concern'

The administration has prioritized cybersecurity of critical infrastructure since last year's very public attacks against Colonial Pipeline and other industrial companies, and a number of executive orders and industry-specific mandates emerged urging more visibility into the assets running the country's most critical services.

White House national security adviser Jake Sullivan went so far as to call the use of open source software as a "key national security concern." Not only is the lack of visibility into where open source software lives within commercial products a concern, but Williams added that many of these projects are run by "volunteers." The Apache Software Foundation maintains Log4j, and on its website, it says more than 850 individual members and 8,200 committers collaborate on the enterprise-grade software built and maintained by the foundation. There are more than 300 projects listed on the Apache website; it's unknown how many members and committers work on Log4j, for example.

Many open source projects are under-resourced and poorly funded; these challenges often don't come to light unless a critical vulnerability surfaces. Heartbleed, the crypto vulnerability found in 2014 in OpenSSL, shone a harsh light on the lack of resources keeping OpenSSL afloat, despite the fact the software lived everywhere from commercial software, to smartphones, to industrial devices. There was a skeleton crew maintaining OpenSSL at the time, woefully behind on updates, yet faithful to keeping the project on track. Heartbleed put a lot of businesses at risk and reactively, the industry was forced to create groups to audit the code base and funnel money and development resources to the project.

Tomorrow's White House meeting is a concrete step the Biden administration is taking toward proactively assessing the risks posed by open source software.

SBOM a Key Risk Management Tool

Last May, the first steps were taken toward locking down software development for code used by the federal government.

Buoyed by the Solarwinds supply chain attack, the administration issued an executive order that included a prominent section on enhancing software supply chain security that included the creation of guidelines to evaluate secure development practices. Furthermore, the EO mandated that a software bill of materials (SBOM) be published on a public website for each product within the federal supply chain.

SBOMs are akin to ingredient labels on food products, for example. They describe the components—and relationships between those components—used in building software; developers often compile projects using code from numerous sources, including open source projects, for example.

An SBOM would enable a buyer to know up-front what components make up the software they're buying, ensure they're up to date, and prioritize response in the event of a critical vulnerability. The government expressed via the executive order that SBOMs are a crucial risk management tool, and one that's largely missing today from a decision-maker's arsenal.

OT Not Immune to Open Source Issues

Claroty's Team82 research arm has uncovered vulnerabilities that prove OT may also be greatly impacted by open source software vulnerabilities.

Let's look at two prominent cases:

OpenVPN:

Industrial remote access solutions have never been more central to business in industrial environments than since the start of the pandemic almost two years ago. Many are built with OpenVPN running under the hood. OpenVPN is the most common VPN implementation used to create secure site-to-site connections in routed or bridged configurations, as well as remote access facilities. If you're looking to build a secure tunnel, you're not going to reinvent the wheel, you'll use OpenVPN.

Team 82 examined four vendors' industrial remote access clients running atop OpenVPN: HMS Industrial Networks, Siemens, PerFact, and MB connect line. Vulnerabilities discovered by Team82 allowed for either remote code execution, or the establishment of a new OpenVPN instance with an arbitrary configuration, allowing an attacker to elevate privileges.

In either scenario, an attacker could exploit a bug in a widely used open source component to seriously compromise the integrity of a remote connection.

OpENer ENIP Stack:

Open source can also be at the core of popular industrial communication protocols. These protocols oversee how control systems interact with field devices, upload new configurations and commands, and download data. The OpENer ENIP stack implements ENIP and CIP protocols that run inside many commercial products used inside industrial enterprises.

Last year, Team82 published a report disclosing a handful of vulnerabilities that could be used to crash devices, remotely run code, or read data from a device.

ENIP is the leading industrial protocol; it adapts the Common Industrial Protocol to Ethernet, allowing for the transmission of device data between different industrial applications. Visibility into these protocols is essential to maintain the integrity of data sent to and from industrial devices.

Recommendations

Secure software development among open source projects remains a voluminous challenge, one that the federal government appears to recognize. Albeit reactionary to the Log4j vulnerability, tomorrow's White House meeting should serve as more impetus to mandate visibility into software running on key critical infrastructure systems, and the adherence to minimum secure development standards.

The federal government's deep pockets can prompt companies to improve code analysis, develop SBOMs to help prioritize vulnerability management, and improve visibility into where open source is running inside critical systems.

Otherwise, vulnerabilities such as Log4j, Heartbleed, and others will continue to pop up, disrupt business continuity, and linger on in legacy systems for years to come.