admin管理员组文章数量:1530014
文章目录
- 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 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
,第二个为虚假的example zone
:
测试部署
Get the IP address of ns.attacker32
与 Attacker nameserver 的zone file对应(此前DNS配置 local DNS server第四点)
Get the IP address of www.example.
1)user主机,输入命令dig www.example,会直接发请求给local DNS server,其会把请求发给对应的官方的nameserver:
2)使用@,直接发给ns.attacker32:
获得的结果与Attacker上zone文件相同:
3)DNS缓存投毒目标
使受害者 向ns.attacker32发送请求,如果攻击成功,输入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的子域名dns请求都会返回被某恶意权威域名服务器的控制的结果。
-
缓存投毒代码task2.py修改如下,代码见task3.py
-
local dns server清除缓存
-
attacker运行代码,user仍旧通过www.example查询
-
结束代码运行,测试其他子域名
hello.example:
test.example:
实现成功!
-
缓存情况确认
将local DNS server的缓存保存到文件中。具体步骤见task2。
被修改的ns记录:
刚刚查询的example域名:
Task 4: Spoofing NS Records for Another Domain
通过Authority Section,将影响扩充到google。实验经过:
-
如下,在task3.py基础上修改编写task4.py,,增加NS记录,其他保持一致。
测试构造多个NS:
-
清除缓存,attacker运行代码,user端
dig www.example
。查看缓存发现仅example的被留在缓存中
-
尝试调换NS记录顺序
仍旧不行 -
将包的判定条件修改为example,成功
并且,user端dig 任意example的子域名都可以。
-
验证
如下,将NS_NAME仍旧改为www.example,与3一样,不一样的是,把NS记录google改为google.example。发现成功录入cache。
-
综上总结
a. 成功的实验步骤为4.所示,1)攻击代码为task4.py;2)local DNS host 清除缓存;3)Attacker端运行代码;4)user端运行dig xxx.example;5)查看缓存成功投毒;6)dig xxx.google不会再像没缓存的时候返回正确的值,而是会返回空A值,因为ns.attacker32中对于只有自己的和example的nameserver。
b.实验关键
1)只会缓存一个域名的NS记录,存在覆盖情况。
2)选择包并构造NS记录时,保证NS记录的
rrname
为条件语句:ns_name in pkt[DNS].qd.qname
的ns_name的同样层级的域名,即ns_name=='example'
时,rrname
为google
。即保证,将所有包含与ns记录对应的域名的包都抓到并构造响应的欺骗包。c.从task4中获取的经验,可以将前面task关于ns部分的代码进一步改进。注:前面没有用到ns记录的代码中关于该部分的没有做详细编写,即没有与实际对应,不影响使用。
Task 5: Spoofing Records in the Additional Section
-
按照要求修改攻击代码task5.py构造部分如下:
-
清除缓存,Attacker运行代码,user端 dig www.example。
可以看到发包的资源记录部分是与预想的一致。
-
,local dns server dump缓存(见task2 3.),缓存结果如下:
1) ns记录都显示了,没有附加记录在缓存中
2) 可以看到,因为ns.attacker32在local dns server中原本就有设置(见环境配置dns配置与测试部署部分),所以并没有被我们构造的Additional Section部分ip:1.2.3.4影响。注释掉Additional Section部分的ns.attacker32,缓存结果仍然与上述相同:
task4的4.情况下,会出现‘;additional ns.attacker32’的cache(见task4 4图)。是因为ns记录被覆盖只剩google的,没有ns.attacker32的,故该additional 记录存在。而我们这次ns记录存在ns.attacker32的。也确实ns.example没有被使用,参考了ns记录的ns.attacker32的,所以www.example才会是1.2.3.5(见该服务器对应zone)。
3)如果将addsec2 ns.example改成ns.example,查询返回A记录是空值。从缓存结果图中看到,ns.example在ns.attacker32前面,于是转向使用它的内容,而该服务器在additional记录中被定义为5.6.7.8,找不到而没有返回。可以推断,符合要求的additional section有参考到的,没有在缓存中显示。
4) 超出域的附加记录会直接被丢弃,即代码中对应第二第三条附加记录都没有录入到cache中。
2.2 DNS_Remote
2.2.1 环境搭建
具体过程与DNS_Local部分相同,不同的是主机有所变化,实验网络结构:
主要欺骗目标为www.example,该域名真实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,且不在缓存中,task2.py:
-
经wirshark抓包可以看到,local dns server 10.9.0.53向别的dns server发起查询。
Task 3: Spoof DNS Replies
-
编写欺骗程序,目的是向local dns server返回xxx.example的response,并欺骗其ns为攻击者的。代码task3.py如下:
其中,ns为攻击者的dns server,目标ip为local dns server的,源端口为53,我们需要伪造真正example给local dns server的response,因此,src ip为某example权威域名服务器的。而在实验环境配置时,我们已经将local dns server的源端口号固定为33333,因此dport =33333。以下为dig example 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的子域名,发送请求包的同时,构造大量id响应包:
伪装权威域名第二个nameserver:
c.函数:随机化函数与原始套接字发送
-
查看缓存,确认成功:
Task 5: Result Verification
-
向local dns server(已经被缓存)发起查询,在dig之前启动wireshark抓包:
-
直接向attacker的dns server发起dig查询:
-
对比1.2.结果,完全一致,即都是在ns.attacker32里设置的example zone规则,www.example为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的ip,最后该dns server返回www.example的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机制应对的挑战留待解决。
版权声明:本文标题:Seed lab dns欺骗实验——dns local&dns remote 内容由热心网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:https://m.elefans.com/dongtai/1726533303a1074407.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
发表评论