AWS - Federation Abuse

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

SAML

SAML के बारे में जानकारी के लिए कृपया देखें:

SAML के माध्यम से एक पहचान संघ को कॉन्फ़िगर करने के लिए, आपको केवल एक नाम और मेटाडेटा XML प्रदान करने की आवश्यकता है जिसमें सभी SAML कॉन्फ़िगरेशन (एंडपॉइंट्स, सार्वजनिक कुंजी के साथ प्रमाणपत्र) शामिल हैं।

OIDC - Github Actions Abuse

एक github क्रिया को पहचान प्रदाता के रूप में जोड़ने के लिए:

  1. प्रदाता प्रकार के लिए, OpenID Connect चुनें।

  2. प्रदाता URL के लिए, https://token.actions.githubusercontent.com दर्ज करें।

  3. प्रदाता का थंबप्रिंट प्राप्त करने के लिए Get thumbprint पर क्लिक करें।

  4. Audience के लिए, sts.amazonaws.com दर्ज करें।

  5. एक नया भूमिका बनाएं जिसमें github क्रिया को आवश्यक अनुमतियाँ और एक विश्वास नीति हो जो प्रदाता पर विश्वास करती हो जैसे:

{ "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. पिछले नीति में ध्यान दें कि केवल एक **शाखा** को एक **संस्थान** के **भंडार** से एक विशिष्ट **ट्रिगर** के साथ अधिकृत किया गया था।
7. **भूमिका** का **ARN** जिसे github क्रिया **प्रतिनिधित्व** करने में सक्षम होगी, वह "गुप्त" होगा जिसे github क्रिया को जानने की आवश्यकता है, इसलिए इसे एक **गुप्त** के अंदर एक **पर्यावरण** में **स्टोर** करें।
8. अंत में, कार्यप्रवाह द्वारा उपयोग किए जाने वाले AWS क्रेडेंशियल्स को कॉन्फ़िगर करने के लिए एक github क्रिया का उपयोग करें:
```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 दुरुपयोग

# 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

यह संभव है कि EKS क्लस्टर में OIDC providers उत्पन्न किए जाएं, बस क्लस्टर के OIDC URL को नए Open ID Identity provider के रूप में सेट करके। यह एक सामान्य डिफ़ॉल्ट नीति है:

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

यह नीति सही ढंग से संकेत कर रही है कि केवल EKS क्लस्टर जिसका id 20C159CDF6F2349B68846BEC03BE031B है, वह भूमिका ग्रहण कर सकता है। हालाँकि, यह यह नहीं बता रहा है कि कौन सी सेवा खाता इसे ग्रहण कर सकता है, जिसका अर्थ है कि कोई भी सेवा खाता जिसमें एक वेब पहचान टोकन है वह भूमिका ग्रहण करने में सक्षम होगा।

जिस सेवा खाते को भूमिका ग्रहण करने में सक्षम होना चाहिए, उसे निर्दिष्ट करने के लिए, एक शर्त निर्दिष्ट करना आवश्यक है जहाँ सेवा खाता नाम निर्दिष्ट किया गया है, जैसे:

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

संदर्भ

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)

HackTricks का समर्थन करें

Last updated