KRPweb.com

Overview

PDQ Deploy is a service intended for usage by system administrators for the deployment of software or updates to targeted machines within their network. PDQ Deploy uses "run modes" to deploy software to their target devices. The run mode "Deploy User" insecurely creates credentials on the target device. These credentials are deleted from the device following a full deployment of a software file, however, an attacker with access to the target device can compromise these credentials prior to deletion through common password tools such as Mimikatz. These credentials could then be used to gain administrator access on the target device, or to compromise any other device using these credentials that is enrolled through active directory and has previously had software deployed to it by PDQ Deploy.

Description

PDQ Deploy is a service intended for usage by system administrators and others for the deployment of software or updates to targeted machines within their network. PDQ Deploy has various configurations, including automated deployment and availability based deployments. PDQ Deploy also uses various "run modes" to deploy software to their target devices. The "Deploy User" run mode can use a domain or local account with administrator rights on the target computer during the deployment process.

The deployment process is as follows: 1: PDQ Deploy initiates an application deployment. 2: The central server connects to the target device remotely with the "Deploy User" credentials. 3: A local service is created on the device and is run as the selected domain or local user account specified as the deploy user. 4: PDQ follows the application deployment process, installing the requested software. 5: The service is removed from the remote device.

An attacker with access to the device can use a password dumping tool, such as Mimikatz, to dump these credentials during the deployment process, specifically during steps 2 to 4, prior to their deletion. If using a domain user, these credentials created by the Deploy User domain account are static and can be used to compromise any other device that is enrolled in PDQ Deploy through Active Directory sharing this user, allowing for lateral movement.

PDQ Deploy supports other "Run Modes" for use during the deployment process. These run modes alter how credentials are saved on the device. These include the "Local System" deploy mode, in which the service is ran as a Local System account. A Local System account has lower privileges than a domain account, but PDQ Deploy still uses the Deploy User Account to connect to the device and initiate the Local System account, resulting in the vulnerabilities still being present for that user.

Impact

An attacker with access to the PDQ Deploy service and the ability to execute common password tools such as Mimikatz can dump the Deploy User administrator credentials from a device during the deployment process, then use those credentials to either further compromise the current device, or move laterally and compromise other PDQ Deploy enrolled systems on the Active Directory system that share the user and use a domain account. The compromised machine must have been previously deployed to via PDQ Deploy.

Solution

The CERT/CC is creating this Vulnerability Note to advise and make users of PDQ Deploy aware of potential avenues of attack through the deploy service. System administrators that are using PDQ Deploy should employ LAPS to mitigate this vulnerability. System administrators could also follow the recommendations outlined in the How-to-Guides listed on the PDQ Deploy website. (https://help.pdq.com/hc/en-us/articles/360033877651-Adding-and-Using-Multiple-Credentials-in-PDQ-Deploy-Inventory) Additionally, alternate deploy modes could be used. The "Logged on User" deploy mode utilizes the active credentials of the device currently logged in to create the necessary services and deploy the requested software.This deploy mode does not create a service with the domain/local credentials, and as such, is an appropriate deployment mode to avoid the vulnerability. It should be noted this Run Mode is only available on the Enterprise mode, and requires user input to complete the deployment of the software.

Acknowledgements

Thanks to the reporter who wishes to remain anonymous. A French source validated and coordinated this vulnerability note and case with CERT/CC. This document was written by Christopher Cullen.

Overview

A command injection vulnerability has been identified in the Wi-Fi Test Suite, a tool developed by the WiFi Alliance, which has been found deployed on Arcadyan routers. This flaw allows an unauthenticated local attacker to exploit the Wi-Fi Test Suite by sending specially crafted packets, enabling the execution of arbitrary commands with root privileges on the affected routers.

Description

The Wi-Fi Test Suite, as described by its developer, was originally created by the Wi-Fi Alliance—a global non-profit industry association responsible for Wi-Fi standards—to support the development of certification programs and device certification. This software was not designed for use in production environments. However, it has been discovered in commercial router deployments, exposing a vulnerbility in the test code in production. The Wi-Fi Test Suite contains vulnerable code that is susceptible to command injection attacks. An attacker can exploit this vulnerability by sending specially crafted packets to a device running the Wi-Fi Test Suite, allowing them to execute commands with administrative (root) privileges.

CVE-2024-41992 It is possible for an unauthenticated local attacker to use specially crafted packets to execute commands as root.

Impact

An attacker who successfully exploits this vulnerability can gain full administrative control over the affected device. With this access, the attacker can modify system settings, disrupt critical network services, or reset the device entirely. These actions can result in service interruptions, compromise of network data, and potential loss of service for all users dependent on the affected network.

Solution

The CERT/CC recommends that vendors, who have included the Wi-Fi Test Suite, to update it to version >=9.0 or remove it entirely from production devices to reduce the risk of exploitation.

Acknowledgements

Thanks to the reporter Noam Rathaus from SSD Disclosure. This document was written by Timur Snoke.

Overview

A stack-based overflow vulnerability exists in the tinydhcp server in the Microchip Advanced Software Framework (ASF) that can lead to remote code execution.

Description

An implementation of DHCP in ASF fails input validation, thereby creating conditions for a stack-based overflow. The software is no longer supported by the vendor. Because this vulnerability is in IoT-centric code, it is likely to surface in many places in the wild.

CVE-2024-7490 There exists a vulnerability in all publicly available examples of the ASF codebase that allows for a specially crafted DHCP request to cause a stack-based overflow that could lead to remote code execution.

Impact

This vulnerability can be tested by sending a single DHCP Request packet to a multicast address. This vulnerability exists in the current version of ASF 3.52.0.2574 and all previous versions of the software. There are also multiple forks of the tinydhcp software in github that are also potentially susceptible to this vulnerability.

Solution

The CERT/CC is currently unaware of a practical solution to this problem other than replacing the tinydhcp service with another one that does not have the same issue.

Acknowledgements

Thanks to the reporter Andrue Coombes of Amazon Element55. This document was written by Timur Snoke.

Overview

A vulnerability in the user of hard-coded Platform Keys (PK) within the UEFI framework, known as PKfail, has been discovered. This flaw allows attackers to bypass critical UEFI security mechanisms like Secure Boot, compromising the trust between the platform owner and firmware and enabling manipulation of sensitive system settings.

Description

The UEFI standard establishes trust relationships using Public Key Infrastructure (PKI) between the platform owner, the platform firmware, and the operating system. Central to this process is the Platform Key (PK), which is designed to secure the connection between the platform owner and the platform firmware.

The platform owner enrolls the public half of the key (PKpub) into the platform firmware. The platform owner can later use the private half of the key (PKpriv) to change platform ownership or to enroll a Key Exchange Key. For UEFI, the recommended Platform Key format is RSA-2048. (Section 7.2.1 of the UEFI 2.3.1 Errata C standard)

The PKFail vulnerability highlights a critical flaw in the UEFI ecosystem. While the Platform Key is expected to originate from the Original Equipment Manufacturer (OEM) using a secure hardware security module (HSM), in practice, much of the UEFI software and drivers are developed by a complex network of supply-chain partners and Independent BIOS Vendors (IBVs). These components are often shared across multiple OEMs. In some cases, temporary test software keys, or "softkeys," which are hard-coded for ease of build and testing, inadvertently make their way into production firmware.

These softkeys, intended solely for compatibility testing and performance evaluation, are supposed to be untrusted and restricted in their usage. The current UEFI's key verification process is limited - it only checks against the keys in the local database, with no verification against the root Certificate Authority (CA) or special validation of extended attributes. Although keys cannot be self-signed, the lack of stringent verification allows these untrusted keys to be mistakenly included in production firmware.

Recent audits have uncovered that many OEM devices shipped with hard-coded, untrusted keys in their production UEFI firmware. Despite these keys often having attributes like "DO NOT TRUST," there is no programmatic safeguard or other validations (say attribute-based) to prevent their inclusion in final products. The compromise or leak of these private keys could have bad consequences, allowing attackers to sign malicious modules that execute with high privileges during the boot process, even if Secure Boot is enabled. This undermines the very purpose of signed software verification, leaving systems vulnerable to untrusted and malicious modules.

Compounding the issue, UEFI firmware is largely invisible to most Endpoint Detection and Response (EDR) software, making it difficult to audit and detect the use of compromised keys. Moreover, many UEFI implementations lack Remote Measurement or Auditing capabilities that could dynamically check the integrity of the key database via network resources.

Impact

An attacker with access to an undesired-yet-trusted test Platform Key's private portion can exploit it to sign malicious UEFI software, enabling the execution of code with the highest privileges during the early boot phases of a UEFI Secure Boot-protected system. A successful attack could lead to the following impacts:

• Invalidation or bypass of UEFI security features like SecureBoot.
• Installation of persistent software that cannot be easily detected or erased, that can also persist across reboots and potentially surviving OS reinstalls.
• Creation of backdoors and back communications channels to exfiltrate sensitive data.
• Interruption of system execution leading to device damage or permanent shutdown.

Solution

• Update UEFI Firmware: Ensure you install the latest stable version of UEFI firmware provided by your PC vendor or the reseller of your computing environment. Refer to the Vendor Information section below for specific resources and updates from vendors addressing these vulnerabilities.
• Use Researcher Tools for Impact Assessment: Utilize tools and information provided by Binarly to assess the impact of untrusted Platform Keys on your systems. These resources can help you conduct a thorough analysis of affected systems.
• Leverage Automatic Firmware Updates: If your operating system supports automatic or managed firmware updates (e.g., Linux Vendor Firmware Service, LVFS), regularly check for updates using fwupdmgr get-updates and apply them with fwupdmgr update or use Windows OEM supported mechanisms as appropriate. Keeping your firmware up to date is crucial in mitigating the risks associated with PKfail.

Acknowledgements

Thanks to Binarly for disclosing this vulnerability. This document was written by Vijay Sarvepalli.

Overview

Multiple hosted, outbound SMTP servers are vulnerable to email impersonation. This allows authenticated users and certain trusted networks to send emails containing spoofed sender information. Two vulnerabilities were identified that reduce the authentication and verification of the sender, provided by the combination of Sender Policy Framework (SPF) and Domain Key Identified Mail (DKIM). Domain-based Message Authentication, Reporting, and Conformance (DMARC) builds on SPF and DKIM, adding linkage to the author (FROM:) domain name, published policies for recipient handling of authentication failures, and reporting from receivers to senders to improve and monitor protection of the domain from fraudulent email (DMARC.org). An authenticated remote attacker can spoof the identity of a sender when sending emails using a hosted service provider.

Description

As identified in RFC 5321 #7.1, the SMTP protocol is inherently insecure and susceptible to spoofing the sender identity that is present in the various parts of the SMTP transaction. Various facilities, such as SPF and DKIM, continued to evolve to address these issues. SPF records identify the IP networks that are allowed to send email on behalf of a domain. Receiving servers can check SPF records to verify that incoming messages that appear to be from an organization are sent by permitted (allowed) networks. DKIM goes further in email security by providing a digital signature that verifies specific portions of the SMTP-relayed message, allowing to digitally assert specific information that is part of a message such as the FROM: address, subject, and date fields. While SPF verifies the network source of an email transaction, DKIM looks into an email message to prevent message tampering. DMARC is an email authentication, policy, and reporting protocol that builds on the widely deployed SPF and DKIM protocols. As a useful combination of these two capabilities, DMARC helps both email senders and receivers work together to better secure emails, protecting users and brands from costly abuse.

A set of vulnerabilities were discovered by researchers in the practical usage of these capabilities exposing the potential abuse of sender trust in email communications. Many of the hosted, email services provide hosting for multiple domains and use a wide range of network resources to deliver emails from their domain addresses. The hosting service providers typically provide a way to authenticate before allowing emails to be sent on behalf of the sender. However, due to the nature of their shared hosting, many of them do not verify the authenticated sender against their allowed domain identities. Hosting providers who have published SPF records, and, in some cases, also add DKIM signatures, do not sufficiently verify the trust relationship of authenticated user against the allowed domains. This allows an authenticated attacker to spoof an identity in the email Message Header to send emails as anyone in the hosted domains of the hosting provider, while authenticated as a user of a different domain name.

Any remote email receiving services may incorrectly identify the sender’s identity as it passes the cursory check of DMARC policy adherence. The DMARC policy is thus circumvented, allowing spoofed messages to be seen as an attested and a valid message.

CVE-2024-7208 A vulnerability in multi-tenant hosting allows an authenticated sender to spoof the identity of a shared, hosted domain, thus bypass security measures provided by DMARC (or SPF or DKIM) policies.

CVE-2024-7209 A vulnerability exists in the use of shared SPF records in multi-tenant hosting providers, allowing attackers to use network authorization to be abused to spoof the email identify of the sender.

Impact

An authenticated attacker using network or SMTP authentication can spoof the identity of a shared hosting facility, circumventing any DMARC policy and sender verification provided by a domain name owner.

Solution

Hosting providers

Domain hosting providers that provide email relay should verify the identity of an authenticated sender against authorized domain identities. The email service providers should use reliable ways to verify that the network sender identity (MAIL FROM) and the Message Header (FROM:) are the same or related. As much as SMTP software does not verify the Message Header with the network sender, identity mail filter software, such as (Milter) Milterfrom, may provide ways to enforce such requirements.

Domain owners

Domain owners should use strict measures to ensure their domain, DNS-based DMARC policy (DKIM and SPF) protects their sender identity and their users and brands from abuse caused by spoofing. If a domain is expected to provide high assurance of identity, the domain owner should use their own DKIM facility, independent of the hosting provider, to reduce the risk of spoofing attacks.

Email Senders

Email senders that require high fidelity of their identity can use facilities such as S/MIME and PGP, as suggested in RFC 5321 #7.1.

Acknowledgements

Thanks to the reporters, Caleb Sargent and Hao Wang, for raising awareness of these vulnerabilities. This document was written by Dr. Elke Drennan, Vijay Sarvepalli, and Timur Snoke.