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
Manchester United Suffers Cyberattack
Dark Reading Staff 11/23/2020
As 'Anywhere Work' Evolves, Security Will Be Key Challenge
Robert Lemos, Contributing Writer,  11/23/2020
Cloud Security Startup Lightspin Emerges From Stealth
Kelly Sheridan, Staff Editor, Dark Reading,  11/24/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-29378
PUBLISHED: 2020-11-29
An issue was discovered on V-SOL V1600D V2.03.69 and V2.03.57, V1600D4L V1.01.49, V1600D-MINI V1.01.48, V1600G1 V2.0.7 and V1.9.7, and V1600G2 V1.1.4 OLT devices. It is possible to elevate the privilege of a CLI user (to full administrative access) by using the password [email protected]#y$z%x6x7q8c9z) for the e...
CVE-2020-29379
PUBLISHED: 2020-11-29
An issue was discovered on V-SOL V1600D4L V1.01.49 and V1600D-MINI V1.01.48 OLT devices. During the process of updating the firmware, the update script starts a telnetd -l /bin/sh process that does not require authentication for TELNET access.
CVE-2020-29380
PUBLISHED: 2020-11-29
An issue was discovered on V-SOL V1600D V2.03.69 and V2.03.57, V1600D4L V1.01.49, V1600D-MINI V1.01.48, V1600G1 V2.0.7 and V1.9.7, and V1600G2 V1.1.4 OLT devices. TELNET is offered by default but SSH is not always available. An attacker can intercept passwords sent in cleartext and conduct a man-in-...
CVE-2020-29381
PUBLISHED: 2020-11-29
An issue was discovered on V-SOL V1600D V2.03.69 and V2.03.57, V1600D4L V1.01.49, V1600D-MINI V1.01.48, V1600G1 V2.0.7 and V1.9.7, and V1600G2 V1.1.4 OLT devices. Command injection can occur in "upload tftp syslog" and "upload tftp configuration" in the CLI via a crafted filename...
CVE-2020-29382
PUBLISHED: 2020-11-29
An issue was discovered on V-SOL V1600D V2.03.69 and V2.03.57, V1600G1 V2.0.7 and V1.9.7, and V1600G2 V1.1.4 OLT devices. A hardcoded RSA private key (specific to V1600D, V1600G1, and V1600G2) is contained in the firmware images.