Azure Devops Zero-Click CI/CD Vulnerability

The Legit Security research team has found and reported a zero-click attack that allowed attackers to submit malicious code and access secrets. The vulnerability does not require any action from the project maintainer, making it a zero-click supply chain vulnerability.

In this blog post, we will introduce CVE-2023-36561 - a vulnerability in Azure Pipelines that allows an attacker to access secrets and internal information and perform actions in elevated permissions in the context of a pipeline workflow. This could allow attackers to move laterally in the organization and initiate supply chain attacks.

This vulnerability is not the first Azure Pipelines vulnerability discovered by the team. For more information about our previous discovery, read the blog post.

Our research was focused on the question: "What can be achieved if a malicious user forks your GitHub repository?" As we know, GitHub took extra security measures and prevented first-time contributors from running GitHub Actions. We wanted to explore the option to perform a “zero-click” supply chain attack. As we looked for other risky patterns, we encountered many GitHub repositories using Azure Pipelines.

Azure Pipelines and GitHub forks

Azure Pipelines allows building pull requests from forks by default, which seems to be dangerous. Microsoft knows it as well.

Microsoft also warns the users in the docs of two risks in their default behavior:

1. Leak secrets from your pipeline
2. Compromise the machine running the agent to steal code or secrets from other pipelines

Now that we understand the attack surface, let's see which security mitigations are in place (from here):

We have demonstrated in the past how such mitigations can be bypassed, for example, using GitHub's workflow_run trigger. Let's examine the Azure Pipelines' equivalent technique.

Exploiting Pipeline Triggers

Pipeline triggers were created to enable running a second pipeline as soon as the first one finished. A popular use case for pipeline triggers is using the first pipeline to perform tests, and only if the tests pass, use the second pipeline to release a new artifact.

Let's look at the pipeline trigger syntax:

Pipeline A

Pipeline B

As seen in the two images above, we have created two pipeline scripts. When a pipeline is triggered by a "pipeline resource trigger," it shows in the platform as "Automatically Triggered For …"

Example of how two pipeline triggers appear on Azure Pipelines

Instead of running in fork default permissions, preventing any access to secrets and sensitive actions, Azure Pipelines "confuses" the trigger for an internal build allowing us to execute our edited pipeline with access to secrets. Let’s recap what’s happened here - we opened a PR, it ran our own malicious code, and we were able to access sensitive build secrets like cloud keys. This is a zero-click attack!

In the video below, you can see a full demo of the attack with our explanation.

Vulnerability Exploitation Demo

Estimating the Blast Radius

There are three conditions for a project to be vulnerable:

1. Public GitHub repository that runs Azure pipelines on pull-request
2. Use default Azure pipeline fork configurations to trigger pipeline run
3. The project is using Pipeline-Triggers

There is no public information about how many open-source projects use Azure Pipelines. In order to estimate how many GitHub-hosted open-source projects use Azure Pipelines, we looked at the readme.md badge. The status badge helps collaborators find the status of their current build or test inside Azure Pipelines. We found over 70,000 open-source projects that run Azure Pipelines on pull requests from external collaborators by default. However, we estimate that many more projects use Azure Pipelines without adding the status badge to their readme.md page. It is difficult to estimate, out of these projects, how many projects are using Pipeline-Triggers (condition number 3), so the number of vulnerable projects is smaller than the number of total projects meeting conditions (1) and (2).

Azure Pipelines status badge taken from Microsoft’s PowerToys readme.md file

Azure DevOps Security Enhancements

Along with the fix for the vulnerability. The Azure DevOps team has also made it easier for organizations to control at organization-level the policy with respect to building pull requests from forked GitHub repos. You can read more about it in their release notes. The new toggle adds the warning of the high risks in running pipelines in external forks. The Legit Security platform detects and alerts for such misconfigurations in your Azure DevOps organization.

Summary

Allowing remote attackers complete control over your pipeline can have critical implications for your organization. An attacker can create a fully anonymous GitHub account, fork your repository and gain complete control over your organization's secrets. The attacker could then escalate this vulnerability by leveraging exfiltrated secrets and access keys to achieve lateral movement. This vulnerability was disclosed as a high-severity information disclosure impact.  

Timeline

• May 23, 2023: Vulnerability was reported to MSRC
• July 7, 2023: The vulnerability was acknowledged as an “Information Leak”
• July 11, 2023: Bounty awarded
• Aug 8, 2023: The vulnerability was updated to be “Elevation of privileges”
• Oct 10, 2023: A fix released for Azure DevOps Services CVE-2023-36561 - builds triggered by a forked PR build will act as they are forked as well, so they would obey the same restrictions.

Legit Security Can Help You Prevent Software Supply Chain Attacks

The Legit Security platform connects to your Azure DevOps environment and detects attack attempts in your pipeline and much more. If you are concerned about these vulnerabilities and others across your software supply chain, don't hesitate to contact us or request a demo on our website.