Vulnhub SP: leopold Walkthrough

    The other day, I received an email from someone who asked me to write up a walk-through on SP: leopold which is part of a new series of boxes on Vulnhub.  Sometimes I really appreciate the Internet for what it truly is -- a remarkable instrument for communication.  It allows someone, from somewhere, to reach out and collaborate with another stranger with a common interest.  I was flattered actually and it made my day.

    When I replied to my new found friend, I said that I would take a look at it over the weekend and I offered my quick thoughts.  I received a reply not long after with a bit more information which included a solid hint.  Prior to receiving that hint, I did what I normally do --

    Starting off with an Nmap scan:

    This machine is pretty much closed down with the exception of SMB.  Looking at the version, I think this is vulnerable to CVE 2017-7494.  Scanning with Nmap specifically for this vulnerability:

    We learn that this server is potentially vulnerable.  When we look up this vulnerability, it scores 10 out of 10:

    Double checking the version:

    3.6.6 -- looks like we have a solid match but we need an open share and we need credentials. 

    At that point, I had to put this on the shelf.  I emailed my new friend back and I explained what I had uncovered.  My friend replied and the response contained a hint which pointed me in another direction.  Basically, I was told that if I sniffed the traffic with Wireshark, I would capture some outbound traffic and Responder could be used to intercept or poison that request.

    I fire up Responder and I see what's up:

    My friend was correct.  Leopold is looking for DISNEYWORLD:

    If you're using Responder on a network with other machines, this could get noisy, if not messy, so if you edit the Responder.conf file, you can isolate the responses to the victim:

    In addition, we can redirect the request to a local file, not a URL.  But if we create a local file which contains a redirect to BeEF, we can hook the browser. 

    Setting up our redirect:

    And then editing the Responder.conf file:

    Then firing up Responder:

    Which is now only listening for requests from our victim. 

    We wait for the request:

    Moments later:

    Excellent!  We've hooked the browser in BeEF.

    We see that we've hooked a Firefox Browser and we move over to Metasploit:

    We get our options setup and...

    We background our job.

    Adjusting our redirect for Metasploit:

    Again, we fire up Responder:

    Moments later:

    We see that Responder answers the request with our malicious URL.  And when we look over at Metasploit:

    We see that we've caught an inbound connection.  

    The first time around, I tried to clean up the connection with the typical syntax but for some reason, it hung the session.  The second time around, I tossed another shell back to Netcat:

    With the Netscat handler setup:

    This time, it cleans up without a problem.  

    Looking at the system, I immediately think Dirtycow:

    I download it, I compile it, and then I execute it:

    And that's a wrap!

    This is the second SP box I've rooted and I have to say that I'm very impressed with this new series.  I had an issue with another one of the boxes which discouraged me but that was probably my fault for switching hypervisors.  But now I feel like I need to go through this entire series because they've upped the game on what they call "easy" and their thinking is outside the box. 

    I'm glad my new friend pointed me to this box because I might have ignored the rest of this series.  To be fair, I can only accept 50% credit for the root since I got the solid hint prior to really digging in.  

    © 2020