Comprehensive DNS Attack Analysis: Identifying and Mitigating Five Common Types

First of all, I completely abandoned the second question. Algorithms are particularly stressful for me, so I decisively gave up. After all, it’s no longer time to answer questions, so if there are any errors in the following analysis, please feel free to correct them in the comments. Thank you!

This is a review of the first question in the DNS direction of the DataCon competition. At the time of the competition, I was quite busy at work, so I didn’t participate. Now that I have a little more time, I will try to solve these questions, especially since attending the White Hat Conference, President Wu has mentioned that there is a significant gap in personnel who can analyze responses. Therefore, mastering more analytical skills is beneficial.

After decompressing, the data packet for the first question was quite large at 2.6G, so splitting the packets was necessary.

Simulate the attack analysis process of a network administrator. The given traffic contains five types of DNS attack traffic. Participants need to accurately identify the five types of DNS attacks and indicate which packets in the pcap file are attack traffic.

Please pay attention to the focus in the question. We need to find the five types of DNS attacks and specify which data corresponds to which attack.

First, load it into Wireshark and check the IO chart to find the time period with the highest frequency. Split this period into a new pcap packet for the upcoming analysis. (Filtering rule q1_final.pcap always crashes.)

Here I set the range to 3812183-4748606

Next, let’s count the servers, the most requested protocol, packet size, etc.

Protocol classification

As can be seen, the extracted packets only have the DNS protocol, with the majority being packets sent by users actively.

Packet length

In the packet length, it can be seen that there are quite a few packets greater than 1000 that need analysis.

Basic Knowledge Supplement

A DNS resolution query request and response:

52 is the resolution query request, and 53 is the response request that uses the UDP protocol. This results in lower server load and faster responses.

DNS uses TCP protocol during zone transfers, but uses UDP protocol at other times. Since it is the UDP protocol, the source address of UDP should be spoofable, right? This creates a potential for reflection DOS attacks.

DNS Subdomain Bruteforce

First, let’s count the IP list with the highest number of requests. Here, I have to complain that Wireshark is really slow—after half an hour, the progress bar is still only a few percent…

I have no choice but to use the tshark command, which is much faster.

tshark -r timeTop.pcap -T fields -e ip.src -e ip.dst | tr “\t” “\n” | sort | uniq -c | sort -nr

The first IP 45.80.170.1 can be excluded because it corresponds to a DNS service ns2.c76e40.net.

So by filtering 144.202.64.226, I found that the domain name prefixes in the Info field are abnormal and numerous, hence they belong to subdomain bruteforce behavior.

DNS Amplification DDOS Attack

UDP is a stateless, connectionless transport protocol. An attacker can spoof an IP of the victim, request available target servers, and the target server, upon receiving the request, will send data back to the victim, forming a DDOS attack.

In DNS resolution, to return a large number of packets, ANY is typically used, meaning that return packets might be particularly large. For example, dig @114.114.114.114 ANY baidu.cn

This will filter out DNS service response data, next we need to locate the request data initiated by the attacker. Here, it’s important to know which DNS servers support recursion and which do not.

Then, exclude DNS servers that do not support ANY, meaning those that result in Refused (see Appendix: dns.qry.type list, or Wikipedia):

So, what’s left are 71.85.232.160, 127.130.104.152, and 105.191.150.205.

This leads to an interesting finding from the reference “A Few Thoughts on Reflective DDOS Attack Defense”:

The author discovered that his ANY query does not return a response packet larger than 3000 bytes; instead, there is truncation. In the end, they found that using DNS’s extension mechanism (EDNS0) in the source request, along with specifying the UDP payload size, could dictate the length of the returned message.

So, by filtering through dns.rr.udp_payload_size, one can identify attack requests:

Interestingly, a new attack type was found when filtering by type.

Unauthorized Dynamic Updates

Checked up on [Dynamic update response], and it implies dynamic updates.

Unauthorized Dynamic Updates: With the advent of the Dynamic Host Configuration Protocol (DHCP), client computers are dynamically allocated IP addresses by the DHCP server, making the previous manual updates of their A (Address) records and PTR (Reverse Resolution) records difficult to manage. Therefore, in the RFC2136 draft standard, DNS dynamic update was proposed, allowing DNS clients to register and dynamically update their resource records any time their IP addresses or names change. Although the DNS dynamic update protocol specifies that only authorized hosts can dynamically update the server’s zone file, attackers can still use IP spoofing to impersonate a trusted host to add, delete, and replace zone data.

There were a total of 5055 Dynamic update requests.

Zone Transfer Vulnerability

This one is relatively easier to detect, comprised of IXFR and AXFR:

It can be seen that the requests are centered on the IP 96.199.230.176, so just calculate its initiation number.

DNSSec Domain Traversal (Enumeration)

This last one is really hard to find. After Googling for a long time, all DNS attack types are just repeats of the aforementioned four types. No choice but to check other experts’ writeups.

DataCon 9102: DNS Analysis, THU Team 1

https://github.com/shyoshyo/Datacon-9102-DNS

At first, I was quite puzzled—why does this count as an attack? Because in timeTop.pcap I also saw it, wasn’t it just a packet with a public key string, not even considered reflection?

Until I saw the master’s script: q1.sh:

https://github.com/shyoshyo/DataCon-9102-DNS/blob/master/src/q1.sh

Alright, I admit I’m just an amateur…

Domain name prefixes with wildcard characters, really astonishing…

Summary

1. Got a basic understanding of DNS, having previously only known it superficially.

2. Gained deeper understanding of DNS protocols and attack scenarios.

3. Learned the ingenious solutions and thought processes of various experts.

This DNS statistic contains almost everything. How come I didn’t realize how useful it was at the beginning?

Common Fields

dns.qry.type List