FourAndSix: 2.01 Walkthrough

FourAndSix: 2.01 Walkthrough

By: Tony Wu

Welcome to the walkthrough of FourAndSix: 2.01, the second installment of the ‘FourAndSix’ series created by Fred Wemeijer.
The objective of this vulnerable machine is to become root and read the /root/flag.txt.
For more information regarding FourAndSix: 2.01 please visit https://www.vulnhub.com/entry/fourandsix-201,266/.

First Steps: Information Gathering

Our first step is to discover the network we are on using ip r. This indicates that we are currently in the private network 192.168.72.0/24. This is because our virtual machine is in host-only mode for the purpose of this exercise.

A simple netdiscover -r 192.168.72.0/24 scan will reveal our vulnerable machine: 192.168.72.128.

With the IP Address, we are able to perform an nmap scan of all the common TCP ports using the command nmap -sC -sV -A 192.168.72.128:

Mounting the Network File System

The most interesting results from the scan is the NFS → Network File System. The Network File System allows a user or administrator of a system to mount a proportion of the file system onto a server. It allows other users or clients to access whatever is mounted through Remote Procedure Calls, which facilitates the communication between the client and the server. For more information, see: https://searchenterprisedesktop.techtarget.com/definition/Network-File-System.

We can use the showmount -e 192.168.72.128 command to query the server regarding more information about the NFS server. The -e flag shows the export list of the NFS server. In this case, the command reveals that the remote server allows the mounting of the /home/user/storage directory of the machine.

By creating a temporary folder /tmp/blah, and mounting the remote folder to the local temporary folder using mount -t nfs 192.168.72.128:/home/user/storage /tmp/blah, then navigating to the directory, we are shown that there is a backup.7z file.

Extracting the 7z File

It is possible to use the linux command 7za x backup.7z to extract the file and reveal its contents. However, the 7zip file is password protected, which means that the only method is to use a password cracker. The output of the results do reveal some interesting information about the contents of the compressed file, including the public and private keys. More on that later.

In this case there are several methods to attempt to crack the 7 zip file. The most common method is use John the Ripper. This requires to extract the hash from the 7 zip file, using a 7z2john script.

• The Perl Script (Confirmed to work): https://github.com/koboi137/john/blob/master/7z2john.pl
• The Python Script: https://github.com/truongkma/ctf-tools/blob/master/John/run/7z2john.py

The Perl script to create the hash: perl 7zjohn.pl backup.7z > backup.7z.hash. Note the hash continues for a lot of lines past this screenshot. To unhash using john, simply use john --format=7z backup.7z.hash to reveal the password: chocolate.

Alternatively, it is also possible to use hashcat, as well as the 7z2hashcat perl script, located at: https://github.com/philsmd/7z2hashcat. You can also use cracx for Windows, as well as many online tools that are available for password cracking. Re-enter the password after the 7za x backup.7z command to extract the contents of the 7 zip file.

Secure Shell Scripting

The pictures are just ordinary images of Hello Kitty. The other two files however, are the public and private keys that allow for SSH into the remote server. We can concatenate the files to discover more about the keys:

It seems these keys are for the user user@fourandsix2. This credential allows us to attempt to SSH with the private key using ssh -i id_rsa user@192.168.72.128:

Unfortunately, it seems that the authentication is rejected because the passphrase is not provided. The reason for this is probably because the private key is encrypted using a symmetric key derived from a passphrase. Therefore we will need to bruteforce the passphrase to be allowed SSH access.

Normally, ssh-keygen is used to create new public and private keys, but can also be used to dictionary attack and brute force SSH passphrases. The following command found in the help file is what we will need to create a simple script to offline dictionary attack the SSH id_rsa private key.

The bash script takes each word in the most common 1575 passwords (found at: https://github.com/danielmiessler/SecLists/blob/master/Passwords/probable-v2-top1575.txt) inserts it into the -P parameter of the ssh-keygen command.

After running it, the passphrase is successfully revealed to be 12345678:

Now we can successfully SSH into the machine using the command from earlier:

Enumeration of Local Shell and Privilege Escalation

Since we know the machine has a linux operating system, we can conduct some basic enumeration of the box. Our ultimate objective is to obtain root privileges, and according to whoami we are only ‘user’. The id command shows that whilst ‘user’ has standard user and group privileges, it also as another security permission → wheel.

Wheel is a special user group in modern Unix systems that allows the control access of su (superuser) and sudo commands. This allows the user to gain additional system privileges that are most often restricted to these accounts. Generally, root is also in the wheel group. The most beneficial command in this case will be sudo, since su requires knowledge of the root password.

Unfortunately, sudo does not exist on this machine, but since this is an OpenBSD Linux machine, there is an alternative → doas.

From the above command find / -perm -4000 -type f 2>/dev/null, it can reveal SUID files, which are files that upon execution will set the user ID to be the owner of the file. /usr/bin/doas will be executed with root permissions.

We cannot run any command with doas however, because this is restricted by the system. We can check the doas configuration file located in /etc/doas.conf to find more information:

The first line of the configuration file is exactly what is needed. It permits the user group to execute this command as root through the doas command. Furthermore, there is no password required (nopass), and the environment is kept the same (keepenv). Since it may be a bit complicated, we’ll break it down:

• Permit
• Nopass: Does not require any authentication or password
• Keepenv: Keep the environment the same
• User as root: Grants root permissions for the execution of this command only
• Cmd /usr/bin/less: The less command that is allowed to be used
• Args /var/log/authlog: The argument that the less command can read

Executing this command will open the authlog file in vim with root permissions:

However, it seems nothing can be written in it at the moment. This is because vim is in the incorrect mode. Simply enter ‘v’ into vim to change to visual mode, which allows for command inputs, and then either :shell or :!sh to exit the program and execute the respective shell.

Then simply navigate to the root directory and cat flag.txt and we will have completed the machine! Thank you very much for reading this walkthrough and I’ll see you again next time!

html {overflow-x: hidden;}

Droopy: v0.2 Walkthrough by qwutony

Hello everyone! Thank you for visiting my blog site where I talk about Offensive Security.
My first post is about Droopy, a vulnerable boot2root machine that is available on Vulnhub (https://www.vulnhub.com/entry/droopy-v02,143/).

This is the methodology of how I successfully obtained root permissions on the Droopy virtual machine,
and obtain the flag that was hidden after getting root. Let's begin!

Firstly, we find our IP address using ifconfig and ip r.  
A simple netdiscover scan (netdiscover -r 192.168.72.0/24) then revealed all the other addresses on the network.
All the machines are on the local host-only network, so anything caught by the network scanners will either by my machine or the virtual machine or the local gateway.

It seems like the vulnerable machine has an IP address of 192.168.72.130. We should then use a nmap -Pn -v [IP Address] scan.

The nmap scan revealed that the only port open after scanning the first 1000 common ports is port 80 (HTTP).
We’ll run a deeper nmap scan using nmap -sV -A -v [IP Address] but for now we’ll explore more into the HTTP port. A dirb (directory buster) scan should reveal any hidden URLs and potential directories:

(There is more to this scan, but the image is cropped because the other parts are irrelevant.
Also, because of some issues with the server I have to redownload the VM, which means the IP address has changed.)

Let’s have a look at the robots.txt file:

There are some interesting directories in this. The /includes/ directory has a lot of other subdirectories which have all the files to the website.
The website by the way, is a simple Drupal web server, which is a content management system - more on that later. A navigation through the URLs in robots.txt didn’t yield me much, so I moved on.

Once I had discovered that the web server was running on a Drupal CMS engine, I decided to use CMSmap to do some further enumeration of the server.
The most interesting pieces of information was that the server is run using Apache, PHP and Drupal 7.30.

Drupal 7.3 is interesting because generally CMS has many vulnerabilities. I searched it up on CVE and turns out there are a lot of vulnerabilities.
The most interesting one is the first one because it allows for remote code execution. We want to create a limited shell on the server, so remote code execution is the best idea.

After trying this for a while, I realised that it doesn’t seem to work. After a while I decided to give something else a try.

So while I was reading into that, I was a little distracted and thought that it would be a good idea to use Metasploit to infiltrate the system.
I opened msfconsole and searched for Drupal related exploits. The Drupalgeddon 2 allows for remote code execution so let’s give it a try.

So after configuring the settings for the exploit, I tried to activate it but it failed repeatedly.
After being unable to figure it out, I decided to change to another method.

Searching around the internet again, I realised that there was a possible SQL Injection that allowed creating an admin user on the server.
It was a python script. I decided to give it a try:

I succeeded in creating another account, and then logged into the system.
After awhile I found the original admin - drupaladmin, and decided to take over his account for fun:

After navigating around the website, I noticed that it is possible to execute PHP code from the website.
It required changing some of the admin settings to allow for PHP code to be allowed on the webpage. I downloaded the code for a reverse shell and pasted it in the body of an article to be executed:

This allowed for the creation of a web shell, which can then be redirected back to create a shell.

Success! This allowed the creation of a limited reverse shell on my computer, which I used to navigate around.
The commands that I typed to enumerate the system included:

• Uname -a (revealed that it was a droopy linux kernel)
• Cat /etc/passwd (showed some username)
• Whoami (www-data)
• Cat /proc/version
• Cat /etc/issue
• Ps aux (found that there is netcat on the system, which turns out to be useless)

I tried to find some vulnerabilities using netcat, cron and apache, however they didn’t work.
I decided maybe there were some kernel-related vulnerabilities that will allow for privilege escalation, so I searched the name of the kernel.
I downloaded the exploit and transferred it to the /tmp folder of the server using netcat -lp [PORT] > file.
It was important to transfer to the /tmp folder because this directory has execute permissions for the limited shell user.

Unfortunately, the SHELL file could not be executed using ./SHELL no matter how much I tried.
It seems like the shell that was uploaded to the website has limited functionalities, so we found another PHP reverse shell that was more capable.
This allowed us to execute the shell, and obtain root!

Now it is time to locate the flag. After a while of locating, I found a mail with a clue that seems to point at using the rockyou wordlist to bruteforce a password.
Then I found the dave.tc file that is located in the /root home directory.

I created a simple python server to transfer the dave.tc file onto my own computer.

After a long time of research, I discovered that the .tc file extension is truecrypt, and the password can be cracked using truecrack.
The clues from the www-data file indicates that the password is in the rockyou.txt file that has academy in the name.
After a while of searching and using truecrack, the password was found.

The output of the file was in /dev/mapper. I used the mount function to mount the file into a new directory in the /mnt folder.
Opening the folder resulted in three files and a secret file.

After probing a bit, in the directory .secret/.top was the hidden flag!

Using cat flag.txt we revealed the flag and completed the challenge!

Thank you very much and I hope my first walk-through was useful to you! - Tony