If you’re going to protect yourself from getting hacked, it helps to understand how you get hacked in the first place. Here are 3 attack vectors for your AWS account, and some best practices to lock them down.
#1: Leaked AWS Credentials
Obviously, if you share your credentials publicly, bad people can do bad things with them. And you wouldn’t do that, right? But mistakes happen, more often than you might think. This particular attack vector most commonly arises from access keys getting committed to public source code repositories. Typically, the committer thought the repository was private.
MITIGATION: DON’T STORE SECRETS IN SOURCE CONTROL
Never check access keys, passwords, or other secrets into source control. It doesn’t matter that the repo is private. Manage them in a secret store that can be accessed at runtime (sometimes at deploy time) such as AWS Secrets Manager, Systems Manager Parameter Store, or Hashicorp Vault.
MITIGATION: OR DON’T STORE SECRETS AT ALL
All of the AWS compute services allow you to specify an IAM Role for their compute instances (EC2 instances, ECS tasks, EKS pods, or Lambda functions) to run as. When you use IAM Roles, the access keys are automatically provided to the process – you don’t have to handle them at all.
#2: Compromised Laptop (Or Desktop)
When bad people steal access to your computer, they have access to do all kinds of things. At the very least, they can easily discover any AWS access keys you’ve stored in the AWS credentials file. They may also be able to log key presses, including the password you enter into the AWS console. You don’t want that.
MITIGATION: MFA
You’ve heard it 1000 times before, but you should be using multi-factor authentication when accessing your production AWS account. This is commonly used to control access to the AWS console, but you should also use it at the command line, and for any programmatic access that originates from your machine. Unfortunately, AWS command line access with MFA enabled is pretty cumbersome. Take a look at aws-vault for a nice way to simplify it.
#3: Compromised Compute Instance
As mentioned above, compute instances (EC2, ECS, EKS, and Lambda) in AWS can optionally run as an IAM Role, which implicitly grants the software on those instances the ability to access other resources in your AWS account. The scope of access depends on the policies applied to the IAM Role.
Under the covers, this works by making access keys available within the environment of the compute instance. For Lambda, they’re in the standard AWS environment variables, while for other types of compute they’re available as metadata that can be queried over HTTP from the box.
If an attacker compromises your compute instance. They can get these keys. And if the associated IAM Role is granted permission to do nefarious things, the attacker can do those nefarious things. That’s not a good thing.
MITIGATION: APPLY YOUR SECURITY PATCHES!
Whether it’s a Lambda script, a docker container in ECS/EKS, or a full operating system running on an EC2 instance, you need to make sure you’re up to date on your security patches. Not staying current on fixes to well-publicized security vulnerabilities is just asking for trouble.
MITIGATION: LEAST PRIVILEGE FOR YOUR IAM ROLES.
You’ve undoubtedly heard this 1000 times as well. Don’t grant your IAM Roles more permissions than they absolutely need for the software running on the instance.
About Arpio
Arpio is comprehensive disaster recovery for AWS so that you don’t have to build it yourself. If your AWS account ever gets hacked, and the attacker decides to ransomware or delete your data (including your backups), Arpio makes it easy to recover.
Learn more at www.arpio.io.
