Aquaboutic | Focus Security Research | Vulnerability Exploit | POC

 Home

internal test notes of datacon dns attack traffic identification

Posted by mitry at 2020-04-13
all

DATACON DNS direction topic one internal test record.

subject

Data download link: https://804238.link.yunpan.360.cn/lk/surl yf3jspec9qf

Decompression password: 7K! Y $V1 + EJ. YH] = 4

Requirements for internal test questions:

1、 Basic DNS Security Issues

Title Introduction: players find security problems such as attacks around DNS through analysis in a given packet. The packet size of the contest is 2.6g.

Answer submission: the answer should include the IP address, time, end time and domain name list of the attack.

Result of competition

Analytical thinking

To investigate the DNS Security, we first look for the DNS security problems.

Main ideas:

Difficulties and challenges

Timeline

4 hours manual + script analysis + tool analysis

Used to understand dataset, pcap segmentation, UDP, TCP ratio, packet proportion, retransmission, DNS server IP, client IP, etc

4-8 hours (learn the rules of tshark, Snort and Suricata, and make simple magic changes to snort and Suricata to meet the needs of the scene).

Snort and Suricata are host IDS, which have the concept of internal IP network segment (home? Net).

Target IP of all queries is mapped to home net

tshark -r q1_final.pcap -Y "dns.flags.response == 0" -T fields -e ip.dst |sort|uniq -c |awk -F ' ' '{if ($2>=0)print $2 }' > ip.dst

Request IP as attack external IP

tshark -r q1_final.pcap -Y "dns.flags.response == 1" -T fields -e ip.dst |sort |uniq -c |awk -F ' ' '{if ($2>=0)print $2 }' > ip.from

Define and modify snort rules to detect DNS attacks

As follows:

alert tcp $EXTERNAL_NET any -> $HOME_NET 53 (msg:"DNS zone transfer TCP"; flow:to_server,established; content:"|00 00 FC|"; offset:15; reference:arachnids,212; reference:cve,1999-0532; reference:nessus,10595; classtype:attempted-recon; sid:255; rev:13;) alert udp $EXTERNAL_NET any -> $HOME_NET 53 (msg:"DNS zone transfer UDP"; content:"|00 00 FC|"; offset:14; reference:arachnids,212; reference:cve,1999-0532; reference:nessus,10595; classtype:attempted-recon; sid:1948; rev:6;)

Analyze all kinds of attacks and detect them (8 hours +)

Attack and detection

DNS cache poisoning or gateway hijacking

freebuf.com

DNS domain delivery vulnerability

Generally, DNS zone transfer operation is necessary only when there is a backup domain name DNS server in the network. However, many DNS servers are wrongly configured to provide each other with the detailed information of a zone database as long as a client sends a request, that is, to allow untrusted Internet users to perform DNS zone transfer operation. Harm: it is convenient to quickly determine all hosts in a specific area, obtain domain information, such as network topology, server IP address, and provide a lot of sensitive information for attackers' invasion.

Attack characteristics:

Attack steps:

Area transfer attacks are usually AXFR or ixfr (AXFR is the most common, full area transfer, ixfr is incremental area transfer)

Ixfr (incremental zone transfer request) is different from the traditional AXFR (full zone transfer). When ixfr is doing zone transfer (DNS synchronization mechanism), it will synchronize with the differentiated part, while AXFR synchronizes with the whole zone

General data is transmitted by TCP.

Detection logic:

Simply judge whether there is DNS zone transfer attack

tshark -n -r q1_final.pcap -Y "((udp.port==53)||(tcp.port==53))"|grep -E 'AXFR|IXFR' > dns_zone_transfer

There are attacks

Adjust the filter rules to get more detailed data

tshark -r q1_tmp_00967_20190126002811.pcap -Y "dns.qry.type==252||dns.qry.type==251"

A successful attempt to attack

tshark -r q1_tmp_00967_20190126002811.pcap -Y "dns.qry.type==252||dns.qry.type==251" -2 -R "tcp.srcport==53" |grep -v "Refused" tshark -r q1_final.pcap -Y "dns.qry.type==252||dns.qry.type==251" -T fields -e frame.number -e frame.time -e ip.src -e ip.dst -e dns.id -e dns.flags.response -e dns.qry.name -e dns.data -e dns.flags.rcode > dns_zone_transfer_succ_end

detection result

The unsuccessful DNS zone transfer uses snort detection, and you can write a rule yourself:

alert tcp $EXTERNAL_NET any -> $HOME_NET 53 (msg:"DNS zone transfer TCP"; content:"|00 00 FC|"; offset:14; reference:moxiaoxi; classtype:attempted-recon; sid:9999; rev:6;)

Snort's own detection of DNS zone transfer will detect the TCP connection status (established) for TCP, so the above attacks will be filtered out.

Run command line:

sudo snort -r q1_tmp_00967_20190126002811.pcap -c /etc/snort/snort.conf -l ./log/ -A fast

Illegal DNS dynamic update:

sudo suricata -c ./suricata.yaml -r q1_final.pcap -l ./log/

The attack was detected by Suricata with the following alerts:

alert udp $EXTERNAL_NET any -> $HOME_NET 53 (msg:”ET POLICY DNS Update From External net”; byte_test:1,!&,128,2; byte_test:1,!&,6 4,2; byte_test:1,&,32,2; byte_test:1,!&,16,2; byte_test:1,&,8,2; reference:url,doc.emergingthreats.net/2009702; classtype:policy- violation; sid:2009702; rev:5; metadata:created_at 2010_07_30, updated_at 2010_07_30;)

In most production environments, the system administrator configures only secure dynamic updates for DNS. By allowing only trusted domain client computers to automatically register themselves with the DNS server, the management overhead is reduced, and the security risk is significantly reduced. However, in some cases, administrators choose to use non active directory integration zones to maintain policy compatibility with the organization. At this time, any computer can send a registration request to the DNS server. Even if the computer does not belong to the same DNS domain, the DNS server automatically adds the records of the requesting computer to the DNS database.

Check the logic, call Suricata directly, and then modify an output plug-in to get the result.

Test results:

Attacker IP:

19.220.251.87 200.152.141.106 237.205.156.233 18.100.48.86

Attack time: 2019-01-25t20:29:37.010896 + 0800-2019-01-25t23:49:27.633018 + 08002019-01-26t00:22:01.672532 + 0800-2019-01-26t00:50:11.665267 + 0800

List of domain names involved: 2024 domain names in total

DNS Amplification Attack

Amplification attack (also known as leverage attack, English name DNS amplification attack) uses the feature that the reply packet is larger than the request packet (amplification of traffic), forges the source IP address of the request packet, and directs the reply packet to the target being attacked. For DNS server, only need to discard the response packet of the request packet that is not sent out by itself. From the test point of view, send a large number of reply packets to the tested server to see whether they are discarded, and observe whether the CPU utilization rate rises sharply at this time.

Attack characteristics:

Detection logic:

Magically change the Suricata DNS rule base, and then process a wave of output.

alert udp any any -> $HOME_NET 53 (msg:"ET DOS DNS Amplification Attack Inbound"; content:"|01 00 00 01 00 00 00 00 00 01|"; dept h:10; offset:2; pcre:"/^[^\x00]+?\x00/R"; content:"|00 ff 00 01 00 00 29|"; within:7; fast_pattern; byte_test:2,>,4095,0,relative ; threshold: type both, track by_dst, seconds 60, count 5; classtype:bad-unknown; sid:2016016; rev:8; metadata:created_at 2012_12 _11, updated_at 2012_12_11;)

Suricata detects incomplete results, which can be filtered by Wireshark

Dns.flags.response==0 && dns.qry.type==255 && dns.rr.udp_payload_size>=2000 && dns.flags.recdesired==1

Test results:

Detected results:

175.222.102.169 → 188.141.167.218

127.130.104.152 → 187.199.129.12

105.191.150.205 → 70.85.232.160

In this case, we should ignore the attack requests with too large reflection amplification length, as well as the returned packets.

DNS subdomain enumeration

The detection is rough, and the result estimation needs further analysis.

DNS subdomain enumeration is mainly used for violent enumeration of subdomain information to facilitate in-depth attacks in the later stage.

Test results:

Attacker IP:

144.202.64.226

DNS tunnel

DNS tunneling, a kind of covert channel, establishes communication by encapsulating other protocols in DNS protocol. Because DNS is an essential service in our network world, most firewalls and intrusion detection devices rarely filter DNS traffic, which provides conditions for DNS as a hidden channel, so it can be used to achieve operations such as remote control, file transmission, and so on. Now more and more researches have proved DNS Tunneling also often plays an important role in botnet and apt attacks.

Nsec enumeration

Type not found before giving the answer.

For this attack, please refer to the previous blog: https://momoxiaoxi.com/2017/11/05/eisctf/ ා214 – nsec% E8% AE% B0% E5% BD% 95

In short, the attacker can obtain the information of the next data by using nsec to repeatedly obtain the next DNS record, so as to achieve the role of disclosure.

Detection logic:

Get DNS records of all nsec types

Attacker IP, attack initiation time, enumeration of domain name list

tshark -r q1_final.pcap -Y '(dns.resp.type == 47 and dns.flags.response == 1)' -T fields -e frame.number -e frame.time -e ip.dst -e ip.src -e dns.qry.name -e dns.resp.type -e dns.resp.name

Test results:

Harvest

In the whole analysis process, we have learned a lot, which is worth recording.

After reading the following WP submitted by you, you can still see a lot of interesting ideas.

I'll wait for you to share it later, so I won't describe it here.

I hope you will get something from this competition! )

Reference resources

© 2023