AWS Command Line Interface (aka AWS CLI) is an open source tool by Amazon that allows you to manage and interact with your AWS account with
the same access and permissions as you would in the AWS Management console. It provides a great method to automate your work without
having to log into the AWS dashboard.
If you use the AWS CLI tool, it will store your AWS CLI credentials and configuration in your home directory by default. It will look something like this:
$ cat ~/.aws/credentials
[default]
aws_access_key_id=ABC
aws_secret_access_key=XYZ
$ cat ~/.aws/config
[default]
region=us-west-2
output=json
The credentials are stored in plaintext files and are not encrypted.
This means that if someone gets access to these sensitive files (specifically: /.aws/credentials) they could potentially get access to the users AWS account.
This seems to be a big enough problem that attackers are actively scanning for it. It's also supported by the uptick in stories that start with "AWS account compromised, massive bill" or "Horrified to see it's $45,000 in charges due to some scammer hacking my account + mining Crypto for the last few weeks"...
Or as shared a few months ago "Rise in AWS accounts getting hacked and owner being stuck with the bill"...
One technique being employed by bad actors is to scan for these sensitive files on web servers and their corresponding websites.
If you are using the AWS CLI tool via a web server (or a web interface of some kind), and your home directory is exposed, someone would
be able to query yoursite.com/.aws/credentials and get full access to your AWS account.
That will allow them to launch new servers, delete yours and compromise your data as if they were inside your AWS account. Or spin dozens of servers for crypto minining.
Here is a list of the configuration files being scanned for by bad actors via port 80 and 443:
/.aws/credential
/.aws/config
/api/.env/.aws/
/.env/aws/credential
/.env/aws/config
We tracked 366 different IPs via our honeypots over the past 60 days:
This number grows as we start to look at production servers and websites. It's a combination of GET'ing or POST'ing those AWS CLI specific files:
109.237.103.9 - - [16/Jul/2022:05:22:38 +0000] "GET /.aws/credentials HTTP/1.1" 404 162 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36" cache:-
109.237.103.9 - - [16/Jul/2022:05:22:38 +0000] "POST /.aws/credentials HTTP/1.1" 404 162 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36" cache:-
109.237.103.9 - - [16/Jul/2022:05:22:38 +0000] "GET /.aws/config HTTP/1.1" 404 162 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36" cache:-
If you are using AWS CLI, make sure that your home directory is not publicly accessible and that if you are running commands as your
web server user (www-data, apache2, nginx) that their home directory on /etc/passwd is not accessible over the web. The default web directory in Ubuntu is /var/www:
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
Which is safe, but if you have additional users or modified your server to store files at /var/www, you might be at risk.
You can also block access to .aws via your Apache or NGINX config. For Apache:
# The following lines prevent .htaccess and .htpasswd files from being
# viewed by Web clients.
#
<FilesMatch "^\.ht">
Require all denied
</FilesMatch>
<FilesMatch "^\.aws">
Require all denied
</FilesMatch>
But ideally, don't run the AWS CLI from a publicly accessible server, specially one that might be at risk of a compromise.
AWS provide additional recommendations here.