We are deeply numbed, shocked and saddened today by the sudden and tragic loss of our fellow technician, coworker, compatriot […]
We are deeply numbed, shocked and saddened today by the sudden and tragic loss of our fellow technician, coworker, compatriot […]
Fog and Akira ransomware operators have increased their exploitation efforts of CVE-2024-40766, a critical access control flaw that allows unauthorized access to resources on the SSL VPN feature of SonicWall SonicOS firewalls. […]
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.
Update 10/8/2023 Data carrier indicated that there was a failure of one of their core routers. They have replaced it […]
As with most nerds these days, I have been pretty enamored with the ability of ChatGPT to cull data from the net and write some fairly amazing stuff with it.
With the end of the year coming and with the increase in phishing attempts due to the holidays, we thought it would be a good time to post this refresher on phishing and the things you can do to protect yourself.
LastPass revealed today that attackers stole customer vault data after breaching its cloud storage earlier this year using information stolen during an August 2022 incident.
Overview
The Heimdal Software Kerberos 5 implementation is vulnerable to a null pointer dereferance. An attacker with network access to an application that depends on the vulnerable code path can cause the application to crash.
Description
A flawed logical condition allows a malicious actor to remotely trigger a NULL pointer dereference using a crafted negTokenInit token.
Impact
An attacker can use a specially crafted network packet to cause a vulnerable application to crash.
Solution
The latest version of code in the Heimdal master branch fixes the issue. However, the current stable release 7.7.0 does not include the fix.
Acknowledgements
Thanks to the International Continence Society for reporting this issue.
This document was written by Kevin Stephens.
Overview
A security feature bypass vulnerability exists in signed 3rd party UEFI bootloaders that allows bypass of the UEFI Secure Boot feature. An attacker who successfully exploits this vulnerability can bypass the UEFI Secure Boot feature and execute unsigned code during the boot process.
Description
UEFI firmware is software written by vendors in the UEFI ecosystem to provide capabilities in the early start up phases of a computer. Secure Boot is a UEFI standard that can be enabled and used to verify firmware and to protect a system against malicious code being loaded and executed early in the boot process, prior to the loading of the operating system.
Security researchers at Eclypsium have found three specific UEFI bootloaders that are signed and authenticated by Microsoft to be vulnerable to a security feature bypass vulnerability allowing an attacker to bypass Secure Boot when it is enabled. The vulnerable bootloaders can be tricked to bypass Secure Boot via a custom installer (CVE-2022-34302) or an EFI shell (CVE-2022-34301 and CVE-2022-34303). As a vulnerable bootloader executes unsigned code prior to initialization of the the Operating System’s (OS) boot process, it cannot be easily monitored by the OS or common Endpoint Detection and Response (EDR) tools.
The following vendor-specific bootloaders were found vulnerable:
Inherently vulnerable bootloader to bypass Secure BootNew Horizon Datasys Inc (CVE-2022-34302)
UEFI Shell execution to bypass Secure BootCryptoPro Secure Disk (CVE-2022-34301)
Eurosoft (UK) Ltd (CVE-2022-34303)
Impact
An attacker can bypass a system’s Secure Boot feature at startup and execute arbitrary code before the operating system (OS) loads. Code executed in these early boot phases can provide persistence to an attacker, potentially loading arbitrary kernel extensions that survive both reboot and re-installation of an OS. It may also evade common OS-based and EDR security defenses.
Solution
Apply a patch
Apply your vendor-provided security updates that address these vulnerabilities to block vulnerable firmware from bypassing Secure Boot. Microsoft has provided details with their KB5012170 article released on August 9th 2022. Note, these updates can be delivered from your OEM vendor or the OS vendor to install an updated Secure Boot Forbidden Signature Database (DBX) .
Enterprise and Product Developers
As DBX file changes can cause a system to become unstable, Vendors are urged to verify the DBX updates do not cause the machine to be unusable. Enterprises and Cloud Providers that manage large number of computers are also urged to do the required security updates and ensure DBX files are implemented reliably without any risk of boot failure.
Acknowledgements
Thanks to Mickey Shkatov and Jesse Michael of Eclypsium who researched and reported these vulnerabilities.
This document was written by Brad Runyon & Vijay Sarvepalli.
You may not be able to tell right away if an incoming call is spoofed. Be extremely careful about responding to any request for personal identifying information.