Government and security-sensitive companies are increasingly requiring software makers to provide them with software bills of material (SBOMs), but in attackers’ hands, the list of components making up an application could provide a blueprint for exploiting the code.
An attacker who determines what software a targeted company is running, can retrieve the associated SBOM, and analyze the application’s components for weaknesses, all without sending a single packet, says Larry Pesce, a director for product security research and analysis at software supply-chain security firm Finite State.
Today, attackers will often have to do technical analysis, reverse engineer source code, and look to see if specific known-vulnerable components exist in an exposed software application in order to find vulnerable code. Yet, if the targeted company maintains SBOMs that are publicly accessible, then a lot of that information is already available, says Pesce, a former penetration tester of 20 years who plans to warn about the risk in a
presentation on “Evil SBOMs” at the RSA Conference in May.
“As an adversary, you’re having to do a lot of that work upfront, but if companies are required to provide SBOMs, either publicly or to customers, and that … leaks out into other repositories, you don’t have to do any work, it’s already been done for you,” he says. “So it’s kind of like — but not exactly — pressing the Easy button.”
SBOMs are quickly proliferating, with more than half of companies currently requiring that any application be accompanies by a list of components —
a number that will reach 60% by next year, according to Gartner. Efforts to make SBOMs a standard practice see transparency and visibility as the first steps to help the software industry
better secure their products. The concept has even spread to the critical infrastructure sector, where energy giant Southern Company embarked on a project to
create a bill of materials for all the hardware, software, and firmware in one of its substations in Mississippi.
Using SBOMs for Evil Cyberattack Purposes
Producing a detailed list of software components in an application can have offensive implications, Pesce argues. In his presentation, he will show that SBOMs have enough information to allow attackers to
search for specific CVEs in a database of SBOMs and find an application that is likely vulnerable. Even better for attackers, SBOMs will also list other components and utilities on the device that the attacker could use for “living off the land” post-compromise, he says.
“Once I’ve compromised a device…an SBOM can tell me what the device manufacturer left behind on that device that I could potentially use as tools to start probing other networks,” he says.
The minimum baseline for SBOM data fields include the supplier, the component name and version, dependency relationships, and a timestamp of when the information was last updated,
according to the US Department of Commerce guidelines.
In fact, a comprehensive database of SBOMs could be used in a manner similar to the Shodan census of the Internet: Defenders could use it to see their exposure, but attackers could use it to determine what applications might be vulnerable to a particular vulnerability, Pesce says.
“That would be a really cool project, and honestly, I think we’re probably going to something see like that — whether it is a company that does a giant database or it is something that the government mandates,” he says.
Red Team Early & Often
When Pesce mentioned the talk to one SBOM advocate, they argued that his conclusions would make the struggle to get companies to adopt SBOMs more difficult. Yet, Pesce argues that those concerns miss the point. Instead, application-security teams should take to heart the adage that, “Red informs Blue.”
“If you’re an organization that is consuming or generating SBOMs, know that there are going to be people like me — or worse — that are going use SBOMs for evil,” he says. “So use them for evil yourself: Bring them in as part of your overall vulnerability management program; bring them in as part of your pen test program; bring them in as part of your secure development lifecycle — bring them in as part of all of your internal security programs.”
While software-makers could argue that SBOMs should only be shared with customers, limiting SBOMs will likely be a Herculean task. SBOMs will likely leak to the public, and the widespread availability of tools to generate SBOMs from binaries and from source code will make limiting their publication a moot point.
“After being in this industry long enough, we know that when something is private, it will eventually become public,” he says. “So there will always be someone that leaks the information [or] someone will spend money on a commercial tool to go generate SBOMs on their own.”
https://eu-images.contentstack.com/v3/assets/blt6d90778a997de1cd/blt58bb2fe4dca8f749/662bc07a2b9a4fea22ee939f/ArtemisDiana-software-components-shutterstock.jpg?disable=upscale&width=1200&height=630&fit=crop
