Specialized application security scanning tools embedded in the development pipeline can do wonders to harden code and bolster software supply chain security. But if engineering teams aren’t careful, these security scanners can also become a gateway for attacks deep in the supply chain.
Last spring, the development and security worlds saw that scenario play out with broad supply chain attacks that compromised development environments for two different security open source projects, which served up poisoned versions of Trivy and KICS to unsuspecting software engineering teams. The attacks were part of broader supply chain attacks by TeamPCP to commit widespread credential theft and fraud.
Next week, during the Black Hat USA conference in Las Vegas, another security researcher will demonstrate a different way attackers can use security tools to their advantage. This attack takes less effort, as it doesn’t require full compromise of the vendor’s development environment. All it takes is asking the tool to do a scan and feeding it a specially crafted malicious code repository.
The research in question was conducted by the security team at ZeroPath, which investigated the susceptibility of 20 unnamed security vendors and identified significant findings with five of them. One of them even awarded the researchers the maximum-sized bug bounty for their discoveries.
“Most of the findings disclosed sensitive secrets like cloud credentials. One included the production database. Some included the Docker and GitHub personal access token for the actual developer that worked at the vendor,” says Raphael Karger, co-founder and CTO for ZeroPath, who will be leading the session next week to dive into the details. “These instances could have reached customers that thought they were secure.”
It Started with a Sketchy Probe
The genesis of the research all started with an alert that Karger’s team ran down late last year in their own environment. They picked up some evidence of a failed scan in their production monitoring software that looked suspicious.
“It was referencing a file that was trying to read something outside of the scope of its current repository. And the file it was trying to read could have potentially had sensor credentials, et cetera,” he says. “We detected this proactively, and we began investigating the repository.”
By looking at a few artifacts from the repository, the team found that an attacker was systematically testing the surface of the firm’s hosted security product. The attacker examined how ZeroPath’s scanning tools dealt with arbitrary files, dependency handling procedures, and secrets handling. The probe was so intriguing that Karger and his team decided right then to build a tool that would pick up where this exploratory probe left off and test their own environment for defects in the same processing surfaces the bad guys were apparently interested in.
The team built off the idea that repository analysis may not always be a read-only function. Many scanners execute code and examine files that could be used to force the execution of code, depending on how they process those files. It comes back to the age-old AppSec issue of executing untrusted content. If the scanner processes it without isolation, that could allow an attacker to present unexpected content that causes the scanner to not only read a file but also run malicious code. For example, if a tool scans cloud configuration files for security problems and can be pointed at a folder of custom rules to check, an attacker controlling the repository being scanned might be able to plant a custom rule that’s not actually a rule but a malicious program. When the scanner loads that, it executes it.
Scanning the Scanners
After digging deeper into their own internal products along these lines, the ZeroPath team decided that the experimental tool they built could bring broader value to the entire AppSec supply chain. From there, they tweaked their tool to find out how susceptible other security vendor scanners were as well.
“We built this tool that goes a step beyond and actually reads all the documentation of a vendor, and automatically creates these payloads and builds them in a way where it’s actually testing them dynamically. That way we can create this expanded set of payloads, in some cases that’s tailored based on a specific vendor,” Karger says. “So essentially, this thing was doing what this attacker was doing, but on steroids.”
Dubbed Build Canaries, the tool was first put through its paces by looking at the initial set of 20 scanners handpicked by his team. They chose security platforms that offered free sign-up versions they could register for without going through a sales-assisted process or social engineering to gain access, but that also showed evidence of “marquee logos on websites and case studies, as well as evidence of funding.”
The talk at Black Hat will dive into the major findings of this research, but the biggest takeaway is that most of them could have had significant downstream effects on customer organizations, including Fortune 1000 enterprises, defense contractors, and key government agencies. For example, the production database they gained access to had plenty of ammunition to go after big-name customers.
“It had the right permissions, and you could have potentially modified the code for these companies,” he says. “You could have gone as well and viewed all of the unpatched findings for these companies. It had things like secrets and policy violations.”
Karger will take the wraps off Build Canaries at Black Hat, offering it up as an open source tool that comes with 349 different validated payloads that AppSec teams can use to test their own security scanning estate. He’ll also be releasing A taxonomy of repository ingestion execution surfaces that security teams can use immediately to audit their own pipelines and vendor relationships. More broadly, he will encourage security teams to start asking the same tough questions of their security scanning vendors as they would of any other build tool.
“AppSec is notoriously a hyper-competitive market. And so a lot of these smaller teams maybe are investing less in security and more in go-to-market functions,” he warns. “You want to be making sure that there’s correct isolation and multi-tenancy handling within these environments.”
