ACM.127 AWS CLI instructions with an AWS SSO (AWS Identification Heart) session — menace modeling and assault floor
This can be a continuation of my sequence on Automating Cybersecurity Metrics.
In my final put up I confirmed you ways we’d add a brand new group and permission set in AWS SSO to handle domains in a separate AWS account.
Now let’s say we wish to grant that consumer entry to make use of the AWS CLI to handle DNS configuration. How can we try this? There’s no idea of entry keys for an AWS SSO consumer.
Utilizing AWS CLI profile for an IAM consumer with cross-account entry
I defined the best way to create belief insurance policies to permit a consumer in a single account to run instructions in one other account on this put up. The coverage can implement MFA and use an exterior ID to stop a confused deputy assault. I exploit most of these insurance policies when performing penetration assessments and safety assessments on buyer accounts. The shopper has a bit extra confidence that solely I’m accessing their account as a result of enforcement of MFA and use of the exterior ID.
Then we will create a profile that makes use of the matching exterior ID add a selected MFA gadget to the AWS profile configuration matching the gadget within the associated belief coverage.
I defined why we’d like the exterior ID to stop the confused deputy assault:
Creating an AWS CLI Profile for an AWS SSO consumer
This documentation explains the best way to configure the AWS CLI for an SSO Consumer, and the beneficial possibility is the SSO token supplier configuration.
Basically you possibly can configure an AWS CLI profile routinely or manually like we did for our different cross-account roles utilizing IAM however the format goes to look completely different. As you possibly can see under there’s a new sso_session possibility the place you outline your begin URL and area.
You then arrange your account profiles with some completely different choices: sso_session, sso_account_id, sso_role_name.
You additionally arrange one login profile that solely requires a area and a begin url.
That is attention-grabbing:
Nonetheless,
sso_account_idandsso_role_namearen’t required for all situations of SSO token configuration. In case your utility solely makes use of AWS providers that help bearer authentication, then conventional AWS credentials should not wanted.
So is that this:
The authentication token is cached to disk below the
~/.aws/sso/cachelisting with a filename primarily based on the session title.
Clearly if an attacker will get entry to the cache listing, that’s an issue.
The session period is managed by the related permission set. (AWS Identification Heart (SSO) permission units had been coated in my final put up.)
Utilizing the AWS SSO CLI profile
So how do you utilize the AWS SSO CLI profile?
It’s a must to work together 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 (just like how Azure works in some situations):
IAM Identification Heart makes use of the code [the random code generated above which is QCFK-N451] to affiliate the IAM Identification Heart session along with your present AWS CLI session. The IAM Identification Heart browser web page prompts you to log in along with your IAM Identification Heart credentials. This provides permissions to the AWS CLI to retrieve and show the AWS accounts and roles that you’re approved to make use of with IAM Identification Heart.
Presumably in case your credentials require MFA you additionally need to enter your second issue (by way of a {hardware} or digital MFA gadget).
Then you possibly can see the accounts you’re allowed to entry, decide one, and run instructions.
If you happen to actually wish to dive into all the main points, Ben Kehoe wrote this nice put up which fits into extra particulars about how this all works. There’s some Q & A within the feedback about caching classes on the finish as effectively.
Issues I don’t like concerning the SSO browser-based method for the AWS CLI
I’ve to supply the URL the place I log into AWS SSO (IIC) in a configuration file
I might quite not have that data in a configuration file on a bunch the place I execute automation. I are likely to hold my browser logins to the AWS console on a separate machine from the host the place I run automation. I give my automation credentials completely different ranges of permissions than I give customers that login to the AWS console.
The thought of utilizing a single code to affiliate an lively SSO session with an AWS CLI session appears dangerous.
What may an attacker attempt to do to run instructions in your account by leveraging this performance?
- Configure a login profile (which solely requires the beginning URL and a area as Ben Kehoe explains within the weblog put up above.)
- Run the login command within the CLI.
- Get the URL and code after working the command.
- Craft a hyperlink that routinely visits the URL and submits the code.
- Trick a consumer into clicking the hyperlink after which getting into their AWS SSO (IAM Identification Heart) credentials.
- Increase. The attacker has an lively CLI session that may do no matter that consumer can do — together with entry any AWS account the consumer has entry to as defined in Ben Kehoe’s put up above.
Is that actually all that it requires for an attacker to hyperlink their CLI session along with your consumer’s AWS SSO session?
Getting into codes in shared authentication web sites is a standard supply of assault
Getting customers to enter codes in faux web sites was the premise of the Oktapus assault I wrote about right here:
This method will get customers to enter codes in a standard web site utilized by all AWS customers in a specific area. It could be simple to craft a lookalike web page and attempt to trick a consumer to login to that generic web page.
You received’t have the ability to login along with your SSO consumer and use a Yubikey for MFA on a distant digital machine
If you happen to use a Yubikey because the MFA gadget on your AWS SSO consumer, you won’t be able to log into the SSO web page that hyperlinks your SSO session to your CLI session on the distant VM. That’s since you can not bodily plug your Yubikey into the distant machine.
If you happen to may consider a method to switch that code by way of software program to the distant machine then that defeats the aim of a HARDWARE safety key and introduces extra assault floor.
It seems that you may register each a Yubikey and a digital MFA gadget in AWS SSO however I haven’t tried it but. You would use a code within the browser as an alternative in your distant machine however see all of the browser assault points above. After I’m authenticating by way of an internet site, I choose to make use of a Yubikey, if potential.
Browser as assault floor
Including the browser into the method to hyperlink a session initiated in a browser to a CLI session will increase the assault floor, in comparison with the AWS IAM method the place a consumer enters a code in a terminal window.
Browsers could also be compromised by way of net extensions like this one:
Make sure that to warn your customers to not set up untrusted net extensions (or any if potential).
Browsers work together with many various net pages and may change into contaminated in numerous methods.
Right here’s an attention-grabbing guide on browser hacks if you wish to know extra:
The Browser Hacker’s Handbook offers a sensible understanding of hacking the on a regular basis net browser and utilizing it as a beachhead to launch additional assaults deep into company networks.
Hold net browsers updated as attackers usually attempt to assault them utilizing recognized vulnerabilities. An increasing number of attackers are utilizing zero days (see my guide on the backside of this put up) to assault programs. Browsers have an immense quantity of code to supply a whole lot of performance and a broad assault floor. It looks as if utilizing a terminal window is a smaller assault floor.
That mentioned, I’m going to make use of a browser for my batch job authentication course of however I’m going to keep away from the generic AWS login web page and single code to hyperlink SSO classes with automated actions.
Automating MFA for AWS Batch with AWS SSO
How would leverage the AWS SSO method to authenticating CLI instructions with an AWS Batch automation move? Let’s say we had been going to make use of the AWS CLI in a batch job. We’d be executing a command inside a batch job and the job may doubtlessly seize the URL and submit the code by way of curl or another methodology. However then the response would immediate for credentials and it’s a non-interactive course of, in order that doesn’t work.
What if we program the job to e mail or textual content the URL and code to a consumer?
To start with, the consumer would wish to reply and login earlier than the request to supply credentials occasions out. I discussed that in a previous put up.
How might methods may that e mail or textual content message be intercepted by an attacker? That will increase the assault floor. It additionally introduces the potential of a phishing assault.
As soon as the consumer will get the e-mail or textual content, how would they have the ability to confirm what that code was for precisely and that it was legit and never a spoofed e mail with a hyperlink and code to authenticate an attacker CLI session? The AWS URL would be the similar both means. The code is meaningless. It’s only a random code.
There’s an enormous potential for attacker race situations with this method. What if the attacker can ship their very own code earlier than the batch job can ship it’s code to the consumer or just intercepts and blocks the true code from attending to the consumer?
Nicely to permit the consumer to validate what the code is for, we must present an interface and monitor the code and what it was related to.
The issue is that there’s no method to implement a consumer to confirm the code is for one thing legit earlier than logging in to affiliate the CLI session with their very own AWS SSO session.
This simply appears far too dangerous. Possibly I’m lacking one thing however for now I’m going to skip this selection and leverage one other method.
Let’s contemplate another potential points with this method per my analysis and Ben Kehoe’s put up:
- The logout course of is inconvenient and doubtlessly complicated.
- I’m unsure how one can terminate a session. I discovered this put up which feels like a cumbersome method to terminate a session for an AWS SSO consumer however I suppose it might work:
- This can be a shared URL not a URL that you simply management and may monitor for suspicious exercise.
- You may’t restrict visitors to it from your individual personal community since it’s a shared AWS URL.
- Are there any confused deputy assaults which are potential utilizing this method? I haven’t considered this in any respect but.
- What if a consumer used their SSO credentials to login and provoke a session after which handed the bearer token to the batch job. Then the consumer would have entry to manufacturing credentials and the manufacturing bearer token. That possibility doesn’t meet my necessities.
I’m simply unsure this method will be secured as simply and even in any respect in comparison with the opposite method I wish to attempt, however I’ll hold considering by means of it as I work by means of these posts to verify I’m not lacking one thing. This complete course of appears very dangerous.
The issue with AWS SSO for exterior assessments
The most important downside for me is that it doesn’t actually work if I’m making an attempt to carry out a penetration check or safety evaluation for a buyer and implement MFA. If I’m working instructions towards a buyer account two issues need to occur which neither the shopper and I’ll like:
- They to begin with have so as to add a consumer for me into their major AWS SSO / IIC listing (versus granting my distant account and consumer permission to make use of a job of their account).
- I’d need to enter my MFA gadget into their AWS account and listing to allow them to implement MFA, which I don’t wish to do. I solely wish to retailer my MFA gadget data in my very own account.
Another issues with AWS SSO / AWS IAM Identification Heart
These are a few of the different issues I’ve usually with the implementation of AWS SSO that I nonetheless have to analysis additional.
- Is the SAML Implementation safe and free from potential Golden SAML and different varieties of SAML assaults? I haven’t had time to look into any of this. I presume AWS is doing job right here however I haven’t personally analyzed and verified this or seen any documentation on it.
- I’ve not but had time to check imposing all of the situations we’re imposing on this weblog sequence, however I not suppose we will implement MFA on the AWS SSO roles if I keep in mind accurately. Extra testing is required.
- I discover AWS SSO complicated. The UI is cumbersome to me. Maybe I’m nonetheless used to AWS IAM however I discover it simpler to determine what permissions a consumer or group has and during which accounts when utilizing AWS IAM.
- I have to discover that touch upon the bearer token above additional.
- I would wish to check all of it out to show or disprove my theories — however given I’ve so many reservations on it already I’m not going to spend extra time on it.
- Can I even disable automation for AWS SSO customers? I don’t see an possibility to decide on both programmatic entry, console entry, or each when creating an AWS SSO consumer. Does that imply that even when I by no means wish to use automation with my AWS SSO customers I can’t flip it off?
My preliminary conclusion…
I’m going to proceed utilizing AWS IAM customers and credentials for automation with digital MFA. I’m going to leverage restricted SSO customers to login to the AWS console with {hardware} safety key as I proceed to analyze and assess all of the above points.
After which…I found this proof of idea (Thanks!)
I used to be too fascinated about transferring on to the remainder of my Batch job implementation to login and attempt to show all my theories above. However after writing this whole put up, I used to be checking a few of my information similar to in search of a method to terminate an current SSO session and ran throughout this text:
Thanks for offering working examples of my presumptions so I don’t need to show what I’m writing about is an issue. 🙂 Nice put up. It just about demonstrates a few of my issues above and gives a software for phishing gadget codes.
Notable bits:
It’s additionally not potential to make use of a SCP to limit the calls to sso-oidc:CreateToken to sure situations, since this API name is carried out towards the group grasp account (which isn’t topic to SCPs).
Nicely, I can’t use an SCP to restrict programmatic entry however maybe I can restrict SCP entry in one other means similar to including a to not a coverage?
and
When it comes to detection, the preliminary calls to sso-oidc:RegisterClient and sso-oidc:StartDeviceAuthorization should not logged to CloudTrail since they’re carried out with out authentication, and never towards a selected AWS account of the group.
The article does present some tricks to get clues from CloudTrail.
Alert on uncommon supply IPs of sso-oidc:CreateToken occasions
…or presumably can restrict to the group’s community IP vary. Sure, community safety is useful and this may be carried out in quite a few methods, even for distant customers.
Sadly, with out figuring out the SSO entry token worth, there is no such thing as a documented method to revoke it. Manually disabling an consumer within the AWS SSO id listing doesn’t instantly invalidate its entry tokens. Identical goes in the event you use a third-party IdP similar to Okta; disabling a compromised consumer in Okta doesn’t assist if an attacker already stole its AWS SSO entry token. I reported this difficulty to the AWS safety staff, they usually clarified the next:
AWS response:
AWS SSO caches consumer attributes once they login to the consumer portal and refreshes them hourly to grant/revoke extra entry. If you wish to revoke all consumer entry earlier than any 1-hour interval expires, you are able to do so by removing all assignments to the permission units and accounts the consumer has entry to.
We’re already working in the direction of an express session revocation function for the SSO consumer portal.
^^^^ That’s good!! Quicker, please. #awswishlist
It looks as if the crux of the issue right here is that permitting an SSO session is just not began from inside the AWS console the place a consumer has an lively session after first authenticating — hopefully with MFA. The “code” used to hyperlink the consumer login to an AWS SSO session comes from any random AWS CLI login command and is probably not coming from the SSO consumer in any respect.
It looks as if the consumer ought to first login to the AWS console and generate a code (or, um, an AWS programmatic credential like AWS developer keys?) and may have to supply these within the configuration of the AWS profile to be able to hyperlink a session to a consumer as an alternative of the opposite means round. The code (or developer credentials if you’ll) must be seen within the AWS console after they’re generated by the consumer that owns them and whom they establish.
Then when a command makes an attempt to execute…require an MFA token if that’s what the group needs to imagine roles. Like AWS IAM. Like I’m doing on this weblog sequence.
The code (or credentials) plugged into the AWS CLI profile after producing it within the AWS console may very well be related to each account an SSO consumer has entry to — like AWS developer credentials, however on the organizational stage — to facilitate the performance that the AWS SSO CLI authentication and authorization mechanism at the moment gives. If you’d like quick lived session credentials, drive customers to rotate them extra regularly.
Nicely, that’s not the way it works, and I don’t wish to use the present SSO implementation. So my greatest concern at this level is stopping all automated choices for SSO customers.
Comply with for updates.
Teri Radichel
If you happen to appreciated this story please clap and comply with:
******************************************************************
Medium: Teri Radichel or Electronic mail Record: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests providers by way of LinkedIn: Teri Radichel or IANS Analysis
******************************************************************
© 2nd Sight Lab 2022
All of the posts on this sequence:
____________________________________________
Writer:
Cybersecurity for Executives within the Age of Cloud on Amazon
Want Cloud Safety Coaching? 2nd Sight Lab Cloud Safety Coaching
Is your cloud safe? Rent 2nd Sight Lab for a penetration check or safety evaluation.
Have a Cybersecurity or Cloud Safety Query? Ask Teri Radichel by scheduling a name with IANS Analysis.
Cybersecurity & Cloud Safety Sources by Teri Radichel: Cybersecurity and Cloud safety lessons, articles, white papers, displays, and podcasts
