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

9/10/2020
10:00 AM
Paul Lariviere
Paul Lariviere
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

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
Comments
Newest First  |  Oldest First  |  Threaded View
NSA Appoints Rob Joyce as Cyber Director
Dark Reading Staff 1/15/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: I like the old version of Google assistant much better.
Current Issue
2020: The Year in Security
Download this Tech Digest for a look at the biggest security stories that - so far - have shaped a very strange and stressful year.
Flash Poll
Assessing Cybersecurity Risk in Today's Enterprises
Assessing Cybersecurity Risk in Today's Enterprises
COVID-19 has created a new IT paradigm in the enterprise -- and a new level of cybersecurity risk. This report offers a look at how enterprises are assessing and managing cyber-risk under the new normal.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-8567
PUBLISHED: 2021-01-21
Kubernetes Secrets Store CSI Driver Vault Plugin prior to v0.0.6, Azure Plugin prior to v0.0.10, and GCP Plugin prior to v0.2.0 allow an attacker who can create specially-crafted SecretProviderClass objects to write to arbitrary file paths on the host filesystem, including /var/lib/kubelet/pods.
CVE-2020-8568
PUBLISHED: 2021-01-21
Kubernetes Secrets Store CSI Driver versions v0.0.15 and v0.0.16 allow an attacker who can modify a SecretProviderClassPodStatus/Status resource the ability to write content to the host filesystem and sync file contents to Kubernetes Secrets. This includes paths under var/lib/kubelet/pods that conta...
CVE-2020-8569
PUBLISHED: 2021-01-21
Kubernetes CSI snapshot-controller prior to v2.1.3 and v3.0.2 could panic when processing a VolumeSnapshot custom resource when: - The VolumeSnapshot referenced a non-existing PersistentVolumeClaim and the VolumeSnapshot did not reference any VolumeSnapshotClass. - The snapshot-controller crashes, ...
CVE-2020-8570
PUBLISHED: 2021-01-21
Kubernetes Java client libraries in version 10.0.0 and versions prior to 9.0.1 allow writes to paths outside of the current directory when copying multiple files from a remote pod which sends a maliciously crafted archive. This can potentially overwrite any files on the system of the process executi...
CVE-2020-8554
PUBLISHED: 2021-01-21
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typicall...