AWS CLI for SSO user (2023)

Part of my series onAutomating cybersecurity metrics.I AM. THECode.

Free contentcyber jobs| subscribe toEmail list

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

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

Note that below I wrote about AWS CLI issues with SSO (AWS IAM Identity Center) and explained here how AWS can fix it:

Using the AWS CLI profile for an IAM user with access to multiple accounts

In this post, I explained how to create a trust policy to allow a user in one account to execute commands in another account. The policy can enforce MFA and use an external ID to prevent a confused helper attack. I use this kind of policy when I perform penetration tests and security assessments on customer accounts. The customer is a little more confident that I'm the only one who can access their account by enforcing MFA and using the external ID.

We can then create a profile that uses the corresponding external identifier and add a specific MFA device to the AWS profile configuration that matches the device in the associated trust policy.

I explained why we need the external identifier to avoid the confusing help attack:

Create an AWS CLI profile for an AWS SSO user

This documentation explains how to configure the AWS CLI for an SSO user and is the recommended optionSSO Token Provider Configuration.

Essentially, you can configure an AWS CLI profile automatically or manually, just like we did for the other cross-account roles using IAM, but the format will be different. As you can see below, there is a new sso_session option where you set your home URL and region.

You then set up your account profiles with a few different options:sso_session, sso_account_id, sso_role_name.

Here's one tooconnection profilerequire only oneareait is onestart-URL.

This is interesting:

However,sso_account_idmsso_rolnaamnot required for all SSO token configuration scenarios. If your application uses only AWS services that support bearer authentication, traditional AWS credentials are not required.

Then this is it:

The authentication token is cached on disk under the~/.aws/sso/cachefolder with a file name based on the session name.

Obviously, if an attacker gets access to the cache folder, it will be a problem.

The duration of the operating session is determined by the relevant set of licenses. (AWS Identity Center-toestemming (SSO)Sets are covered in my last post.)

Use the AWS SSO CLI profile

So how do you use the AWS SSO CLI profile?

You must interact with a browser.

Run a command like this:

$ aws sso connection --profile my-developer-profile

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

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

If your credentials require MFA, you'll likely need to enter the second factor as well (via a hardware or virtual MFA device).

You can then see the accounts you have access to, select one, and execute commands.

If you really want to dig into all the details, Ben Kehoe has written this great post that takes a close look at how this all works. There are also some questions and answers in the caching period comments at the end.

Things I don't like about AWS CLI's browser-based SSO approach

I need to provide the URL where I connect to AWS SSO (IIC) in a configuration file

I prefer not to have this information in a config file on a host where I run the automation. I tend to keep my browser connections to the AWS console on a machine separate from the host I'm running automation on. I grant my automation credentials different permission levels than I allow users logging into the AWS console.

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

What could an attacker try to do to execute commands on your account using this feature?

1. Set up a login profile (which only requires the home URL and a region, as Ben Kehoe explains in the blog post above).
2. Run the connect command from the CLI.
3. Get the URL and code after running the command.
4. Create a link that automatically goes to the URL and sends the code.
5. Have a user click the link and enter their AWS SSO (IAM Identity Center) credentials.
6. Crotos. The attacker has an active CLI session that can do anything the user can do — including accessing any AWS account the user has access to, as explained in Ben Kehoe's post above.

Is this really all an attacker needs to connect the CLI session to your user's AWS SSO session?

Entering passwords on shared authentication sites is a common source of attack

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

This approach requires users to inject code into a common site that is used by all AWS users in a specific region. It would be easy to create a similar page and try to trick a user into linking to this generic page.

You cannot login with the SSO user and use a Yubikey for MFA on a remote VM

If you use a Yubikey as the MFA device for the AWS SSO user, you will not be able to sign in to the SSO page that connects the SSO session to the CLI session on the remote VM. This is because you cannot physically connect the Yubikey to the remote machine.

If you could find a way to transfer this code to the remote machine via software, it would defeat the purpose of a HARDWARE security key and introduce an additional attack surface.

It looks like you can register a Yubikey device and a virtual MFA device with AWS SSO, but I haven't tried that yet. You can run code in the browser on your remote computer, but you'll run into all of the browser attack problems listed above. When authenticating via a website, I prefer to use a Yubikey if possible.

Browser as an attack surface

Adding the browser to the process of associating a session started in a browser with a CLI session increases the attack surface compared to the AWS IAM approach where the user enters code in a terminal window.

Browsers can be hacked through web extensions like these:

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

Browsers communicate with many different websites and can be infected in various ways.

Here's an interesting book about browser hacks if you want to learn more:

The browser hacker's manualprovides practical information on how to hack and use the everyday web browseras a base to launch more attacks deep into corporate networks.

Keep your web browsers up to date as attackers often try to attack them using known vulnerabilities. More and more attackers are using zero-day (see my book at the end of this post) to attack systems. Browsers contain a huge amount of code that offers a lot of functionality and a large attack surface. It seems that using a terminal window is a small attack surface.

That said, I will use a browser for my teamwork authentication process, but avoid the generic AWS login page and one-time code to connect SSO sessions with automated actions.

Automate MFA for AWS batch with AWS SSO

How can you use the AWS SSO approach to authenticate CLI commands with an AWS Batch automation flow? Let's say we were to use the AWS CLI in a batch job. We would run a command in a batch job and the job could potentially grab the URL and send the code via curl or some other method. But then the response would ask for credentials, and it's a non-interactive process, so it won't work.

What if we schedule the task to email or text the URL and password to a user?

First of all, the user must answer and sign in before the credential prompt expires. I mentioned this in an earlier post.

How can this email or SMS be intercepted by an attacker? This increases the attack surface. It also introduces the possibility of a phishing attack.

After the user receives the email or text, how can the user verify what exactly this code is for and that it is legitimate and not a fake email with a link and code to verify an attacker's CLI session? The AWS URL will be the same in either case. The code makes no sense. It's just random code.

There are huge opportunities for attackerscompetitive conditionswith this approach. What if the attacker could send their own code before the batch could send it to the user, or simply intercept and prevent the actual code from reaching the user?

In order for the user to validate the purpose of the code, we should provide an interface and trace the code and what it is related to.

The problem is that there is no way to force a user to verify that the code is legitimate before logging in to connect the CLI session to their own AWS SSO session.

This seems very dangerous. Maybe I'm missing something, but for now I'll skip that option and go with a different approach.

Let's look at some other potential problems with this approach, based on my research and Ben Kehoe's post:

• The disconnection process is laborious and potentially confusing.
• Not sure how to end a session. I found this post which seems like a complicated way to end a session for an AWS SSO user, but I guess it would work:

• This is a shared URL, not one that you control and can monitor for suspicious activity.
• You cannot throttle your private network traffic because it is a shared AWS URL.
• Are proxy confusion attacks possible with this approach? I haven't thought about it yet.
• What happens if a user uses SSO credentials to login and start a session and then passes the bearer token to the batch job? The user will then be able to access the producer credentials and token of the producer. This option does not meet my requirements.

I'm just not sure if this approach can be secured as easily or even compares to the other approach I want to try, but I'll keep thinking about it as I work through these posts to make sure I'm not missing anything. This whole process seems very dangerous.

The problem with AWS SSO for external assessments

The main problem for me is that this doesn't really work when I try to run a penetration test or security assessment for a customer and implement MFA. When I run jobs from a customer account, two things have to happen that neither the customer nor I will like:

• First they need to add a user for me to the AWS SSO/IIC root directory (instead of giving my external account and the user permission to use a role in their account).
• I would have to import my MFA device into my AWS account and directory to apply MFA, which I don't want to do. I just want to save my MFA device information to my own account.

Some other concerns about AWS SSO/AWS IAM Identity Center

These are some of the other concerns I have in general when implementing AWS SSO that I need to investigate further.

• Is the SAML implementation secure and free from potential Golden SAML attacks and other types of SAML attacks? I didn't have time to analyze all this. I'm guessing AWS is doing a good job here, but I haven't researched and verified it myself, nor have I seen any documentation about it.
• I haven't had time to test if all the conditions we apply in this blog series apply, but I don't think we can enforce MFA on AWS SSO features if I remember correctly. More tests are needed.
• I find AWS SSO confusing. The user interface is complicated for me. Maybe I'm still getting used to AWS IAM, but I find it easier to know what permissions a user or group has and to what accounts when using AWS IAM.
• I need to further investigate this symbolic comment above.
• I'll have to try everything to prove or disprove my theories - but since I already have so many reservations about it, I won't waste any more time on it.
• Can I disable automation for AWS SSO users?I don't see an option to choose programmatic access, console access, or both when creating an AWS SSO user. Does this mean that even if I never want to use automation with my AWS SSO users, I can't turn it off?

My first conclusion…

I will continue to use AWS IAM users and credentials for automation with Virtual MFA. I will take advantage of limited SSO users to log into the AWS console with a hardware security key as I continue to investigate and evaluate all of the above issues.

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

I really wanted to continue with the rest of my batch application to connect and try to prove all of my theories above. But after writing this entire post, I checked some of my stuff, like looking for a way to terminate an existing SSO session, and found this article:

Thanks for giving practical examples of my cases so I don't have to prove what I'm writing is a problem. :) Good post. It addresses some of my concerns above and provides a tool for phishing device codes.

notable places:

It is also not possible to use an SCP to restrict calls to sso-oidc:CreateToken in some circumstances, since this API call is made in the organization's root account(for which SCPs do not apply).

Well, I can't use an SCP to restrict access programmatically, but maybe I can restrict access to the SCP in some other way, like adding a no to a policy?

m

In terms of detection, the first calls are tosso-oidc:RegistreerClientmsso-oidc:StartDeviceAuthorizationthey are not connected to CloudTrailsince they run unauthenticated and not on an organization-specific AWS account.

The article provides some tips for capturing leads in CloudTrail.

Warning about unusual source IPs from sso-oidc:CreateToken events

…or possibly restrict the IP range of the organization's network.

Unfortunately, without knowing the value of the SSO access token,there is no documented way to revoke it.manuallyDisabling a user in the AWS SSO identity directory does not immediately invalidate access tokens. The same is true if you use a third-party IdP like Okta. Disabling a compromised user on Okta won't help if an attacker has already stolen the AWS SSO access token. I reported this issue to the AWS security team and they clarified the following:

AWS Response:

AWS SSO caches and updates user attributes when they sign in to the user portalper hourto grant/revoke additional access. If you want to revoke all user access before the one-hour period is up, you can rremove all assignments to permission sets and accounts that the user has access to.

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

^^^^ This is good!! Faster please. #awswishlist

Update - This has been added. When I log in to manageAWS IAM Identity Center,click on a user,AndActive Sessions.Check the sessionwant to delete and clickdelete session.

I'm not sure if this has been documented yet, as I couldn't find it while searching while writing this post, but it probably will soon.

It seems that the root of the problem here is that the ability to sign in from an AWS CLI session to an AWS SSO (IAM Identity Center) session does not start in the AWS console where a user has an active session after initial authentication - hopefully with AMF . The "code" used to associate the user's login with an AWS SSO session comes from any AWS CLI login command and may not originate from the SSO user.

It looks like the user must first log into the AWS console and generate some code (or, uh, a programmatic AWS credential like AWS developer keys?) and provide it in the AWS profile configuration to create a session for a user and not the other way around. The code (or developer credentials if you prefer) should be visible in the AWS console once generated by the user who owns and identifies it.

So when you're trying to run a job... request an MFA token if the organization wants to take over. Like AWS IAM. As I do in this blog series.

The code (or credentials) associated with the AWS CLI profile after it is created in the AWS console can be associated with any account that an SSO user has access to - like AWS developer credentials, but at the organization level - to facilitate AWS functionality The authentication and authorization mechanism currently offered by the SSO CLI. If you want short-lived session credentials, force users to change more often.

Well, it doesn't work that way and I don't want to use the current SSO implementation. So my main concern right now is to avoid all automated options for SSO users.

Follow for updates.

Teri Radichel©2e Visielaboratorium2023

The best way to support this blog is to join the email list and encourage the stories you love. It also helps me determine what stories people like and what I should write about more often. Other ways to follow and support can be found below. Thanks!

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~~
Auteur:Cybersecurity for executives in the cloud era
presentations:Presentations by Teri Radichel
Recognition:SANS Difference Makers Award,AWS Security Hero,IANS College
The certification:SAN
Education: BA Business, Master in Software Engineering, Master in Infosec
Company:Cloud penetration testing, assessments and training~2e Visielaboratorium

Did you like this story? Use the options below to help me write more!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
❤️Applaud
❤️bibliographical references
❤️Average:Teri Radichel
❤️ Email list:Teri Radichel
❤️ Twitter:@teriradichel
❤️ Moloch:@teriradichel@infosec.exchange
❤️ Facebook:2e Visielaboratorium
❤️ YouTube:@2ndsightlab
❤️ Buy a book:Teri Radichel on Amazon
❤️ Request a penetration test, assessment or training
via LinkedIn:Teri Radichel 
❤️ Schedule a consultation with me viaIANS-survey

My Cyber ​​Security Book:Cybersecurity for executives in the cloud era