Searchsploit command line shortcut options -m and -x.

I thought I would share a couple of useful shortcuts I came across recently in searchsploit, the command line search tool for Exploit-DB . This might help someone out as well as a useful reminder to myself. For a long time now when using searchsploit in Kali Linux I have always searched for what I wanted then either manually copied the path to the script to my working directory. Likewise to review the script or text file I would type the path out with either less, more or cat etc. Until now.

I recently came across the shortcuts ‘-m’ for mirror and ‘-x’ for examine. ‘-m’ for mirror will copy that exploit to your current working directory like so:

searchsploit -m shortcut

‘-x’ will allow you to examine the text like this:

searchsploit -x shortcut

Well I hope this helps someone out!

Hardening Microsoft IIS 8.5 Security Headers

In this post we will walk through how to implement some of the most common security headers that crop up in Microsoft IIS 8.5 web application testing. Typically Burp, zap nikto will highlight missing security headers. I have covered some of these for Apache in earlier posts here. Now its time for the same treatment in IIS. Some of the headers I will look at in this session are:

X-Frame-Options header – This can help prevent the clickjacking vulnerability by instructing the browser not to in bed the page in an iframe.
X-XSS-Protection header – This can help prevent some cross site scripting attacks.
X-Content-Type-Options header – This will deny content sniffing.
Content-Security-Policy – This can help prevent various attacks by telling the browser to only load content from the sources you specify. In this example I will only specify the source, ie my webpage however if you have content being pulled from youtube for example you will want to add this site also.
HTTP Strict Transport Security header – This will tell the browser to only ever load https only, once the site has been visited.

Corresponding values for the above headers are described below.

In order to lab this up we will use a vanilla Windows Server 2012 R2 server that has had the IIS role installed and configured and is serving just a simple single page running over HTTPS (only with a self signed cert for testing purposes), which looks like this:

With completely standard configuration output from Nikto would give us the following results:

OWASP Zap would give us similar results (I did this whilst still on http, however you get the idea):

Granted there is next to nothing to actually scan on this pages, however this is really only designed to demonstrate how to implement the security headers.

In the IIS console we will want to select the ‘HTTP Response Headers’, you can do this at the site level as I have done or at the webserver level which will affect all sites.

Next select Add from the left hand side:

First we will add X-XXS-Protection security header, here we can use the value of ‘1;mode=block’, this essentially means we will turn the feature on and if detected block it. Other basic options consist of ‘1’ to enable or ‘0’ to set the header however disable the feature :

Next the X-Frame-Options security header, here we can use the value of ‘DENY’ to prevent any content embedding, however this maybe too strict otherwise there is ‘SAMEORIGIN’ to allow content from your site, another option is to use ‘ALLOW-FROM’ to allow content framing from another site:

Next the X-Content-Type-Options security header, here we can use the value of ‘nosniff’:

The content security policy header, here we are specifying a very basic policy to only load content from the source:

The HTTP Strict Transport Security header, here we are setting the max age the browser should honour the header request, to include all subdomains and the preload essentially means that if HTTP site is available only load via HTTPS so on a second visit load the config first before hitting the site:

Re-running nikto gives us the following output, much better!

Hopefully this has helped harden your IIS web server just that little bit more!

 

MiTM Thick Client Web Services Testing.

This post walks through MiTM Thick Client Web Services Testing designed for testing thick client web applications for web services using burp and iptables on an internal engagement.

Scenario:

So you need to man in the middle web traffic for application testing on an internal test. This could be either a thick client application for web services that has no proxy settings. Or a client device that is using the system proxy settings (ie proxy settings controlled from Internet Explorer). Or proxying traffic from a client device through the browser as any other usual web application test.

In this scenario the thick client application is installed on a corporate device. So we look to setup some sort of MiTM (Man in The Middle) scenario to watch and alter the traffic as we see fit. The client device IP address must remain the same (ACLs are in place for example or you are unable to change the IP address on the client device). A simple solution to this is two use two virtual machines on your testing laptop to get around having two default gateways with the same IP on one device. With some clever iptables rules we can essentially do a double nat type affair and spoof the client device on the corporate network, at the same time spoofing the gateway for the client device. Bingo MiTM nobody is non the wiser. I talk a bit more about iptables in this post.

If DHCP is used on the client device this is significantly simpler. Rather than using the same ip address range as the corporate network you can set this to an alternative IP and thus removing the need for two virtual machines supporting the double NAT scenario.

They say a picture paints a thousand words… so to bring it all together it the scenario looks similar to this:

Example 1 Configurable proxy settings on client device:

In this example the application on the client system is using the proxy settings configured for IE or Firefox. You are able to modify these and so you can redirect traffic to the proxy of your choice on 8080 for example like so. Note Chrome uses IE system settings:

Network Configuration:

Caution: Don’t use network-manager for this. Dual homing interfaces does not play nice in network manager. Stop the network-manager service first, verify it is stopped then continue to work in the standard networking service with the interfaces file.

service network-manager status

service network-manager stop

service network-manager status

service networking status

Now continue to work using just the interfaces file with the standard networking services.

Set the mac address of the eth0 on VM2 the same as the PC mac address

Ifconfig eth0 down

macchanger –mac 08:00:27:8D:CD:53 eth0

ifconfig eth0 up

On both VM2 and VM1:

echo 1 > /proc/sys/net/ipv4/ip_forward

VM2 interfaces file:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 172.16.0.2
gateway 172.16.0.1
netmask 255.255.255.0
dns-nameservers 8.8.8.8 8.8.4.4


auto eth1
iface eth1 inet static
address 192.168.0.2
netmask 255.255.255.0
dns-nameservers 8.8.8.8 8.8.4.4

**Gateway is always set on the forwarding interface.

VM2 iptables:

iptables -t nat -A POSTROUTING –out-interface eth0 -j MASQUERADE

VM1 interfaces file:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.0.1
gateway 192.168.0.2
netmask 255.255.255.0
dns-nameservers 8.8.8.8 8.8.4.4

auto eth1
iface eth1 inet static
address 172.16.0.1
netmask 255.255.255.0
dns-nameservers 8.8.8.8 8.8.4.4

**Gateway is always set on the forwarding interface.

VM1 iptables configuration:

iptables -t nat -A POSTROUTING –out-interface eth0 -j MASQUERADE

Using burp set your proxy to the listening IP and port.

Example 2: No proxy Settings/Thick client App or Web Services etc..

In this example you have a thick client app that doesn’t allow you to set a proxy and doesn’t use the system proxy settings. You can use ‘prerouting’ in IP tables on VM1. This will route traffic destination port 443 and ‘redirect this to port 8081 with this command:

iptables -t nat -A PREROUTING -i eth1 -p tcp –dport 80 -j REDIRECT –to-port 8080

iptables -t nat -A PREROUTING -i eth1 -p tcp –dport 443 -j REDIRECT –to-port 8081

Then using burp configure your proxy to listen on all interfaces for 8080 and 8081 do this for as many destination ports as required. In addition to this ensure ‘Support for ‘invisible proxying’ is enabled.

 

 

Things to Remember!:

After every reboot IP forwarding and iptables will reset so check both on a restart:

cat /proc/sys/net/ipv4/ip_forward

iptables -t nat -L -v -n

To make IP forwarding persistent you can do the following:

Edit /etc/sysctl.conf and uncomment the ‘net’ line:

# Uncomment the next line to enable packet forwarding for IPv4

#net.ipv4.ip_forward=1

 

DNS: hostnames will need to resolve on both the client and proxy machine.

Its is useful to create a bash script for your config for each machine. Then on a reboot there is no faffery looking for the right commands simply run the bash script. Note – the nameservers are pushed to the resolve.conf to save bringing down and back up the interfaces, and restarting the networking. A sample script might look like the below:

 

On the proxy VM:

#!/bin/sh

service network-manager stop
echo 1 > /proc/sys/net/ipv4/ip_forward

echo nameserver 8.8.8.8 > /etc/resolv.conf

iptables -t nat -A POSTROUTING --out-interface eth0 -j MASQUERADE

iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 8080
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 443 -j REDIRECT --to-port 8081

This is definitely a labs worth! Hope this helps!

Server Hardening: HTTP TRACE TRACK Methods Allowed – Part1 Apache

HTTP TRACE / TRACK Methods AllowedMany vulnerability scanners will often bring back HTTP TRACE TRACK Methods Allowed against Apache and Microsoft web servers of the older generation. TRACE is usually associated with Apache and TRACK for Microsoft. This has a CVSS score of 4.3 and is a relatively easy fix. Clearly the older generation operating systems should be migrated to a supported platform, both the later distributions of Ubuntu and Microsoft 2012 R2 do not allow these methods to be used. However a simple way to validate this finding is to use telnet to connect to the web server on port 80, once connected you can type something similar to the following for each method. The ‘Host’, ‘TestA’ and ‘TestB’ aren’t needed however if you use some custom text you will be sure to see it echoed back by the web server if trace is enabled.

TRACE / HTTP/1.1
Host: 192.168.0.29
TestA: Is this correct?
TestB: Are we sure?

Tap return twice to send.

Which would look something like the below as you can see the user input was returned, the web server accepting the method:

HTTP Trace enabled on Apache
HTTP Trace enabled on Apache

Remediation:

As I said the HTTP TRACK / TRACE issue is this is relatively straight forward to fix, simple add ‘TraceEnable off’ somewhere in your main Apache config file outside of the vhost configuration.

Once implemented retesting should reveal that the method is not allowed:

after adding 'TraceEnable off' HTTP Trace disabled on Apache
After adding ‘TraceEnable off’