Attack and Defense: DHCP Spoofing and DHCP Snooping Lab
Introduction
In the following article, we will first pull off a DHCP spoofing attack. Then examine how it could have been mitigated through the Cisco switch feature DHCP snooping.
One of the basic requirements, for local clients on a network to communicate with each other and out to the internet. Is for each device needing to be configured with basic addressing info (i.e. IP address, subnet mask, default gateway, DNS, etc…).
For medium, to large enterprises, it’s impractical for the network/system administrator to statically configure IP addresses to each client. That is why we set up a DHCP server and then kick back and allow it to automatically assign IP addresses to each client on our LAN.
Once DHCP is up and running. From most admins this is it. We might not think of the possible security implications.
Consider this, an attacker introduces a rogue DHCP server onto our LAN network. This rogue device starts handing out IP leases, however, it puts its own IP address as the default gateway. So, the client’s traffic will be forwarded to the rogue server first before being sent to its actual destination. This is called a man-in-the-attack.
With this rouge server in place. The attacker can now analyze traffic coming from a client device. Stealing clear text passwords and having access to other sensitive information.
One way this type of attack is mitigated this is through a Cisco Catalyst switch feature called DHCP snooping.
When we enable DHCP snooping on our trusty Cisco switch all ports are now categorized as either trusted or untrusted. Port(s) we know that are connected to legitimate DHCP servers are labeled as trusted. Whereas, all other ports are considered untrusted. This means any DHCP replies coming onto an untrusted port are automatically disregarded.
DHCP snooping also keeps track of DHCP bindings and stores this information. Inside this database we see client MAC addresses mapped to DHCP assigned IP addresses. It even provides additional info like VLAN and switchport number the addresses are tied to. This database provides a great resource for troubleshooting a problem. DHCP snooping is a prerequisite to other switch security features such as Dynamic Arp Inspection and IP Source Guard.
Anyways, let’s see all this in action in our lab.
Lab Scenario
In this lab topology, we have an Ubuntu Server acting as our DHCP server. And an Ubuntu workstation acting as our DHCP client. With a switch connecting the devices.
Life is good until an attacker plugs into our switch and introduces a rogue DHCP server onto our LAN.
Initial Lab Prep
The following tools were used to build this lab:
Ubuntu Server 19.10 VM – The DHCP server we are using.
Ubuntu Desktop 19.10 VM – Our DHCP client workstation.
Kali Linux VM – The attacker machine.
Cisco IOSvL2 15.2 – The image for the switch (SW1)
VMware Workstation Pro – Where our VMs located.
GNS3 – Open source network emulator
VMware Workstation Configuration
Once the VMs are setup in VMware Workstation.
We need to create a host-only virtual network adapter and assign it to each VM in the lab.
This will keep the lab network isolated to just our local computer.
A good breakdown of how to create host-only adapters and assign them to VMs can be found here.
After this, we import the VMs into GNS3. For in-depth instructions go here.
Topology and Base Configuration
This how the GNS3 topology for this lab looks like:
Before we jump right into the DHCP spoofing lab and mitigation. We will need to do some preliminary configuration on the switch and the DHCP server.
Cisco Switch Configuration
First thing first, we need to get the network up and running. The following commands achieve just that.
SW1
Configure terminal hostname SW1 vlan 20 name LAN DATA
We name the switch SW1 then create VLAN 20 and name it LAN DATA.
int vlan 20 ip address 10.0.20.1 255.255.255.0 no shut
This switch is Layer 3. So, we create an SVI (switch virtual interface) and assign it an IP address of 10.0.20.1. This IP will also act as the default gateway on the LAN.
int range gi0/0 - 2 switchport mode access switchport access vlan 20 no shut
Here we configure all the interfaces that will be used on the lab network to VLAN 20. Then we enable them.
line con 0 logging synchronous end
This command is optional. I turn it on because it’s a pet peeve of mine to be typing in the terminal then suddenly be interrupted by a console message.
This gets SW1 up and running providing basic connectivity between the devices.
Linux DHCP Server Setup
It’s now time to do some work on the Ubuntu server.
First, before connecting the server to our lab environment we need to connect to the internet and install the DHCP service.
The command used to accomplish this:
sudo apt install isc-dhcp-server
If you want, you could enter the following commands as well, but they are optional:
sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade
This line makes sure the server is patched with the latest updates. A breakdown includes the following:
sudo apt-get update – Fetches the list of available updates
sudo apt-get upgrade – Upgrades the current packages
sudo apt-get dist-upgrade – For kernel package upgrades, also if there are conflicting packages this command may remove the package that’s causing the problem
sudo apt install net-tools
This command installs net-tools which allows us to use more traditional Linux networking commands (which are being phased out) i.e. ifconfig, netstat, route, etc… (this article will try and feature newer commands when possible).
After installing the package(s) we change the network interface of the server to host-only. Shut it down and then turn it back on within our GNS3 topology.
Next, we statically assign an IP address to the DHCP server:
IP address 10.0.20.5
Subnet mask: 255.255.255.0
Default Gateway: 10.0.20.1
DNS: 10.0.20.5
To do this we edit the network settings using the command:
sudo nano /etc/netplan/*.yaml
Then make the following changes:
network:
ethernets:
ens33:
addresses:
- 10.0.20.5/24
gateway4: 10.0.20.1
nameservers:
addresses: [8.8.8.8]
version: 2
This is a screenshot of how it looks on the terminal:
Exit out and apply the config using:
sudo netplan apply
To verify the static IP address of the DHCP server and the default gateway enter:
ip addr route -n
We get output that looks like this:
Finally, we need to setup the DHCP scope (the group of IP addresses we want the DHCP server to hand out).
To do this edit the file:
sudo nano /etc/dhcp/dhcpd.conf
Inside this file we then add the following under the max-lease-time 7200 line:
subnet 10.0.20.0 netmask 255.255.255.0 {
range 10.0.20.10 10.0.20.200;
option routers 10.0.20.1;
option domain-name-servers 8.8.8.8;
option domain-name "nitedata.com";
}
Subnet is the subnet we’re using in this demo 10.0.20.0.
Within this scope, we’re handing out IP addresses between 10.0.20.10 through 10.0.20.200.
Option routers is our default gateway 10.0.20.1.
Option domain-name-servers is the domain server we want to use 8.8.8.8 (optional).
This is how it looks:
Exit nano and save.
Then restart dhcpd.
sudo systemctl restart isc-dhcp-server.service
Time to verify if the DHCP server is doing its job and handing out DHCP leases.
Turn on the ubuntu workstation on the GNS3 topology.
Open a terminal to see:
Alright it’s now confirmed that the DHCP server is assigning DHCP leases. Good!
Time to shut down the Ubuntu machine.
On to the next section…
DHCP Spoofing Attack Lab
#Disclaimer – The following is for demonstration and educational purposes. Please do not attempt in a production environment. Unless you have written permission.
Now, if you happen to like consistency… this attack isn’t for you.
If you happen to be following along, note that 8 times out of 10 this attack won’t work. Throughout my labbing journey, the DHCP server always seemed to assign an IP address to the client workstation faster than the Kali box could. Didn’t matter if I was in a Linux or Windows environment.
After multiple attempts, I eventually got it to work but randomly. I could not seem to replicate the attack successfully on demand.
Researching it online it may have something to do with the virtual environment.
If you attempt to lab this up be prepared to release and renew DHCP leases on the client.
A couple of Linux commands that can achieve that:
sudo dhclient -r eth0 sudo dhclient eth0
And/or restart the client workstation multiple times.
Also, you may want to remove DHCP leases on the DHCP server.
sudo service isc-dhcp-server stop sudo nano /var/lib/dhcpd/dhcpd.leases
Delete all DHCP leases in dhcpd.leases
sudo service isc-dhcp-server start
Start the DHCP service again.
Regardless, let’s get into it.
Alright, our DHCP server is setup. Check
The switch is configured. Check
Our legitimate DHCP server is assigning leases to the client on the network as it should. Check
Now let’s turn on our Kali machine.
The first thing we check is our IP address.
We know we’re on the LAN because we pulled an IP address from our legitimate DHCP server.
Inside our kali terminal, we input the following:
ifconfig eth0 promisc echo 1 > /proc/sys/net/ipv4/ip_forward
The first command enables promiscuous mode on the interface that plugs into the switch. The second command turns on IP forwarding.
With this done. It’s now time to bring up Ettercap.
In the terminal type:
ettercap -G
The program GUI now pops up.
Click on Sniff > Unified sniffing
Select the network interface on your Kali machine that is doing the sniffing. In our case its eth0.
After this, we get additional options on our top menu bar.
Select MITM > DHCP Spoofing
A box comes up with the following fields: IP Pool, Netmask, DNS Server IP.
We’ll leave the IP Pool blank. For Netmask we’ll set to 255.255.255.0 and DNS server we’ll use the public DNS server 1.1.1.1.
Select OK
Now we wait for a new client to join the network and request a DHCP IP address.
Let’s restart our Ubuntu machine.
After the restart is complete. Notice the last message in our Ettercap terminal.
#Note Ettercap will report false positives you will need to verify DHCP lease information on the client workstation.
Looks like Ettercap just assigned a DHCP IP address of 10.0.20.14 to the client.
We go to our Ubuntu machine and check the network info (in a perfect world on the first try) we will see the following:
Notice the default gateway is no longer pointing to 10.0.20.1 but to 10.0.20.13. This just so happens to be the IP of the Kali Linux box.
Kali is now acting as a Man-in-the-Middle on the LAN.
If we were to open Wireshark in Kali Linux, we can now see all the HTTP traffic from the Ubuntu victim.
Remediation with DHCP Snooping
In the last section, we walked through the steps of a DHCP spoofing attack.
All is not lost though.
There is a way to mitigate this attack.
On the Cisco switch we implement the following commands:
Configure terminal ip dhcp snooping ip dhcp snooping vlan 20 int gi0/0 ip dhcp snooping trust
That’s it!
Let’s breakdown the commands:
ip dhcp snooping – Turns on DHCP snooping
ip dhcp snooping vlan 20 – We enable DHCP snooping on specific VLANs in this lab all hosts are on VLAN 20
ip dhcp snooping trust – We identify the port on the switch where the legitimate DHCP server is connected to. In our lab, the legitimate DHCP server is attached to gi0/0. We enter this command to trust the interface.
Remember by default, when we enable DHCP snooping all ports are now considered untrusted. Meaning DHCP messages are discarded.
We’ve now looked at the nitty-gritty of DHCP spoofing. Knowing how it operates and looks like in the wild. We’re now better prepared to defend against it using DHCP snooping.
Mission accomplished!
Leave a Comment