In September of 2022, AWS announced an update to IAM role trust policy behavior.
At the time of the post nearly all IAM roles had been updated to use the new behavior and a small percentage (approximately 0.0001%) that relied on the old behavior were allowlisted into the older behavior. Over the past year and a half the number of allowlisted roles where reduced further as they were recreated or usage was updated to avoid relying on the previous behavior.
This modification in IAM Role trust policies overlapped with my examination of sts:AssumeRole, focusing on a niche scenario within IAM evaluation known as Implicit Self-Assume Role (Implicit SAR). Throughout this period, I explored various cases where I proposed that Implicit Self-Assume Role might result in unintuitive behavior, topics I will cover later.
By sharing these blog posts I hope to dive deeper into AWS’s original discussion, focusing on the potential exploitation of past behaviors of Implicit SAR.
If you would like to verify your roles are not allowlisted into the old behavior I would recommend reading through the original blog post by AWS. It is also worth noting that AWS has also recently added the explicitTrustGrant to AssumeRole log events to help detect legacy trust role behavior, this is covered in AWS’s post linked above and documented here.
The first couple of posts in the IAM Evaluation section below go over the basics of AssumeRole in the context of IAM and how Implicit SAR worked before the change. You can skip these if you want, just know these are there if they are helpful.
After that, I’ll cover a few attacks that may have been possible in the past with Implicit SAR. Starting with persistence with Bypassing Session Expirations and Revocations, then Modifying Session State to throw off auditing or potentially escalate privileges, finally in Attacking The Confused Deputy I’ll show how Implicit SAR can turn a few missing security best practices into a critical non-authenticated vulnerability chain resulting in the compromise of all customers of a SaaS Provider.
I started this post about a year and a half ago, but took me a long time to finish. After digging into this topic quite a bit I ended up just getting burnt out on it and set it away for a while.
I want to thank the AWS security team for reviewing this post, and separately, for the work that was put into updating the Role Trust behavior.
The mention of implicit SAR bypassing SCP enforcement of EC2 sessions in the Session Expirations and Revocations was originally brought up by Houston Hopkins.
The effect Implicit SAR had on Role Session Names, which is covered in Modifying Session State, was also mentioned in this blog post by Arkadiy Tetelman.
Aidian Steele also covers the same topic, along with the explicitTrustGrant CloudTrail attribute, which I reference later, in When AWS invariants aren’t [invariant].
Lastly, I want to thank Houston Hopkins and Nick Frichette for reveiwing and providing feedback the Implicit SAR summary post.