I’d like to end the Implicit SAR series with a critical assessment of what we’ve covered so far by answering a few withstanding questions directly. I’ll keep things shorter and to the point here but if you’re just jumping and feel you missed something you can find an introduction to the Implicit SAR series here.
I’ll start this post with a quick review of the attack’s we’ve covered so far that Implicit SAR enabled.
Nearly all high-privilege IAM roles were unexpectedly able to bypass session expirations and revocations until detection or role deletion.
IAM Role session state which was expected to be invariant in certain IAM deployments could be modified by an attacker when a role is affected by Implicit SAR. This may result in the ability to escalate privileges or misattribute logs made by the attacker to another user.
This can be broken up into two separate attacks:
Implicit SAR allowed an unauthenticated attacker to gain access to the IAM Role used by a SaaS provider for accessing customer environments when this role did not explicitly deny sts:AssumeRole access to itself. This cross-account role could be used
through the capabilities of the SaaS platform, restricted by the combination of permissions on the role and the resource policies in the account.
Depending on the features of the SaaS platform this may result in unrestricted access to customer’s AWS accounts using existing IAM role trusts.
In the previous posts, I didn’t touch on the fact this was an undocumented behavior, so I’d like to make sure that’s clear here.
Implicit SAR was an undocumented feature of IAM in that the documentation implied it should not work, and that no tooling available at the time indicated it was a possibility:
Back in 2019, Houston Hopkins also discovered Implicit SAR and identified it as a potential bypass for the data perimeter controls built to protect against attacks similar to the 2019 Capital One breach. This behavior was identified as a method to convert instance roles into regular assume role credentials, which in turn, allowed bypassing SCPs which restricted the use of EC2 Instance Profile credentials. The behavior was reported to the IAM/STS team, and he was told Implicit SAR was an “undocumented feature” that worked by design.
This surprised me when I learned this because this is an incident that made it clear the importance of this specific control, yet it wasn’t until several years later when I accidentally stumbled on Implicit SAR while working on liquidswards and intended to disclose the behavior at fwd:CloudSec 2022, that action was taken by AWS.
However, regardless of the exact reasoning behind this being addressed in 2022, what concerns me more is that it shouldn’t be the responsibility of customers to rediscover undocumented behavior when that behavior is known to have unintended side effects on security. Furthermore, undocumented behavior like this in IAM, which is either known internally or where the documentation implies a deny but the result is an allow, simply should not be a problem.
I don’t think this is very controversial, so I’m hoping AWS can comment on whether this will be considered a bug internally, rather than a feature, in the future.
Yes, or more specifically it can be considered the root cause of several different vulnerabilities.
The fact is, we ultimately rely on accurate and transparent documentation of AWS to build secure infrastructure. Because Implicit SAR was both unintuitive and undocumented, customers had no reasonable ability to protect themselves against or detect the attacks I covered previously.
Yes. If you use the console to create a role to be assumed by an AWS account and use the default ‘this account’ option, then the trust policy will list the account itself, and so any principal in the account (including the role in question) that has sts:AssumeRole privileges can assume the role. This can have similar behavior in some of the scenarios previously covered, but it is fundamentally different in that Implicit SAR was both unexpected and undocumented.
Personally, I have some ongoing concerns about the last attack I covered which I’ll cover here along with a few clarifications to my previous post.
sts:ExternalID Protected from Attacking the Confused Deputy?No, sts:ExternalID has no effect in this situation for two reasons:
First, calling sts:AssumeRole with sts:ExternalID set on a role that does not require will not cause the AssumeRole attempt to fail.
But, more specifically, even in the cases where sts:ExternalID is required on the SaaS provider’s role, for example, if they are dogfooding their own product. The sts:ExternalID requirement would have been ignored during the Implicit SAR evaluation.
I believe it’s fairly easy for us to reason that many SaaS providers that used IAM roles were likely affected in some form, however to what degree, or whether this had a material risk on customers is difficult to answer.
This is based on the observation that SaaS providers will need to use "sts:AssumeRole": "*" to avoid IAM policy size limits as well as avoid updating the IAM policy each time a new customer is onboarded. Secondly, as covered above, AWS made no indication the behavior required to exploit this existed before September 2022.
The primary blocker for this attack I believe comes down to whether the platform soft or hard fails on partial access, and whether, access in the same account or organization was denied or not. However, on the second point, how many SaaS providers take this arguably unnecessary pre-caution is uncertain. I’ve never come across any public documentation or blog posts encouraging SaaS providers to explicitly deny same-account access before my mention of it in Attacking the Confused Deputy. Furthermore, many SaaS providers are still struggling with fairly basic issues that have already been well documented, which does not instill confidence this is a commonly implemented mitigation.
Not likely. I’m not aware of this being exploited previously and new occurrences of this attack would be unlikely due to AWS’s change in role behavior. However, ongoing self-assume behavior can lock roles into the previous Implicit SAR behavior which means providers may still be susceptible either through accidental role re-assumption or by having previously been targeted by this attack.
Additionally, since the Attacking the Confused Deputy attack had the potential to target customer’s accounts directly you may want to verify your SaaS providers were not affected previously. Among other persistence techniques, some SaaS providers require customer roles to be self-assumable which allows for persistence through self-role juggling as I previously covered in Bypassing Session Expirations and Revocations.
So while I don’t believe there’s much need for most people to worry about this, I would encourage SaaS providers, as well as others concerned to thoroughly investigate the previous possibility of this attack.
I recommend checking with your SaaS providers as they would need to dig into their specific configuration and platform thoroughly to answer this question accurately. However, you may also be able to verify their answer to some degree by configuring a SaaS account with a cross-account role that has no permissions. If you can retrieve you’re own session credentials through any feature of the SaaS provider, it is a good indicator that they were vulnerable to the full attack described in Attacking the Confused Deputy which results in the attacker being able to access all customer’s accounts. If you can get this far, the SaaS provider needs to ensure they were explicitly denying access to their own role, or more likely, as this was undocumented, all roles in the current account using an explicit Deny condition prior to migrating to a new IAM Role not affected by Implicit SAR.
Conversely, if there is no possibility of account credentials being passed to user-controlled code, either now, or in the past, you can rule out the most direct method of accessing customer’s accounts with this attack.
I was thinking last night about what the underlying problem is that led to the Attacking the Confused Deputy scenario being possible and I think it has to do with an underlying difference, and confusion, between machine and user authentication. I’m not an expert on AuthN, but with sts:AssumeRole there is no difference between them, which may lead to defaults that may make sense for one but not the other? I’m not sure how this correlates to alternatives, but the main example I’m thinking of here is how sts:ExternalID doesn’t cause a request to fail when it is not enforced on the target role. I suspect this would be a rather obvious design decision if it weren’t for the dual-purpose nature of IAM Roles.
Anyway, while I have some ongoing concerns about the Attacking the Confused Deputy scenario, the point I want to get across here is more related to the fact that this behavior was ever undocumented. I don’t know what the solution for this is, I’d like to see IAM open-sourced, but is that even possible? What about a model of how it works, something beyond written English, more like a spec? Would this include edge cases from various teams? I would imagine there is an internal process for making exceptions to the commonly documented model, or at least I hope so. Is there a place where we can find these listed? I haven’t seen it if it exists, but maybe I haven’t looked hard enough (i actually don’t feel like looking right now… let me know if it does though).
Lastly, I appreciate that AWS ultimately decided to change the Role Trust behavior. So while I may be critical here, and have some outstanding concerns, it is worth remembering the underlying cause of these issues was fixed provided your roles have been recreated since the change, or alternatively followed the instructions described in AWS’s original announcement.