AWS CLI for an SSO User. ACM.127 AWS CLI commands with an AWS… | by Teri Radichel | Cloud Security | Jan, 2023

ACM.127 AWS CLI commands with an AWS SSO (AWS Identity Center) session — threat modeling and attack surface

$ aws sso login --profile my-dev-profile
  1. Configure a login profile (which only requires the start URL and a region as Ben Kehoe explains in the blog post above.)
  2. Run the login command in the CLI.
  3. Get the URL and code after running the command.
  4. Craft a link that automatically visits the URL and submits the code.
  5. Trick a user into clicking the link and then entering their AWS SSO (IAM Identity Center) credentials.
  6. Boom. The attacker has an active CLI session that can do whatever that user can do — including access any AWS account the user has access to as explained in Ben Kehoe’s post above.
  • The logout process is inconvenient and potentially confusing.
  • I’m not sure how you can terminate a session. I found this post which sounds like a cumbersome way to terminate a session for an AWS SSO user but I suppose it would work:
  • This is a shared URL not a URL that you control and can monitor for suspicious activity.
  • You can’t limit traffic to it from your own private network since it is a shared AWS URL.
  • Are there any confused deputy attacks that are possible using this approach? I haven’t thought about this at all yet.
  • What if a user used their SSO credentials to login and initiate a session and then passed the bearer token to the batch job. Then the user would have access to production credentials and the production bearer token. That option does not meet my requirements.
  • They first of all have to add a user for me into their primary AWS SSO / IIC directory (as opposed to granting my remote account and user permission to use a role in their account).
  • I’d have to enter my MFA device into their AWS account and directory to enable them to enforce MFA, which I do not want to do. I only want to store my MFA device information in my own account.
  • Is the SAML Implementation secure and free from potential Golden SAML and other types of SAML attacks? I haven’t had time to look into any of this. I presume AWS is doing a good job here but I haven’t personally analyzed and verified this or seen any documentation on it.
  • I have not yet had time to test enforcing all the conditions we are enforcing in this blog series, but I do not think we can enforce MFA on the AWS SSO roles if I remember correctly. More testing is needed.
  • I find AWS SSO confusing. The UI is cumbersome to me. Perhaps I am still used to AWS IAM but I find it easier to figure out what permissions a user or group has and in which accounts when using AWS IAM.
  • I need to explore that comment on the bearer token above further.
  • I would need to test it all out to prove or disprove my theories — but given I have so many reservations on it already I’m not going to spend more time on it.
  • Can I even disable automation for AWS SSO users? I don’t see an option to choose either programmatic access, console access, or both when creating an AWS SSO user. Does that mean that even if I never want to use automation with my AWS SSO users I can’t turn it off?

Source link