Container Threats and Attack Surface

on-premise, CLOUD & Saas VECTORS

No need to re-invent the wheel, Microsoft and MITRE attack models already have you covered. However, I believe MITRE and Microsoft missed the mark when they put together their threat model on the the Kubernetes platform specifically.

At scale, this isn’t a “Kubernetes” problem, it’s a container security management problem. Large organizations need to understand the vectors in which, Kubernetes clusters and other container platforms are introduced.

On-premise or Cloud or SaaS completely changes the threat profile of the solutions and introduces additional attacks, tools and techniques. Additionally, there are numerous flavors of each platform as well.

A few important takeaways to consider before moving forward

  • Take an inventory of all the container platforms you have. How can you perform asset discovery?
  • Understand where they are hosted and the unique attack vectors of those hosting solutions
  • Consider that you probably have developers pulling down a ton of malicious content onto local Desktops from public registries, think supply chain attack. Are you going to restrict network access at the proxy?
  • Remember you need capability to scan for “Infrastructure-as-code” vulnerabilities
  • Remember you need capability to scan for package vulnerabilities within the container
  • Remember that traditional “detection” tools don’t have the same visibility into these platforms. Do you have runtime detection coverage for threats, lateral movement etc. etc. ?

You can learn more about the Security Architecture strategy to deal with these concerns in this link

Where and how how big is the attack surface

START WITH CLOUD ATTACK MATRIX

https://attack.mitre.org/matrices/enterprise/cloud/

Because so many Container Orchestration platforms are hosted on Cloud services, the MITRE attack framework for cloud is a good place to start but falls short on considering the broader attack surface which most companies need to solve for.

MITRE offer GCP, Azure and AWS etc. covers the platform specific so no need to reinvent the wheel. Each threat matrix can be used to focus on the specific platform that can be abused but we need to enhance them to see the forest through the trees.

Here are a few examples why you should focus on the cloud platform before the container platform itself.

  • Users may deploy many distributed shadow IT instances on container runtime across the enterprise
  • Users may deploy to personal accounts
  • Platforms management interfaces, APIs, Web UIs are more easily exposed to the internet on VPCs
  • Platforms container secrets and container databases may be backed up to insecure cloud storage
  • Platform storage may be deployed on insecure cloud instances
  • Platform may be poorly configured when users input initialization scripts into the cloud deployment
  • Users may inherit super admin permissions to clusters via their cloud Role permissions
  • API keys which deploy, configure and access clusters may be insecurely stored within the cloud
  • Web SSH consoles can be used to backdoor into the platform

All that being said, if you host your container runtime on an underlying platform, then that platform expands the attack surface to the overall solution. If your operating in the public cloud the risk profile increases because of how easy it is to expose your systems to the broader internet as well. Here’s a snippet of other threats to consider as part of the cloud platform you may be building on. Think of it as an onion, at the middle is the infrastructure you use (on-premise or public cloud) and on the next layer is the container runtime and the final layer is the application running on-top of that. You have to peel back the entire onion to fully design for the system.

external integrations vectors

The attack vectors are not limited to the cloud or hosting platforms either. There are even more layers to the onion that need to be peeled back. More layers of abstraction to consider an end-to-end system. Lateral movement and priv escalation attacks are possible via indirect methods as well.

For example ….

  • CICD tools automating and provisioning the Cloud Platform
  • CICD tools automating and provisioning the Container Orchestration Platform
  • Git providing the source code and infrastructure-as-code
  • Docker registries
    • Public
    • Private

If your just learning and trying to figure out where to focus your time on external integration layers, here is some suggestions

  • Complex passphrases for login
  • Integrate into corporate directory infrastructure, not local accounts
  • Manage access by ADOM groups, not local account permissions
  • Integrate with SSO with Multi factor Authentication enabled
  • Set 10-15 minute expiration periods on sessions and tokens
  • Pull secrets from trusted secrets store such as Hashicorp, CKMS, Azure Vault, CyberArk etc.
  • Prioritize patching unauthenticated remote vulnerabilities such as RCE, XSRF, XSS etc.
  • Consider vulnerability scanning of your Docker registries and within CICD pipelines
  • Consider scanning for secrets and tokens in GIT and registries
  • Advanced endpoint detection feeding a SIEM like Splunk

new microsoft mitre att&ck matrix

https://www.microsoft.com/security/blog/2021/03/23/secure-containerized-environments-with-updated-threat-matrix-for-kubernetes/

After all of that, you finally get to the container platform itself where you can begin learning and thinking about how it’s features and capabilities can be abused. Luckily, the below matrix is a good template for a platform specific threat model. Microsoft built this based on Kubernetes but many of these concepts apply to other hosting platforms.

If your just learning and trying to figure out where to focus on the container platform layer, here is some suggestions

  • AuthN
    • Certificate based, Tokens or pluggable LDAP modules
    • How do you generate and distribute the tokens and certificates
    • Who generates the tokens and certificates e.g. grants access
  • RBAC
    • Separation of Cluster Admin, Namespace Admin and other namespace roles
    • EXEC – Lockdown kubectl exec permissions altogether
  • Pod Security Policies (PSP) .. a few notable top priority items
    • Preventing root containers
    • Preventing privilege containers
    • Restricting escalation to root privileges
    • Requiring the use of a read only root file system
  • Admission Controller
    • Consider controllers that lock down cluster to only private registries
  • KubeAPI
    • Consider restricting access to API to cluster admin SSH forward proxy
    • Consider restricting access down to API to CICD systems instead of general Desktops
  • Vulnerability
    • Registry scan
    • Runtime scan for both images, containers and container orchestration platform
  • Runtime detection
    • Consider that containers run in a separate namespace,meaning traditional agent based tools on hosts don’t have visibility into local files, process execution or network movement within the cluster

old microsoft mitre att&ck matrix

https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/