How to End an Active AWS CLI Assumed Role Session

ACM.371 They may or may not be in the credentials file and deleting a file or environment variables is not enough

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

⚙️ Check out my series on Automating Cybersecurity Metrics | Code.

🔒 Related Stories: AWS Security | Secure Code | Cybersecurity | IAM

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

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

In the last post I wrote about restricting users so they can only change their own credentials.

While testing, I was looking around for how to end an active CLI session the other day because I forgot where they were so I am writing a post about it. I ended up digging around in my file system as some of the answers I found in a quick Google search were not applicable.

If you’re using the AWS CLI and you’ve assumed a role and wanted to end that session, you can delete the cached credentials. Initially I thought the cached credentials were in the credentials file. Depending on how you create the CLI profile and assume the role, sometimes they are.

But if you have assumed a role as I explained in this post they will be in another location.

What I wanted to do while testing the above post was clear my current MFA session so I could test that it still worked after making changes to an IAM policy. You also might want to clear these files when you’re done with a particular IAM session so someone cannot continue to use the session after you’re done with it.

I’m doing all my development work on an AWS EC2 instance. I can navigate to the .aws directory as shown below and you’ll see a cli directory. In that directory is a cache directory. In there you’ll find various json files depending on how many sessions you created.

If you look in those files you’ll find your credentials.

You can delete those files and then your local CLI and machine doesn’t have the credentials anymore — but note — the session is still active if someone else got ahold of those credentials in the meantime.

There’s not a good way to terminate sessions in AWS. They have a way to terminate SSM sessions and SSO sessions so why not CLI sessions? I really don’t understand. Please add an AWS CLI command to revoke an assumed role session. #awswishlist

As this documentation explains, you can terminate a session by essentially changing a policy to remove all permissions and that’s risky. First of all, you’re tampering with policies and might fat finger something. Secondly, if something or someone else is actively using a role session they will also be affected.

One other note.

You can obtain short term STS session credentials and use them in other ways. One would be to put them in the aws credentials file. You might also put them in environment variables where the AWS CLI can find them.

I’ve read posts about never doing one or the other. I personally don’t like using environment variables because they seem more easily accessible — on penetration tests, for example, if you don’t encrypt your Lambda environment variables and give me read access to your account to assess your security.

😊

I’m not one to say “Never” because it depends on your use case and where you are using the credentials. If you cannot write to a file system them you might have to use environment variables — which gets me thinking again about my problem using MFA in Lambda. Hmm. I’m still trying to see if there’s a way I can work this out.

I was able to do this with an EC2 instance.

The downside of putting your credentials in your credentials file or as a role profile is that you will have to design a way to refresh the credentials stored in your CLI credentials periodically when your session times out, as opposed to the method I used in the above post.

But to me, it doesn’t matter which one you use as all these methods are going to leave credentials hanging around on your system. If you put them in your environment variables you’ll have to change them every time you change your role as well.

Whatever method you choose, an attacker that gets on your system can get those credentials, so it’s a good idea to clear them out when you’re done using a session that requires MFA to assume and use. You can add the commands to clear those files out when you are done and clear your bash history as well. I’ve written about those things in other posts in this series:

If you want to read about all the different ways you can create short term credentials and assume roles and restrict privilege escalation and compromise check out my posts on IAM here:

Also, please make sure you are not relying on IAM alone. Stolen and abused credentials are involved in almost every data breach. Design your architecture with layers of defenses as I’ve demonstrated in the above series.

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