Pillaging Data from Private AWS Subnets

Exploiting overly permissive VPC endpoints to exfiltrate data from private AWS subnets

When conducting AWS configuration reviews and when l see VPC endpoints in use, more often than not they are configured with permissive default policies which allow all actions, principals and resources and therefore can be exploited to easily exfiltrate data from the AWS environment. An example Default VPC Endpoint Policy is shown below:

{
 "Statement": [
  {
   "Action": "*",
   "Effect": "Allow",
   "Principal": "*",
   "Resource": "*"
  }
 ]
}

VPC endpoints are an AWS networking feature which provide private connections between resources within a VPC to supported AWS services using the backbone network and private APIs of each service. This configuration ensures that resources within a VPC do not require an Internet connection or VPN to communicate with other AWS services, directly supporting the implementation of secure isolated networks which do not require the use of potentially insecure public infrastructure. As an example, using a VPC endpoint, a service on an EC2 instance can make a request to the private API endpoint of an S3 bucket to download required objects, if a VPC endpoint has not been created for the S3 service, traffic will instead require a route via an internet gateway or similar device to the public, internet facing S3 API endpoint.

Several VPC endpoint service types include the ability to configure endpoint policies to restrict the communications of resources with the associated AWS services. If no endpoint policy is defined when the endpoint is created, AWS will automatically attach a default policy which provides full, unrestricted access to the associated service, including principals in other AWS accounts. As the default policy provides full access to the service, a malicious actor with access to a private subnet within the VPC could leverage the configuration to extract data from the AWS environment and write data to an attacker controlled service.

Here are two fairly obvious and more common examples of AWS services that can be leveraged via an overly permissive VPC endpoint policy to extract data from private or heavily filtered subsets. There are likely many more.

S3

For example, an S3 VPC endpoint with the default full access policy would provide full access to the private S3 APIs which could be used to extract sensitive information to an S3 bucket within an attacker controlled AWS account. This could be achieved several ways but a common method would be If a malicious user had access to an EC2 instance within the VPC, they could upload the AWS access keys of an IAM user with write permission to an S3 bucket within their own account and use these permissions to exfiltrate data to their S3 bucket via the VPC endpoint. Additionally, tools like S3Backdoor can be used to set up a covert remote command and control channels which can be used by an attacker to maintain access and pillage sensitive data.

SSM

A slightly more involved example is leveraging the Systems Manager service. An overly permissive SSM VPC endpoint can be used to access EC2 instances in an attacker controlled account via the SSM “send-command” and “start-session” commands. Firstly, an attacker with access to an compromise EC2 instance in a private subnet creates an EC2 instance in an external attacker controlled account which has the “AmazonSSMManagedInstanceCore” policy attached to its instance profile and the SSM agent installed. The attacker then needs to upload IAM access keys for an IAM user account with the “AmazonSSMFullAccess” AWS managed policy attached. These can then be used on the compromised EC2 instance in the private subnet to run the AWS CLI SSM “start-session” and “send-command” commands via the SSM VPC endpoint, and copy data to the EC2 instance hosted in the attacker controlled account.

Recomendations

It is recommended that VPC endpoints are created for each supported service within each VPC to limit the requirement for internet connectivity and provide secure access to AWS services. However a custom policy should be created in line with the principal of least privilege for all supported VPC endpoints in use within the AWS environment. These policies should ensure that network connections to AWS services is only accessible to those resources within the internal AWS account or organiation. Care should be taken to restrict access to individual resources by name or ARN and minimize the use of wildcards which may provide unintended access to services. Additionally there are several types of VPC endpoints available including Interface endpoints which are a type of network interface providing access to the PrivateLink network for access to services. These Interface endpoints also support the use of security groups to restrict traffic, however it is recommended that these security groups are used in tandem with VPC endpoint policies as a defence-in-depth approach to implementing fine grained access controls. Other VPC endpoint types such as Gateway endpoints which act as route tables do not support the use of security groups and as such it is essential that a restrictive endpoint policy is implemented to restrict traffic to external resources. An example policy for the S3 service is provided below:

{
    "Statement": [
        {
            "Action": "S3:*",
            "Effect": "Allow",
            "Resource": [
                "*:*:*:*:xxxxxxxxxxxx:*",
                "*:*:*:*:yyyyyyyyyyyy:*"
            ],
            "Principal": "*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalOrgID": "o-zzzzzzzzzz"
                }
            }
        }
    ]
}

This example policy ensures that resources in the isolated network can only use the VPC endpoint for S3 if they try to interact with S3 buckets controlled by specific accounts (xxxxxxxxxxxx and yyyyyyyyyyyy) and only if the principal is from your Org (o-zzzzzzzzzz) In this situation and attacker would not able to access any S3 buckets they control.