Why one of your favorite pen testing techniques doesn’t work on AWS

One of the first techniques I learned for penetration testing was something called ARP Cache Poisoning, also known as ARP Spoofing. This technique is explained on many other sites so I won’t go into a lot of detail here, but basically, an attacker tricks your machine into thinking the attacker’s computer is your router. Then the attacker can capture all the traffic flowing between you and your router and potentially view or manipulate the packets before passing them on to the actual destination.

Some cloud penetration testing involves the same type of activities you’d use in an on-premises test. However, if you’ve gained access to a virtual machine (otherwise known as an EC2 Instance) on AWS, sorry, your ARP cache poisoning isn’t going to work. Here’s why.

Amazon has something called a “mapping service” that takes the place of some of the functionality of the Address Resolution Protocol. From your point of view, when looking at the traffic on your EC2 Instance, it will appear that your host is performing ARP requests and getting responses just as you would expect. Almost. I was pondering doing some packet captures to show what this looks like, but I found this video by CTO Advisor that did it for me. If you’re curious, check it out: AWS ARP Wire Capture.

When packets leave your virtual network interface, AWS encapsulates them with custom headers that contain information about your VPC. Traffic is routed on AWS using a mapping service which was designed to be meet network scalability and isolation requirements. The source, destination, and mapping service need to agree that the packets are valid as they pass through the cloud network otherwise they will be rejected.

The full explanation is a bit longer and more involved, but now you understand why, if you ever tried to perform ARP cache poisoning on AWS, it’s not going to work as you would expect. In addition to the fact that it won’t work, what you are allowed to test in an AWS penetration test is limited to certain parts of the cloud infrastructure, not including the mapping service. That means if you are trying to perform this attack you might get a nasty-gram from AWS indicating some unapproved activities are occurring in your account.

As a customer, does this mean you no longer have to worry about this type of man-in-the-middle attack in a cloud network? Not really. Although the Address Resolution Protocol attacks as we know and love them no longer exist, similar attacks may arise that target this new cloud infrastructure and networking protocol. What this means is that you are not responsible securing, monitoring, or testing that layer of the networking. You outsource that responsibility to AWS. This concept is not easy for some security professionals to accept who are used to having control of all layers of the OSI model and view every detail in every packet header, but it comes down to risk assessments, liability, and trust. And as I like to say in my classes, you have choices. More on that in a future blog post.

Teri Radichel — Follow me on Twitter @teriradichel


Follow me for future blog posts on cloud security, or sign up for cloud security training to learn more. © 2nd Sight Lab 2019