Security News


 Vulnerability News SecurityWeek Feed
 
  • VU#290915: F5 BIG-IP contains multiple vulnerabilities including unauthenticated remote command execution


    Overview

    F5 BIG-IP provides a Traffic Management User Interface (TMUI), also referred to as the Configuration utility, that has multiple vulnerabilities including a remotely exploitable command injection vulnerability that can be used to execute arbitrary commands and subsequently take control of a vulnerable system.

    Description

    F5 BIG-IP devices provide load-balancing capability to application services such as HTTP and DNS. The F5 BIG-IP TMUI management web interface improperly neutralizes untrusted user input and can be abused by unauthenticated remote attackers to perform malicious activities such as cross-site scripting (XSS), cross-site request forgery (CSRF), and command injection CWE-74. F5 has also announced that BIG-IP devices do not properly enforce access controls to sensitive configuration files that be read and overwritten by an authenticated user via Secure Copy (SCP). The vulnerability identified by CVE-2020-0592 can be abused to achieve arbitrary code execution on the target device with root privileges.

    Underlying causes and factors in these vulnerabilities include:

    F5 recommends that the TMUI web interface should be accessible only from a secure or an out-of-band network and not directly from the Internet (K13092). However, many installations, as observed by Bad Packets, do not seem to follow this recommendation.

    Impact

    An unauthenticated attacker with network access to the TMUI may be able to execute arbitrary system commands, create or delete files, disable services, and subsequently execute arbitrary code with high privileges such as root. An authenticated user is also be able to perform unexpected activities such as changing configuration files on a vulnerable device.

    Solution

    Apply updates

    F5 has provided updated software for the several impacted versions of BIG-IP devices. Note that BIG-IP appliances as well as virtual instances are also vulnerable as identified by F5 advisories. It is highly recommended that you upgrade to the latest secure and stable software provided by F5. These updates are essential to your device's security, even if the TMUI is not accessible over the Internet. The upgrade reduces the risk to your device being compromised using CSRF or XSS attacks.

    Workarounds

    In many cases, an attack against BIG-IP's recent vulnerabilities require access to TMUI. Blocking or disabling access to TMUI from untrusted networks is highly recommended. F5 has also provided multiple temporary workaround options in their advisory.

    Acknowledgements

    Several of these vulnerabilities were reported by Mikhail Klyuchnikov of Positive Technologies, who worked with F5 on a coordinated disclosure.

    This document was written by Vijay Sarvepalli.

  • VU#576779: Netgear httpd upgrade_check.cgi stack buffer overflow


    Overview

    Multiple Netgear devices contain a stack buffer overflow in the httpd web server's handling of upgrade_check.cgi, which may allow for unauthenticated remote code execution with root privileges.

    Description

    Many Netgear devices contain an embedded web server, which is provided by the httpd process, to provide administrative capabilities. On multiple Netgear devices, this code fails to properly validate the header size provided to the upgrade_check.cgi handler. Despite copying the header to a fixed-size buffer on the stack, the vulnerable code copies an attacker-provided count of bytes from attacker-provided data. This allows for remote code execution by way of stack buffer overflow. This vulnerability is exacerbated by a number of issues:

    1. The httpd process runs with root privileges.
    2. Stack cookies, which can help prevent exploitation of stack buffer overflows, are not universally used in Netgear devices.
    3. Authentication is not required to reach the vulnerable code.
    4. The vulnerability occurs before Cross-Site Request Forgery (CSRF) token checking occurs.
    5. Target device fingerprinting can occur by visiting the /currentsetting.htm page on an affected device.

    Exploit code that targets 79 different Netgear devices is publicly available.

    Impact

    By convincing a user to visit a malicious or compromised website, a remote, unauthenticated attacker may be able to execute arbitrary code on a vulnerable device with root privileges.

    Solution

    Apply an update

    Netgear has provided updates for several vulnerable devices. Note that Netgear does not indicate when devices have reached an end of life (EOL) state. This may be difficult to determine if a vulnerable device may receive an update in the future.

    The CERT/CC has made a spreadsheet to more clearly indicate which devices have updates, and which devices may either be receiving an update in the future, or may possibly be unsupported.

    As outlined in the blog post It's Time to Retire Your Unsupported Things, you should factor the vendor's support life span into purchasing decisions. Vendors that indicate how long products will be supported should be preferred over those that do not clearly indicate how long a device will be supported. Similarly, vendors that clearly indicate when a product has reached EOL state should be preferred over vendors that do not.

    Acknowledgements

    This vulnerability was publicly disclosed by ZDI, who in turn credit d4rkn3ss from VNPT ISC. Additional analysis was provided by GRIMM.

    This document was written by Will Dormann.

  • VU#257161: Treck IP stacks contain multiple vulnerabilities


    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 embbeded 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.

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


    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.

  • VU#636397: IP-in-IP protocol routes arbitrary traffic by default


    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.

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


    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.

  • VU#534195: Bluetooth devices supporting LE and specific BR/EDR implementations are vulnerable to method confusion attacks


    Bluetooth Low Energy (BLE) and Basic Rate / Enhanced Data Rate (BR/EDR) Core Configurations are used for low-power short-range communications. To establish an encrypted connection, two Bluetooth devices must pair with each other using an agreed upon Association Model. It is possible for an unauthenticated, adjacent attacker to man-in-the-middle (MITM) attack the pairing process and force each victim device into a different Association Model, possibly granting the attacker the ability to initiate any Bluetooth operation on either attacked device.

  • VU#647177: Bluetooth devices supporting BR/EDR are vulnerable to impersonation attacks


    Bluetooth Basic Rate / Enhanced Data Rate (BR/EDR) Core Configurations are used for low-power short-range communications. To establish an encrypted connection, two Bluetooth devices must pair with each other using a link key. It is possible for an unauthenticated, adjacent attacker to impersonate a previously paired/bonded device and successfully authenticate without knowing the link key. This could allow an attacker to gain full access to the paired device by performing a Bluetooth Impersonation Attack (BIAS).

  • VU#366027: Samsung Qmage codec for Android Skia library does not properly validate image files


    The Samsung Qmage codec used in the Android Skia library does not properly validate image files. A number of memory corruption vulnerabilities allow an attacker to execute arbitrary code by causing a vulnerable system to parse a Qmage file.

  • VU#660597: Periscope BuySpeed is vulnerable to stored cross-site scripting


    Periscope BuySpeed version 14.5 is vulnerable to stored cross-site scripting, which may allow a local, authenticated attacker to execute arbitrary JavaScript.

  • VU#962085: Versiant LYNX Customer Service Portal is vulnerable to stored cross-site scripting


    The Versiant LYNX Customer Service Portal version 3.5.2 is vulnerable to stored cross-site scripting, which may allow a local, authenticated attacker to execute arbitrary JavaScript.

  • VU#944837: Vertiv Avocent UMG-4000 vulnerable to command injection and cross-site scripting vulnerabilities


    The Vertiv Avocent Universal Management Gateway Model UMG-4000 is a data center management appliance. The web interface of the UMG-4000 is vulnerable to command injection, stored cross-site scripting (XSS), and reflected XSS, which may allow an authenticated attacker with administrative privileges to remotely execute arbitrary code.

  • VU#354840: Microsoft Windows Type 1 font parsing remote code execution vulnerabilities


    Microsoft Windows contains two vulnerabilities in the parsing of Adobe Type 1 fonts, which may allow a remote, unauthenticated attacker to execute arbitrary code on a vulnerable system.

  • VU#425163: Machine learning classifiers trained via gradient descent are vulnerable to arbitrary misclassification attack


    Overview

    Machine learning models trained using gradient descent can be forced to make arbitrary misclassifications by an attacker that can influence the items to be classified. The impact of a misclassification varies widely depending on the ML model's purpose and of what systems it is a part.

    Description

    This vulnerability results from using gradient descent to determine classification of inputs via a neural network. As such, it is a vulnerability in the algorithm. In plain terms, this means that the currently-standard usage of this type of machine learning algorithm can always be fooled or manipulated if the adversary can interact with it. What kind or amount of interaction an adversary needs is not always clear, and some attacks can be successful with only minor or indirect interaction. However, in general more access or more interaction options reduce the effort required to fool the machine learning algorithm. If the adversary has information about some part of the machine learning process (training data, training results, model, or operational/testing data), then with sufficient effort the adversary can craft an input that will fool the machine learning tool to yield a result of the adversary's choosing. In instantiations of this vulnerability that we are currently aware of, "sufficient effort" ranges widely, between seconds and weeks of commodity compute time.

    Within the taxonomy by Kumar et al., such misclassifications are either perturbation attacks or adversarial examples in the physical domain. There are other kinds of failures or attacks related to ML systems, and other ML systems besides those trained via gradient descent. However, this note is restricted to this specific algorithm vulnerability. Formally, the vulnerability is defined for the following case of classification.

    Let \(x\) be a feature vector and \(y\) be a class label. Let \(L\) be a loss function, such as cross entropy loss. We wish to learn a parameterization vector \(\theta\) for a given class of functions \(f\) such that the expected loss is minimized. Specifically, let

    \[\theta_{\star} = min_\theta \mathop{\mathbb{E}}_{x,y} L\left(f\left(\theta, x\right), y\right) \]

    In the case where \(f\left(\theta,x\right)\) is a neural network, finding the global minimizer \(\theta_{\star}\) is often computationally intractable. Instead, various methods are used to find \(\hat{\theta}\) which is a "good enough" approximation. We refer to \(f\left(\hat{\theta}, .\right)\) as the fitted neural network.

    If stochastic gradient descent is used to find \(\hat{\theta}\) for the broadly defined set of \(f\left(\theta,x\right)\) representing neural networks, then the fitted neural network \(f\left(\hat{\theta}, .\right)\) is vulnerable to adversarial manipulation.

    Specifically, it is possible to take \(f\left(\hat{\theta}, .\right)\) and find an \(x'\) such that the difference between \(x\) and \(x'\) is smaller than some arbitrary \(\epsilon\) and yet \(f\left(\hat{\theta}, x\right)\) has the label \(y\) and \(f\left(\hat{\theta}, x'\right)\) has an arbitrarily different label \(y'\).

    The uncertainty of the impact of this vulnerability is compounded because practitioners and vendors do not tend to disclose what machine learning algorithms they use. However, training neural networks by gradient descent is a common technique. See also the examples in the impact section.

    Impact

    An attacker can interfere with a system which uses gradient descent to change system behavior. As an algorithm vulnerability, this flaw has a wide-ranging but difficult-to-fully-describe impact. The precise impact will vary with the application of the ML system. We provide three illustrative examples; these should not be considered exhaustive.

    • Automatic speech recognition can be forced to erroneously transcribe an audio clip, and the attacker can freely pick the target transcription if they can pick the audio clip.
    • Facial recognition can be forced to erroneously identify faces across many photographs, in different lightings, by use of physical eyeglass frames or manipulation of the source photo. The attacker can choose an arbitrary target identity of the misclassification.
    • Tesla autopilot in March 2019 had a demonstrated vulnerability (as in, on a closed road course, the attack works) where the car can be forced to change lanes arbitrarily based on stickers placed on the road surface. In January 2020, similar attacks were demonstrated using projections, such as from airborne drones, rather than stickers.

    Solution

    The CERT/CC is currently unaware of a specific practical solution to this problem. To defend generally, do both of:
    1. Adversarial training and testing of ML models. If a model must be exposed to adversarial input, the only well-tested defense against this kind of adversarial attack is adversarial training: using adversarially perturbed examples as part of the neural network's training regimen. When used for training, these examples increase the model's robustness against adversarial attack. Such training significantly increases the difficulty of attacking the model, but it does not guarantee the model is not vulnerable. Test your machine learning algorithm against known attacks. Libraries featuring reference implementations of popular attacks and defenses include Cleverhans, Foolbox, and the Adversarial Robustness Toolkit (ART).

    2. Standard defense in depth. A machine learning tool is not different from other software in this regard. Any tool should be deployed in an ecosystem that supports and defends it from adversarial manipulation. For machine learning tools specifically designed to serve a cybersecurity purpose, this is particularly important, as they are exposed to adversarial input as part of their designed tasking. See CMU/SEI-2019-TR-005 for more information on evaluating machine learning tools for cybersecurity.

    Other proposed solutions, which rely on either pre-processing the data or simply obfuscating the gradient of the loss, do not work when your adversary is aware that you are attempting those mitigations.

    Acknowledgements

    See Papernot et al. (2016) Towards the Science of Security and Privacy in Machine Learning or Biggio and Roli (2018) Wild patterns: Ten years after the rise of adversarial machine learning for a brief history.

    This document was written by Allen Householder, Jonathan M. Spring, Nathan VanHoudnos, and Oren Wright.

  • VU#872016: Microsoft SMBv3 compression remote code execution vulnerability


    Overview

    Microsoft SMBv3 contains a vulnerability in the handling of compression, which may allow a remote, unauthenticated attacker to execute arbitrary code on a vulnerable system. This vulnerability is being referred to as "SMBGhost and CoronaBlue."

    Description

    Microsoft Server Message Block 3.1.1 (SMBv3) contains a vulnerability in the way that it handles connections that use compression. This vulnerability may allow a remote, unauthenticated attacker to execute arbitrary code on a vulnerable system. It has been reported that this vulnerability is "wormable."

    Impact

    By connecting to a vulnerable Windows machine using SMBv3, or by causing a vulnerable Windows system to initiate a client connection to a SMBv3 server, a remote, unauthenticated attacker may be able to execute arbitrary code with SYSTEM privileges on a vulnerable system.

    Solution

    Apply an update

    This issue has been addressed in the Microsoft update for CVE-2020-0796. Please also consider the following workarounds:

    Disable SMBv3 compression

    According to Microsoft Security Advisory ADV200005 :


      You can disable compression to block unauthenticated attackers from exploiting the vulnerability against an SMBv3 Server with the PowerShell command below.

      Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" DisableCompression -Type DWORD -Value 1 -Force

      Notes:

      1. No reboot is needed after making the change.
      2. This workaround does not prevent exploitation of SMB clients.

      You can disable the workaround with the PowerShell command below.

      Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" DisableCompression -Type DWORD -Value 0 -Force

    Block inbound and outbound SMB

    Consider blocking outbound SMB connections (TCP port 445 for SMBv3) from the local network to the WAN. Also ensure that SMB connections from the internet are not allowed to connect inbound to an enterprise LAN.

    Acknowledgements

    This document was written by Will Dormann.