Detecting rogue DHCP servers with Suricata
Recently I've been asked to detect rogue DHCP servers by a customer.. I never thought it could be such a nice and simple rabbit hole.
What's DHCP and why it might be rogue?
First of all, DHCP: basically a service that provides IP addresses.
When you connect your phone to your home wifi network, the device will most likely talk to your wifi access point to get an IP address.
Having an IP address is essential to become part of a network, but how do we ask for an IP address if we are not part of a network? Simple, we "broadcast".
The device will broadcast a message that basically says
"hey! I'm new here, I'd like to be part of this network but I don't have an IP address yet, could anybody help me please?"
DHCP server to the rescue!
At this point, a DHCP server literally listening for cries of help will interveen and broadcast itself
"Hey! Nice to meet you, here we talk to each other in this network and I can even tell you which IP address you could assign yourself from my pool of available addresses"
Big powers --> Big responsibilities
OK, so this DHCP server gives us an IP address, what's the big deal?
Well, the devil is in the details.. The DHCP server is so kind that it might give you a gateway IP address (which will be useful for your device to get out from the network..like reaching Internet), and DNS servers IP addresses which are other superheroes capable of telling us every IP address for a domain requested like: www.cybermeng.info ;)
Now imagine our DHCP superhero going rogue, first thing it would do is to give your device fake DNS servers IP addresses or a fake gateway IP address.
Why? Because with the help of an evil DNS server and/or gateway, all of the device traffic could be intercepted and modified.
Scary, but can we detect it?
Yes, thanks to an ever watching small mongoose called
"Suricata"
which is a "NIDS" or Network Intrusion Detection System.
Basically it listens on the network to packets that match a set of "signature" we feed it to and it alerts us when something matching one of those signatures appears in the network.
OK, so what's a Suricata signature?
I'm glad you asked ;)
Basically, a signature (in this case to detect a rogue DHCP server) looks something like this:
alert udp !192.168.1.1 67 -> any 68 (msg:"detect rogue DHCP servers!"; sid:123456789;)
basically we say to Suricata:
alert: I want to be alertedudp: when a UDP packet!192.168.1.1: that doesn't come from 192.168.1.1 (which is our "good" DHCP server)->: goes towardsany: any IP address68: on destination port "68" (which is used by the DHCP protocol)
Then we have a "metadata" section between parenthesis that basically indicates a description of the rule and an ID.
Yeah OK, but does it work?
yes, it works. According to the Suricata log, we were able to detect something broadcasting DHCP responses.
I just see random characters
And you are right (kind of..) what you see is a JSON file generated by Suricata that contains some informations but most importantly the "payload":
Which is a representation in Base64
of the actual packet in the network.
Still random characters..
Because to see what really happens we need to decode the Base64, something we can do thanks to a simple base64 -d command on Linux:
aaaand it doesn´t look better isn't it?
That's because our terminal tries to interpret the characters decoded and it's not really able to.
The soulution is to pass those characters to something able to show us in a terminal what they really are, something like hexdump:
Nice table, it still looks like nothing to me
That's because this is how the DHCP protocol is transmitted in the network between devices.
How do we know that? Well, if it's a network protocol, there's an RFC for that: specifically the RFC 2131
An RFC basically it's a very "simple" document that explains how a protocol works and its "datagram" or how to interpret those numbers we see in our table.
In this case, by looking at the datagram:
We can compare each one of these fields with what we obtained:
And we can for example determine which is the "chaddr" or Client hardware address. according to the RFC.
which looks to be:
00 11 32 52 64 9d 00 00 ...
Which should be a MAC address or basically a kind of digital fingerprint of a network device.
There's only one way to be sure:
