hacktricks-cloud/src/pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md

AWS - Federasie Misbruik

{{#include ../../../banners/hacktricks-training.md}}

SAML

Vir inligting oor SAML, kyk asseblief:

{{#ref}} https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html {{#endref}}

Om 'n Identiteitsfederasie deur SAML te konfigureer, moet jy net 'n naam en die metadata XML wat al die SAML-konfigurasie bevat (eindpunte, sertifikaat met publieke sleutel) verskaf.

OIDC - Github Aksies Misbruik

Om 'n github aksie as Identiteitsverskaffer by te voeg:

1. Vir Verskaffer tipe, kies OpenID Connect.
2. Vir Verskaffer URL, voer https://token.actions.githubusercontent.com in.
3. Klik op Kry duimafdruk om die duimafdruk van die verskaffer te kry.
4. Vir Doelgroep, voer sts.amazonaws.com in.
5. Skep 'n nuwe rol met die toestemmings wat die github aksie benodig en 'n vertrouensbeleid wat die verskaffer vertrou soos:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::0123456789:oidc-provider/token.actions.githubusercontent.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "token.actions.githubusercontent.com:sub": [ "repo:ORG_OR_USER_NAME/REPOSITORY:pull_request", "repo:ORG_OR_USER_NAME/REPOSITORY:ref:refs/heads/main" ], "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" } } } ] }

6. Let op in die vorige beleid hoe slegs 'n **tak** van 'n **bewaarplek** van 'n **organisasie** met 'n spesifieke **trigger** gemagtig was.
7. Die **ARN** van die **rol** wat die github aksie gaan kan **naboots**, gaan die "geheim" wees wat die github aksie moet weet, so **stoor** dit binne 'n **geheim** binne 'n **omgewing**.
8. Laastens, gebruik 'n github aksie om die AWS krediete te konfigureer wat deur die werksvloei gebruik gaan word:
```yaml
name: "test AWS Access"

# The workflow should only trigger on pull requests to the main branch
on:
pull_request:
branches:
- main

# Required to get the ID Token that will be used for OIDC
permissions:
id-token: write
contents: read # needed for private repos to checkout

jobs:
aws:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v3

- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v1
with:
aws-region: eu-west-1
role-to-assume:${{ secrets.READ_ROLE }}
role-session-name: OIDCSession

- run: aws sts get-caller-identity
shell: bash

OIDC - EKS Misbruik

# Crate an EKS cluster (~10min)
eksctl create cluster --name demo --fargate

# Create an Identity Provider for an EKS cluster
eksctl utils associate-iam-oidc-provider --cluster Testing --approve

Dit is moontlik om OIDC providers in 'n EKS kluster te genereer deur eenvoudig die OIDC URL van die kluster as 'n nuwe Open ID Identiteitsverskaffer in te stel. Dit is 'n algemene standaardbeleid:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::123456789098:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B:aud": "sts.amazonaws.com"
}
}
}
]
}

Hierdie beleid dui korrek aan dat slegs die EKS-kluster met id 20C159CDF6F2349B68846BEC03BE031B die rol kan aanvaar. Dit dui egter nie aan watter diensrekening dit kan aanvaar nie, wat beteken dat ENIGE diensrekening met 'n webidentiteitskennisgewing in staat gaan wees om die rol te aanvaar.

Om te spesifiseer watter diensrekening die rol moet kan aanvaar, is dit nodig om 'n voorwaarde te spesifiseer waar die diensrekeningnaam gespesifiseer word, soos:

"oidc.eks.region-code.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B:sub": "system:serviceaccount:default:my-service-account",

Verwysings

• https://www.eliasbrange.dev/posts/secure-aws-deploys-from-github-actions-with-oidc/

{{#include ../../../banners/hacktricks-training.md}}