My Backdoors in your AWS infrastructure – Part 3: Network

Time for another dose of backdoors that I'll be happy to plant in your AWS environments. With EC2 and IAM already covered, this article will focus on your network. Before describing my network backdoors, however, let's discuss the threats arising from this attack vector:

• Data Breach: A misconfigured database security group can allow unrestricted access, leading to data exfiltration. Imagine a MongoDB instance that's accidentally exposed to the internet. An attacker can easily find it on BinaryEdge, connect to it and dump the entire database, leading to a massive data breach. Your company could face big fines for violating data protection laws and suffer a loss of customer trust.
• Resource Hijacking: Attackers can gain access to EC2 instances, databases, and other resources, using them for malicious activities like crypto mining or launching further attacks. Your EC2 instance may be used to mine cryptocurrency, causing a spike in your operational costs, and draining resources that could be used for legitimate business activities (like a pay raise for your team!)
• Denial of Service (DoS): Gaining network access can allow attackers to flood your VPC with traffic, making it unresponsive for your legit traffic, causing service disruption, and making your customers angry—pushing them to spend their money somewhere else. This could severely damage your brand reputation and result in lost revenue as customers switch to more reliable competitors.
• Man-in-the-Middle Attacks: Misconfigured egress rules can allow attackers to redirect and potentially alter data in transit. If an egress rule is set to allow all outbound traffic, an attacker could reroute your data through a malicious server, capturing sensitive information. This could lead to the theft of intellectual property, giving you a competitive disadvantage, or compromise sensitive customer data, resulting in legal battles.
• Unauthorized API Calls: With network access, an attacker could potentially make unauthorized API calls to services that should not be publicly accessible. This could lead to various forms of abuse, including data manipulation or deletion.

Risks highlighted, let’s use some backdoors to turn theory into practice ?

?

Security Group Rules

Security Groups in AWS act as virtual firewalls that control inbound and outbound traffic to resources like EC2 instances. Unlike traditional firewalls, Security Groups are stateful, meaning if you allow an incoming request from an IP, the response is automatically allowed, regardless of outbound rules.

Ingress rules control incoming traffic, while egress rules manage outgoing traffic. By default, Security Groups deny all inbound traffic and allow all outbound traffic. Rules can be set based on IP protocol, port number, and source/destination CIDR block.

If you have an ingress rule allowing CIDR 10.10.1.17/32 (let's call it "Internal Visitor") to initiate an HTTPS connection with your EC2 instance, it means the Internal Visitor can send a request to your EC2 and your EC2 is allowed to send back the response. On the flip side, egress rules are for connections initiated by your resource. For instance, if your EC2 needs to ask for an update from a patch repository and the security group egress rule allows that connection, the response from remote repository server is also allowed.

In a well-architected three-layer application, each layer should have a pair of inbound and outbound rules in its Security Group to control the flow of traffic. Starting from your public Load Balancer which should have an inbound rule that allows traffic on port 443 from the internet and an outbound rule that directs this traffic to the Security Group of your Frontend Servers. Then, your Frontend Servers only accept traffic from the Security Group of the public Load Balancer and an send the traffic to the Security Group of your internal Load Balancer. Layer by layer, this pattern continues down the stack: the internal Load Balancer only accepts traffic from the Frontend Servers and sends it to the Backend Servers, which in turn have rules to communicate only with your Database Servers on port 3306. Databases usually do not need to initiate any connections.

By using Security Group names instead of CIDR blocks for internal traffic, you make your setup more maintainable and secure. Such configuration ensures that only the necessary components can communicate with each other, following the Principle of Least Privilege. If you use CIDR blocks instead, I may be able to deploy a resource in your “allowed” subnet and talk to your not-so-secure services.

One of the most common misconfigurations I find during my AWS audits is placing your EC2s in public subnets and allowing unrestricted access to various ports like SSH by setting the source to 0.0.0.0/0. It is often a leftover from the development phase. Another frequent mistake is using a single Security Group for multiple resources, which often leads to overly permissive rules. For example, if you use the same Security Group for a web server and a database server, you could end up allowing web traffic to access your database.

To set up a Security Group backdoor, you'll first need to identify the name of the Security Group that's protecting your target resource. Armed with permissions for ec2:AuthorizeSecurityGroupIngress and optionally ec2:AuthorizeSecurityGroupEgress, you can modify the ingress and/or egress rules of the Security Group. This opens the door for additional IPs to not only access the resource but also potentially kick off communication with rogue servers.

But wait, there's another trick up the sleeve. Security Groups in AWS only use ALLOW rules; there are no DENY rules. And you can attach more than one Security Group to a single resource. So, if the current Security Group isn't giving you the access you need, just create a new one with your preferred rules and attach it to the target resource. AWS will combine the rules from all attached Security Groups, giving you the access, you need.

Protection from this kind of backdoors can be challenging. Product teams often require the ability to create, modify, and attach Security Groups to their resources so locking such permissions on Service Control Policy (SCP) level is not commonly done. However, you can limit the potential impact by ensuring there are no public-facing resources with IAM roles. Additionally, consider using Network Access Control Lists (NACLs) as an extra layer of protection to complement your Security Groups.

For detection, Infrastructure as Code tools like Terraform can be invaluable. Any manual changes to Security Groups will show up in the plan of your next Terraform run, alerting you to unauthorized modifications. Additionally, AWS Config can be a powerful ally. By recording changes and setting up rules, you can flag non-compliant resources, making it easier to spot any backdoors.

?

VPC Peering with an external VPC

VPC Peering in AWS allows two VPCs to connect as if they're part of the same network, without the need for a VPN or separate hardware. It's a straightforward but powerful feature that can be exploited if not configured correctly.

To set up a VPC Peering backdoor, you'll need an external AWS account and specific permissions. With ec2:CreateVpcPeeringConnection and ec2:CreateRoute permissions, you can initiate a peering connection with a malicious VPC and add a route to it, effectively creating a network backdoor.

Transit Gateway Attachment

Transit Gateways serve as a network hub, connecting multiple VPCs and even VPNs. They can be a potent vector for backdoors, especially when shared with an external AWS account through the Resource Access Manager (RAM).

To set up this kind of backdoor, you'll need an external AWS account and specific permissions. With ram:CreateResourceShare, ec2:CreateTransitGatewayVpcAttachment, and ec2:CreateRoute, you can share the Transit Gateway with an external AWS account. If the 'auto-accept' setting is enabled on your Transit Gateway, the attachment process becomes even easier. Once the Transit Gateway is shared and the attachment is (auto-)accepted, my network backdoor is ready.

Protecting against VPC Peering and Transit Gateway backdoors involves strict control over who can manage networking resources. Implement a Service Control Policy that denies all network-related actions if not performed by a role like PrivilegedNetworkingRole.

For detection, similar to Security Groups, Infrastructure as Code (IaC) tools like Terraform can be invaluable. Any unauthorized changes to your Transit Gateway settings will appear in your next Terraform plan.

?

Internal Network Lateral Move

This one might sound familiar to those who've seen my "Cloud Hacking Scenarios" presentation. One of the scenarios I discuss involves exploiting a misconfigured Kubernetes Control Plane. Once I've configured .kube/config, I can list all running pods and initiate a bash session using kubectl exec on any of them.

Now, I'm inside your internal network. If you haven't implemented a zero-trust architecture, it's like an open playground for me. I can start poking around, maybe find an internal API that's not properly secured, and extract sensitive data like user credentials or confidential business information.

But the fun doesn't stop there. I could also discover a database connection string with plaintext database username and password. A simple SQL query later, and I've got tables containing customer data or financial records. And if I find an open, internal admin panel, it's like handing me the keys to your kingdom.

For detection, monitoring solutions like AWS CloudWatch or specialized third-party services are invaluable. Anomaly detection can flag unexpected internal data transfers or unauthorized access to services. Additionally, don't underestimate the power of VPC Flow Logs. These logs capture information about the IP traffic going to and from network interfaces in your VPC. By enabling and regularly analyzing VPC Flow Logs, you can identify suspicious activities, such as unexpected data packets being sent to or from your resources, helping organizations catch intruders before they can do significant damage.

?

Takeaways

The article is longer than I expected, so I'll keep this short. If you want to protect your environment, follow the Principle of Least Privilege, do not expose your critical infrastructure parts to the internet, configure granular rules on a firewall and don’t make everyone admin :) But if for some reason you want to get hacked, just do the opposite.

Remember, the fewer permissions a resource has, the less damage I can do if I hack into it. Use Infrastructure as Code to maintain a single source of truth; otherwise, how will you know if something's been tampered with in a "ClickOps" world? And don't forget—collect and ANALYZE logs. Spot my odd behavior in your network and stop me before I own your infrastructure.

Got AWS security questions? Don't hesitate to reach out—I won't hack you on LinkedIn chat :)