Author Archives: CERT

Overview

Treck IP stack implementations for embedded systems are affected by multiple vulnerabilities. This set of vulnerabilities was researched and reported by JSOF, who calls them Ripple20.

Description

Treck IP network stack software is designed for and used in a variety of embedded systems. The software can be licensed and integrated in various ways, including compiled from source, licensed for modification and reuse and finally as a dynamic or static linked library. Treck IP software contains multiple vulnerabilities, most of which are caused by memory management bugs. For more details on the vulnerabilities introduced by these bugs, see Treck’s Vulnerability Response Information and JSOF’s Ripple20 advisory.

Historically-related KASAGO TCP/IP middleware from Zuken Elmic (formerly Elmic Systems) is also affected by some of these vulnerabilities.

These vulnerabilities likely affect industrial control systems and medical devices. Please see ICS-CERT Advisory ICSA-20-168-01 for more information.

Impact

The impact of these vulnerabilities will vary due to the combination of build and runtime options used while developing different embedded systems. This diversity of implementations and the lack of supply chain visibility has exasperated the problem of accurately assessing the impact of these vulnerabilities. In summary, a remote, unauthenticated attacker may be able to use specially-crafted network packets to cause a denial of service, disclose information, or execute arbitrary code.

Solution

Apply updates

Update to the latest stable version of Treck IP stack software (6.0.1.67 or later). Please contact Treck at security@treck.com. Downstream users of embedded systems that incorporate Treck IP stacks should contact their embedded system vendor.

Block anomalous IP traffic

Consider blocking network attacks via deep packet inspection. In some cases, modern switches, routers, and firewalls will drop malformed packets with no additional configuration. It is recommended that such security features are not disabled. Below is a list of possible mitigations that can be applied as appropriate to your network environment.

• Normalize or reject IP fragmented packets (IP Fragments) if not supported in your environment
• Disable or block IP tunneling, both IPv6-in-IPv4 or IP-in-IP tunneling if not required
• Block IP source routing and any IPv6 deprecated features like routing headers (see also VU#267289)
• Enforce TCP inspection and reject malformed TCP packets
• Block unused ICMP control messages such MTU Update and Address Mask updates
• Normalize DNS through a secure recursive server or application layer firewall
• Ensure that you are using reliable OSI layer 2 equipment (Ethernet)
• Provide DHCP/DHCPv6 security with feature like DHCP snooping
• Disable or block IPv6 multicast if not used in switching infrastructure

Further recommendations are available here.

Detect anomalous IP traffic

Suricata IDS has built-in decoder-event rules that can be customized to detect attempts to exploit these vulnerabilities. See the rule below for an example. A larger set of selected vu-257161.rules are available from the CERT/CC Github repository.

#IP-in-IP tunnel with fragments
alert ip any any -> any any (msg:"VU#257161:CVE-2020-11896, CVE-2020-11900 Fragments inside IP-in-IP tunnel https://kb.cert.org/vuls/id/257161"; ip_proto:4; fragbits:M; sid:1367257161; rev:1;)

Acknowledgements

Moshe Kol and Shlomi Oberman of JSOF https://jsof-tech.com researched and reported these vulnerabilities. Treck worked closely with us and other stakeholders to coordinate the disclosure of these vulnerabilities.

This document was written by Vijay Sarvepalli.

Continue reading VU#257161: Treck IP stacks contain multiple vulnerabilities→

Overview

The Universal Plug and Play (UPnP) protocol in effect prior to April 17, 2020 can be abused to send traffic to arbitrary destinations using the SUBSCRIBE functionality.

Description

The UPnP protocol, as specified by the Open Connectivity Foundation (OCF), is designed to provide automatic discovery and interaction with devices on a network. The UPnP protocol is designed to be used in a trusted local area network (LAN) and the protocol does not implement any form of authentication or verification.

Many common Internet-connected devices support UPnP, as noted in previous research from Daniel Garcia (VU#357851) and Rapid7. Garcia presented at DEFCON 2019 and published a scanning and portmapping tool. The UPnP Device Protection service was not widely adopted.

A vulnerability in the UPnP SUBSCRIBE capability permits an attacker to send large amounts of data to arbitrary destinations accessible over the Internet, which could lead to a Distributed Denial of Service (DDoS), data exfiltration, and other unexpected network behavior. The OCF has updated the UPnP specification to address this issue. This vulnerability has been assigned CVE-2020-12695 and is also known as Call Stranger.

Although offering UPnP services on the Internet is generally considered to be a misconfiguration, a number of devices are still available over the Internet according to a recent Shodan scan.

Impact

A remote, unauthenticated attacker may be able to abuse the UPnP SUBSCRIBE capability to send traffic to arbitrary destinations, leading to amplified DDoS attacks and data exfiltration. In general, making UPnP available over the the Internet can pose further security vulnerabilities than the one described in this vulnerability note.

Solution

Affected devices

A number of devices have been identified as vulnerable by the security researcher and have been posted at the CallStranger website. There is more information on affected devices in Tenable’s blog on cve-2020-12695.

Apply updates

Vendors are urged to implement the updated specification provided by the OCF.. Users should monitor vendor support channels for updates that implement the new SUBSCRIBE specification.

Disable or Restrict UPnP

Disable the UPnP protocol on Internet-accessible interfaces. Device manufacturers are urged to disable the UPnP SUBSCRIBE capability in their default configuration and to require users to explicitly enable SUBSCRIBE with any appropriate network restrictions to limit its usage to a trusted local area network.

IDS Signature

This Surricata IDS rule looks for any HTTP SUBSCRIBE request to what is likely to be an external network (i.e., not RFC1918 and RFC4193 addresses). Network administrators and ISPs can deploy this signature at the Internet access point to detect any anomalous SUBSCRIBE requests reaching their users.

alert http any any -> ![fd00::/8,192.168.0.0/16,10.0.0.0/8,172.16.0.0/12] any (msg:"UPnP SUBSCRIBE request seen to external network VU#339275: CVE-
2020-12695 https://kb.cert.org "; content: "subscribe"; nocase; http_method; sid:1367339275;)

Acknowledgements

This vulnerability was reported by Yunus Çadirci from EY Turkey.

This document was written by Vijay Sarvepalli.

Continue reading VU#339275: Universal Plug and Play (UPnP) SUBSCRIBE can be abused to send traffic to arbitrary destinations→

Overview

IP Encapsulation within IP (RFC2003 IP-in-IP) can be abused by an unauthenticated attacker to unexpectedly route arbitrary network traffic through a vulnerable device.

Description

IP-in-IP encapsulation is a tunneling protocol specified in RFC 2003 that allows for IP packets to be encapsulated inside another IP packets. This is very similar to IPSEC VPNs in tunnel mode, except in the case of IP-in-IP, the traffic is unencrypted. As specified, the protocol unwraps the inner IP packet and forwards this packet through IP routing tables, potentially providing unexpected access to network paths available to the vulnerable device. An IP-in-IP device is considered to be vulnerable if it accepts IP-in-IP packets from any source to any destination without explicit configuration between the specified source and destination IP addresses. This unexpected Data Processing Error (CWE-19) by a vulnerable device can be abused to perform reflective DDoS and in certain scenarios used to bypass network access control lists. Because the forwarded network packet may not be inspected or verified by vulnerable devices, there are possibly other unexpected behaviors that can be abused by an attacker on the target device or the target device’s network environment.

Impact

An unauthenticated attacker can route network traffic through a vulnerable device, which may lead to reflective DDoS, information leak and bypass of network access controls.

Solution

Apply updates

The CERT/CC recommends that you apply the latest patch provided by the affected vendor that addresses this issue. Review the vendor information below or contact your vendor or supplier for specific mitigation advice. If a device has the ability to disable IP-in-IP in its configuration, it is recommended that you disable IP-in-IP in all interfaces that do not require this feature. Device manufacturers are urged to disable IP-in-IP in their default configuration and to require their customers to explicitly configure IP-in-IP as and when needed.

Disable IP-in-IP

Users can block IP-in-IP packets by filtering IP protocol number 4. Note this filtering is for the IPv4 Protocol (or IPv6 Next Header) field value of 4 and not IP protocol version 4 (IPv4).

Proof of Concept (PoC)

A proof-of-concept originally written by Yannay Livneh is available in the CERT/CC PoC respository.

Detection Signature (IDS)

This Snort IDS rule looks for any IP-in-IP traffic, whether intentional or not seen at upstream network path of a vulnerable device. This Snort or Suricata rule can be modified to apply filters that ignore sources and destinations that are allowed by policy to route IP-in-IP traffic.

alert ip any any -> any any (msg: "IP-in-IP Tunneling VU#636397 https://kb.cert.org"; ip_proto:4; sid: 1367636397; rev:1;)

Acknowledgements

Thanks to Yannay Livneh for reporting this issue to us.

This document was written by Vijay Sarvepalli.

Continue reading VU#636397: IP-in-IP protocol routes arbitrary traffic by default→

Overview

iOS, iPadOS, tvOS, watchOS, and macOS contain a double-free vulnerability in the GNU kernel’s lio_listio() function, which can allow a malicious application to achieve unsandboxed, kernel-level code execution.

Description

iOS, iPadOS, tvOS, watchOS, and macOS contain an a double-free vulnerability in the GNU kernel’s lio_listio() function. This can lead to triggering a use-after-free condition. This vulnerability can allow code execution with kernel privileges. This vulnerability is being used by the public unc0ver 5.0 jailbreak utility, which claims to support all devices from iOS 11 through 13.5, excluding versions 12.3-12.3.2 and 12.4.2-12.4.5. It is also reported that this jailbreak works on modern iOS devices that use a CPU that supports Pointer Authentication Code (PAC), which indicates that PAC does not prevent exploitation of this vulnerability.

It is reported that this vulnerability is a regression of the vulnerability known as LightSpeed.

Impact

By convincing a user to run a malicious application on a device running iOS, iPadOS, tvOS, watchOS, or macOS, an attacker may be able to achieve arbitrary code execution in the kernel that is not restricted by sandboxes or other OS protections.

Solution

Apply updates

This issue is addressed in the following OS updates from Apple:
macOS Catalina 10.15.5 Supplemental Update, Security Update 2020-003 High Sierra
tvOS 13.4.6
watchOS 6.2.6
iOS 13.5.1 and iPadOS 13.5.1

Acknowledgements

This document was written by Will Dormann.

Continue reading VU#127371: iOS, iPadOS, tvOS, watchOS, and macOS contain a double-free vulnerability in the XNU kernel lio_listio() function→

Bluetooth is a short-range wireless technology based off of a core specification that defines six different core configurations,including the Bluetooth Basic Rate/Enhanced Data Rate(BR/EDR)Core Configurations. Bluetooth BR/EDR is used for low-power sho… Continue reading VU#647177: Bluetooth devices supporting BR/EDR are vulnerable to impersonation attacks→

Bluetooth is a short-range wireless technology based off of a core specification that defines six different core configurations,including the Bluetooth Low Energy(BLE)Core Configuration. Like Bluetooth Classic(BR/ER),BLE is used for low-power short-ran… Continue reading VU#534195: Bluetooth devices supporting LE and specific BR/EDR implementations are vulnerable to method confusion attacks→

The Samsung May 2020 Android Security Update notes that”a possible memory overwrite vulnerability in Quram qmg library allows possible remote arbitrary code execution.”Samsung identifies this vulnerability as SVE-2020-16747,more commonly known as CVE-2… Continue reading VU#366027: Samsung Qmage codec for Android Skia library does not properly validate image files→

Periscope BuySpeed is a”tool to automate the full procure-to-pay process efficiently and intelligently”. BuySpeed version 14.5 is vulnerable to stored cross-site scripting,which could allow a local,authenticated attacker to store arbitrary JavaScript w… Continue reading VU#660597: Periscope BuySpeed is vulnerable to stored cross-site scripting→

The Versiant LYNX Customer Service Portal(CSP)is a”full-service customer portal that provides real-time information to terminal operators on the status of shipments into and out of a marine container terminal”. The LYNX CSP,version 3.5.2,is vulnerable … Continue reading VU#962085: Versiant LYNX Customer Service Portal is vulnerable to stored cross-site scripting→

The Vertiv Avocent UMG-4000 contains multiple vulnerabilities that could allow an authenticated attacker with administrative privileges to remotely execute arbitrary code. The web interface does not sanitize input provided from the remote client,making… Continue reading VU#944837: Vertiv Avocent UMG-4000 vulnerable to command injection and cross-site scripting vulnerabilities→