AWS CLI for an SSO User

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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Part of my series on Automating Cybersecurity Metrics. The Code.

🔒 Related Stories: AWS Security | Application Security | IAM

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

FYI, I’m not getting paid for anyone who reads or claps on this store by Medium for some unknown reason. If you like this story please read and clap on the story in this blog to show your support.

Some Stories Receiving No Payment on Medium for No Apparent Reason

~~

In my last post I showed you how we might add a new group and permission set in AWS SSO to manage domain names in a separate AWS account.

AWS SSO (IAM Identity Center) for Separation of Duties

Now let’s say we want to grant that user access to use the AWS CLI to manage DNS configuration. How can we do that? There’s no concept of access keys for an AWS SSO user.

Note that I wrote about problems with the AWS CLI with SSO (AWS IAM Identity Center) below and I explain how AWS could fix it here:

How to Fix AWS IAM Identity Center

Using AWS CLI profile for an IAM user with cross-account access

I explained how to create trust policies to allow a user in one account to run commands in another account in this post. The policy can enforce MFA and use an external ID to prevent a confused deputy attack. I use these types of policies when performing penetration tests and security assessments on customer accounts. The customer has a bit more confidence that only I am accessing their account due to the enforcement of MFA and use of the external ID.

Cross account AWS IAM roles with external IDs and MFA

Then we can create a profile that uses the matching external ID add a specific MFA device to the AWS profile configuration matching the device in the related trust policy.

Using an AWS CLI Profile with MFA

I explained why we need the external ID to prevent the confused deputy attack:

Confused Deputy Attack in IAM, Resource, and AssumeRole Policies

Specifying the Roles an IAM Identity Can Assume

Creating an AWS CLI Profile for an AWS SSO user

This documentation explains how to configure the AWS CLI for an SSO User, and the recommended option is the SSO token provider configuration.

Configuring the AWS CLI to use AWS IAM Identity Center (successor to AWS Single Sign-On)

Essentially you can configure an AWS CLI profile automatically or manually like we did for our other cross-account roles using IAM but the format is going to look different. As you can see below there is a new sso_session option where you define your start URL and region.

Then you set up your account profiles with some different options: sso_session, sso_account_id, sso_role_name.

You also set up one login profile that only requires a region and a start url.

This is interesting:

However, sso_account_id and sso_role_name aren't required for all scenarios of SSO token configuration. If your application only uses AWS services that support bearer authentication, then traditional AWS credentials are not needed.

So is this:

The authentication token is cached to disk under the ~/.aws/sso/cache directory with a filename based on the session name.

Obviously if an attacker gets access to the cache directory, that’s a problem.

The session duration is controlled by the associated permission set. (AWS Identity Center (SSO) permission sets were covered in my last post.)

Set session duration

Using the AWS SSO CLI profile

So how do you use the AWS SSO CLI profile?

You have to interact with a browser.

Run a command like this:

$ aws sso login --profile my-dev-profile

This prompts you to open up a browser an enter a code (similar to how Azure works in some scenarios):

IAM Identity Center uses the code [the random code generated above which is QCFK-N451] to associate the IAM Identity Center session with your current AWS CLI session. The IAM Identity Center browser page prompts you to log in with your IAM Identity Center credentials. This gives permissions to the AWS CLI to retrieve and display the AWS accounts and roles that you are authorized to use with IAM Identity Center.

Presumably if your credentials require MFA you also have to enter your second factor (via a hardware or virtual MFA device).

Then you can see the accounts you are allowed to access, pick one, and run commands.

If you really want to dive into all the details, Ben Kehoe wrote this great post which goes into more details about how this all works. There’s some Q & A in the comments about caching sessions at the end as well.

You only need to call `aws sso login` once for all your profiles

Things I don’t like about the SSO browser-based approach for the AWS CLI

I have to provide the URL where I log into AWS SSO (IIC) in a configuration file

I would rather not have that information in a configuration file on a host where I execute automation. I tend to keep my browser logins to the AWS console on a separate machine from the host where I run automation. I give my automation credentials different levels of permissions than I give users that login to the AWS console.

The idea of using a single code to associate an active SSO session with an AWS CLI session seems risky.

What could an attacker try to do to run commands in your account by leveraging this functionality?

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.

Is that really all that it requires for an attacker to link their CLI session with your user’s AWS SSO session?

Entering codes in shared authentication websites is a common source of attack

Getting users to enter codes in fake websites was the premise of the Oktapus attack I wrote about here:

Oktapus

This approach gets users to enter codes in a common website used by all AWS users in a particular region. It would be easy to craft a lookalike page and try to trick a user to login to that generic page.

You won’t be able to login with your SSO user and use a Yubikey for MFA on a remote virtual machine

If you use a Yubikey as the MFA device for your AWS SSO user, you will not be able to log into the SSO page that links your SSO session to your CLI session on the remote VM. That’s because you cannot physically plug your Yubikey into the remote machine.

There’s an approach for generating codes with a Yubikey and I wrote about why I don’t like that here.

The Yubikey CLI and AWS MFA

If you could think of a way to transfer that code via software to the remote machine then that defeats the purpose of a HARDWARE security key and introduces additional attack surface.

It appears that you can register both a Yubikey and a virtual MFA device in AWS SSO but I haven’t tried it yet. You could use a code in the browser instead in your remote machine but see all the browser attack issues above. When I’m authenticating via a website, I prefer to use a Yubikey, if possible.

Browser as attack surface

Adding the browser into the process to link a session initiated in a browser to a CLI session increases the attack surface, compared to the AWS IAM approach where a user enters a code in a terminal window.

Browsers may be compromised via web extensions like this one:

Experts Warn of Browser Extensions Spying On Users via Cloud9 Chrome Botnet Network

Make sure to warn your users not to install untrusted web extensions (or any if possible).

Browsers interact with many different web pages and can become infected in different ways.

Here’s an interesting book on browser hacks if you want to know more:

The Browser Hacker’s Handbook gives a practical understanding of hacking the everyday web browser and using it as a beachhead to launch further attacks deep into corporate networks.

The Browser Hacker's Handbook

In addition to inserting themselves into browser sessions, browsers may be subject to more complex use after free vulnerabilities and similar that get down into the bits and bytes of code and access memory they shouldn’t. What if your AWS session credentials are in that particular space in memory?

For example:

I got that from gbhackers.com but I recommend looking up the CVEs in NIST directly.

One of those came from China’s biggest hacking competition — the Tianfu Cup.

Keep web browsers up to date as attackers often try to attack them using known vulnerabilities. More and more attackers are using zero days (see my book at the bottom of this post) to attack systems. Browsers have an immense amount of code to provide a lot of functionality and a broad attack surface. It seems like using a terminal window is a smaller attack surface.

That said, I am going to use a browser for my batch job authentication process but I’m going to avoid the generic AWS login page and single code to link SSO sessions with automated actions.

Automating MFA for AWS Batch with AWS SSO

How would leverage the AWS SSO approach to authenticating CLI commands with an AWS Batch automation flow? Let’s say we were going to use the AWS CLI in a batch job. We’d be executing a command inside a batch job and the job could potentially capture the URL and submit the code via curl or some other method. But then the response would prompt for credentials and it’s a non-interactive process, so that doesn’t work.

What if we program the job to email or text the URL and code to a user?

First of all, the user would need to respond and login before the request to provide credentials times out. I mentioned that in a prior post.

How may ways could that email or text message be intercepted by an attacker? That increases the attack surface. It also introduces the possibility of a phishing attack.

Once the user gets the email or text, how would they be able to verify what that code was for exactly and that it was legitimate and not a spoofed email with a link and code to authenticate an attacker CLI session? The AWS URL will be the same either way. The code is meaningless. It’s just a random code.

There’s a huge potential for attacker race conditions with this approach. What if the attacker can send their own code before the batch job can send it’s code to the user or simply intercepts and blocks the real code from getting to the user?

Well to allow the user to validate what the code is for, we would have to provide an interface and track the code and what it was associated with.

The problem is that there’s no way to enforce a user to verify the code is for something legitimate before logging in to associate the CLI session with their own AWS SSO session.

This just seems far too risky. Maybe I’m missing something but for now I’m going to skip this option and leverage another approach.

Let’s consider some other potential issues with this approach per my research and Ben Kehoe’s post:

• 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:

How to revoke a user session when using AWS SSO?

• 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.

I’m just not sure this approach can be secured as easily or even at all compared to the other approach I want to try, but I’ll keep thinking through it as I work through these posts to make sure I’m not missing something. This whole process seems very risky.

The problem with AWS SSO for external assessments

The biggest problem for me is that it doesn’t really work if I’m trying to perform a penetration test or security assessment for a customer and enforce MFA. If I am running commands against a customer account two things have to happen which neither the customer and I will like:

• 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.

Some other concerns with AWS SSO / AWS IAM Identity Center

These are some of the other concerns I have in general with the implementation of AWS SSO that I still need to research further.

• 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?

My initial conclusion…

I am going to continue using AWS IAM users and credentials for automation with virtual MFA. I am going to leverage limited SSO users to login to the AWS console with hardware security key as I continue to investigate and assess all the above issues.

And then…I discovered this proof of concept (Thank you!)

I was too interested in moving on to the rest of my Batch job implementation to login and try to prove all my theories above. But after writing this entire post, I was checking some of my facts such as looking for a way to terminate an existing SSO session and ran across this article:

Phishing for AWS credentials via AWS SSO device code authentication

Thank you for providing working examples of my presumptions so I don’t have to prove what I’m writing about is a problem. :) Great post. It pretty much demonstrates some of my concerns above and provides a tool for phishing device codes.

Notable bits:

It’s also not possible to use a SCP to restrict the calls to sso-oidc:CreateToken to certain conditions, since this API call is performed against the organization master account (which is not subject to SCPs).

Well, I can’t use an SCP to limit programmatic access but perhaps I can limit SCP access in another way such as adding a not to a policy?

and

In terms of detection, the initial calls to sso-oidc:RegisterClient and sso-oidc:StartDeviceAuthorization are not logged to CloudTrail since they are performed without authentication, and not against a specific AWS account of the organization.

The article does provide some tips to get clues from CloudTrail.

Alert on unusual source IPs of sso-oidc:CreateToken events

…or possibly can limit to the organization’s network IP range.

Unfortunately, without knowing the SSO access token value, there is no documented way to revoke it. Manually disabling an user in the AWS SSO identity directory does not immediately invalidate its access tokens. Same goes if you use a third-party IdP such as Okta; disabling a compromised user in Okta doesn’t help if an attacker already stole its AWS SSO access token. I reported this issue to the AWS security team, and they clarified the following:

AWS response:

AWS SSO caches user attributes when they login to the user portal and refreshes them hourly to grant/revoke additional access. If you want to revoke all user access before any 1-hour period expires, you can do so by removing all assignments to the permission sets and accounts the user has access to.

We are already working towards an explicit session revocation feature for the SSO user portal.

^^^^ That’s good!! Faster, please. #awswishlist

Update — this has been added. When I login to administer AWS IAM Identity Center, click on a user, then Active sessions. Check the session you want to delete and click Delete session.

Not sure if this is documented yet as I couldn’t find it when searching when writing this post, but it probably will be soon.

It seems like the crux of the problem here is that allowing a link from an AWS CLI session to an AWS SSO (IAM Identity Center) session is not started from within the AWS console where a user has an active session after first authenticating — hopefully with MFA. The “code” used to link the user login to an AWS SSO session comes from any random AWS CLI login command and may not be coming from the SSO user at all.

It seems like the user should first login to the AWS console and generate a code (or, um, an AWS programmatic credential like AWS developer keys?) and should have to provide those in the configuration of the AWS profile in order to link a session to a user instead of the other way around. The code (or developer credentials if you will) should be visible in the AWS console after they are generated by the user that owns them and whom they identify.

Then when a command attempts to execute…require an MFA token if that’s what the organization wants to assume roles. Like AWS IAM. Like I’m doing in this blog series.

The code (or credentials) plugged into the AWS CLI profile after generating it in the AWS console could be associated with every account an SSO user has access to — like AWS developer credentials, but at the organizational level — to facilitate the functionality that the AWS SSO CLI authentication and authorization mechanism currently provides. If you want short lived session credentials, force users to rotate them more frequently.

Well, that’s not how it works, and I don’t want to use the current SSO implementation. So my biggest concern at this point is preventing all automated options for SSO users.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab