Tuesday, February 16, 2016

Vulnhub Primer boot2root walkthrough part 1

From vulnhub.com:

Concept

This is a story based challenge written in a style heavily inspired by Neil Stephensons Snow Crash and William Gibsons Sprawl Trilogy. Each chapter is unlocked by solving the puzzle. From hardcoded clear text javascript password checks, SQL-injections and cracking hashes to a simulated terminal. You only need to start the VM, a webserver will come up and you can connect with your browser. In fact you never have to leave the browser.

Goal

Teach some basic well known techniques and attacks. Spark some curiosity, make the user look at the source code and try to figure out what's going on behind the scenes. The main goal is to give a nice welcoming intro to the scene and hopefully also teach something about ethics and responsibility.

The nmap scan:






The nikto scan:




 Nikto found /phpmyadmin/ directory. After trying to guess various simple passwords, I got in with root:PRIMER.

I tried but was never able to insert a php backdoor using phpmyadmin. Later when I used sqlmap to get an --os-shell, I discovered that there wasn't a writable location to put a shell.

On to the webroot:

The main page at http://192.168.254.130/ has a form for username and password. I read the source and found:

<center>  <form method="post" action="login.php">  <input type="text" name="usr" value="" placeholder="Username">  <input type="password" name="pw" value="" placeholder="Password">  <input type="submit" name="commit" value="Login">  </form>  </center>  <div style="color: #021D29;">  Some f0rms are easier than others.  This one was just a means to get to the next level so there was no need for her to apply her full set of skills or fake credentials. Manufacturing a bo0le4n response would probably be enaugh to let her pass.  </div>



In the Username field I inserted "' OR '1'='1';-- " (note the space after the second hyphen) and landed at URL:

/1_c81e728d9d4c2f636f067f89cc14862c/

When reading the source of this page I find:

<!-- This bot was looking for a Sosū User Agent Identifier she had cracked weeks ago, easy sauce, just a simple md5 hash of the first 7 digits of pi. It was basically common knowledge to the entities moving in these areas but obscurity does create a, albeit virtual, layer of security. -->


echo -n 3.141592 | md5sum

d483d00d07fcc80319d170ccf07fb5be

Since I was proxying my browser through Burp Suite, I set the Burp proxy to intercept then refreshed the page and replaced the user agent in the request with the md5sum above.

I landed at URL /2_eccbc87e4b5ce2fe28308fd9f2a7baf3/

In the page I noticed:

<p>  Mesmerized by the experience she moved around the newly unlocked ever changing outer layer of the company network.<br>  Diverted on a conscious level, her subconscious was working hard on finding the next piece of the puzzle.<br>  A realisation started to form. She needed to penetrate the next circle, blocked of to unauthorized access.<br>  But she felt a presence of something left behind. Like breadcrumbs, not intentional, but something forgotten by an incomplete piece of code to handle access.  </p>


Breadcrumbs? Could that be referring to cookies?

I refreshed the page again. Take a look at the cookie value in Burp:


 I changed the Cookie: activeSession=false to true and forwarded the request.

I landed at URL /3_e4da3b7fbbce2345d7772b0674a318d5/

I viewed the page source and in the header I see: "Think, but don't act like a robot."

One of the first things I did when starting out at the web root was to look at robots.txt, so I already knew that level 4 URL was listed there: Disallow: /4_8f14e45fceea167a5a36dedd4bea2543


After visiting this URL and reading the source I realized that the [ EOF ] at the bottom was a link to the next level, /5_6512bd43d9caa6e02c990b0a82652dca/.

This page has the location of the next level right out in the open:


Visiting this URL results in a JavaScript Window and we're unable to view the source.


Looking in the response in Burp I see that the JavaScript dialog has hidden the rest of the page. In the response source I see the URL of the next level, 7_70efdf2ec9b086079795c442636b55fb.

This page has another JavaScript prompt. Looking at the response in Burp I see what looks like a lot of obfuscated JavaScript and a hint in the middle of it.

/*"Someone didn't bother reading my carefully prepared memo on commonly-used passwords. Now, then, as I so meticulously pointed out, the four most-used passwords are: love, sex, secret, and..." - The Plague*/

This was obviously a hint to the Hackers movie. I googled "The Plague most-used passwords" and found the answer on IMDB. The password is god.


Lowercase god didn't work, but GOD did. No need there to waste time with the JavaScript. I arrived at URL /7_70efdf2ec9b086079795c442636b55fb/

The hint on this page is in the last paragraph.


Hmmm, it had been there since the second node. An artificial pattern. I looked at the pattern of the URLs and noticed that after the level number and underscore, the rest of the URL looks like an MD5 hash. I used hash-identifier to verify that the URL's (minus the level_) were indeed MD5 hashes.


I pasted the hashes into crackstation.net and came up with the following results:


The results are all prime numbers. The next in the sequence would be 19. The MD5 sum of 19 is: 1f0e3dad99908345f7439f8ffabdffc4, so the next URL must be /8_1f0e3dad99908345f7439f8ffabdffc4.

This URL is where things really start to get interesting! Subscribe to my blog and come back for part 2... soon!

Update: As this boot2root seems to be more about a story line with hints, and less about actual security, I don't plan on finishing this one. 

Sunday, February 14, 2016

Vulnhub SickOs walkthrough

This is the highlights of my exploitation of SickOs from Vulnhub. It wasn't the most difficult hack as it only took an hour or less to get root and the flag. Well, at least I didn't think it was difficult.

From the nmap scan results, you can see that only ports 22 and 3128 were opened.


Since port 3128 is Squid proxy, I used it in my Nikto scan to see what was behind the proxy.


Note that /cgi-bin/status appears to be vulnerable to Shellshock.


How to exploit it via the proxy? Normally I would have used a Python Shellshock exploit that's quick and easy. I didn't know off the top of my head how to run a Python exploit through an http proxy, so I googled curl options for specifying proxy, and user agent for the exploit.

First start a netcat listener: "nc -nlvp 443"

Now let's use curl to exploit Shellshock via the proxy on port 3128.


Our low privilege shell:


I remember from PWK/OSCP a lesson I learned was always look for the low hanging fruit first. Always check the webserver directories for secrets in configuration files. I found config.php with a password in the /var/www/wolfcms directory.


Before trying to ssh in using the password in config.php, I checked out the contents of /etc/passwd and noticed the sickos user. Users, even sysadmins are notorious for re-using passwords, so even if the password in config.php doesn't work for root, there may be a good chance it works for another account.


First I tried to ssh in as root:john@123 but was unsuccessful. Next I tried sickos:john@123 and got in! After running the command "id" and seeing admin and sudo groups, all it took to get root was a quick "sudo -i". Always check to see if the unprivileged user in your shell can sudo by entering the command "sudo -l" before resorting to trying exploits for priv escalation.




There may have been other ways to exploit SickOs. I never checked to see if Wolf CMS was using default admin credentials. I also didn't check to see if it was vulnerable to the Wolf CMS arbitrary file upload exploit. Knowing the database username and password, I may have been able to write a file shell or exploit. I didn't see the need since I was able to get in fast and easy without it. This wasn't meant to be a thorough pentest, I was simply having fun with it.

Update: Another way to exploit the host once I found the Nikto results that stated the host was vulnerable to shellshock was to use Metasploit's exploit/unix/dhcp/bash_environment. Setup the exploit options and restart the SickOs host and receive a root shell! Even easier than using curl and then looking for a local privilege escalation exploit.