Common cloud attack surface issues

The migration from on-prem to the cloud, along with the adoption of automation tools, like terraform and chef, have helped to ensure a level of scalability and consistency that really hasn’t existed before now. However, that flexibility can be a bit of a double-edged sword at times, so cloud attack surface management tries to rebalance some of the downsides of the cloud, by making it just as easy to find misconfigurations as it is to cause them. Phew!

So, what kind of cloud attack surface issues are people seeing in the wild?

Best intentions

The point-and-click nature of the cloud consoles and automation tools means that it is really easy for someone to spin up an entire test environment on Friday evening, then forget about clearing it down when they get back on Monday. Due to this, it’s very common to find forgotten servers sitting around unused, racking up costs, and because they are not being actively maintained, also potentially vulnerable to attack.

Firewall quirks

Firewalls and security groups can have quirky defaults that often catch out the unwary. Some have unlisted management ports that are open to the world. Some rule-bases are in fact open by default, and must have an explicit drop-all rule added to the end before any unwanted traffic is rejected. There have also been cases of cloud firewalls that have randomly been removed and replaced a few hours later by the vendor.

IP versions

The vast majority of all traffic is still sent over IPv4, so people tend to be less familiar with IPv6 (even though it has been around for years now). On top of this, the IPv6 support on some of the cloud platforms is a bit strange to deal with. For example, some use a private IPv6 range internally and NAT to public addresses. And others have no internal IPv6 support at all, so everything has to be routed via an IPv6 enabled load balancer. This means that it only takes someone to click the wrong checkbox somewhere, and the defaults for a host or network could be set to include a public IPv6 address by accident.

Automation failures

The recipe-driven automation tools, like puppet and saltstack, mean that it is really simple for a team to create template servers, then deploy them en masse as required. However, it only takes an API call to fail unexpectedly, or a script to break, and you can end up with a fistful of partially-configured servers sitting around, vulnerable to attack.