| Module | Description | Mitigation |
|---|---|---|
| Mount Container Breakout |
Can be exploit on privileged containers or containers with privilege to mount. Creates mount from the container to the host and has access to the host files. |
Reduce container privileges. Prevent creation of privileged containers or with the permissions to mount. |
| docker.sock Breakout |
Can be exploit on containers with docker.sock mounted. It uses docker.sock to create new vulnerable (privileged, with mounts, etc.) container and escape to the host. |
Prevent creating containers with docker.sock mounted. |
| runC (CVE-2019-5736) Breakout |
This module exploit vulnerable runC to escape to the host. |
Make sure to have updated runC version (>1.0.0-rc6). |
| Kubelet attack |
Some Kubernetes cluster might have nodes with Kubelet open for anonymous requests. This module exploit this by listing the pods vulnerable for RCE, run commands inside them and scan the service account tokens from all the pods. |
Make sure that all the kubelets have the config file `/var/lib/kubelet/config.yaml` with the following: 1. No allowing anonymous request: `authentication: anonymous: enabled: false`. 2. Preventing authorization to anyone: `authorization: mode:` NOT set with AlwaysAllow. |
| Pod Escape Using Log Mounts |
A pod running as root and with a mount point to the node’s /var/log directory can expose the entire contents of its host filesystem to any user who has access to its logs. |
1. Don't run as root inside the container. Use a different user or user namespaces. The root in the container is the same as on host unless remapped with user namespaces. 2. Don’t deploy pods with a writeable hostPath to /var/log. Another option related to 2: Don’t allow volume mounts from the /var/log path |
| cGroup breakout |
Abusing the Linux cgroup v1 release agent feature to escape container to the host. |
1. Don't run as root inside the container. Use a different user or user namespaces. By default of docker containers, root in the container is the same as on host unless remapped with user namespaces. 2. Adjust seccomp, AppArmor (or SELinux) profiles to restrict the actions and syscalls available for the container to the minimum required. 3. Don't mount cGroup v1 virtual file system as read-write. privileged containers mount cGroup v1 as read-write. 4. Drop all capabilities (--cap-drop=all) and enable only those that are required (--cap-add=...). In our case dont add cap_sys_admin capabilty. |
| Kernel module breakout |
Break out of the container by abusing the SYS_MODULE capability, which allow to Load and unload kernel modules. |
1. Drop all capabilities (--cap-drop=all) and enable only those that are required (--cap-add=...). In our case dont add cap_sys_module capabilty. |