Opening a Cloud Account Securely
MultiCloud.4 Who has the root credentials?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⚙️ Check out my series on Automating Cybersecurity Metrics. The Code.
🔒 Related Stories: Multi-Cloud Security | AWS Security | Azure Security | GCP & Google Security.
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In the last post I wrote about some things you should do before you open a cloud account.
In this post we’ll consider what you need to do when you decide you do want to open a cloud account.
The credentials that can open the account can close the account
When opening a cloud account, consider that whomever can open the account can usually close the account. These credentials present a risk in a number of ways.
A disgruntled employee can lock you out of your cloud account. Here’s an example where an IT Admin in San Francisco locked up the whole city network.
If something happens to the person with the root credentials you might not be able to close the account or change root level configuration items.
If those credentials are not properly protected and get compromised, an attacker could use them to take over your entire cloud account. That’s what happened to a company called Code Spaces. An attacker got the credentials, created their own back door credentials, and took over the cloud account. Eventually the attacker put the company out of business by deleting all the data.
For these reasons, the moment you open a cloud account and how you go about doing that is critical.
Who has the root credentials?
If you already have open cloud accounts, do you know who has those credentials for each and every cloud account in your organization?
In the case of an emergency situation, such as a ransomware attack that is encrypting or deleting all your data, would you be able to quickly access those credentials and stop the attack?
The initial credentials created to open a cloud account should be created in a controlled manner and stored in such a way that they are not dependent on one person. This creation of the cloud account should be part of your vendor onboarding process.
Set up MFA — with a hardware key and two if possible
If you’re not familiar with MFA I wrote about that here and in my book.
When you create the root credentials ideally you can create the account with a hardware key as a second factor. A hardware key such as a Yubikey is proven to be more phishing resistant than other forms of MFA such as push notifications, SMS text messages.
CloudFlare wrote about how they defended against SMS phishing (smishing) attacks that affected other companies using Yubikeys in this security brief. Use hardware keys whenever possible. You might even make this a requirement for new cloud vendor consoles.
Note that a hardware key is the main way to avoid an Evilginx attack. This type of attack can obtain all manner of SMS tokens but it cannot, as of the time of this writing, get the token provided by a hardware security key.
AWS is currently giving away free hardware keys to certain customers if you need one. I don’t know how long this promotion will last.
Although I love Yubikeys, be aware that no solution is ever perfect all the time. I wrote about some potential weaknesses related to hardware security keys with the AWS CLI, because it requires you to install the management software for the Yubikey. That may provide access to manage the key to an adversary that gets access to the machine.
Set up two second factors when possible
Whenever possible set up two second factors for credentials. If you set up two MFA devices then you will be able to use the second device if something happens to the primary device.
Google has let you set up two MFA devices for your cloud account for a while. Now AWS and Microsoft have these options as well for some accounts.
I wrote about how you can set up two keys for AWS here and will go over the options for Azure and Google in separate posts.
Email Aliases for the root account
It’s a good idea to set up primary credentials with an email that multiple people receive in case there is a problem with the account. If the email only goes to one person and that person is out of the office, then you might find out about a problem when it is too late. Also, what happens if the person leaves the company or something happens to the person?
One company I helped with an audit had one person set up credentials for a system. Then that person had to go on paternity leave. He had to share the credentials with someone else while he was gone. Now the company has no non-repudiation in the case that those credentials are later abused. Whomever had access to the credentials can say that someone else did it. The company cannot use their logs as proof of an action by a person in a court of law. Additionally, the company may be non-compliant with any security regulations which requires companies to have a single set of credentials for each user.
In contrast, if you use an alias that multiple people have access to in order to get emails for an account, that doesn’t necessarily mean they can also login to the account. It depends on the capabilities of the cloud provider. But you may be able to design a process where it takes two people to log into the root credentials — the person with email access and the person with the MFA device. How you do this will depend in part on the size of your organization, tools the organization may use to manage passwords, and the capabilities of the cloud provider.
Understand the process for resetting the password and MFA device
Sometimes it is possible to reset the MFA device online. Go through this process to understand which factors will allow someone to remove the MFA device. If it is a phone number and an email account, understand and document what those factors are and who can access them. You may want to make sure that the same person does not have access to both factors.
Don’t use the root credentials on a day to day basis. The logs showing use of those credentials should be few and far between. Review the logs to make sure you understand which actions are taken by a root user. For a while AWS was logging all kinds of actions with the user “root” in CloudTrail logs but I was told they were trying to fix that. Make sure you set up high priority alerts if anyone logs in or tries to change the credentials.
Keep in mind that whatever emails are used for password and MFA resets have a domain name. That domain name needs to be carefully managed so that someone can’t take over the domain name and thereby gain access to your email used to reset passwords. I wrote about domain name security here:
Set up a secondary user as soon as possible
Set up a secondary user or set of users as soon as possible and have that user set up the base resources in the cloud account.
Hopefully you followed my advice in the last post and set up a trial of the cloud first to determine how you want to set things up. That’s something I’ve been working through as time allows in AWS. Hopefully I will find time to get this to a reasonable state sooner than later. In this series, when I started over, I created what I called the OrgRoot user and used that to deploy some of the initial resources for the organization.
I’ll have more to say about users in future posts but just try to set up your root user, document the credentials and how to access them, and test password resets. Then set up a secondary user to create the initial resources in your account.
Understand who has access to your account
In the past, if you created your Google Workspace through Google Domains, then Google Domains had certain access to your workspace. Now that Google Domains is being sold to SquareSpace you should be aware that SquareSpace will have whatever this access provides:
Once regulatory approvals are obtained and the transaction closes, the billing and support services for Google Workspace (including G Suite) subscriptions currently billed by Google Domains will be managed by Squarespace.
I generally recommend that people open a new Workspace account that is not connected to Google Domains if that is how they are set up. Unfortunately that is not necessarily easy to do.
If you hire a third party to set up your cloud account, do you still have control over that account? Has the vendor set up any backdoor access they could leverage later? You’ll want to know exactly what accounts exist in the account and what they have permission to do.
How do you close an account?
When you try out the cloud environment, take a look at what you need to do to close an account. Sometimes the process is a bit complicated. There may be restrictions and requirements that prevent you from closing the account under certain circumstances. Do you continue to pay for the account during this period?
In Azure, it was pretty much impossible to close my account at one point and I was going around in circles with support. I posted on Twitter that Azure is like Hotel California — you can enter but you can never leave.
The end result was that I could close all the subscriptions but I could not close the Azure account because I had an office subscription associated with the billing account used for the Azure account. What’s the big deal? Well, I’d rather not have credentials hanging around for the Azure account when I don’t need or want anyone to use it.
As for Google Cloud Platform (GCP), I recently closed a project and it was very easy.
However, closing the cloud account completely requires logging into the Google Workspace admin console. Since doing this, I need to review is why I’m still getting a small bill when I have no projects in the account. If you want to remove access to GCP but you are still using Google Workspace, you need to disallow access to GCP for users in Google Workspace.
Closing an account on AWS can be easy if you only have a single account. click on your user name in the top right. Then click on Account.
Scroll down and click Close account. Follow the instructions.
When you have created an organization, something I’ll cover later, it gets more complicated.
Closing an account with AWS Control Tower enabled is also involved.
Password Managers
Some companies use password managers to help users or the organization as a whole manage passwords. One of the problems with access to the password manager may provide access to all the accounts with credentials in the password management system.
An unfortunate example of this concept is provided by the LastPass breach. LastPass is a company that sells a password manager. The attacker got access to a developer’s machine via a vulnerability in some software he installed to play music. With access to the developer’s machine, the attacker was able to access the password manager and capture keystrokes such as MFA pins entered as second factors into websites.
Although the company used a password manager to store the passwords securely, once the user entered credentials to get into the password manager the attacker had access to all the passwords. Any MFA codes entered by the developer on the machine were available to the attacker via a keylogger. Although sometimes password managers are advertised as a panacea it is important to understand their risks and weaknesses.
How might those weaknesses be addressed? In this case, a push method of MFA where the developer pushes a button on a separate device besides the one where credentials are entered would be better. I wrote in my post above how a second factor may not really be a second factor if the attacker has access to both factors via one device.
What type of push MFA might work better? DUO is an example of an MFA solution where a user can push a button on a phone to log into a website. Although phones can be stolen or compromised, the attacker would need to access both the phone and the computer where the password manager is installed.
The problem with that solution is that users often log into websites on their phones. Is the password manager also on the phone? If the attacker obtains access to the phone, then the attacker can capture the credentials used to login to websites using the phone and any second factors sent to or generated on the phone.
A hardware key provides better protection because an attacker would need to get access to the physical device to push the button on the device to initiate the second factor (unless you have some software that facilitates generating a token from that device as explained in my post above related to using a Yubikey with the AWS CLI.) That is exactly what LastPass did after the breach. They issued hardware keys to their administrators. You can now get hardware keys that work both on phones and computers.
A better solution for passwords might be an enterprise solution where passwords are not stored on the same devices where developers are installing software and searching the web. These enterprise password managers are used possibly for administrative logins like root credentials and passwords used by applications to access storage systems like databases.
I haven’t used this solution but I’ve heard various companies mention CyberArk as a potential solution. If a security team can completely manage the password server and solution they can create strict network controls and tightly monitor access to the password manager and the passwords in it, unlike the password manager on a laptop of a developer working in a home office or at a coffee shop.
Although endpoint solutions exist to monitor remote systems, an attacker may be able to turn those off if they get full access to the system. On a corporate network, more security controls exist which may trip a wire and alert the security team to the attacker’s presence.
Managing Passwords in Cloud Environments
In cloud and DevOps environments different types of vaults store passwords used in automated processes. If you use a solution directly from the cloud provider you can use multiple controls including networking, IAM, and encryption to limit access to the secrets. Unfortunately, if you store your root credentials to get into your cloud account in your cloud account, that could lead to problems. Make sure you can access those credentials should an attacker be actively locking out your other accounts.
I’ve already written about AWS Secrets Manager.
Azure has a service that can store secrets called Key Vault.
Google also has a Secret Manager.
Just make sure you think through access to secrets in the event of a cloud outage such as those I wrote about in the last post.
There’s another secret manager called HashiCorp Vault that was popular for a while. I have not performed a security assessment on that solution personally. Just make sure you do your due diligence, no matter which solution you choose.
Define a process
There’s no way to make cloud management easy, but you can make it easier by defining a clear process to those who wish to use cloud services. What are the steps that need to be taken for each new cloud service you use? Where do you track the cloud services, who owns them, and where the credentials exist?
Do you plan for and practice what will happen in the event of a cloud data breach? Who can access the credentials and how? Do you have access set up for security teams or disabled accounts that can easily be enabled if needed?
Do people know how to monitor systems? Are they monitoring systems? Is there a process of sending the logs to a system the security team can access or granting access to review the configuration and logs? When you set up the new system you will probably want to define a process to ensure the logs get to the correct location so the security team has access to them.
Those are a few of the things you need to think about when setting up a new account. I’ve already written about setting up a new AWS account here:
The concepts are similar for Azure and Google but I’ll cover some other information about those two cloud environments in upcoming 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 LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow 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