In May of 2021, President Biden issued an Executive Order on Improving the Nation’s Cybersecurity. The order was designed to strengthen US government cybersecurity defenses in the wake of several significant hacks, including the SolarWinds, Kaseya, and Microsoft Exchange Server incidents, which impacted numerous federal agencies and private companies. The order’s importance was underscored by the ransomware attack on the Colonial Pipeline that occurred just a few weeks later.
A vital component of the order is the requirement for a software bill of materials (SBOM) that vendors are now required to provide as part of the government’s procurement process. The SBOM is expected to detail the exact software components utilized in a given product making it much easier and faster for federal agencies to determine whether they are subject to a vulnerability uncovered in one of these components.
In this article, I want to discuss the implications of this order on you as an API hacker. Can you leverage the SBOM to your advantage as part of your API security testing efforts?
Read on to find out!
The debate: Is SBOM a roadmap for hackers or defenders?
If you spend any time looking into SBOM you will come across a common debate. On one side, the belief is that the data within an SBOM can be potentially accessed and exploited by hackers and in the process actually make the software more vulnerable to attack.
On the other side, the belief is that the defensive benefits of transparency far outweigh this concern. The value comes from the fact defenders get the ability to quickly determine if they are at risk when a component is found to be vulnerable. SBOM allows defenders to answer if they are vulnerable, and where, much quicker than without it.
We saw this during the exploitation of log4j.
Even after the experience with log4j, some still believe SBOM is a dangerous source of sensitive data for hackers.
If you think about it though, getting rid of the SBOM requirement would be like destroying their own defensive playbook for fear that it could be used against them. In reality, it just makes them more vulnerable.
SBOM is here to stay. So what does that mean for us on offense?
First off, there is a myth that SBOM has to be published publicly. This isn’t the case. In fact, in section four of the executive order it calls this out:
(vii) providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website;
EXECUTIVE ORDER 14028
So software vendors aren’t actually required to make their SBOM public. They can just give the purchaser the data. But… I wouldn’t consider this a security guardrail. Software supply chain risk still exists.
SBOM Security
There are no minimum requirements for access control to the software bill of materials. Security threats exist since SBOM data can be so easily collected and shared outside of the software supply chain. Not just by software developers and software consumers, but us as attackers.
There are a broad range of software composition analysis (SCA) tools, especially for open source software, that make it trivial to generate a software bill of materials from code. Maintaining SBOMs for third party components, even those used in proprietary software, may help detect known vulnerabilities in components even before software product security teams do. I’ll get more into this later.
But first, lets talk about how we can use the SBOM to our advantage.
How to use SBOM to find vulnerabilities
An SBOM typically holds associated metadata and describes a set of software elements broken down into components, services and dependencies. SBOM documents like the Linux Foundation Software Package Data Exchange (SPDX), and OWASP’s CycloneDX SBOM provide for a simple machine-readable text format that can be easily consumed and parsed.
You can use that to discover a known vulnerability introduced during software development through open source code. As an example, you could use the spdx-to-osv tool to produce an Open Source Vulnerability (OSV) JSON file based on information in an SPDX document. You can then query the Open Source Vulnerability database and return an enumeration of vulnerabilities present in the software’s declared components.
How Google Security uses SBOM + OSV
Google Security has a great write up on their blog on how they leveraged SBOM against OSV to find vulnerabilities in open source software. They even share some of the challenges they came across and some suggestions for better SBOM tooling.
It’s a great showcase on how to leverage accurate SBOMs to detect vulns in open source software and demonstrate supply chain risks. What I find more exciting though is how the federal government is starting to require supply chain security to improve, forcing other organizations (like Google) to make efforts to improve the industry as a whole.
Where we can take this approach
Imagine if instead of using OSV we could tailor the mapping of SBOM to something like the Vulnerability-Exploitability eXchange (VEX). OWASP is already considering this in CycloneDX. It helps to convey the exploitability of vulnerable components in the context of the product in which they’re used, hopefully before the impact of software supply chain attacks can be realized.
As industry standards improve and the latest version of SBOM requirements get adopted, it will help in improving transparency for defenders and allow us to follow common industry usage to improve our own recon on offense.
Everyone wins.
And the benefits here for us on offense are all about the depth in third party dependency trust, and the problem with the typical window of exposure of a vulnerability.
Exploiting the cascading effects of dependency trust
So I want you to think about a software component in code you are testing. I don’t care if its open source or proprietary code. Now consider the components they depend on. With me so far?
Now what about the dependencies THOSE components rely on? See where I am going with this?
Impacts of dependency trust in the real world
Consider this. Component A depends on Component B. Component B depends on Component C. Does Component A even know when there is an exploitable vulnerability in Component C? We saw this issue a lot during the log4j debacle, because software developers took on dependencies of components and libraries without even considering the impact to their products from this third-level order of trust.
It gets worse. The internal team or external vendor of Component C might have the best developers maintaining their code. But even still, it may take the organization several days to create and test a patch. Once its released, then the developers of Component B need to create and test their own patch replacing the vulnerable component(s) which will take even more time. And it keeps going and going, for however deep the dependency trust goes.
Can you see the cascading effects here? It can takes days, weeks or even months to get an exploitable vulnerability in a trusted component fixed in code.
And herein lies the advantage of SBOM that we can use as API hackers. If we track all the component dependancy we may very well be able to leverage a vulnerability detected in a nested component to give us a much larger Window of Exposure for the target API. It means we can use things like OSV and VEX and spider our target dependencies to exploit weaknesses in their code before a security patch is even issued. And maybe before the target is even aware of the security issue.
Conclusion
As industry standards improve and the latest version of SBOM get adopted thanks to President Biden’s executive order, it will help in improving transparency for defenders and allow us to improve our own recon on offense as part of our API security testing.
The benefits here are all about understanding the depth in third party dependency trust, and the problem with the typical window of exposure of a vulnerability. The cascading effects of dependency trust can take days, weeks or even months to get an exploitable vulnerability in a trusted component fixed in code. This gives hackers using SBOM a significant advantage when attacking APIs as we can detect vulnerabilities much deeper into the supply chain than ever before, and abuse that during our testing for a longer period of time.
So can SBOM help us attack APIs? Absolutely. And that’s a good thing.
Interested in learning other ways to improve your API hacking? Check out my free Ultimate Guide to API Hacking Resources for lots of other resources to check out on the subject.
