AWS CLI Session Compromise. ACM.145 Risk-modeling AWS assume position… | by Teri Radichel | Cloud Safety | Jan, 2023

January 31, 2023

1

ACM.145 Risk-modeling AWS assume position momentary credentials

A part of my sequence on Automating Cybersecurity Metrics. The Code.

In my final submit I wrote about who’s liable for what in the case of AWS safety.

I needed to cease and write that as a result of I’m going to hyperlink to it beneath in the case of a few of the threats I’m going to cowl in at the moment’s submit, which is all about classes. Particularly, I’m going to check out how AWS tracks CLI classes and the way attackers can get hold of and abuse them.

Why may an attacker wish to get hold of a person’s AWS CLI session? As a result of if they will get hold of a person’s CLI session credentials, they will do regardless of the person is allowed to do — with out requiring MFA. That’s as a result of the person had to supply the MFA previous to acquiring the session credentials. After that the session credentials are now not required.

What may an attacker do with session credentials? Right here’s one instance: I wrote on CreateUser privilege escalation and backdoors.

I additionally wrote a couple of potential mitigation right here… however wait, there’s extra.

Earlier than I can bought to the extra (there’s [at least] one different menace we have to take into account), I have to cowl the subject of AWS CLI classes and momentary credentials — what they’re, the place they exist, and the way an attacker may get hold of these credentials.

AWS AssumeRole motion

While you assume a job you get some momentary credentials that get rotated periodically:

As soon as the credentials exists, MFA is now not required. The credentials may be freely used from that time on with no MFA immediate. The credentials exist for no matter period of time you have got configured, or the default.

These quick time period credentials and classes can’t be revoked in all circumstances, however you may change the permission of the IAM principal that makes use of them. While you prohibit the permissions for a job — you’ll have an effect on all classes for that position, not simply the session of a single identification. I hope that AWS will present higher mechanisms for revoking a particular set of momentary credentials for a single session sooner or later. #awswishlist

AWS CLI

The place do these credentials exist? It relies upon how and the place you request them. In case you are assuming a job with the AWS CLI, the momentary credentials are accessible:

Within the CLI detailed debug output, as I defined on this submit:

Probably to an attacker that has phished an SSO person as defined on this submit:

Over the community when requested
In reminiscence
Cached (saved on disk) on the host that requested them

An attacker might also trick a bunch into requesting and presenting these credentials externally, utilizing issues like open redirects, SSRF, and DNS rebinding which I’ve spoken about in displays earlier than, however that’s not the subject for the time being. We’re speaking about classes that required MFA to activate however that step has already been accomplished. The momentary credentials or different session identifier can freely be used with no MFA requirement.

Let’s take a look at the potential locations a malicious actor might get hold of your session credentials in additional element for the final three bullets that I haven’t already written about.

Over the community (in transit)

On this case, once I speak about “over the community” I’m speaking particularly about intercepting the credentials in transit when your EC2 occasion (or every other useful resource that may get hold of momentary credentials) requests the momentary credentials and the response comes from the AWS service that delivers the credentials to the compute useful resource.

I can assume of some kinds of entry an attacker might get hold of your credentials this manner. The primary could be that the attacker must be on the compute useful resource (EC2 occasion, container, Lambda operate, and so on.) and be capable to intercept site visitors between the EC2 occasion and AWS utilizing a proxy or community sniffer.

With a view to do this the attacker would possible have to get malware onto the machine, and if they will do this it’s in all probability simpler for them to simply learn the cached credentials. In the event that they couldn’t learn the cached credentials or try to be extra stealthy or one thing they may attempt to learn the community site visitors by way of a sniffer or proxy on the compute useful resource itself.

One other assault might happen if the attacker might by some means redirect your request for these credentials to some kind of proxy earlier than getting the AWS service that gives the credentials. Let’s say an attacker units up a compute useful resource with a non-public IP in your personal VPC. They by some means trick your pc to ship your momentary credential requests to their pc useful resource as an alternative of the metadata service.

The attacker forwards your request alongside after which sends the response again that requires your MFA code. Then once you ship your MFA code the attacker grabs your code, obtains the credentials, and perhaps sends you again an error so that you attempt once more and get a special set of credentials.

The above won’t be attainable when you have zero belief community guidelines in place to forestall this, even in your native community. It might be that by some means that is prevented by the AWS hypervisor or by utilizing some kind of host identification mechanism like a non-public key that forestalls such an assault. I’m not going to discover whether or not that is or isn’t really attainable right here, simply explaining what an attacker may attempt to do. That’s the kind of factor I’d dig into in a penetration check or bug bounty — if one existed. #awswishlist

The opposite level of assault could be internally at AWS. If the site visitors was not correctly encrypted and guarded internally at AWS, an AWS insider may be capable to sniff and intercept the site visitors as soon as it leaves your system and passes via the AWS programs that deal with your request for momentary credentials. That portion of securing the credentials falls within the AWS portion of the AWS Shared Accountability Mannequin, which I confirmed you easy methods to analyze extra in depth than this primary picture within the final submit. That is the kind of element you received’t get out of the diagram beneath, however we do know that after the request leaves our management, it’s AWS’s duty to safe it.

In Reminiscence

Varied kinds of malware learn reminiscence on a bunch via a myriad of strategies I explored in a reverse-engineering malware class and a complicated penetration testing class. I don’t all the time have time to carry out these assaults on a penetration check however engaged on some further automation so I can do extra in much less time. As I wrote in my final submit, the extra primary testing and reporting may be automated (a part of the rationale for this weblog submit and my associated efforts) the extra time I can spend on custom-made, superior assaults. There are a lot of.

I presume once you request the credentials and earlier than they’re cached they’re possible in reminiscence in addition to at any time when it’s essential use them. You could possibly discover this additional on no matter working system you utilize with several types of instruments used for forensic reminiscence evaluation. There are additionally penetration instruments that seize data out of reminiscence reminiscent of Home windows tickets which can be used often in assaults on Home windows programs. The identical ideas and kinds of instruments may be utilized to the AWS credentials whereas in reminiscence.

That stated, once more, there’s in all probability a less complicated approach to get them generally — the credentials are sometimes cached on the host that requests them. Let’s take a look at a number of alternative ways you may run the AWS CLI.

The place do AWS CLI credentials get cached on hosts that require them?

Let’s check out completely different implementations of classes for the AWS CLI. There’s a typical place the place classes are saved on an AWS EC2 occasion. Earlier than I present you that, I wish to see if AWS CloudShell works the identical manner and whether it is simple to search out the momentary session credentials in AWS CloudShell.

AWS CloudShell for an AWS SSO person

Observe that with AWS CloudShell you do not want to request momentary credentials, except you are attempting to make use of some position apart from the one you might be utilizing within the AWS console. Different weblog posts clarify how to try this, and for those who particularly request credentials, they’ll find yourself wherever you retailer them — in reminiscence, atmosphere variables, or on disk. That’s not what I’m looking for out on this submit, however one thing I’ll undoubtedly be overlaying later in additional element.

I ran via a sequence of instructions and as you may see I didn’t need to put in any further credentials or an MFA token. I might run these instructions just because I logged into the AWS console (and I want permission to run the command I ran, which is aws ec2 describe-regions). The MFA token is required on login, not upon operating the instructions. It doesn’t look like there could be a approach to require MFA for a selected motion.

On this case, by some means associated to my login and clicking a hyperlink on the SSO dashboard for a selected account and permission set related me with an AWS position. I presume someplace behind the scenes an AssumeRole command bought executed on my behalf. Let’s discover out.

aws sts get-caller-idenity

Sure, my identification operating the AWS CLI instructions is a job which I’d anticipate primarily based on my description of utilizing AWS SSO with the AWS CLI right here:

The place are the credentials? They might be cached on disk. The may be in atmosphere variables. Let’s go searching.

Hmm. Not precisely what I’m searching for. I wish to know what my credentials are. Let’s dump the atmosphere variables.

That is extra fascinating. However I’m not going to take this any additional. As you may see there’s a credentials URL and a token. That’s fascinating however doesn’t work the identical manner the credentials work on compute assets you instantiate. I’ll depart any additional exploration as an train for the reader, throughout the bounds of the AWS penetration testing phrases. CloudShell isn’t within the record and AWS doesn’t have a bug bounty. #awswishlist

Observe that distant code execution flaws have been found in each Azure and Google Cloud Platform CloudShell implementations — listed below are a number of examples (and hopefully AWS has addressed all comparable threats):

Now, you may trick me into coming into a token someplace, nevertheless it simply appears like that’s more durable to tug off than the AWS SSO strategy. Additionally, this isn’t my last resolution. It is just a stepping stone in the direction of and finish end result.

The unlucky factor is that I’ve to retailer these credentials on my host in a file known as:

/dwelling/ec2-user/.aws/credentials

That’s the place your credentials find yourself once you run the AWS configure command. However when you have designed your IAM roles such {that a} person should enter an MFA token to run the instructions, then the attacker can not merely run them utilizing the credentials. Additionally they want MFA. And hopefully you rotate these credentials often and monitor to be used of credentials beforehand rotated.

So After you enter your MFA code, you get again your momentary credentials, what occurs to them? Have a look over on this listing:

/dwelling/ec2-user/.aws/cli/cache

Aha. These are momentary credentials.

When you take a look at a type of information you’ll see:

{"Credentials": {"AccessKeyId": "xxxxxx", "SecretAccessKey": "xxxxx", 
"SessionToken": "xxx..." ...

You could possibly leverage these tokens anyplace to run instructions and they won’t require MFA because it took MFA to acquire them.

It’s not any completely different than logging into an internet utility the place you must login, enter your MFA token, after which as soon as you might be logged in you may take additional actions with out offering MFA. You could have what’s known as a session. So long as that session is lively you may take actions on that web site. Any attacker who can get your session token or id can do the identical, utilizing your identification, with out MFA, if there aren’t any community restrictions on the actions taken along with your session identifier. Site session tokens have to be dealt with with nice care and guarded.

The identical is true of an AWS CLI session. And that’s what attackers are concentrating on to take actions in your AWS accounts in a variety of safety incidents nowadays.

How can we restrict danger if a session is compromised?

In some unspecified time in the future, anybody may be phished or tricked to click on on a hyperlink that grants an attacker entry. There’s no manner we’re going to utterly eradicate phishing, although there are a variety of issues we are able to do to restrict the variety of profitable phishing assaults.

So I’m going to imagine that sooner or later an attacker can get session credentials by some means.

One of the best factor you are able to do in a cloud atmosphere is the next:

Design your IAM credentials in order that it takes multiple particular person to carry out dangerous actions, reminiscent of I did on this submit:

I’m not addressing all the opposite issues an controls right here that I’ve lined in different posts like encryption, networking, and secrets and techniques administration to restrict the blast radius. These issues may even restrict what an attacker can do along with your credentials and probably provide help to spot an assault (in case you are monitoring suspicious exercise). Moreover, it’s essential have processes and controls to maintain programs updated, which I haven’t lined.

However in all probability your primary management, since credentials are the primary factor attackers use to interrupt into and take actions in your programs, is to restrict what anyone set of credentials can do, even when these credentials are assigned to the identical person. The dangerous credentials are solely used as wanted and when performing different actions, use much less dangerous credentials.

Now, though I’ve designed my system in order that the system requires two roles to create a person and grant entry, I nonetheless have one other concern. Trace: It’s in one of many display screen pictures above. I’ll write about that tomorrow.

When you favored this story ~ use the hyperlinks beneath to point out your assist. Thanks!

Assist:
Clap for this story or refer others to observe me.
Observe on Medium: Teri Radichel
Join Electronic mail Checklist: Teri Radichel
Observe on Twitter: @teriradichel
Observe on Mastodon: @teriradichel@infosec.alternate
Observe on Publish: @teriradichel
Like on Fb: 2nd Sight Lab
Purchase a Guide: Teri Radichel on Amazon
Purchase me a espresso: Teri Radichel
Request companies by way of LinkedIn: Teri Radichel or via IANS Analysis

About:
Slideshare: Displays by Teri Radichel 
Speakerdeck: Displays by Teri Radichel
Recognition: SANS Distinction Makers Award, AWS Hero, IANS College
Certifications: SANS
Schooling: BA Enterprise, Grasp of Sofware Engineering, Grasp of Infosec
How I bought into safety: Lady in tech
Firm (Penetration Exams, Assessments, Coaching): 2nd Sight Lab