FourAndSix 2.01 is a boot2root aimed at beginners.  You can download it from vulnhub here.

Scanning & Vulnerability Analysis

First step is to find our target’s IP address. We’ll accomplish this with arp-scan

arp-scan -l

Our target is located at 192.168.56.102. The next step is to determine what ports are open, using nmap.

nmap -sV -T4 -O -F --version-light 192.168.56.102

Port :22

OpenSSH 7.9 is connected to port 22. Some cursory research with searchsploit reveals no likely vulnerabilities here.

Port :2049

There is a network file share running behind port 2049. We can use showmount to tell us what directory(ies) is being shared. Incidentally, we also learn the likely name of one of the users on the machine, too.

We make a directory to which we will mount that network share, and then mount it. Keep in mind, this isn’t downloading a copy of those files, we are connecting directly to the files on that computer. I forgot this while working with this target, and ended up doing a lot of the following work on the target machine rather than locally. Looking in the network share, we find a 7zip archive. The archive appears to contain a number of images, along with a public and private key. These might be useful for logging into the target via SSH!

Exploitation

7z Brute-Force

If we try to extract the files, though, we’ll find that the archive is password protected!

Luckily, JohnTheRipper (JTR) is capable of brute-forcing 7zip archive passwords. I quickly found that the tool to convert 7zip archives into a format that JTR can handle is included in the version installed on Kali. I followed the instructions at this post to get the correct version, and then progressed with brute-forcing. First, the password hash needs to be pulled from the archive with the following command:

/opt/JohnTheRipper/run/7z2john.pl backup.7z > backup.7z.hash

Then, using john and rockyou.txt, we can brute-force that hash.

Now that we have the password, we can extract the files from the archive.

Looks like the images are just fluff, we could always come back and look for some hidden information in them if we needed to. Let’s start with the id_rsa files, though.

SSH

Taking a look at the public key, the key’s comment is user@fourandsix2. This matches the directory name of the file share (/home/user/storage), and indicates that our username is likely literally “user”

Let’s try logging in with the key.

Unfortunately, the key is protected with a password, meaning we will have to brute force a second password. This is why it is best practice to protect authentication certificates whenever possible. If the user had not, we would already have authenticated access to his/her system.

SSH Brute-Force

Now I tried using john to crack this password, too, but I couldn’t get it to work. I even ended up checking some other write-ups to see if others had any success, and I couldn’t find anyone who had. Not the end of the world, though, we can write our own script to brute-force the credentials. It won’t be nearly as fast, but it should work.

#!/bin/bash



IFS=$'\n'       # make newlines the only separator

set -f          # disable globbing

for pass in $(cat < "$1"); do

  # echo "tester: $pass"

  if ssh-keygen -c -C "user@fourandsix" -P "$pass" -f "$2" &>/dev/null

    then

      echo "[+] Password Found: $pass"

      break

  fi

done

Success!

SSH Login

Now that we have a password, we can try logging in to the target again.

Reconnaissance

Unfortunately, sudo isn’t available, so that escalation isn’t available to us. With Toppo, we had success with files that had the suid bit set (see that walkthrough for a quick explanation of what this is and how it can be used). This time I tried a different one-liner to list all of the files owned by root that had that bit set.

find / -perm -g=s -o -perm -4000 ! -type l -maxdepth 3 -exec ls -ld {} \; 2>/dev/null

Vulnerability Analysis

doas

4th in the list is /usr/bin/doas. Of course sudo wasn’t available, I completely overlooked the OS type identified by nmap in the beginning. We’re working with an OpenBSD target, doas is like sudo but on OpenBSD machines. Let’s see if we can identify whether or not “user” is authorized to use doas.

“user” is allowed to read the contents of the authorization log as root using the command less. This is our ticket! less has a dangerous convenient feature that allows us to execute a shell from within the program. If we are allowed to run less as root, and we can open a shell from within less, we can likely escalate our privileges very easily.

Exploitation

doas less

Let’s read the contents of the auth log as root with less

doas /usr/bin/less /var/log/authlog

From within less, we can get a shell by typing ‘v’ which starts “visual mode” and allows us to enter in a command followed by ‘:!sh’ which opens up a new shell. Let’s see who we are.

We have root!

Bonus – Get Root Password

Let’s see if we can crack any user passwords. First step is to grab the passwd and shadow-equivalent files. The BSD equivalent of /etc/shadow is /etc/master.passwd. Since we have root, we can save each of these files to the file share, change the owner of these copies, and copy them onto our attacker machine.

Next, we use unshadow to convert these two files into a format that john can handle

unshadow passwd master.passwd > unshadowed

The password hashes are bcrypt hashes, we can use john and rockyou.txt to try to brute-force them.

john --format=bcrypt -w /usr/share/wordlists/rockyou.txt unshadowed

After a little bit, I was able to successfully crack the root password, princess1