Tuesday, November 28, 2017

arp-ping.sh

For those times you need to do recon with an infected host for pivoting purposes, but don't want to install netdiscover or tools of the like... there's arp-ping.sh. Available on my Github page, but here's the source anyway:

#!/bin/bash

if [ "$#" -ne 2 ]; then
 echo "[!] Usage: arping.sh <network> <mask>"
 echo "    Example: arping.sh 192.168.1.0 255.255.255.0"
 exit
fi

# Check if interface exists
ifconfig $IFACE >/dev/null 2>&1
if [ $? -ne 0 ]; then
 echo "[!] Interface does not exists!"
 echo "    Use ifconfig to check applicable interfaces"
 exit
fi

# Check if IP
DOTS=$(echo $1 | grep -o "\." | wc -l)
if [ $DOTS -ne 3 ]; then
 echo "[!] Not a valid IP Address!"
 exit
fi

# Check if Mask
DOTS=$(echo $2 | grep -o "\." | wc -l)
if [ $DOTS -ne 3 ]; then
        echo "[!] Not a valid Mask!"
        exit
fi

# Check if IP is in range
OCTA=`echo $1 | cut -d"." -f1`
if [ $OCTA -lt 0 ] || [ $OCTA -gt 255 ]; then
 echo "[!] Not a valid IP address!"
 exit
fi

OCTB=`echo $1 | cut -d"." -f2`
if [ $OCTB -lt 0 ] || [ $OCTB -gt 255 ]; then
        echo "[!] Not a valid IP address!"
 exit
fi

OCTC=`echo $1 | cut -d"." -f3`
if [ $OCTC -lt 0 ] || [ $OCTC -gt 255 ]; then
        echo "[!] Not a valid IP address!"
 exit
fi

OCTD=`echo $1 | cut -d"." -f4 | cut -d"/" -f1`
if [ $OCTD -lt 0 ] || [ $OCTD -gt 255 ]; then
        echo "[!] Not a valid IP address!"
 exit
fi

# Check if IP is in range
MASKA=`echo $2 | cut -d"." -f1`
if [ $MASKA -lt 0 ] || [ $MASKA -gt 255 ]; then
        echo "[!] Not a valid subnet mask!"
        exit
fi

MASKB=`echo $2 | cut -d"." -f2`
if [ $MASKB -lt 0 ] || [ $MASKB -gt 255 ]; then
        echo "[!] Not a valid subnet mask!"
        exit
fi

MASKC=`echo $2 | cut -d"." -f3`
if [ $MASKC -lt 0 ] || [ $MASKC -gt 255 ]; then
        echo "[!] Not a valid subnet mask!"
        exit
fi

MASKD=`echo $2 | cut -d"." -f4 | cut -d"/" -f1`
if [ $MASKD -lt 0 ] || [ $MASKD -gt 255 ]; then
        echo "[!] Not a valid subnet mask!"
 exit
fi

# Check for continguous ones in mask
if [ $MASKA -lt $MASKB ] || [ $MASKB -lt $MASKC ] || [ $MASKC -lt $MASKD ]; then
 echo "[!] Mask must be contiguous binary ones"
 echo "    Example: 255.255.255.128"
 exit
fi

# Set Floors and Ceilings of IP ranges
if [ $MASKA -ne 255 ]; then
 FLOORA=$(($OCTA & $MASKA))
 CEILINGA=$(($FLOORA + 255 - $MASKA))
else 
        FLOORA=$OCTA
        CEILINGA=$OCTA
fi

if [ $MASKB -ne 255 ]; then
        FLOORB=$(($OCTB & $MASKB))
        CEILINGB=$(($FLOORB + 255 - $MASKB))
else 
        FLOORB=$OCTB
        CEILINGB=$OCTB
fi

if [ $MASKC -ne 255 ]; then
        FLOORC=$(($OCTC & $MASKC))
        CEILINGC=$(($FLOORC + 255 - $MASKC))
else 
        FLOORC=$OCTC
        CEILINGC=$OCTC
fi

if [ $MASKD -ne 255 ]; then
        FLOORD=$(($OCTD & $MASKD))
        CEILINGD=$(($FLOORD + 255 - $MASKD))
else
 FLOORD=$OCTD
 CEILINGD=$OCTD
fi

echo "========================================================================="
echo "ARPing the range..."
echo "$FLOORA.$FLOORB.$FLOORC.$FLOORD - $CEILINGA.$CEILINGB.$CEILINGC.$CEILINGD"
echo "========================================================================="

for a in `seq $FLOORA $CEILINGA`; do
 for b in `seq $FLOORB $CEILINGB`; do
  for c in `seq $FLOORC $CEILINGC`; do
   for d in `seq $FLOORD $CEILINGD`; do
    arp $a.$b.$c.$d | grep ethernet | tr -d "()" | \
     awk -F" " '{print $2":\t"$1}'
   done
  done
 done
done

echo "========================================================================="

You can write it to a file as-is or, for a "file-less malware" approach, just modify the nested for loop by replacing the variables with your "floors and ceilings" of the infected host's subnet, copy, and paste into terminal (don't forget to clear your bash_history...).

Sunday, February 12, 2017

Exploiting and Protecting Against CVE-2017-0016 (SMB 0-day)

The Vulnerability

CVE-2017-0016 has been explained on many sites, but has yet to be shown a walkthrough to put into perspective just how bad this flaw is and what we can do (in the meantime) until Microsoft releases a patch. The vulnerability exists in Windows 8.1 and newer systems (I successfully tested Windows Server 2012R2 (8.1) and Windows 10. The exploit did not seem to affect Windows 7.) Some sources with a rundown of the flaw include:
  • http://malwarejake.blogspot.com/2017/02/why-you-should-care-about-cve-2017-0016.html
  • http://www.darkreading.com/attacks-breaches/windows-smb-zero-day-exploit-on-the-loose-/d/d-id/1328056

The Exploit

The source code for this exploit has been released on Github over a week ago and is located here. To pull this off, the only thing the attacker needs is the two python scripts (win10.py refers to odict.py... so you only have to run win10.py from command line). 

The Exploit in Action

I'm simply using two Virtual Machine in VMware Workstation:
  • Kali Linux Rolling
  • Windows 10 (Free Microsoft IE/Edge test Virtual Machines located here)
The preparation for Kali is extremely easy:
  • Open a terminal and create the two python scripts and paste (ctrl-shift-v) the Github code inside each one
    vi win10.py
    vi odict.py
  • Create a "web page" in the default Apache directory with an embedded SMB link of some kind back to the attacker machine (My IP of my attacker machine is 192.168.190.132 and I'm using an "image" tag in my example)
  • vi /var/www/html/badpage.html

  • Start the Apache2 service
    /etc/init.d/apache2 start
  • Run the win10.py script
    python win10.py
The "preparation" for the Windows 10 VM is simply a gullible user... This could come in the form of phishing, a defaced web site, or other client-side attack vector. In my example, I simply browse to "http://192.168.190.132/badpage.html" with either Internet Explorer or Edge since these browser STILL support SMB integration.

And... here's what I get seconds later:



Looks like the flaw worked as it crashed the client workstation (Denial-of-Service, if you will).

What Can be Done to Protect Ourselves?

Mitigation is rather easy for external attacks... Block all internet-bound SMB! There is likely NO need for this traffic. Ever. As a community, we've done a good job at blocking inbound TCP 139 and 445 due to the many previous service-side exploits against NetBIOS and SMB, but nothing for outgoing connections.

When it comes to internal attacks... there may be bigger problems since the "trusted" network is now infested with malware. One way to potentially prevent this is to only allow SMB between clients and approved servers (configurable in Windows Firewall or another host-based firewall).

Example Windows Firewall configuration:
  • Start >> type "Firewall" and select "Windows Firewall

  • On the left side of the screen, choose Advanced 

  • Select "Outbound Rules" and "New Rule..."


  • Walk through the prompts and choose:
    • "Port"
    • "Specific Remote Ports: 139,445"
    • "Block the connection"
    • Apply rules to all network types
    • Give the rules a name (e.g., "Outbound SMB Block")
  • The rule should now be at the top (if not, put it there so it is processed first -- before any other programs could potentially allow SMB connections).
  • If SMB to a file server is needed, create a VERY SPECIFIC SMB rule above this one to allow only those approved SMB connections.

Upon re-testing this exploit by navigating to 192.168.190.132, it appears that this mitigation was successful... NO CRASH!


What's next?

This is likely only the beginning of this exploit. Many exploits begin life by crashing a system, but it's just a matter of time before it is morphed into something more malicious (e.g., information disclosure, privilege escalation).