Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

10:00 AM
Paul Lariviere
Paul Lariviere
Connect Directly
E-Mail vvv

Ripple20 Malware Highlights Industrial Security Challenges

Poor security practices allowed software vulnerabilities to propagate throughout industrial and IoT products for more than 20 years.

The recent discovery of 19 vulnerabilities in a lightweight TCP/IP library has sent shockwaves across industries as it exposes millions of organizations to potential cyberattacks. Known as Ripple20, these vulnerabilities were found in a library first released back in the 1990s.

The vulnerabilities vary in severity, but some can allow an attacker to control an affected device remotely, or cause availability issues. The number of affected systems was estimated to be in the hundreds of millions, and the affected products include "smart home devices, power grid equipment, healthcare systems, industrial gear, transportation systems, printers, routers, mobile/satellite communications equipment, data center devices, commercial aircraft devices, various enterprise solutions, and many others." 

Related Content:

Ripple20 Threatens Increasingly Connected Medical Devices

Ripple20: More Vulnerable Devices Identified

Quite obviously, everyone wondered aloud how these vulnerabilities could exist in so many products and go unnoticed for over 20 years. However, I am not surprised by the situation. Poor security practices implemented in industrial control systems (ICS) and the Internet of Things (IoT) have contributed to how vulnerabilities like those outlined in the Ripple20 research propagate throughout so many products.

Understanding Risk, Software Quality in ICS
Several ICS manufacturers' products, including various makes and models of programmable logic controllers (PLCs) and multiple human-machine interface (HMI) manufacturers, are primarily designed with safety and availability in mind. The reliability of PLCs is exceptional—ICS systems can be deployed in production facilities for decades and still function properly. 

Safety is engineered into all ICS systems at a physical level, not just a logical level. This leads me to the topic of risk as it relates to the majority of industrial control systems.

While there are certain industries where security can have real-world catastrophic implications, such as the nuclear energy sector and other critical infrastructure, the vast majority of ICS systems do not have these extreme considerations to contend with. The reality for most manufacturing plants is that there is financial risk present with respect to security issues: processes can be interfered with to disrupt production, products can be contaminated if the process is altered in specific ways, or IP can be stolen in the form of recipes, formulae, and proprietary process details.

It is important to properly understand the risks a process could face from potential security issues without overreacting. While production issues that affect product quality can arise, such issues will be identified during the QA process. Manufacturers have processes in place to detect problems, investigate them, scrap contaminated batches, clean out equipment or fix the issue, and then resume production. While this process can be costly, it isn't necessarily dire.

A common issue faced by systems integrators is being forced to use proprietary software of poor quality. While PLCs themselves are engineered and built to be extremely robust and reliable, the same cannot be said for other software released by these manufacturers. When working with some of the lowest-quality software, it is not uncommon to have multiple crashes per day while using the software as intended.

IT Versus OT
Since availability is critical to ICS systems, and since the systems themselves can be fragile and quirky, these are generally the responsibility of operational technology (OT) teams. The information technology (IT) team usually manages the corporate network. OT employees are familiar with process technology and the systems they manage, but they do not generally know a great deal about information security, which can lead to insecure deployments.

One fairly common situation for manufacturers is a divide, sometimes adversarial, between the IT and OT staff within a company. 

OT employees do not want the IT staff to tamper with their systems out of fear of downtime that can cost the company. From what we have seen, these relationships often resemble red team versus blue team attitudes at many organizations. The blue team can resent the efforts of the red team because those efforts create more work for the blue team and can be considered a criticism of their work.

OT employees also often don't want to consult with their IT counterparts when making arrangements such as remote access, leading to situations such as RDP on control networks commonly being exposed to the public Internet. IT and OT teams are on the same team and need to educate each other and enable each other to achieve their goals and mandates.

Ensuring Product Security in ICS 
The ICS/IoT industries face many of the same challenges as traditional software development shops. However, there are unique challenges in ICS/IoT, where devices can be deployed for decades and could need unpatched legacy systems to be in place on the network to support them. Drop-in replacement for a legacy component may not exist, and re-engineering the process to accommodate a more modern component, coupled with the financial losses arising from downtime to complete the upgrades, could be cost-prohibitive.

Similarly, challenges exist with supply chain management. Manufacturers that integrate third-party components into their products may not know whether any of their individual components contain vulnerable libraries. The lack of basic security and secure coding principles in developer education means that they often aren't aware of security weaknesses. Colleges and universities have a responsibility to train developers to produce secure software in the same way that they need to make sure engineering students can design a structure that won't collapse. 

Each of these issues needs to be addressed systematically if we want to see an increase in the security of the embedded devices that control much of our surroundings, often unnoticed, in the background. While preventing these vulnerabilities in the first place is ideal, having a way to track potentially vulnerable third-party components in products is a must to facilitate patching and other remediation efforts.

Paul is a Technical Director at Security Compass with a strong background in ICS, embedded development, and security assessments. As a security consultant, Paul has conducted network penetration tests, application security assessments, embedded device security assessments, ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, when determining the common dimension size of two tensors, TFLite uses a `DCHECK` which is no-op outside of debug compilation modes. Since the function always returns the dimension of the first tensor, malicious attackers can ...
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, a crafted TFLite model can force a node to have as input a tensor backed by a `nullptr` buffer. This can be achieved by changing a buffer index in the flatbuffer serialization to convert a read-only tensor to a read-write one....
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, if a TFLite saved model uses the same tensor as both input and output of an operator, then, depending on the operator, we can observe a segmentation fault or just memory corruption. We have patched the issue in d58c96946b and ...
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, saved models in the flatbuffer format use a double indexing scheme: a model has a set of subgraphs, each subgraph has a set of operators and each operator has a set of input/output tensors. The flatbuffer format uses indices f...
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 2.2.1 and 2.3.1, models using segment sum can trigger writes outside of bounds of heap allocated buffers by inserting negative elements in the segment ids tensor. Users having access to `segment_ids_data` can alter `output_index` and then write to outside of `outpu...