Vulnhub RootThis: 1

    I'm working on another box but I can't root it.  The initial foothold is very unique and even though I was tempted to write up just that part, I really want to do a full write-up so I'm holding off.  After banging my head far for too long and spending more time than I allot for these diversions, I decided to step back from it for a day or two.  In my "cooling off" period, I fired up another newly released box from Vulnhub titled "RootThis".  

    Before I get started with the walk-through, let me point to a post I'd recently written:  Drupal to Reverse Shell

    The timing of these articles couldn't be better.  Spending the time working with Drupal and then coming across this box made my life so much easier.

    Let's not get too far ahead --

    Kicking off with an Nmap scan:

    The web port is open and we get a hostname.  I edit my hosts file, add the name and IP, and then go after it with Nikto:

    Not really much gathered from Nikto.  Moving to GoBuster:

    Ok, that gives us a couple of crumbs.  Checking out /backup:

    We get what appears to be a backup file.  Checking the file type:

    We have a zip file.  I rename the file to and in parallel, I'm scanning the Drupal install with Droopescan:

    This version of Drupal should be vulnerable to Drupalgeddon but I get nowhere and I circle back to the backup file:

    Using fcrackzip, I get the password, now we're going to unzip it:

    We retrieve what appears to be a MySQL export.  Rather than search through this file, I want to import it into MySQL in order to query it instead:

    I create a blank DB for the import and now I'll import it into that DB:

    That's odd.  I import it into the Drupal DB I just created but when I search for tables, I come up empty.  Circling back:

    I actually imported it several times until I executed "show databases" which is when I discovered that even though I was telling it to import into Drupal, it was importing into DrupalDB.  That's a first.  I didn't realize the .sql file could dictate where it would end up.  I thought if I gave it a DB that it would go where I pointed it.  I digress.  Not really that important, just something I haven't seen.

    Ultimately, the goal here is to get at the Drupal user hashes:

    Only one user, we grab the hash, and now we're moving over to the password cracking machine.  Checking the hash mode from the Hashcat example hashes, we see that Drupal's mode is 7900:

    Let the cracking begin:

    It took less than one minute to crack the hash, moving to the Drupal login page:

    Using the credentials we just uncovered, we login:

    This is where I'm going to breeze through a little quicker than I would under normal circumstances but I literally just wrote up this exact avenue a week or so ago.  The link is at the top, in the second paragraph.

    Our goal is to upload a reverse shell inside a post but first we need to enable the PHP filter:

    When need to give the Administrator permission:

    We are then able to upload our shell:

    When we select preview with a handler setup:

    We catch our shell.  Cleaning up the environment:

    We learn that Python is not installed.  We move to a different method and then we're going to see what OS we're working with:

    Looking for an easy route to root, I go hunting for credentials in the Drupal settings file:

    Scrolling to where the DB connection gets setup:

    We learn that we already have these credentials from the Drupal admin login.  Hunting around, I find tje user -- "user":

    In user's folder, we find a note to root which clues us into the fact that we can brute root's password easily if we can figure out HOW to do that.  Prior to my brute force attempts, I create a subset of the Rockyou.txt password list:

    With my mini Rockyou file, I'm ready to brute force.

    Admittedly, this isn't something that I frequently do so I spent a couple of minutes trying to figure out if I could loop "su" but it turns out that is not possible.  There were also some posts that indicated that sudo -S was another way of going about it but perhaps that was back in the day.  Current versions of Linux operating systems, the two that I tested, do not like that approach.  

    Then I discovered the command "sucrack" which is exactly what I wanted.  I moved it and my mini Rockyou file over to the server and let it go to work:

    Not long after, I found the root password. 

    Going in for the kill:

    We are root!

    That was a fun diversion and I learned about a new command that might prove to be useful in other situations.  

    © 2020