2

Let's say the following scenario exists:

  • A git repository exists on Azure DevOps Repos.
  • The repository uses yaml pipelines (azure-pipelines.yml).
  • The repository has branch policies to ensure that changes go through pull requests.
  • The build pipeline has authorization to resources (Azure, Private Build Agent, etc.)

The advantage of having yaml pipelines is that changes to the pipeline can coincide with changes to the code base as part of the same pull request, and you can even have branch policies that if the azure-pipelines.yml file is modified, it requires the administrators to approve.

However, what I see as problematic (as an attack vector) is that someone could modify the yaml file and have that pipeline run through a pull request. One example is that the pipeline could run a malicious script on the build agent, and then the user could proceed to abandon the pull request and delete their branch, hiding their tracks... eventually the build history will get deleted as well. One example of something that would be malicious is to have the script run which watches the build agent and modifies source code files prior to compilation so that code which is deployed is now infected, giving back door access to even more resources. The possibilities are endless.

Are there others out there who have identified tools or methods to prevent such an attack? Any recommendations on how to approach this aside from abandoning yaml based build pipelines?

myermian
  • 121
  • 1

1 Answers1

1

The Azure team published guidelines on securing Azure pipelines. In case the link is down, here is my summary of some of the suggestions:

  1. Lock down repository permissions to limit the people who can open pull requests to a trusted set of people.
  2. Separate different projects into different repositories and lock down each repository for all but the people who are working actively on that project.
  3. Require a manual approval check before pipelines are run.
  4. Use templates with security checks. The templates must be in a separate repository that only a few key people have access to. Make sure that the workflow will be broken if the template include is maliciously removed or changed.

P.S. The GitHub team termed the exact scenario you're describing "pwn requests" in this blog post, and I just think that's an awesome name for it.

Aram Panasenco
  • 11
  • 1