Reputation: 51
I am creating a custom AMI for my AWS EC2 Instances. I am trying to configure a user's password via cloud-init
. I am doing it using passwd
in cloud-init's config.
I was surprised to find out that cloud-init's config (aka /etc/cloud/cloud.cfg
) can be read by anyone:
-rw-r--r-- 1 root root 2607 Oct 25 11:40 /etc/cloud/cloud.cfg
I have the following questions:
/etc/cloud/cloud.cfg
read by all? Can I make it available only for root
?P.S. I tried to look for an answer to any of my questions in the internet, but to no avail.
Upvotes: -1
Views: 125
Reputation: 48
Setting a default password is a well-known & commonly exploited vulnerability class (CWE-1392: Use of Default Credentials). If you're setting this up as a private, dev AMI, setting up a password could be OK. Outside of that, I'd recommend the alternatives at the end.
Is it a security issue if anyone can see a (SHA-512) hashed password of my user? How can I mitigate it?
If you absolutely must offer a password to folks using your AMI, the effort required to crack the hash should be as long as the planned lifetime of the AMI. mkpasswd
offers options to harden SHA-512 password hashes in Ubuntu:
# invoked this way, mkpasswd will expect you to type in the password
mkpasswd --method sha-512 --salt dont_use_this_salt --rounds some_number_of_rounds --stdin
A older question in the infosec Stack Exchange has a discussion on how many rounds make sense. You should set the number of rounds to be appropriate for your use case.
What is the proper way to configure user's password via cloud-init?
If you absolutely have to set a default password in /etc/cloud/cloud.cfg
, you should automate the process by using a custom component in EC2 Image Builder: https://docs.aws.amazon.com/imagebuilder/latest/userguide/create-component-yaml.html
Amazon provides an example using the ExecuteBash action. I'd recommend storing the hash generated by mkpasswd
using AWS Secrets Manager and not the AWS Systems Manager Parameter Store. You should also be able to use the GetRandomPassword
call from SecretsManager to grab, by default, a random 32-character password with the space [a-zA-Z0-9!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~] and pass that to mkpasswd
.
Why is /etc/cloud/cloud.cfg read by all? Can I make it available only for root?
You should assume all users of your AMI can get access to the contents of the filesystem.
Default credentials for your AMI could open the door for folks to exploit the EC2 instance. Here are some alternatives to consider:
If your users can use SSH keys, the following may work:
PubkeyAuthentication yes
and PasswordAuthentication no
in /etc/ssh/sshd_config
. (https://aws.amazon.com/articles/public-ami-publishing-hardening-and-clean-up-requirements/)cloud_init
to snag the selected credentials on launch via IMDS: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/building-shared-amis.html#public-amis-install-credentialsThis way, folks have to authenticate either in the AWS console / AWS cli, and have the proper IAM role to get shell access to the instance running your AMI. Role permissions can be revoked as needed, and you won't have to worry about credential provisioning, complexity, rotation, or disposal.
This won't fit your use case if your intended users aren't AWS users logging into your account. For more info:
Upvotes: 1
Reputation: 857
Is it a security issue if anyone can see a (SHA-512) hashed password of my user? How can I mitigate it?
That depends on your threat model. Sharing this hash with non-root users is generally less secure than not doing so, but based on your other context and questions it seems that you already knew that. I wouldn't recommend doing that for most users. You can mitigate by providing secrets in a format that aren't readable to non-root users.
What is the proper way to configure user's password via cloud-init?
That depends: which cloud / datasource are you using? Are you inserting user-data directly into this file? That's not recommended, though might 'work'.
Why is /etc/cloud/cloud.cfg read by all? Can I make it available only for root?
There are no secrets in this file, and cloud-init doesn't expect users to put these there. If a user puts secrets in a globally readable file, then yes, they have created a security problem.
Upvotes: 1