Intro

  • Today We’ll be discussing a simple way that can help you to reduce the risk of security/data breaches due to leakage of Aws access key.

Background

Ideally, as a best practice, you should consider using temporary security credentials (IAM roles) instead of access keys, and disable any AWS account root user access keys.

But recent history/breach incidents have shown us organizations (including large multi-national corporations) are still using static long term AWS access keys in their cloud computing environments on Internet-facing web servers. The practice of ensuring your development team adheres to your security best practices is important. However, it is more important to prepare for when this policy fails.

Incident Examples

  • The Uber Incident The attack was carried out by two individuals who found a private Github repo being used by Uber Software Engineers. They found AWS access keys and secrets to a company-owned AWS account and subsequently compromised the records of millions of people without getting noticed. This failure to disclose brought lawsuits as well as quite a bit of speculation around the company’s security practices. The attackers obtained data on 57 million people across the globe, hence compromising information like names, email addresses, as well as mobile numbers of customers and drivers.

  • The DXC Incident In this attack The Register reported “a techie accidentally uploaded (an) outsourced firm’s private AWS access keys to a public GitHub repo”. also here, the time to discovery was four days by that time, the attackers have already the stolen keys to start 244 compute resources and pile up a $64,000 AWS bill on DXC’s behalf.

Few others

At this point, you might have understood that if you are using long term static AWS access keys then why it’s so important to ensure you at least have:

  • Mechanisms to prevent tech resources from leaking secrets e.g people putting secrets into code etc which can be detected in CI/CD itself.
  • Visibility of anomalous user behavior, especially regarding your API access keys to various cloud environments.

Also even after all of the above are in place, at the same time we should have some mitigations in place to reduce the risk in case any such event occurs. In the next section, we will be discussing the same

Mitigation

As we know while fixing any security issue it’s equally important to strike a balance between security and convenience, this may be one of the reasons why many companies are still using long-term static AWS keys, and hence need for mitigation methods as discussed below arises.

Mitigation By Simple IP Restriction.

It’s very common for companies to have a static IP address attached with resources for Internet access. So if you know that access to your internal resources like dev/staging environments, internal dashboards, etc has to happen from a specific trusted network/IP(e.g VPN network, etc), then why not apply the same concept/restriction to AWS access keys too.

This seems pretty simple and straight forward but many companies/teams are not doing so, which is proven by the above-discussed security incidents/breaches. Also, I have seen few teams avoid doing this because of an edge case for which we will give a solution below.

Implementation For implementing this restriction we need an IAM policy that will enforce our restriction. The policy should deny any user’s actions made from untrusted IP. To make this happen, we just have to create a condition and specify two keys:

  • aws:SourceIp
  • aws:ViaAWSService

The first key will make sure that we allow access from our IPs, and the second one is responsible for allowing AWS services to access our resources without the restriction [aws services that make requests on behalf of the IAM principal (user or role)].

Your policy may look like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Deny",
        "Action": "*",
        "Resource": "*",
        "Condition": {
            "NotIpAddress": {
                "aws:SourceIp": [
                # here you need to put trusted IPs(by comma) 
                    "x.x.x.x/x"
                ]
            },
            "Bool": {"aws:ViaAWSService": "false"}
        }
    }
}

One more best practice here will be the usage of IAM user groups to apply this restrictive policy. But this approach will work with a single user as well.

Now even if access keys or a user’s credentials will be leaked/compromised, an attacker still has to break into your internal/trusted network) to get into your AWS Account/environment. This drastically reduces the risk of a security/data breach happening due to leaked access keys

Why do we need ViaAWSService key?

When a principal makes a request to an AWS service, that service might use the principal’s credentials to make subsequent requests to other services, and obviously that request won’t be coming from our whitelisted IP and hence not using the above key will break some AWS service calls that make requests on behalf of the IAM principal (user or role).

For example, you can use AWS CloudFormation to read and write from an Amazon DynamoDB table. DynamoDB then uses encryption supplied by AWS Key Management Service (AWS KMS).

for more information see (https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html).

Final Thoughts …

I would strongly recommend first follow aws security best practices, and consider using temporary security credentials (IAM roles) instead of access keys, then implement the above-discussed mitigations.

But In case due to some reason you are using long-term static AWS access keys then the IP restriction alone still reduces a lot of risk if any AWS access key belonging to org is leaked or compromised. This can prevent a big data breach from happening.