CyberWire Daily - The supply chain in disarray. [Research Saturday]

Episode Date: March 30, 2024

Elad, a Senior Security Researcher from Cycode is sharing their research on "Cycode Discovers a Supply Chain Vulnerability in Bazel." This security flaw could let hackers inject harmful code, potentially affecting millions of projects and users, including Kubernetes, Angular, Uber, LinkedIn, Databricks, DropBox, Nvidia, Google, and many more. The research states "We reported the vulnerability to Google via its Vulnerability Reward Program, where they acknowledged our discovery and proceeded to address and fix the vulnerable components." Please take a moment to fill out an audience survey! Let us know how we are doing! The research can be found here: Cycode Discovers a Supply Chain Vulnerability in Bazel Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. of you, I was concerned about my data being sold by data brokers. So I decided to try Delete.me. I have to say, Delete.me is a game changer. Within days of signing up, they started removing my personal information from hundreds of data brokers. I finally have peace of mind knowing my data privacy is protected. Delete.me's team does all the work for you with detailed reports so you know exactly what's been done. Take control of your data and keep your private life Thank you. Hello, everyone, and welcome to the CyberWires Research Saturday. I'm Dave Bittner, and this is our weekly conversation with researchers and analysts tracking down the threats and vulnerabilities, solving some of the hard problems, and protecting ourselves in a rapidly evolving cyberspace.

Thanks for joining us. So initially, we started searching and researching for workflow vulnerabilities and built pipelines, attack vectors. That's Elad, a senior security researcher at SciCode. The research we're discussing today is titled SciCode discovers a supply chain vulnerability in Bazel. Meaning, try to map the whole surface, the whole attack vector surface, and try to find where could be a misconfiguration,

where can be vulnerabilities in workflows. One of the vulnerabilities that could be made in workflows are command ejections vulnerabilities. So let's try to break it down what it means from the beginning. So command ejections are not new. They exist in web applications and they exist anywhere that user input is inserted and is not properly being verified, and then is being executed somehow.

So if the user is inserting some malicious input, it could be executed and will be run in some other system. So the same thing could happen in build workflows. Workflows run automatically. Workflows run based on triggers like push event, issue event, or fork event, or anything else that, let's say, GitHub offers us. Let's say we have a workflow, and that workflow checks if the issue title contains a specific prefix, for example. So every new issue, the pipeline will be automatically triggered. We'll check that if the issue title contains something like that, and we'll return some result. Maybe we'll open a new comment on the issue.

So now, as far as we understand workflows and the automatic procedures of them, let's try where it can be tempered and where the attack factor is regarding injections of workflows. So let's say a user opens an issue. And like we said before, there's a workflow that checks the issue title. If the issue title is not treated properly,

then the user could insert a malicious payload as the issue title, and then it will be interrupted in the workflow and will cause an injection, meaning a user input that is not being civilized and treated properly could be interrupted and inject the entire workflow. So those kinds of vulnerabilities are already well known. We published several articles about them and we thought about creating something else,

researching something else. Those kinds of vulnerabilities could be not detected by standard security tooling. Meaning, if we already know how to find command ejection vulnerabilities in workflows, let's try to think about something else. So we decided to map GitHub actions and try to map the entire components that users can use inside workflows. And one of those components was well, composite actions. So composite actions are like functions inside code. You call composite action, it is containing some code or calling another composite actions. So it runs specific procedures and maybe returns a result, maybe it's not.

It inputs some parameters, maybe it's not. So we decided to look for workflows that weren't vulnerable to command ejections, but use a composite action that were vulnerable to command ejection. So the Basel story starts right there, meaning a workflow, but that by itself wasn't vulnerable to any command ejection, just used two composite actions, command injection just used two composite actions, but the command injection was inside the composite actions. So it was way harder to find, way harder to maybe standard security tooling

to find this kind of vulnerability because the command injection wasn't in the workflow itself, but in a composite action, in a function, you can say that this workflow called inside the workflow. We'll be right back. And now a message from our sponsor Zscaler, the leader in cloud security. Enterprises have spent billions of dollars on firewalls and VPNs, yet breaches continue to rise by an 18% year-over-year increase in ransomware attacks

and a $75 million record payout in 2024. These traditional security tools expand your attack surface with public-facing IPs that are exploited by bad actors more easily than ever with AI tools. It's time to rethink your security. Zscaler Zero Trust plus AI stops attackers by hiding your attack surface, making apps and IPs invisible, eliminating lateral movement, connecting users only to specific apps, not the entire network. Continuously verifying every request based on identity and context. Simplifying security management with AI-powered automation. And detecting threats using AI to analyze over 500 billion daily transactions.

Hackers can't attack what they can't see. Protect your organization with Zscaler Zero Trust and AI. Learn more at zscaler.com slash security. So I understand here, I mean, it sounds like the composite actions are kind of code within code. So does that make it so that someone can change something within the composite action and then it might not be completely obvious to the user of that composite action that something has changed within it? So you cannot change the content of the composite action because like in the workflow itself,

are YAML files that are stored in a repository. In that case, it was another repository, also maintained by Bazel. But you can try to find command ejections, vulnerabilities in those composite actions and try to map what are the workflows that are using this kind of composite actions. So you cannot touch the content of the composite action, but you can try to find vulnerabilities inside that and try to roll it back and see what workflows are using this kind of composite actions.

So if a composite action is vulnerable to one kind of composite actions. So if a composite action is vulnerable to one kind of vulnerability, if a workflow is using that composite action, the workflow is vulnerable too. Well, tell us about the sample attack that you all put together here. What's going on? Of course, we tried to map GitHub and GitHub

actions, and we came across Bazel, the Bazel repository. So let's start from the beginning of the workflow. We saw a workflow that was being triggered on a milestone. A milestone is an event where a maintainer can mark an issue as milestone. So if a maintainer would milestone that issue and composite action a workflow will be triggered and a composite action will be called. And when investigating that composite action, we can see that that composite action was vulnerable to command ejection because it used the issue title

and issue body in an unsecured way. They passed directly the issue title to an inline script, the issue title to an inline script. Meaning if a user would tamper the issue body, for example, it would go to the workflow and then to the composite action and then inject the workflow from the composite action. And so what are your recommendations here for folks to protect themselves? I guess I should say first that you went through a disclosure process here with Google,

and they awarded you all a bounty. Yeah, so let's start with mitigation. It's unrecommended to pass directly user-controlled input into inline scripts in GitHub, in GitHub Actions. So the recommended manner here is to first declare those user inputs as environment variables, and then pass those environment variables into the build pipeline. So this process mitigates that issue. So Google took two procedures to fix that issue. The first one is the one that I just said. They declared environment variables and passed those environment variables to the inline script. The second manner they took was to lower the permissions as slow as possible of the workflow. In that case, they removed completely the workflow permissions.

If someone tried to inject code, even if they succeed, the workflow has no permissions and the attack vector will be lower. But of course, we want to remove the scenario of any injection, so they also mitigated that risk in the composite action. So those two completely removed the attack vector. Have you seen any examples of people using this technique in the wild? So, so far, we haven't seen any behavior like that. It all started by we researched new attack vectors of workflows. Then we mapped to see if there's any vulnerable workflows. And it came as a research purpose of us

for trying to learn and investigate in more attack vectors of workflows and then try to map using Raven and the entire surface and see if something is vulnerable in the area, in the field of GitHub actions. Bazel wants one of them, but we haven't seen such technique in the wild. And we hope that using the blog about the buzzer, others can take this example and avoid such scenarios using the recommendation, using everything that we suggested. Are you satisfied with the response that you've had from Google?

Yeah, Google were very quick. So we opened an issue to Google. We wrote a report using, and we detailed everything that we found, and we gave examples and everything that they needed. They quickly responded. They were very nice. It was very great to work with them.

And they acknowledged their vulnerability really quick. They mitigated the vulnerability, like I said, by lowering the permission of the workflow and mitigating their command injection vulnerability. And it was all very nice, very smooth, and like every vulnerability disclosure should be. So we're very glad and pleased with the disclosure process with them.

Our thanks to Elad, senior security researcher from Psycode. The research is titled, Psycode discovers a supply chain vulnerability in Basel. We'll have a link in the show notes. And now, a message from Black Cloak. Did you know the easiest way for cybercriminals to bypass your company's defenses is by targeting your executives and their families at home? Black Cloak's award-winning digital executive protection platform secures their personal devices, home networks, and connected lives. Because when executives are compromised at home, your company is at risk. In fact, over one-third of new members discover they've already been breached. Protect your executives and their families 24-7, 365 with Black Cloak.

Learn more at blackcloak.io. N2K Strategic Workforce Intelligence optimizes the value of your biggest investment, your people. We make you smarter about your team while making your team smarter. Learn more at n2k.com. This episode was produced by Liz Stokes. Our mixer is Elliot Peltzman. Our executive producers are Jennifer Iben and Brandon Karp. Our executive editor is Peter Kilby, and I'm Dave Bittner. Thanks for listening.

We'll see you back here next time.