Where are all of the container breaches?

How will threat actors attack and utilize containers? This is a question I constantly think about. I’ve been working in this area for more than two decades now, and I feel like I should have an answer. But I don’t.

Instead, I have a lot of different ideas, none of which I can really pinpoint as correct. Part of this indecision is because of all the time I spent learning security in the “legacy” world. Containers do not really have an analog. Sure, virtual machines (VMs) are often conflated with containers, but they were never able to scale like containers. They are also used for completely different purposes than containers. It’s taken a while to adjust my thinking and understand where containers actually fit into the attack surface.

The public examples of attacks against containerized environments are very limited. The breaches almost always are cryptomining related, which are serious attacks, but the incident responder in me finds them underwhelming. Another commonality is they are mostly the result of a misconfiguration, whether that be in Kubernetes or a cloud account. The combination of the motives and the tactics have not been very inspiring so far.

The Old Way

Remote code execution (RCE) vulnerabilities have been the main concern in computer security for a long time. They are still, but how does this way of thinking apply to containers? It’s easy to immediately jump to RCE as the primary threat, but it doesn’t seem to be the right way to approach containers. For one thing, containers are often very short lived – 44% of containers live less than five minutes – so an intruder would have to be quick.

This approach also assumes that the container is exposed to the Internet. Certainly some containers are set up this way, but they often are very simple and use well-tested technologies, like NGINX. There may be zero-days out for these applications, but they would be extremely valuable and hard to come by. My experience has shown me that a lot of containers are used internally and don’t connect directly to the Internet. The RCE scenario gets a lot more difficult in that case. I should mention Log4j, though these sorts of vulnerabilities have the potential of being exploited remotely even if the vulnerable system isn’t on the edge.

To read the complete article, visit Dark Reading.