SBOMs the Hard Way Hacking Bob the Minion

SBOMs the Hard Way Hacking Bob the Minion

Speakers: Larry Pesce

Conference: DEF CON 32

YouTube: https://www.youtube.com/watch?v=Cxrwpij2MSQ

Overview

In his DEF CON 32 talk, "SBOMs the Hard Way Hacking Bob the Minion," Larry Pesce, Product Security Research and Analysis Director and Services Team Lead at Finite State, delves into the practical application of Software Bill of Materials (SBOMs) for identifying and exploiting vulnerabilities in connected devices. The presentation transcends theoretical discussions of SBOMs, offering a hands-on perspective on how these inventories can be operationalized by both defenders and attackers. Pesce uses the whimsical example of "Bob the Minion"—a consumer-grade connected device—as a case study to illustrate the comprehensive process of obtaining, analyzing, and leveraging an SBOM to uncover potential security weaknesses.

Pesce, a self-described "reformed/unreformed penetration tester," brings a unique blend of offensive and defensive security expertise to the topic. His work at Finite State, a company specializing in SBOMs and product security, provides him with deep insights into the challenges and opportunities presented by the evolving regulatory landscape and the increasing complexity of software supply chains. This talk is crucial for anyone involved in product development, security research, or regulatory compliance for connected devices, as it highlights the imminent necessity of SBOMs and their profound impact on security postures.

The core message of the talk underscores that SBOMs are not merely compliance checkboxes but powerful tools that, when properly utilized, can significantly enhance an organization's understanding of its software components, facilitate proactive vulnerability management, and ultimately improve overall product security. By demonstrating the "hard way" of hacking Bob the Minion, Pesce illustrates that a thorough, component-level analysis, often enabled by SBOMs, is indispensable for truly understanding and securing modern connected products.

Background

▶ Watch: Introduction to 'SBOMs the Hard Way' and speaker background (0:00)

The concept of a Software Bill of Materials (SBOM), essentially an inventory of all software components, their versions, and origins within a product, has rapidly moved from a niche concept to a critical element of modern cybersecurity. This shift is primarily driven by an escalating awareness of software supply chain risks, exemplified by high-profile incidents like the SolarWinds attack, and a burgeoning regulatory push across various sectors and geographies. Larry Pesce's talk provides essential context by outlining the current regulatory landscape that is mandating and encouraging SBOM adoption.

In the United States, several initiatives are pushing for greater transparency in software components. Executive Order 14208 (Pesce mistakenly refers to it as 14208, the correct number for the cybersecurity EO is 14028), issued in May 2021, emphasizes improving the nation's cybersecurity and includes provisions for enhancing software supply chain security, explicitly mentioning SBOMs for software sold to the federal government. For medical devices, the FDA 524B regulation requires medical device manufacturers submitting new devices for use on humans to include an SBOM as part of their submission process, alongside a comprehensive plan for securing devices, managing vulnerabilities, and issuing updates over their lifecycle. Furthermore, the FCC Cyber Trust Mark program is a voluntary initiative designed to help consumers identify more secure IoT devices. Devices participating in this program can receive a "stamp on the box" and a barcode linking to a website providing a security score, indicating a commitment to security practices, including vulnerability monitoring and updates, with SBOMs playing a foundational role.

Perhaps the most stringent and far-reaching regulation discussed is the EU Cyber Resiliency Act (EU CRA). This mandatory legislation aims to prevent any connected products with known vulnerabilities from being sold into the European market. It demands that manufacturers not only provide an SBOM but also establish robust processes for vulnerability management, patching, and continuous monitoring. Given that many manufacturers sell devices globally, compliance with the EU CRA is expected to drive widespread adoption of SBOMs and enhanced security practices across the entire product lifecycle, benefiting consumers and businesses worldwide.

Beyond regulatory compliance, SBOMs offer significant general benefits. They provide a comprehensive software inventory for both first-party (internally developed) and third-party (open-source or commercially acquired) components. This detailed list enables enrichment, allowing organizations to cross-reference components with known vulnerability databases (e.g., CVEs) and identify associated risks. With this information, manufacturers can perform risk mitigation and take appropriate actions, from patching to architectural redesigns. Pesce strongly advocates for operationalizing SBOMs, integrating them into daily security processes, including penetration testing. As he highlighted in his previous RSA talk, "SBOMs for Evil," understanding a product's components can give attackers an advantage by pinpointing vulnerable elements, which conversely, can be used by defenders to proactively strengthen their security posture. The problem exists because historically, manufacturers lacked granular visibility into their software components, making vulnerability identification and management a reactive, rather than proactive, endeavor. SBOMs aim to rectify this fundamental lack of transparency.

Key Findings

▶ Watch: US regulations driving SBOM adoption (EO, FDA, FCC) (3:29)

The central "finding" of Pesce's talk is not a single, specific vulnerability discovered in Bob the Minion, but rather the compelling demonstration of a robust methodology that leverages SBOMs to uncover potential security weaknesses in firmware and connected devices. The talk illustrates that by meticulously generating and analyzing an SBOM for a seemingly innocuous consumer product like "Bob the Minion," one can systematically identify components with known vulnerabilities, thereby creating a roadmap for potential exploitation. This process reveals that many connected devices, even those with a playful facade, often contain a treasure trove of third-party software components that may harbor publicly disclosed security flaws.

Pesce emphasizes that his "day job" often involves taking a random device, extracting its firmware, and generating an SBOM to assess its security posture. This process frequently uncovers "scary things," highlighting that the "surprises" found in devices like Bob the Minion are often not 0-day vulnerabilities but rather instances of manufacturers using software components with long-known and published vulnerabilities. The "key finding" is therefore the validation of the hypothesis that SBOMs, even when generated "the hard way" through reverse engineering, are an incredibly effective mechanism for identifying latent risks within complex embedded systems. The talk reinforces that "known" vulnerabilities are often unknown or unaddressed by device manufacturers and consumers, making SBOMs a critical tool for bridging this knowledge gap. The talk confirms that this systematic approach provides actionable intelligence for both offensive security (identifying attack vectors) and defensive security (prioritizing patches and mitigations).

Technical Deep Dive

▶ Watch: The mandatory and stringent EU Cyber Resiliency Act (4:15)

The "hard way" in "SBOMs the Hard Way" refers to the meticulous, often manual, process of obtaining and analyzing firmware to generate an SBOM for a device where one is not readily provided by the manufacturer. This technical deep dive outlines the methodology Pesce and his team employ, which is critical for assessing the security of many IoT and OT/ICS devices. The process begins with firmware acquisition, which can involve various techniques depending on the device. For consumer devices like Bob the Minion, this might entail extracting the firmware directly from the device's memory chips, intercepting over-the-air updates, or even downloading publicly available firmware images.

Once the firmware is acquired, the next crucial step is firmware extraction. This often involves using tools to unpack proprietary or compressed file formats. Many embedded systems use common Linux distributions or real-time operating systems, meaning the firmware image often contains a file system that can be extracted and mounted. This allows researchers to access individual binaries, libraries, configuration files, and scripts within the firmware. Pesce stresses the importance of verifying the extraction to ensure its accuracy, as incomplete or corrupted extractions can lead to a misleading SBOM.

Following extraction, the process moves into component identification and analysis. This is where the core of SBOM generation occurs. Automated tools can scan the extracted files to identify known software packages, libraries, and their versions. However, the "hard way" often necessitates reverse engineering specific binaries. This is particularly important for custom code or obfuscated components that automated scanners might miss. Reverse engineering helps in understanding the function of unknown executables, identifying their dependencies, and determining the specific versions of open-source or commercial libraries they incorporate. This manual effort ensures a more comprehensive and accurate SBOM, revealing components that might otherwise remain hidden.

With a comprehensive list of components and their versions, the next phase is vulnerability enrichment. This involves cross-referencing each identified component against various vulnerability databases, such as the National Vulnerability Database (NVD) for CVEs (Common Vulnerabilities and Exposures). This enrichment process immediately highlights known security flaws associated with the software used in the device. For instance, a device might use an outdated version of a common library like OpenSSL or BusyBox, which has publicly documented vulnerabilities. The SBOM acts as a comprehensive index, allowing researchers to quickly pinpoint these potential attack vectors.

Pesce emphasizes that this detailed analysis can lead to the discovery of "all sorts of scary things," from publicly known vulnerabilities in common components to potential 0-day exploits in less scrutinized custom code. The "known vulnerabilities" in "air quotes" refers to the fact that while these flaws are public knowledge within the security community, they are often unknown or unaddressed by the manufacturers or end-users of the devices in question. This technical deep dive into firmware provides the granular detail necessary to understand the true security posture of a product, enabling targeted penetration testing and informed risk mitigation strategies. The goal is not just to list components, but to understand their security implications within the context of the device's operation.

Demo / Proof of Concept

▶ Watch: Beyond compliance: operationalizing SBOMs for security (5:15)

While the talk's title, "Hacking Bob the Minion," strongly implies a direct demonstration of an exploit, Larry Pesce's presentation focuses more on the methodology and potential for hacking rather than a live, step-by-step exploit of a specific device. The "adventure" of hacking Bob the Minion serves as a compelling narrative framework to illustrate the practical application of SBOMs in offensive security reconnaissance.

Pesce describes his routine work of acquiring a random device, extracting its firmware, and generating an SBOM to identify components and their associated vulnerabilities. He states, "we may have some surprises here with Bob the Minion. And arguably it might not be all that surprising after all." This indicates that the "proof of concept" is the very process of generating an SBOM for Bob the Minion and the subsequent identification of components with known security flaws. The "surprise" is not a novel exploit but the likely discovery of existing, publicly documented vulnerabilities within the device's software stack, which could be exploited.

Therefore, the "demo" in this context is the conceptual demonstration of how an attacker, armed with an SBOM (generated "the hard way" through firmware analysis), gains a significant advantage. By knowing the exact versions of software components, an attacker can:

1. Identify known CVEs: Easily search public databases for vulnerabilities affecting those specific versions.
2. Locate exploitable services: Pinpoint services or applications that utilize vulnerable components.
3. Develop targeted exploits: Tailor existing exploit code or craft new ones based on the identified weaknesses.

The talk doesn't present a specific exploit payload or a live hack of Bob the Minion, but rather showcases the pre-exploitation intelligence gathering phase, which is arguably the most critical and often overlooked aspect of advanced persistent threats and targeted attacks. The "proof" lies in the fact that generating an accurate SBOM for a complex device like Bob the Minion provides an attacker with a clear attack surface and a list of high-probability targets, transforming a black-box target into a gray-box or even white-box scenario. This systematic approach, driven by SBOM data, constitutes the implicit "proof of concept" for "hacking Bob the Minion."

Defensive Implications

▶ Watch: Using SBOMs for penetration testing and vulnerability discovery (6:09)

The insights gleaned from "SBOMs the Hard Way" offer profound defensive implications for manufacturers, consumers, and security professionals dealing with connected devices. The talk unequivocally demonstrates that SBOMs are not just a regulatory burden but a fundamental tool for improving an organization's security posture and reducing its exposure to software supply chain risks.

For manufacturers, the primary implication is the urgent need to embrace and proactively generate accurate SBOMs for all their products. This extends beyond merely listing top-level components to a deep, granular understanding of all third-party and open-source software embedded within their firmware. Manufacturers must:

• Integrate SBOM generation into their CI/CD pipelines: Automate the creation of SBOMs throughout the development lifecycle to ensure they are always up-to-date.
• Operationalize SBOMs for vulnerability management: Continuously monitor the components listed in their SBOMs against public vulnerability databases (e.g., NVD, proprietary feeds). This allows for proactive identification and patching of known CVEs before they are exploited.
• Establish a robust patching strategy: Be prepared to issue timely firmware updates when vulnerabilities are discovered in their components, as mandated by regulations like the EU Cyber Resiliency Act (EU CRA).
• Conduct SBOM-informed penetration testing: Use the SBOM as a guide for internal security assessments and external penetration tests, directing efforts to components most likely to harbor exploitable flaws. This "known vulnerability" approach is far more efficient than traditional black-box testing.
• Improve disclosure processes: Be transparent with customers about the security posture of their devices, potentially leveraging programs like the FCC Cyber Trust Mark to build trust.

For consumers and organizations deploying connected devices, the defensive implications revolve around demanding and utilizing SBOMs.

• Demand SBOMs from vendors: As regulations like the EU CRA take effect, consumers should expect and demand SBOMs for the products they purchase, especially for critical infrastructure or medical devices (as per FDA 524B).
• Leverage SBOMs for risk assessment: Enterprises should use vendor-provided SBOMs to assess the security risk of third-party devices before deployment. This allows them to identify potential vulnerabilities and implement compensating controls or choose alternative products.
• Monitor for vulnerabilities: Even with a vendor-provided SBOM, organizations should actively monitor for new vulnerabilities affecting the listed components and pressure vendors for patches.

Ultimately, the talk serves as a stark reminder that ignorance is not bliss in the realm of cybersecurity. The "hard way" of hacking Bob the Minion illustrates that attackers will go to great lengths to understand a product's internal workings. Defenders must match or exceed this level of diligence by embracing SBOMs, operationalizing them, and proactively addressing the vulnerabilities they reveal. This shift from reactive patching to proactive, intelligence-driven security is crucial for navigating the complex and interconnected digital landscape.

Key Takeaways

• SBOMs are becoming mandatory and critical: Driven by regulations like the EU Cyber Resiliency Act, FDA 524B, and Executive Order 14028, SBOMs are transitioning from a best practice to a compliance requirement, significantly impacting how connected products are developed and sold globally.
• SBOMs provide essential software inventory: They offer a comprehensive list of first-party and third-party components, their versions, and origins, which is foundational for understanding a product's attack surface.
• SBOMs enable proactive vulnerability management: By cross-referencing SBOM components against vulnerability databases (CVEs), organizations can identify known security flaws early and prioritize patching efforts, shifting from reactive to proactive security.
• SBOMs can be operationalized for both offense and defense: While they can guide penetration testers to exploit known weaknesses, they are equally powerful for defenders to harden products, conduct targeted security assessments, and improve overall risk mitigation strategies.
• Firmware analysis is key for "hard way" SBOMs: For devices without readily available SBOMs, reverse engineering and detailed firmware extraction are necessary to generate an accurate component inventory, revealing hidden vulnerabilities.
• Many connected devices contain known, unaddressed vulnerabilities: The "adventure" of hacking devices like "Bob the Minion" often reveals that manufacturers use components with publicly disclosed vulnerabilities that remain unpatched, highlighting a significant security gap that SBOMs can help close.

About the Speaker(s)

Larry Pesce is a prominent figure in the cybersecurity community, currently serving as the Product Security Research and Analysis Director and Services Team Lead at Finite State. With a background as a "reformed penetration tester" who frequently finds himself "unreformed" and back in the field, Pesce brings extensive hands-on experience in OT/ICS, IoT, and hardware hacking. He is a co-host of the long-running security podcast, Paul's Security Weekly, now in its 19th year. Additionally, Pesce is a dedicated instructor and course author for SANS, specializing in wireless hacking and IoT hacking. Known for his advocacy of the Oxford comma and his preparedness for the zombie apocalypse (evidenced by his ham radio hobby), Pesce combines deep technical expertise with an engaging presentation style. His work at Finite State focuses on leveraging Software Bill of Materials (SBOMs) and other product security initiatives to enhance the security of connected devices.