Migrate to using mdbook

2026-01-07 02:03:45 -08:00 · 2024-12-31 17:04:35 +01:00
parent b9a9fed802
commit cd27cf5a2e
1373 changed files with 26143 additions and 34152 deletions
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md
@@ -0,0 +1,103 @@
+# AWS - IAM Post Exploitation
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+## IAM
+
+For more information about IAM access:
+
+{{#ref}}
+../aws-services/aws-iam-enum.md
+{{#endref}}
+
+## Confused Deputy Problem
+
+If you **allow an external account (A)** to access a **role** in your account, you will probably have **0 visibility** on **who can exactly access that external account**. This is a problem, because if another external account (B) can access the external account (A) it's possible that **B will also be able to access your account**.
+
+Therefore, when allowing an external account to access a role in your account it's possible to specify an `ExternalId`. This is a "secret" string that the external account (A) **need to specify** in order to **assume the role in your organization**. As the **external account B won't know this string**, even if he has access over A he **won't be able to access your role**.
+
+<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
+
+However, note that this `ExternalId` "secret" is **not a secret**, anyone that can **read the IAM assume role policy will be able to see it**. But as long as the external account A knows it, but the external account **B doesn't know it**, it **prevents B abusing A to access your role**.
+
+Example:
+
+```json
+{
+  "Version": "2012-10-17",
+  "Statement": {
+    "Effect": "Allow",
+    "Principal": {
+      "AWS": "Example Corp's AWS Account ID"
+    },
+    "Action": "sts:AssumeRole",
+    "Condition": {
+      "StringEquals": {
+        "sts:ExternalId": "12345"
+      }
+    }
+  }
+}
+```
+
+> [!WARNING]
+> For an attacker to exploit a confused deputy he will need to find somehow if principals of the current account can impersonate roles in other accounts.
+
+### Unexpected Trusts
+
+#### Wildcard as principal
+
+```json
+{
+  "Action": "sts:AssumeRole",
+  "Effect": "Allow",
+  "Principal": { "AWS": "*" }
+}
+```
+
+This policy **allows all AWS** to assume the role.
+
+#### Service as principal
+
+```json
+{
+  "Action": "lambda:InvokeFunction",
+  "Effect": "Allow",
+  "Principal": { "Service": "apigateway.amazonaws.com" },
+  "Resource": "arn:aws:lambda:000000000000:function:foo"
+}
+```
+
+This policy **allows any account** to configure their apigateway to call this Lambda.
+
+#### S3 as principal
+
+```json
+"Condition": {
+"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
+    "StringEquals": {
+        "aws:SourceAccount": "123456789012"
+    }
+}
+```
+
+If an S3 bucket is given as a principal, because S3 buckets do not have an Account ID, if you **deleted your bucket and the attacker created** it in their own account, then they could abuse this.
+
+#### Not supported
+
+```json
+{
+  "Effect": "Allow",
+  "Principal": { "Service": "cloudtrail.amazonaws.com" },
+  "Action": "s3:PutObject",
+  "Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
+}
+```
+
+A common way to avoid Confused Deputy problems is the use of a condition with `AWS:SourceArn` to check the origin ARN. However, **some services might not support that** (like CloudTrail according to some sources).
+
+## References
+
+- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)
+
+{{#include ../../../banners/hacktricks-training.md}}