DNS Spoofing: Part Deux
A little more info on data packets, the DNS layer and what fields to check if you suspect spoofing!
The more you know, the less that surprises you… and that’s an advantage worth having. And consider yourself one of the very privileged few to get this advantage because these network security posts are so boring that only like 14 people ever read these. So… 14 out of roughly more than 7 billion people on this planet makes you very special! Statistically speaking, that makes you more elite than the “one-percenters” of society.
Anyway, that’s enough of my “pandering to the audience.” I’ll get on with the actual topic.
What are data packets?
Put as simply as my humble understanding can allow, these data packets carry the stuff we see on the internet, among many other types of data. The “many other types of data” is where hackers can fiddle around and change what you actually see.
It’s helpful to think of these packets as like onions, as in they have many layers. And so the first level to a packet is actually called a layer. Within the layers are fields and/or sub-layers, which can also have fields or more sub-layers, and so on…
Anyway, that’s a grossly oversimplified explanation of a data packet, but you can get a better idea of how they appear programmatically in the first post of this series … and here’s a more technical description of what a data packet is
What is the DNS layer?
DNS Spoofing is called what it is, because the strategy involves spoofing (modifying) the DNS layer of a data packet. There’s roughly three ways to carry out this strategy:
- Install and configure a DNS server
- craft a DNS response
- forward the original request unmodified, and then modify the response sent back to the user
The screenshots below refer to a spoofing attack that carries out the 3rd strategy listed above. To incorporate this strategy, a hacker will gain m.i.t.m. status and then capture and modify response packets sent to the user from the internet. The screenshots will show you which fields to check for if you suspect this attack.
What are the Fields to Check in a Suspected Spoofed Packet
Now that we have a little more context on what a data packet is, we can understand a little better what we’re looking at when we examine a potentially spoofed packet.
Environment Set-up
To do this yourself, please refer to the code I shared in the previous article, and here’s a little background on running it if you’re so inclined:
The code was tested on a Kali Linux virtual machine through VMware Workstation 16 Player. It should be able to run on any OS as long as you have Python 2 on your computer. Feel free to copy the code, refactor it, tweak it, whatever.
Code
As mentioned it’s python 2, but I’m sure a simple tweak can get it to work on python 3.
Furthermore, to develop this program,netfilterqueue and scapy were imported.
Fields to Check for Spoofing
So, when examining a data packet for spoofing check these fields:
- chksum — this field is found in the IP and UDP layers of the data packet; it used to make sure a packet has not been modified
- len — also found in the IP and UDP of the data packet; this field corresponds to the length of the layer
- ancount — found in the DNS layer of the data packet; corresponds to the number of responses that can be counted in the \an \ layer, which is a sub-layer of the DNS layer
Now, to verify if you’ve been spoofed or not, just compare the suspected spoofed packet with a data packet you know not to be spoofed and see if you can find any discrepancies… or any inconsistencies within the spoofed packet itself. For example, a quick one to note would be the ancount field, as shown in the screenshot above. If the number doesn’t match the actual number of response answers received then we have a RED FLAG.
Anyway, that’s all for now. I hope this quick and dirty explanation has helped you gain a little more digital situational awareness. I encourage you to do more research on this because I only provide a broad overview of this and more knowledge is better.