CERT/CC

Subscribe to CERT/CC hírcsatorna
CERT publishes vulnerability advisories called "Vulnerability Notes." Vulnerability Notes include summaries, technical details, remediation information, and lists of affected vendors. Many vulnerability notes are the result of private coordination and disclosure efforts.
Frissítve: 2 óra 17 perc
2022. június 21.

VU#142546: SMA Technologies OpCon UNIX agent adds the same SSH key to all installations

Overview

SMA Technologies OpCon UNIX agent adds the same SSH key on every installation and subsequent updates. An attacker with access to the private key can gain root access on affected systems.

Description

During OpCon UNIX agent installation and updates, an SSH public key is added to the root account's authorized_keys file. The corresponding private key titled sma_id_rsa is included with the installation files and is not encrypted with a passphrase. Removal of the OpCon software does not remove the entry from the authorized_keys file.

Impact

An attacker with access to the private key included with the OpCon UNIX agent installation files can gain SSH access as root on affected systems.

Solution Remove private key

SMA Technologies has provided a tool to address the issue.

Another option is to manually remove the SSH key entry from root's authorized_keys file. The key can be identified by its fingerprints:

SHA256:qbgTVNkLGI5G7erZqDhte63Vpw+9g88jYCxMuh8cLeg MD5:f1:6c:c9:ba:21:66:ce:7c:5a:55:e2:4d:07:72:cc:31

Depending on the shell and operating system there are various ways to generate fingerprints for public keys listed in authorized_keys.

Upgrade

SMA Technologies reports that "We have updated our UNIX agent version 21.2 package to no longer include (and also remove) any existing vulnerability."

Acknowledgements

Thanks to Nick Holland at Holland Consulting for researching and reporting this vulnerability.

This document was written by Kevin Stephens.

2022. május 9.

VU#473698: CVE-2022-30295 - uClibc, uClibc-ng Libraries Have Monotonically Increasing DNS Transaction ID

Overview

The uClibc and uClibc-ng libraries are vulnerable to DNS cache poisoning due to the use of predicatble DNS transaction IDs when making DNS requests. This vulnerability can allow an attacker to perform DNS cache poisoning attacks against a vulnerable environment.

Description

The uClibc and the Uclibc-ng software are lightweight C standard libraries intended for use in embedded systems and mobile devices. The uClibc library has not been updated since May of 2012. The newer uClibc-ng is the currently maintained fork of uClibc, as announced on the OpenWRT mailing list in July 2014.

Researchers at the Nozomi Networks Security Research Team discovered that all existing versions of uClibc and uClibc-ng libraries are vulnerable to DNS cache poisoning. These libraries do not employ any randomization in the DNS Transaction ID (DNS TXID) field when creating a new DNS request. This can allow an attacker to send maliciously crafted DNS packets to corrupt the DNS cache with invalid entries and redirect users to arbitrary sites. As uClibc and uClibc-ng are used in devices such as home routers and firewalls, an attacker can perform attacks against multiple users in a shared network environment that relies on DNS responses from the vulnerable device.

The DNS cache poisoning scenarios and defenses are discussed in IETF RFC5452.

Impact

The lack of DNS response validation can allow an attacker to use unsolicited DNS responses to poison the DNS cache and redirect users to malicious sites.

Solution Develop and apply updates

If your vendor has developed a patched version of software to address this issue, apply the updates provided by your vendor. If you have a forked or customized version of uClibc or uClibc-ng, develop a patch to ensure the dns_lookup function provides adequate randomization of DNS TXID's while making DNS requests.

Follow security best practices

Consider the following security best-practices to protect DNS infrastructure:

  • Prevent direct exposure of IoT devices and lightweight devices over the Internet to minimize attacks against a caching DNS server.
  • Provide secure DNS recursion service with features such as DNSSEC validation and the interim 0x20-bit encoding as part of enterprise DNS recursion services where applicable.
  • Implement a Secure By Default configuration suitable for your operating environment (e.g., disable caching on embedded IoT devices when an upstream caching resolver is available).
Acknowledgements

Thanks to the Nozomi Networks Security Research Team for this report

This document was written by Vijay Sarvepalli and Timur Snoke.

2022. április 28.

VU#730007: Tychon is vulnerable to privilege escalation due to OPENSSLDIR location

Overview

Tychon contains a privilege escalation vulnerability due to the use of an OPENSSLDIR variable that specifies a location where an unprivileged Windows user may be able to place files.

Description

Tychon includes an OpenSSL component that specifies an OPENSSLDIR variable as a subdirectory that my be controllable by an unprivileged user on Windows. Tychon contains a privileged service that uses this OpenSSL component. A user who can place a specially-crafted openssl.cnf file at an appropriate path may be able to achieve arbitrary code execution with SYSTEM privileges.

Impact

By placing a specially-crafted openssl.cnf in a location used by Tychon, an unprivileged user may be able to execute arbitrary code with SYSTEM privileges on a Windows system with the vulnerable Tychon software installed.

Solution Apply an update

This issue is addressed in Tychon 1.7.857.82

Acknowledgements

This document was written by Will Dormann.

2022. április 28.

VU#411271: Qt allows for privilege escalation due to hard-coding of qt_prfxpath value

Overview

Prior to version 5.14, Qt hard-codes the qt_prfxpath value to a fixed value, which may lead to privilege escalation vulnerabilities in Windows software that uses Qt.

Description

Prior to version 5.14, Qt hard-codes the qt_prfxpath value to a value that reflects the path where Qt exists on the system that was used to build Qt. For example, it may refer to a specific subdirectory within C:\Qt\, which is the default installation location for Qt on Windows. If software that is built with Qt runs with privileges on a Windows system, this may allow for privilege escalation due to the fact that Windows by default allows unprivileged users to create subdirectories off of the root C:\ drive location.

In 2015, a patch was made to windeployqt to strip out any existing qt_prfxpath value from Qt5Core.dll. If Windows software that uses Qt prior to version 5.14 is not properly packaged using windeployqt, then it may be vulnerable to privilege escalation.

Impact

By placing a file in an appropriate location on a Windows system, an unprivileged attacker may be able to execute arbitrary code with the privileges of the software that uses Qt.

Solution Apply an update

This issue is addressed in Qt 5.14. Starting with this version, Qt no longer hard-codes the qt_prfxpath value in Qt5Core.dll.

Run windeployqt to prepare Windows Qt software for deployment

The windeployqt utility will replace the qt_prfxpath value in the Qt core DLL with the value of ., which helps prevent this path from being used to achieve privilege escalation.

Acknowledgements

This document was written by Will Dormann.

2022. március 31.

VU#970766: Spring Framework insecurely handles PropertyDescriptor objects with data binding

Overview

The Spring Framework insecurely handles PropertyDescriptor objects, which may allow a remote, unauthenticated attacker to execute arbitrary code on a vulnerable system.

Description

The Spring Framework is a Java framework that can be used to create applications such as web applications. Due to improper handling of PropertyDescriptor objects used with data binding, Java applications written with Spring may allow for the execution of arbitrary code.

Impact

By providing crafted data to a Spring Java application, such as a web application, an attacker may be able to execute arbitrary code with the privileges of the affected application. Depending on the application, exploitation may be possible by a remote attacker without requiring authentication.

Solution Apply an update

This issue is addressed in Spring Framework 5.3.18 and 5.2.20. Please see the Spring Framework RCE Early Announcement for more details.

Acknowledgements

This issue was publicly disclosed by heige.

This document was written by Will Dormann