gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-01-09 03:40:59 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/README.md', 'src/banners/hacktricks-training.md', 'src/

Browse Source
This commit is contained in:
Translator
2024-12-31 20:29:08 +00:00
parent 2753c75e8b
commit 396dbafaf2
245 changed files with 9878 additions and 12609 deletions
Download Patch File Download Diff File Expand all files Collapse all files

160
src/pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md
View File

@@ -1,87 +1,84 @@
# AWS - Federation Abuse
# AWS - Federasie Misbruik
{{#include ../../../banners/hacktricks-training.md}}
## SAML
For info about SAML please check:
Vir inligting oor SAML, kyk asseblief:
{{#ref}}
https://book.hacktricks.xyz/pentesting-web/saml-attacks
{{#endref}}
In order to configure an **Identity Federation through SAML** you just need to provide a **name** and the **metadata XML** containing all the SAML configuration (**endpoints**, **certificate** with public key)
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 Actions Abuse
## OIDC - Github Aksies Misbruik
In order to add a github action as Identity provider:
1. For _Provider type_, select **OpenID Connect**.
2. For _Provider URL_, enter `https://token.actions.githubusercontent.com`
3. Click on _Get thumbprint_ to get the thumbprint of the provider
4. For _Audience_, enter `sts.amazonaws.com`
5. Create a **new role** with the **permissions** the github action need and a **trust policy** that trust the provider like:
- ```json
{
"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. Note in the previous policy how only a **branch** from **repository** of an **organization** was authorized with a specific **trigger**.
7. The **ARN** of the **role** the github action is going to be able to **impersonate** is going to be the "secret" the github action needs to know, so **store** it inside a **secret** inside an **environment**.
8. Finally use a github action to configure the AWS creds to be used by the workflow:
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 _Teiken_, 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:
- ```json
{
"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** gemagtig was met 'n spesifieke **trigger**.
7. Die **ARN** van die **rol** wat die github aksie gaan kan **naboots**, gaan die "geheime" 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 kredensiale 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
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
id-token: write
contents: read # needed for private repos to checkout
jobs:
aws:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v3
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
- 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
- run: aws sts get-caller-identity
shell: bash
```
## OIDC - EKS Abuse
## OIDC - EKS Misbruik
```bash
# Crate an EKS cluster (~10min)
eksctl create cluster --name demo --fargate
@@ -91,43 +88,34 @@ eksctl create cluster --name demo --fargate
# Create an Identity Provider for an EKS cluster
eksctl utils associate-iam-oidc-provider --cluster Testing --approve
```
It's possible to generate **OIDC providers** in an **EKS** cluster simply by setting the **OIDC URL** of the cluster as a **new Open ID Identity provider**. This is a common default policy:
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:
```json
{
"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"
}
}
}
]
"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 webidentiteitskenmerk** in staat gaan wees om die rol te aanvaar.
This policy is correctly indicating than **only** the **EKS cluster** with **id** `20C159CDF6F2349B68846BEC03BE031B` can assume the role. However, it's not indicting which service account can assume it, which means that A**NY service account with a web identity token** is going to be **able to assume** the role.
In order to specify **which service account should be able to assume the role,** it's needed to specify a **condition** where the **service account name is specified**, such as:
Om te spesifiseer **watter diensrekening die rol moet kan aanvaar,** is dit nodig om 'n **voorwaarde** te spesifiseer waar die **diensrekeningnaam gespesifiseer word**, soos:
```bash
"oidc.eks.region-code.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B:sub": "system:serviceaccount:default:my-service-account",
```
## References
## Verwysings
- [https://www.eliasbrange.dev/posts/secure-aws-deploys-from-github-actions-with-oidc/](https://www.eliasbrange.dev/posts/secure-aws-deploys-from-github-actions-with-oidc/)
{{#include ../../../banners/hacktricks-training.md}}