Seed lab dns欺骗实验——dns localdns remote

文章目录

1. 实验
2. 实验步骤及结果
- 2.1 DNS _Local
- - 2.1.1 环境搭建
  - - 容器部署
    - DNS配置
    - 测试部署
  - 2.1.2 The Attack Tasks
  - - Task 1: Directly Spoofing Response to User
    - Task 2: DNS Cache Poisoning Attack – Spoofing Answers
    - Task 3: Spoofing NS Records
    - Task 4: Spoofing NS Records for Another Domain
    - Task 5: Spoofing Records in the Additional Section
- 2.2 DNS_Remote
- - 2.2.1 环境搭建
  - 2.2.2 The Attack Tasks
  - - The Kaminsky Attack
    - Task 2: Construct DNS request
    - Task 3: Spoof DNS Replies
    - Task 4: Launch the Kaminsky Attack
    - Task 5: Result Verification
3. 总结

1. 实验

本实验的目标是获得对DNS（域名系统）的各种攻击的第一手经验。DNS是互联网的电话簿；它将主机名转换为IP地址，反之亦然。这种转换是通过DNS解析实现的，这种解析发生在幕后。DNS欺骗攻击以各种方式操纵此解析过程，目的是将用户误导到其他目的地，这些目的地通常是恶意的。本实验室主要研究几种DNS欺骗攻击技术。将首先设置和配置DNS服务器，然后在实验室环境中的目标上尝试各种DNS欺骗攻击。

第一个大实验任务（本地DNS欺骗）中进行的攻击假设攻击者位于同一本地网络上，因此可以嗅探DNS数据包。这个假设是为了简化实验任务。第二个大实验任务为远程DNS攻击实验，攻击者在没有嗅探数据包的情况下发起远程欺骗攻击，远程攻击实验室比本地DNS欺骗实验更具挑战性

2. 实验步骤及结果

2.1 DNS _Local

2.1.1 环境搭建

容器部署

清除上次docker网络环境
启动容器

LAN结构如下：

DNS配置

1）Local DNS Server(对应10.9.0.53)

已经部署了bind9程序，配置文件见 etc/bind/named.conf

简化：将源端口号固定为33333（DNS服务器会将DNS请求的源端口号随机化使得攻击更加困难）。文件named.conf.options:
关闭DNSSEC（DNSSEC 是防止DNS欺骗的保护机制）。文件named.conf.options:

DNS cache，以下为常用命令：

# rndc dumpdb -cache // Dump the cache to the specified file:/var/cache/bind/dump.db
# rndc flush // Flush the DNS cache

转发attack32.com zone：请求该域名的都会被转发到它的nameserver

2）user

在/etc/resolv.conf中将10.9.0.53添加为第一条nameserver记录，将local dns server作为首要的DNS服务器。

3）Attacker

设置Attacker的nameserver（ etc/bind/named.conf），第一个为合法的zone attacker32.com，第二个为虚假的example.com zone：

测试部署

Get the IP address of ns.attacker32.com

与 Attacker nameserver 的zone file对应（此前DNS配置 local DNS server第四点）

Get the IP address of www.example.com.

1）user主机，输入命令dig www.example.com，会直接发请求给local DNS server,其会把请求发给对应的官方的nameserver：

2）使用@，直接发给ns.attacker32.com:

获得的结果与Attacker上zone文件相同：

3）DNS缓存投毒目标

使受害者向ns.attacker32.com发送请求，如果攻击成功，输入1）的命令，即可直接获得从attacker处的虚假结果，而不会从域名的合法nameserver处（2）的效果）。

2.1.2 The Attack Tasks

Task 1: Directly Spoofing Response to User

使用netwox工具

1）在local DNS Server 使用命令rndc flush清除缓存。

2）在seed-attacker容器内运行如下：

3）user发起dns请求，成功被欺骗：
使用scapy

1）编写代码task1.py如下：

构造欺骗信息如红框，注意iface为10.9.0.0/24对应的网卡。

2）local DNS Server处清除缓存（rdnc flush)
3) attacker容器内运行攻击scapy代码

4）user端进行dns请求，实际信息被篡改，即攻击成功：

5）潜在问题补充

实际实验中成功没有问题。实验手册中补充，可能会存在正常请求的响应比欺骗包回的快，提出解决方案：使用tc命令延迟向外的流量
```
// Delay the network traffic by 100ms etho对应向外的路由器的网卡，即本实验中对应10.8.0.0/24的网卡
# tc qdisc add dev eth0 root netem delay 100ms
// Delete the tc entry
# tc qdisc del dev eth0 root netem
// Show all the tc entries
# tc qdisc show dev eth0
```

Task 2: DNS Cache Poisoning Attack – Spoofing Answers

task1将攻击目标聚焦于user，需要总是等待user进行请求，效率并不高。task2将目标聚焦于DNS server，会是更高效的方式，即DNS缓存投毒：如果攻击者伪装从其他DNS server来的响应，该DNS Server就会把内容存储在缓存中，会保留相当长的一段时间。在该期间的请求都会直接返回缓存内的结果。我们只需spoof一次，影响就会持续直到下次缓存更新。

使用scapy编写代码task2.py,目标为伪造local dns server发出的向其他dns server的查询的响应包

注：ns记录相关没有对应编写，具体见task3；filter处可以再限制一下条件（src host 10.9.0.53 and dport 53)。
运行代码，user发起一次查询，成功实现欺骗（local dns server先flush缓存）。
查看缓存情况，确认投毒结果

1）local dns server中，将cache dump下来并保存到文件中

2）为方便查看，将文件复制到虚拟机中打开

cache被改变，投毒成功：

Task 3: Spoofing NS Records

进一步修改task2代码，实现NS记录的欺骗，以达成任何example.com的子域名dns请求都会返回被某恶意权威域名服务器的控制的结果。

缓存投毒代码task2.py修改如下，代码见task3.py
local dns server清除缓存
attacker运行代码，user仍旧通过www.example.com查询
结束代码运行，测试其他子域名

hello.example.com:

test.example.com:

实现成功！
缓存情况确认

将local DNS server的缓存保存到文件中。具体步骤见task2。

被修改的ns记录：

刚刚查询的example.com域名：

Task 4: Spoofing NS Records for Another Domain

通过Authority Section，将影响扩充到google.com。实验经过：

如下，在task3.py基础上修改编写task4.py，，增加NS记录，其他保持一致。

测试构造多个NS：
清除缓存，attacker运行代码，user端dig www.example.com。查看缓存

发现仅example.com的被留在缓存中
尝试调换NS记录顺序

仍旧不行
将包的判定条件修改为example.com，成功

并且，user端dig 任意example.com的子域名都可以。
验证

如下，将NS_NAME仍旧改为www.example.com,与3一样，不一样的是，把NS记录google.com改为google.example.com。发现成功录入cache。
综上总结

a. 成功的实验步骤为4.所示，1）攻击代码为task4.py；2）local DNS host 清除缓存；3）Attacker端运行代码；4）user端运行dig xxx.example.com;5)查看缓存成功投毒；6）dig xxx.google.com不会再像没缓存的时候返回正确的值，而是会返回空A值，因为ns.attacker32.com中对于只有自己的和example.com的nameserver。

b.实验关键

1）只会缓存一个域名的NS记录，存在覆盖情况。

2）选择包并构造NS记录时，保证NS记录的rrname为条件语句：ns_name in pkt[DNS].qd.qname 的ns_name的同样层级的域名，即ns_name=='example.com'时，rrname为 google.com。即保证，将所有包含与ns记录对应的域名的包都抓到并构造响应的欺骗包。

c.从task4中获取的经验，可以将前面task关于ns部分的代码进一步改进。注：前面没有用到ns记录的代码中关于该部分的没有做详细编写，即没有与实际对应，不影响使用。

Task 5: Spoofing Records in the Additional Section

按照要求修改攻击代码task5.py构造部分如下：
清除缓存，Attacker运行代码，user端 dig www.example.com。

可以看到发包的资源记录部分是与预想的一致。
，local dns server dump缓存（见task2 3.)，缓存结果如下：

1） ns记录都显示了，没有附加记录在缓存中

2）可以看到，因为ns.attacker32.com在local dns server中原本就有设置（见环境配置dns配置与测试部署部分），所以并没有被我们构造的Additional Section部分ip:1.2.3.4影响。注释掉Additional Section部分的ns.attacker32.com,缓存结果仍然与上述相同：

task4的4.情况下，会出现‘；additional ns.attacker32.com’的cache(见task4 4图)。是因为ns记录被覆盖只剩google.com的，没有ns.attacker32.com的，故该additional 记录存在。而我们这次ns记录存在ns.attacker32.com的。也确实ns.example.com没有被使用，参考了ns记录的ns.attacker32.com的，所以www.example.com才会是1.2.3.5（见该服务器对应zone)。

3）如果将addsec2 ns.example.net改成ns.example.com，查询返回A记录是空值。从缓存结果图中看到，ns.example.com在ns.attacker32.com前面，于是转向使用它的内容，而该服务器在additional记录中被定义为5.6.7.8，找不到而没有返回。可以推断，符合要求的additional section有参考到的，没有在缓存中显示。

4）超出域的附加记录会直接被丢弃，即代码中对应第二第三条附加记录都没有录入到cache中。

2.2 DNS_Remote

2.2.1 环境搭建

具体过程与DNS_Local部分相同，不同的是主机有所变化，实验网络结构:

主要欺骗目标为www.example.com,该域名真实ip为93.184.216.34，由ICANN管理。

2.2.2 The Attack Tasks

The Kaminsky Attack

前述已经完成在同一LAN下的DNS攻击，在同一个LAN下是可以直接看到query包。远程攻击缓存投毒的困难主要在于，响应包的事务id必须与请求包相匹配，而请求包的id通常是随机生成的，不在同一子网无法捕捉包看id，而自己暴力手段猜测id会败在缓存机制下，因为当我们成功之前，正确包已经到达被缓存，在time out 之前，dns server不会再向外查询。

Kaminsky提出的方案（主动构造对应域名的requests，同时大量不同id响应包响应dns server的请求以欺骗完成缓存中毒攻击）：[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Sjq00KT6-1637420403002)(C:\Users\34860\AppData\Roaming\Typora\typora-user-images\image-20211119184255268.png)]

Task 2: Construct DNS request

如下伪造从user端发送dns查询给local dns server，最终目的为让local dns server向其他dns server发起dns 查询。

因此查询字段为xx.example.com,且不在缓存中，task2.py：
经wirshark抓包可以看到，local dns server 10.9.0.53向别的dns server发起查询。

Task 3: Spoof DNS Replies

编写欺骗程序，目的是向local dns server返回xxx.example.com的response，并欺骗其ns为攻击者的。代码task3.py如下：

其中，ns为攻击者的dns server，目标ip为local dns server的，源端口为53,我们需要伪造真正example.com给local dns server的response，因此，src ip为某example.com权威域名服务器的。而在实验环境配置时，我们已经将local dns server的源端口号固定为33333，因此dport =33333。以下为dig example.com ns查到的多个权威域名服务器的name server(2 个)以及ip：
通过wireshark抓包看到我们的response成功到达local dns server：

Task 4: Launch the Kaminsky Attack

使用scapy生成构造dns请求包，代码gen_dns_request.py，将包保存到ip_req.bin
使用scapy构造dns回复包(具体思路见task3），代码gen_dns_response.py，将包保存到ip_resp.bin
使用socket发送请求与响应包实施攻击

编写代码attack.c：

a.读取包：

b.随机化example.com的子域名，发送请求包的同时，构造大量id响应包：

伪装权威域名第二个nameserver：

c.函数：随机化函数与原始套接字发送
查看缓存，确认成功：

Task 5: Result Verification

向local dns server(已经被缓存)发起查询，在dig之前启动wireshark抓包：
直接向attacker的dns server发起dig查询：
对比1.2.结果，完全一致，即都是在ns.attacker32.com里设置的example.com zone规则，www.example.com为1.2.3.5.
抓包观察

以下为第一次dig(1.)的抓包结果，可以看到10.9.0.5向10.9.0.53即local dns server发起查询，local dns server继而向10.9.0.153发起查询，而10.9.0.153为ns.attacker32.com的ip，最后该dns server返回www.example.com的A记录结果。因此我们可以判断攻击是成功的。

不仅是dns请求，arp请求也只有10.9.0.153的，即没有向其他dns server发起query，缓存中已有10.9.0.153：

验证一下第二次dig（2.）的抓包：

二者路径一致。

3. 总结

实验顺利完成，即本地LAN与远程dns攻击两部分都完成。对dns欺骗有了更深刻的认知，对缓存投毒手段在实践中了解的更透彻。同一LAN中，可以通过抓包看见dns包进而实施欺骗，而远程没有这个优势，在id匹配方面是不小的挑战，实验通过Kaminsky方法完成了远程dns攻击。在实际情况下，除了id的随机化，还有dns server源端口变化与DNSSEC机制应对的挑战留待解决。