Device Security Newsletter - July 2020
At a Glance
We hope you are healthy and safe during these troubling times. June had one of the most interesting vulnerabilities this year so far, as well as a fair amount of cyber security activity - so let's get to it!
Hundreds of millions of devices worldwide could be vulnerable to remote attacks due to security vulnerabilities in the Treck TCP/IP stack dubbed Ripple20. Treck TCP/IP is a high-performance TCP/IP protocol suite designed for embedded systems. The list of affected vendors includes HP, Schneider Electric, Intel, Rockwell Automation, Caterpillar, and Baxter.
The Kaiji botnet that was targeting Linux-based IoT devices is evolving and now targeting Docker servers! Botnet operators are looking for Docker servers that expose port 2375, which is one of the two ports of the Docker API and used for unauthenticated and unencrypted communications.
And finally, NIST once more steps up to the plate with its new Cybersecurity Guidance for Manufacturers of IoT Devices. NISTIR 8259 provides device manufacturers of new IoT devices with a map of recommended activities to help address cybersecurity in the product development process, while NISTIR 8259A sets out a core baseline of security requirements generally needed to support commonly used cybersecurity controls.
As always, the VDOO team is here to answer any questions you may have about achieving optimal security for your connected products in general, or about any of the issues listed below in particular. Our thoughts are with our readers so keep well!
New XORDDoS, Kaiji DDoS botnet variants target Docker servers The Kaiji botnet was discovered by security researcher MalwareMustDie and the experts at Intezer Labs in April while it was targeting Linux-based IoT devices via SSH brute-force attacks. According to the experts, both threats are linked to China, the variants recently spotted by Trend Micro has recently also targeted Docker servers. Botnet operators are looking for Docker servers that expose port 2375, which is one of the two ports of the Docker API and it’s used for unauthenticated and unencrypted communications.
Vulnerabilities in Connected Devices
Hundreds of millions of devices worldwide could be vulnerable to remote attacks due to security vulnerabilities in the Treck TCP/IP stack dubbed Ripple20. Treck TCP/IP is a high-performance TCP/IP protocol suite designed for embedded systems. Researchers at Israel-based cybersecurity company JSOF have discovered 19 critical and high-severity security flaws. The zero-day flaws reside in a popular low-level TCP/IP software library developed by Treck, Inc. that is used in devices made by more than 100 organizations in various industries. Researchers revealed that the list of affected vendors includes HP, Schneider Electric, Intel, Rockwell Automation, Caterpillar, and Baxter.
F5 Networks has addressed a critical remote code execution (RCE) vulnerability, tracked as CVE-2020-5902, that resides in undisclosed pages of Traffic Management User Interface (TMUI) of the BIG-IP product. The BIG-IP product is an application delivery controller (ADC), it is used by government agencies and major business, including banks, services providers and IT giants like Facebook, Microsoft and Oracle. F5 Networks says the BIG-IP devices are used on the networks of 48 companies included in the Fortune 50 list. US Cyber Command is urging organizations using the F5 product to immediately patch their installs.
A critical vulnerability in traffic light controllers designed by SWARCO could have been exploited by hackers to disrupt traffic lights. SWARCO is the world’s largest manufacturer of signal heads and the number two internationally for reflective glass beads. Researchers at ProtectEM discovered that SWARCO’s CPU LS4000 traffic light controllers have an open port designed for debugging that could be exploited by attackers. The flaw, tracked as CVE-2020-12493, is an “improper access control” issue that could allow hackers to grant root access to the device without access control via network.
Three students of the Florida Institute of Technology have discovered authentication and access control design flaws in 16 models of IoT (Internet of Things) cameras. These flaws could allow someone to access video and audio feeds from the devices, essentially stalking the owners or other users of the device without having to engage in skillful hacking. The team of researchers presented a paper where they describe an attack methodology that demonstrates the possibility to persist even after the revocation of the user access. Moreover, they evaluate the susceptibility of 19 widely used IoT cameras and smart doorbell devices, finding that 16 of them are vulnerable to exploitation.
Security experts disclosed a new UPnP vulnerability, named Call Stranger, that affects billions of devices and could be exploited for various malicious activities. that affects billions of devices, it could be exploited by attackers to carry out multiple malicious activities, including distributed denial-of-service (DDoS) attacks and data exfiltration. The vulnerability, which is tracked as CVE-2020-12695 and is referred to as CallStranger, could be abused by remote, unauthenticated attackers to carry out DDoS assaults, bypass security systems and exfiltrate data, and scan internal ports. Experts pointed out that despite UPnP services should not be exposed on the Internet, a recent Shodan scan revealed the presence of millions of devices exposing them online.
CROSSTALK - speculative execution enables attackers to leak sensitive information also across cores on many Intel CPUs
Speculative execution enables attackers to leak sensitive information also across cores on many Intel CPUs, bypassing all the existing intra-core mitigations against prior speculative (or transient) execution attacks such Spectre, Meltdown, etc. Until now, all the attacks assumed that attacker and victim were sharing the same core, so that placing mutually untrusting code on different cores would thwart such attacks. Instead, we present a new transient execution vulnerability, which Intel refers to as “Special Register Buffer Data Sampling” or SRBDS (CVE-2020-0543), enabling attacker-controlled code executing on one CPU core to leak sensitive data from victim software executing on a different core. Intel has implemented its mitigation for the SRBDS vulnerability in a microcode update distributed to software vendors on Tuesday June 9, 2020 or earlier. The mitigation locks the entire memory bus before updating the staging buffer and only unlocks it after clearing its content.
The Industrial Control Systems' Computer Emergency Response Team - a unit of Department of Homeland Security's Cybersecurity and Infrastructure Security Agency - issued six alerts about vulnerabilities in medical devices from Baxter, BD and Biotronik. Some of the flaws - if exploited - could result in compromises of patient information and allow attackers to alter data or system configurations or launch a distributed denial-of-service attack.
- Baxter - Vulnerabilities in this medication gear include use of hard-coded passwords, cleartext transmission of sensitive data, missing encryption of sensitive data, improper access control, exposure of resource to wrong sphere and improper input validation.
- BD Alaris PCU infusion pump system - Successful exploitation of this vulnerability could allow an attacker to cause a DDoS on the target system and could cause the BD Alaris PCU to disconnect from the facility's wireless network.
- Biotronick CardioMessenger II - The vulnerabilities include improper authentication, cleartext transmission of sensitive information, missing encryption of sensitive data and storing passwords in a recoverable format.
Regulations for Connected DevicesIoT Regulation
The first, NISTIR 8259, provides device manufacturers of new IoT devices with a map of recommended activities to help address cybersecurity in the product development process. There are six recommended activities, four of which address identifying and implementing appropriate security controls in the pre-market phase and two that focus on meeting customers’ cybersecurity needs once the device is on the market. These activities focus on identifying a device’s customers and their cybersecurity needs, meeting those cybersecurity needs and planning for how cybersecurity will be addressed once the device is out on the market.
NISTIR 8259A sets out a core baseline of security requirements generally needed to support commonly used cybersecurity controls. At a high level, this core baseline requires the following: Device identification: The individual device can be identified both logically and physically. Device configuration: An IoT device’s software configuration can be changed and such changes can only be performed by authorized entities. Data protection: The data from an IoT device is protected from unauthorized access or modification, both in storage and transit. Logical access interfaces: Only authorized entities should have logical access to local and network interfaces, and the protocols and services used by those interfaces. Software update: The IoT device’s software can be updated by authorized entities. Cybersecurity state awareness: An IoT device can report on its cybersecurity state to authorized entities only.
Digital Container Shipping Association (DCSA), a non-profit group established to further digitalisation of container shipping technology standards, in conjunction with its nine member carriers, published IoT connectivity interface standards for shipping containers. The new standards are the first of three planned IoT standards releases addressing the connectivity requirements for reefer and dry containers, as well as the RFID registration of these containers. Future releases will focus on data structure and handling, physical device specifications as well as security and access management.
This is What VDOO
In case you missed our latest blog posts, you can read them on our website - Medical Device (IoMT) Cybersecurity 101 and The Case of BusyBox Wget: A Long Overdue Fix, both by Leo Dorrendorf, VDOO's Security Architecture Team Leader.
We will be sponsoring our second Archimedes webinar next week (July 22 at noon CST). This session will be led by Ken Hoyme, Director of Product Security at Boston Scientific, and is part of the Center for Medical Device Security's 2020 Leadership Workshop Webinar series.
Share this post