6.2 KiB
AWS - Federation Abuse
{{#include ../../../banners/hacktricks-training.md}}
SAML
SAML के बारे में जानकारी के लिए कृपया देखें:
{{#ref}} https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html {{#endref}}
SAML के माध्यम से एक पहचान संघ को कॉन्फ़िगर करने के लिए, आपको केवल एक नाम और मेटाडेटा XML प्रदान करने की आवश्यकता है जिसमें सभी SAML कॉन्फ़िगरेशन (एंडपॉइंट्स, सार्वजनिक कुंजी के साथ प्रमाणपत्र) शामिल हैं।
OIDC - Github Actions Abuse
एक github क्रिया को पहचान प्रदाता के रूप में जोड़ने के लिए:
- Provider type के लिए, OpenID Connect चुनें।
- Provider URL के लिए,
https://token.actions.githubusercontent.comदर्ज करें। - प्रदाता के थंबप्रिंट को प्राप्त करने के लिए Get thumbprint पर क्लिक करें।
- Audience के लिए,
sts.amazonaws.comदर्ज करें। - एक नया भूमिका बनाएं जिसमें अनुमतियाँ हों जो 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 क्रिया **प्रतिनिधित्व** करने में सक्षम होगी, इसलिए इसे एक **गुप्त** के अंदर एक **पर्यावरण** में **स्टोर** करें।
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",
संदर्भ
{{#include ../../../banners/hacktricks-training.md}}