As we’ve explained in previous related announcements, the Vulnerability Rating Taxonomy (VRT) implemented in our platform is a key reason that Bugcrowd customers and hackers can quickly adapt to the evolving threat environment. By classifying and prioritizing emergent vulnerabilities across a range of asset types, the VRT helps hackers hunt for specific vulnerabilities and create targeted POCs, and helps users of our platform design scope and rewards that create the best outcomes.
In our previous update (VRT 1.12), we added what we expect to be common LLM-related vulnerabilities to the taxonomy and implemented them in our platform. In this update (VRT 1.13), we’re doubling-down on hardware vulnerabilities to meet the needs of customers like Dell, Xfinity, and iRobot who are collaborating with hackers to secure their attack surface spanning hardware, firmware, and software.
This is an extensive update, including new vulnerabilities in the existing “Insecure OS/Firmware” category, a net-new category covering “Physical Security issues”, and several other modifications. Learn details about the additions below.
New vulnerabilities added to “Insecure OS/Firmware”
P2: Insecure OS/Firmware > Local Administrator on Default Environment
The current configuration of the device uses a local administrator account as the default environment setting. This configuration inherently provides administrator-level access to the running processes and access, posing a significant security risk. If an attacker compromises the application or device, they can gain elevated privileges automatically, allowing for extensive control over the device’s functions and data.
P2: Insecure OS/Firmware > Over-Permissioned Credentials on Storage
The device contains a set of credentials stored on its storage medium that are over-permissioned for their intended use. While these credentials are designed to access a specific shared service, their excessive permissions allow for broader unauthorized access. If the device is compromised or falls into the hands of an unauthorized user, these over-permissioned credentials could be used to access not only the intended service but also additional services and data that should be segregated.
P3: Insecure OS/Firmware > Shared Credentials on Storage
The device in question stores a set of shared credentials on its storage medium. These credentials are intended for accessing a shared service. However, should the device be compromised or acquired by unauthorized parties, an attacker could use these shared credentials to gain access to services that are normally restricted.
Varies: Insecure OS/Firmware > Failure to Remove Sensitive Artifacts from Disk
During the deployment or configuration phases of the device, sensitive artifacts (which can include configuration information, secrets, or credentials) are transferred to and stored on the device’s storage medium. These artifacts are not adequately removed post-deployment or configuration. As a result, an attacker gaining access to the device could view these sensitive artifacts.
Varies: Insecure OS/Firmware > Kiosk Escape or Breakout
A kiosk escape or breakout occurs when an exploit allows users to bypass the software package serving as the frontend for an application on a system, gaining unauthorized access to the underlying operating system. This vulnerability varies in impact depending on the operating system and the level of hardening applied to the system. In cases where the system uses administrator-level access, the consequences can include defacement, installation of malicious software, or breaches of data integrity, potentially affecting stored customer data.
Varies: Insecure OS/Firmware > Poorly Configured Disk Encryption
The device uses a disk encryption to protect stored data from being accessed while at rest. However, due to a poor configuration of the encryption mechanism, an unauthorized attacker with physical access to the device can decrypt the disk’s contents. This vulnerability could expose secrets, customer data, or other sensitive information stored on the device.
Varies: Insecure OS/Firmware > Poorly Configured Operating System Security
The device employs a standard operating system where the configuration fails to adequately secure the device. This poor configuration can expose the device to various security vulnerabilities, making it susceptible to unauthorized access, data breaches, and other malicious activities. An attacker with access to the operating system can gain access to the applications and data on the device.
Varies: Insecure OS/Firmware > Recovery of Disk Contains Sensitive Material
The device’s storage medium fails to adequately delete data when a factory reset is performed due to a flaw in the process. An attacker with access to the storage medium post-reset can recover and exploit the sensitive information.
Varies: Insecure OS/Firmware > Weakness in Firmware Updates > Firmware Cannot be Updated
The hardware lacks the capability for firmware updates, leaving the system exposed to unpatched vulnerabilities and security risks. These limitations prevent effective maintenance and security management, rendering the device obsolete against evolving threats. An attacker can leverage the lack of firmware updates to gain access to sensitive information.
P3: Insecure OS/Firmware > Weakness in Firmware Updates > Firmware Update Integrity Not Validated
The hardware fails to validate the authenticity and integrity of the update file. Without proper validation, the system is susceptible to accepting and installing corrupted or malicious updates, compromising the device’s security and functionality.
P5: Insecure OS/Firmware > Weakness in Firmware Updates > Insecure OS/Firmware > Firmware Not Encrypted
The firmware used for the hardware is stored or transmitted without encryption. This lack of encryption allows for easier reverse engineering and analysis, enabling unauthorized individuals to more readily identify security vulnerabilities within the device’s firmware.
P5: Insecure OS/Firmware > Data not encrypted at rest > Non-Sensitive
The device stores non-sensitive data that is not encrypted at rest. Despite the data not being directly exploitable, its accessibility due to lack of encryption allows attackers with physical access to the device to retrieve this information. This exposure could facilitate reverse engineering efforts or aid in future exploitation attempts, indirectly compromising the system’s security.
Varies: Insecure OS/Firmware > Data not encrypted at rest > Sensitive
The device stores sensitive data that is not encrypted at rest, compromising the confidentiality and integrity of the data. This oversight allows an attacker with physical access to the device to easily access and potentially compromise the sensitive data contained within, exposing personal information, secrets, or credentials.
New “Physical Security issues” category and vulnerabilities
P2: Physical Security issues > Weakness in physical access control > Commonly Keyed System
The physical access control deployed to secure the device was found to use a lock keyed alike to commonly used keys. This scenario typically arises when locks are mass-manufactured with the same key configuration by vendors, intended for low-risk applications, or when a specific key standard is adopted with an expectation of limited use. When these lock systems are employed in contexts requiring higher security, like the device in question, the security efficacy is substantially reduced. The widespread availability or public knowledge of these keys means unauthorized individuals could easily obtain a key to gain access.
Varies: Physical Security issues > Weakness in physical access control > Master Key Identification
The physical access control system designed to secure the device utilizes a master keyed system. In such systems, locks can be opened by multiple keys, each cut differently, but all locks within the system can also be opened by a single master key. This configuration presents a significant security vulnerability. An attacker with access to a mastered lock, or who comes into possession of a key from the system, could derive the master key. With the master key, the attacker would have the capability to open all locks within the system, severely compromising security.
Varies: Physical Security issues > Weakness in physical access control > Cloneable Key
The physical access control system securing the device relies on a physical key that is susceptible to cloning. This design flaw allows attackers, with brief access to the key, to create an unauthorized copy. Access to the key could be obtained through various means, including insider threats or by employing tele-duplication techniques, where a photograph of the key is used to replicate it. Consequently, An attacker can gain unauthorized access by using a cloned key, circumventing intended security measures.
Varies: Physical Security issues > Bypass of Physical Access Control
The physical access control mechanisms implemented to secure the device are vulnerable to a bypass attack. This flaw allows an unauthorized attacker to circumvent the designed physical security measures implemented, gaining access to the device’s internal hardware and components that are intended to be restricted.
Contributions needed!
As we always like to say, these categories and vulnerabilities will evolve over time as hackers, Bugcrowd application security engineers, and customers actively participate in the process—which is what makes this effort so important and worthwhile. If you would like to contribute to the VRT, Issues and Pull Requests are most welcome!
