For today’s post, I’m going to take a break from walking through a Malware Traffic Analysis PCAP — although there is a (relatively) recent one I haven’t tackled yet. Must..resist..the..temptation. To be honest, as much as I’d love for Fridays to be PCAP analysis, it is also meant to be a time to discuss network forensic topics, explore protocols, etc. Today I’m going to take a look at DHCP. This is in response to last week’s MTA analysis, where DHCP packets were part of our information gathering.
DHCP
Dynamic Host Configuration Protocol (“DHCP”) is a protocol that was developed and is used to assist automating the process of joining a device to a network. DHCP was not the original “help I’m new here!” protocol; it was preceded by the Bootstrap Protocol (“BOOTP”). For the purposes of this post, we’ll be focusing on DHCP but note that BOOTP is still around and does make appearances.
DHCP is a Layer 7 protocol that assists with the task of having to assign an IP address to devices on a network. As networks grew in size (we’re talking from a handful of machines to dozens to millions), it became a very cumbersome and laborious task to manually assign IP addresses. Imagine having to manually control IP address allocation for a hotel or airport WiFi! DHCP is all around us, and while you may not be too familiar with the protocol, trust me you’ve interacted with it hundreds, if not thousands, of times.
If you find yourself doing network forensics, I think it is important to understand what DHCP is doing “under the hood”. As you are gathering information, profiling a host, or looking for “wtf happened here?”, DHCP may be a good starting point. I’m going to examine how a DHCP does an initial lease.
In case you’d like to follow along with an actual PCAP, the screenshots I’m using are from sample DHCP PCAPs available at The WireShark Wiki’s SampleCaptures.
It’s time to go exploring with DORA!
DORA
In case you thought I was referring to the child’s cartoon, I apologize. DORA is actually an acronym that represents the four key steps in a DHCP initial lease allocation. DORA stands for:
- Discover
- Offer
- Request
- Acknowledge (or ACK)
I can hear Phil Hagen telling a Dora the Explorer story now…
Let’s look at each step:
Discover
A network device walks into a bar for the first time. There are a bunch of bar stools; some taken, some available. The network device knows it needs to ask Joe for a seat, but it doesn’t know who Joe is. Wanting to make sure Joe hears the message, the network device yells out loud “HEY JOE! Can I have a seat? I’m the guy in the blue shirt.”
A DHCP Discover packet is similar to the analogy above. When a device needs to obtain an IP address, it sends the DHCP Discover packet to the broadcast IP address 255.255.255.255. Packets sent to this IP address are received by all hosts on the network, and is used in this case to try and find the DHCP server. Let’s look at the first packet in our sample PCAP:
There’s not much going on here, as expected. This is just an initial “Hey, can someone help me out?!” packet. A few notes:
- The client IP address is 0.0.0.0. The client doesn’t know what else to give itself, so this is the default.
- Notice that DHCP uses UDP, and this communication happens between ports 68 and 67. This handshake should take place between these ports.
- Despite a blank IP address, the client is still reachable via it’s MAC address, in this case
00:0b:82:01:fc:42. - Lastly, the packet also contains a Transaction ID; in this case, it is
0x00003d1d. This value is generated randomly, and is used to determine the appropriate transaction.
Offer
Joe walks up to the network device and says “Hey blue shirt. Welcome to the bar. I can offer you stool #25, and you can have it for the next 60 minutes. How does that sound?”
Once the DHCP server receives the request, it responds with a DHCP Offer packet. The Offer packet is simply a response to the Discover that says “Yes, there is a DHCP server here. And, I have some goodies for you! Here’s an IP address, how long you can have it for, and here’s where to find me!
Let’s look at some details below:
- The DHCP server responds with it’s IP address, as well as an offer of an IP address for the new device. In this case, the IP address being offered is 192.168.0.10.
- You should notice that the transaction ID is the same as the Discover packet. This is actually the purpose of the transaction ID; it helps the server and client ensure they are trying to achieve the same thing.
- The DHCP Offer packet also provides lease information. IP addresses are technically “leased” from a pool of available IPs.
Request
The network device is happy with the terms that Joe put forward, and says “I like these terms! I accept your offer.”
The client accepts the DHCP Offer by sending back a Request packet. Note that while this is technically a new request (it’s not a continuation of the previous transaction), the events are chained together as a four-step handshake.
Here’s a snippet from our sample data of the third packet in the DORA quartet:
- The network device responds with a “Sure, I’ll take the IP address that you offered me. 192.168.0.10 sounds great!”
- Note that the request is still being sent to 255.255.255.255, the broadcast IP. At this point in time, the device has still not been assigned the IP address, although it’s pretty much reserved. It’s almost like you’re two feet away from sitting down at the restaurant table — it’s not yours yet, but there’s a very slim chance it’s getting taken.
- The packet takes on a new transaction ID. Remember, we’re still using UDP, and this transaction ID helps the client and server make sure they are having the same conversation.
Acknowledge
Joe tells the network device “Congrats! You are now assigned stool #25. Now, if someone wants to find you, they can just go to your seat instead of looking for your blue shirt. You have the stool for 60 minutes, but let’s chat in a bit if you want to keep using the stool”. The network device, now known as stool #25, begins talking with the other folks at the bar.
The fourth and final piece of this initial DHCP lease is the server telling the client that it is acknowledging its request.
- Note within our packet we once again have lease data, the offered IP address (now solidified), and a subnet mask.
- The DHCP server now assigns the IP address, and the system can use this IP address to talk to others on the network.
References
There are a few staple items that are always part of my network forensic arsenal. As I’ve been asked to share a few, I thought I’d mention them here.
- I’d highly recommend picking up Chris Sanders’ Practical Packet Analysis, printed by No Starch Press. I will be posting a review of this book sometime in the future. Oddly enough, as I was skimming through the book I discovered that Chris modeled his DHCP section after the same packets I did!
- The second book that I always have on hand is TCP/IP Guide by Charles M. Kozierok, also printed by No Starch Press. This is a hefty book — 1616 pages — but the level of detail provided on multiple artifacts and protocols has been a fantastic research tool.
- Lastly, I am a graduate and huge fan of SANS FOR572. I realize that recommending two books and a SANS course are opposite ends of the price spectrum, however if you have an opportunity to choose your next training, take FOR572. Phil Hagen and crew have put together an awesome course — it’s well worth the knowledge and gets you thinking about your network as well as the endpoint.
- As discussed earlier, WireShark maintains a huge collection of PCAPs available for testing and analysis. I highly recommend taking advantage of them!
Until tomorrow, Happy Forensicating!
