Backdoors and Privilege Escalation Via Cloud Account Users

ACM.134 Preventing a user from leveraging another user with permissions they don’t have

Part of my series on Automating Cybersecurity Metrics. Data Breaches. Penetration Testing. The Code.

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

In my last few posts I’ve been trying to outline an IAM architecture that prevents IAM administrators (or an attacker who obtains their credentials or an active session) from escalating privileges. In other words, how can we prevent an IAM administrator from simply granting themselves additional permissions they don’t already have and be able to do some thing they should not be allowed to do?

In the last post, we look at how to prevent an IAM user from leveraging a compute resource and granting a role to it that the IAM user should not be allowed to assume themselves.

Now we’re going to think through how we might prevent users from creating users that have more permissions than the users should have themselves.

And. This. Is. Tricky. Let me count the ways…

The risk of allowing a user to create new users and assign permissions

Now we have another problem which I’ve been pondering for a while. Here’s what an IAM user can do with the permissions we have currently granted to them:

User escalation path 1:

• Change a user’s password, MFA device, and/or create a new developer key for the user.
• Do whatever that user is allowed to do by leveraging that user’s credentials.

User escalation path 2:

• Create a new user.
• Create a new policy with whatever permissions they want.
• Assign that policy to the user.
• Login as that user.
• Do whatever that user is allowed to do.

In breaches such as the Code Spaces breach, attackers did exactly that. They logged in using stolen credentials, created a new administrator user, and then changed the password on the root user account. When the company did not meet the attacker’s demands, they deleted the entire account, putting the whole company out of business and wiping out a lot of their customer’s data a well. I generally refer to Code Spaces in my classes as the company that got deleted.

There are various steps which we can and should take to limit potential damage. However when I think through the escalation paths, I still come up with holes that could be used even with some of these protections in place. Let’s go through them.

Protecting the root account an Root of Trust in a cloud environment

A cloud identity should only be allowed to manage his or her own credentials. Since we can’t put those or any other restrictions on the root user, that’s why the root user credentials should rarely be used. That, and the fact that the root account can shut down your entire account.

Although it used to be that only the root account could shut down your AWS account, I recently was surprised when I noticed that as a particular SSO user I also had access to that capability as well. I didn’t test if they could actually go through with it but my SSO user could see those options in the console. Be careful with those permissions and understand who has them.

Google Cloud Platform has an interesting article on Root of Trust in your cloud platform and that’s pretty much the topic I’ve been writing about in these last few posts, but in a bit more detail. Also, the code I’m writing is obviously specific to AWS. But the concepts are universal to any cloud platform.

Limiting who can change credentials and non-repudiation

An identity is supposed to identify a person. If someone else can change the credentials they can impersonate that person, so we want to ensure that only the identity (or user on AWS) themselves can change their own password, MFA devices, and generate developer keys.

How can we ensure that every user in our organization can only change their own credentials?

• Beyond the all-powerful root user and ROOT automation credentials, only allow IAM administrators to create users with a specific permission boundary.
• That permission boundary should limit users to only changing their own credentials (password, MFA device, and any automation credentials).
• Include the inability to change anyone else’s password but their own in the IAM administrator’s permissions.

If we implement the above correctly:

• An IAM administrator cannot change the password for a user.
• No user can change anyone else’s password or credentials.
• We have improved non-repudiation in the case of unauthorized or non-compliant actions.

Now an IAM administrator cannot change a password or create a new automation key for a user and leverage it to perform actions that appear to be taken by that user. We can also be reasonably sure that any actions taken with those credentials belong to a specific user and are either taken on the part of that user or an attacker who has compromised the user’s credentials or session. I covered non-repudiation in my book and a prior post in more detail.

What about password resets? In general, we want users to be able to reset their own passwords. That’s the process taken when you create a new user. The user gets a temporary password, and then they have to reset their password before they can proceed. MFA should obviously be enforced whenever possible.

What if a user’s MFA device is broken or lost? The administrators can remove an MFA device, but not add a new one for a user if they are not logged in as that user. By the way, be careful with this one as an MFA-related request by an attacker is what tipped off Mandiant to the Solar Winds breach.

What if a user’s credentials are compromised? Administrators can disable a user or developer key and delete them if necessary. Make sure not to delete the MFA device only in the case of a compromise. Disabling a user and developer keys first would be a safer approach.

New User Scenario

Let’s consider our options to prevent the second scenario, where an administrator creates a new user, assigns whatever policy they want, and then logs in using the new user credentials.

Perhaps some method of automation can help us. I wrote about automated creation of users here, but in this post the user could not change its own credentials, since it would be used for automation:

Then we created credentials for automation without exposing them to users here (and AWS has subsequently added this approach for RDS passwords — something I developed years ago when deploying databases at for a security vendor).

In this post and the one after I explored creating user-specific secrets, where only a user can access their own secret.

But how can we prevent the IAM administrator from accessing the initial user credentials? Unfortunately AWS has not solved this problem for us. The option exists to email a user credentials, but there are so many ways email can be intercepted, read, spoofed, and used in phishing attacks that I really don’t like this option. At some point, a user needs to get their initial credentials to login to company resources. How might we solve this problem?

We could create an automated process with multiple people and checkpoints like the following:

1. The HR department initiates the creation of a new user through an automated process which notifies the IT and security department that a new user is being added to organization.
2. An corporate login and email account is automatically generated for the new user.
3. The credentials for the corporate login and email are provided by the person who generated them in IT to the user (another potential security gap — how does a new user get his or her initial credentials without anyone seeing them?) Here we are at our catch 22. But we can leverage a few additional steps to prevent an IT admin from using those credentials to access a cloud account with them.
4. The user must login and change their password and set up MFA on their corporate login and email account before they can take any other action.
5. The user sends an email to their manager who confirms that this has all taken place and only the correct user has access to their own email. I suppose there could be some man-in-the-middle or proxy attack at this point where the user changed their user name and password in a fake system but now we’re getting very advanced for an attacker.
6. The manager sends the user instructions for some basic security training. Since the manager must complete this step they are responsible for making sure the correct user has the instructions via the email address, not an IT admin.
7. The training includes information on phishing, malicious links and attachments, smishing (text messages), etc. Perhaps the user has to log into a system with their new credentials which verifies they go through the training and that they can pass a basic test via human interaction (i.e. with captchas and bot detection).
8. Once the user has completed the training HR gets notified, at which point they kick off the process to create a user’s cloud account and other accounts required throughout the organization through an automated mechanism, based on permissions assigned by the user’s manager.
9. The IAM team has created roles for the organization in the cloud account and those rules are automatically assigned by the HR process indicates based on the permissions assigned by the manager.
10. The user cannot take any action in their account until the password is changed and MFA is set up (or perhaps MFA and passwords are provided through the credentials already granted.)

You might think of an even better process but that process seems to have minimal friction and a lot of automation to make it easier. It has multiple checkpoints for people in different departments to verify the correct user has the credentials that are supposed to identify that user. Segregation of duties and limits an IAM administrator — or HR, or IT, or the user’s manager — from obtaining the user’s password and taking actions as that user. It also incorporates basic security training which can help limit future abuse of those credentials.

But that’s complicated and going to take some time to set up, right?

Another option — limit user creation, role assumption, and permissions

If the above all sounds really complicated and time-consuming to set up there’s another option. This consideration of how IAM administrators could abuse credentials started out with considerations of the security risks associated with domain names.

I created a new account and put all my domain names in a single account to make domain name management easier and reduce security risks.

In the above post we transferred a domain between two different accounts in two different AWS organizations.

What would an IAM administrator need to get into that account with a new user he or she creates?

Attack Scenario 1:

• Create a policy in the domains account with permissions to manage domain names.
• Create a user in the domains account that leverages the policy.
• Login as that user to access the domain names.

Solution 1:

• Disallow creation of users in the domains account.

Attack Scenario 2:

• Create a policy in the domains account.
• Create a role to manage domains in the domains account.
• Create a trust policy with cross-account access for a user or role to leverage that role.
• Create a user and/or assign the role with access to the domains account via the trust policy.

Solution 2:

• Only the ROOT automation account has access to critical functions such as creating and deleting domains, or transferring domains in our domains account. This account requires MFA and is disabled when not in use.
• We only grant domain administrators the ability to configure DNS.
• The ROOT account creates the trust policy and IAM policy that allows the IAM administrator to create permissions in the remote account. The IAM policy for managing permissions has an appropriate Permissions Boundary to limit actions in that account to only what should be allowed.
• Create alerts to for any changes to these settings.

In this scenario, the IAM administrator can be restricted from creating users in the domains account. They can also be limited to creating specific permissions for users who are allowed to leverage a cross account role for the purpose of route 53 administration, excluding the most critical functions of domain name management (creation, deletion, transfer, etc.)

The real solution to the problem?

The real solution to the problem is a fully automated pipeline where no users can take actions in a particular account, even via a cross-account role, with a random click or button push in your critical accounts.

The organization has a fully fleshed out, automated pipeline that has appropriate security and integrity in place to prevent unauthorized code changes inserted at any point.

Any single user cannot take an action without someone else knowing about it. The code that makes changes goes through a full SDLC lifecycle with appropriate QA testing and security review. That doesn’t need to be a completely draconian and onerous process for common actions. But when it comes to critical security-related actions such as a domain transfer, that should require a manual review in most cases by people who understand the security implications.

Any one-off, emergency changes go through a process that requires multiple people including enablement of temporary credentials to make a change, oversight, and documentation.

Well that would be nice, but we’re not there yet.

So we’ll do what we can at the moment hat limits the amount of work to implement and limits access to only what we need currently until we can create a fully fleshed out, automated solution.

I wrote about a potential way to mitigate this problem here and am going to be exploring exactly how that might work in subsequent posts.

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