kaminsky 漏洞复现
kaminsky 漏洞复现
0x00 写在前面
笔者实现主要参考0x04部分参考资料(1)，该参考资料是笔者在做博客时找到的唯一一篇kaminsky的复现博客(大多数博主注重讲原理而不注重实现)，实现过程写的还是比较详尽的，但由于原文将原理和实现过程割裂开来，一是使得kaminsky的实现过程与原理缺少对应性，使得读者尽管实现但是难以对应原理的理解；二是很多细节没有被强调，没有具体说明操作的原因和重点，导致笔者实际实现过程中出现了很多不必要的错误，笔者不希望更多学习kaminsky的学习者们在复现时再次浪费不必要的时间，甚至因为小细节放弃，因此作此博客。
合作作者CSDN博客（向往阳光的月光）
0x01 实验原理
有一定web和DNS基础的读者请参考0x04参考资料(2)
部分细节没有读懂或没有基础的读者请参考0x04参考资料(3)
0x02 实验环境搭建
这里以污染LDNS下的hetianlab.com为例，实验环境如下图所示：
1.实验环境系统与条件
如图所示，红色代表被攻击者控制的部分，蓝色代表正常的请求所需要的网络架构，一共设计到充当下面几种角色的主机：
-
attacker：kali20.04 ip:192.168.8.178
这里默认了攻击机可以请求local DNS服务
只要具有不是很旧的metasploit即可
-
attcker controlled DNS: ubuntu 20.04 ip: 192.168.8.163
可以安装bind9和配置DNS即可
-
fake hetianlab.com(attcacker controlled)：与主机2为同一主机， ip：192.168.8.163
由于该主机只需要提供web服务，等待LDNS被污染然后受害主机访问即可，因此这里attacker controlled DNS选定了一台主机，有条件可以选择另外一台主机模拟真实场景(假DNS服务器向受害者提供假ip，使之访问攻击者想让其访问的任意网站，用另一个主机模拟真实网站)
-
vul(vulnerable host)：win7 professional sp1 ip：192.168.8.181
向LDNS请求服务，只需要能手动设置DNS，有浏览器即可
注意这个vul主机模拟了向LDNS请求服务的用户主机群，因此涉及的主机范围从家用路由器网关DNS的下的几台，到地区级非权威LDNS(甚至内网专用LDNS，在参考资料(3)中有提及)涉及的上万台，都可以这里vul主机的对象，也就是kaminsky污染成功往往造成的是一片主机的受害
-
local DNS：win server 2008 ip：192.168.8.2
注意选用server时只能选择2008之前的版本，正如参考资料(3)中所述，2008之后的server上默认DNS服务是开启端口随机化的(2008之前DNS服务端口在一段时间内使固定的)，这样就是65535*65535，使得猜解难度变大很多，kaminsky失效，这一点后面会有体现
需要具有DNS服务器功能，端口非随机，可以手动设置上一级DNS
2. 实验攻击行为分析
正常的用户请求报文行为如下图所示：
这里以请求www.hetianlab.com为例，假设这里vul主机的www.hetianlab.com记录的DNS缓存已过期，需要请求服务的LDNS上的hetianlab.com缓存也已经过期
①vul向LDNS发出对www.hetianlab.com的DNS请求
②LDNS递归地向各级权威域名服务器发出请求，直到拿到www.hetianlab.com的那条A记录从而拿到ip
③LDNS把这条A记录(含有www.hetianlab.com的ip)发给vul主机(注意这里最后几层递归中一定有几个hetianlab.com的权威服务器，然后查www主机的ip)，返回①中的请求
④vul主机访问www.hetianlab.com的ip，从而得到网页
但是kaminsky攻击下的行为如下(还是之前那张图)：
这里的假设和正常条件下的假设是一致的
①攻击者主机attacker向LDNS发出大量在hetianlab.com下的不存在的域名(即xxx.hetianlab.com，由于这个xxx主机不存在，所以注定LDNS收到权威DNS的返回报文是没有结果的)
②LDNS开始向各级各区域权威DNS查xxx.hetianlab.com的ip，同正常的请求过程一样，其最后几个权威服务器中，一定会有几个是hetianlab.com的权威服务器(尽管我们知道查不到结果，但是会使得所有的hetianlab.com的权威DNS都遍历一遍寻找主机，因此有效延长了攻击者窗口时间，如0x01中所述)，在此同时这个窗口时间内，192.168.8.178，即attcker(可以不是attacker这台主机，只要有主机抢先应答伪造的报文即可)向LDNS发出大量伪造报文(猜解id号的报文)，试图告诉LDNS 192.168.8.163(attacker controlled DNS)也是hetianlab.com的权威服务器，你去问他就行了
③假设某一次比如abc.hetianlab.com的时候猜对了，这时LDNS中的关于hetianlab.com的权威服务器的缓存就更新为192.168.8.163(attacker controlled DNS)，假设这时vul主机正在请求www.hetianlab.com，这时LDNS会到attacker controlled DNS上询问www主机的ip，即DNS记录里攻击者配的具有攻击目的的网站(这里是apache配置页)，然后覆盖vul的缓存
④vul按照DNS缓存访问Apache(假的 www.hetianlab.com)，相当于访问到攻击者导向的恶意网页，完成DNS缓冲投毒
3.环境搭建
请大体参考0x04参考资料(1)，注意事项：
1)attcker controlled DNS: ubuntu 20.04(192.168.8.163)
配置bind9过程结合0x04参考资料(4)，配置结果大致如下：
named.conf.local
注意每次更改文件都需要service bind9 restart，如果没有成功的话报错信息可以查看/var/log/messages文件(bind9默认日志信息)，详细的报错日志的设置见0x04参考资料(5)，配置成功后解析结果如下
2)vul(vulnerable host)：win7 professional sp1(192.168.8.181)
注意配置Authentication DNS(IPV4协议设置)的时候不能使用自动配置网络而只是添加一条上级DNS的ip(DNS服务器会自动检测以使用多个DNS之一，手动改的DNS会失效)，可以把手动输入的ip地址栏空着(相当于使用DHCP)，但是首选DNS服务器填attacker controlled DNS，备选服务器空着，如图所示
0x03 实验流程和结果
1.实验流程
在Windows Server 2008上wireshark中开启抓包，然后在WIN 7上随便访问什么最近没访问过的网页(不是本地的，需要WIN7本地记录已过期的，这样就需要向LDNS请求ip，LDNS这就能抓到对应的请求报文)，本文以52262端口为例，如0x02配置环境中所述，这里只能使用WIN server 2008之前的版本，因为在此之前的版本其向权威域名服务器发送请求报文的端口在一段时间内是固定的，因此只要在已知对方请求服务的端口号的情况下向改端口发送大量抢占报文以猜解出1-65535的qid号即可
2008之后的版本，每次发送请求服务的端口号都不一样(端口随机化，0-65535)，这里取WIN server 2019为例，因此猜解变为65535*65535如图：
在kali攻击机上：
（1）在KaliLinux文本模式下执行命令msfconsole，等待一段时间后进入msf>的命令提示符下。
（2）执行命令use auxiliary/spoof/dns/bailiwicked_host
（3）执行命令show options，查看有哪些参数可以设置
（4）执行如下命令
set RHOST 192.168.8.2 （对应被攻击的server2008本地DNS IP地址）
set HOSTNAME ns.hetianlab.com
set NEWADDR 192.168.8.163 （对应攻击者部署好的站点）
set SRCPORT 52262 （对应server2008对外查询时使用的端口号）
set XIDS 50
（5）执行完毕后执行show options再次确认配置
（6）执行run
（7）当屏幕出现Poisoning Successful时代表渗透成功结束。
2.实验结果
使用WIN 7(vul) 访问hetianlab.com，可以看到apache2界面(假的hetianlab.com，实际模拟被攻击网页)，可见攻击成功
从LDNS(SERVER)抓到的包那里也可以看到，一堆No such name(随机化的域名)的返回报文，和最后猜解正确的A记录，返回了假的主机ip(恶意网页ip)192.168.8.163
LDNS收到的报文和发给vul的报文的具体内容如下：
可以看到其猜解正确的qid(Transaction ID)，权威区的SOA记录以及发给vul的恶意主机ip
为了验证被污染域名与域名本身无关的特性，以及说明问题严重性，笔者还做了pianshen.com等域名的实验，并换之查看了LDNS本机对其的访问结果以及LDNS本地缓存记录
3.实验结论
（1）Kaminsky缓存投毒一旦成功影响非常大。
可见污染的域名随意，污染的范围可以很大(LDNS下有很多主机，其管辖的区域内所有向其请求该域名的主机全部缓存投毒)，可见kaminsky的危害
（2）尽量使用随机端口比较好的DNS软件作为本地缓存DNS，如果用windows server那么一定要做系统升级。本实验中的问题微软已经给出升级补丁。
（3）本地缓存DNS负责人一旦发现缓存投毒，可立即执行“缓存清除”操作。然后通过DNS解析日志或者抓包分析发起随机域名请求的源IP是什么，可尝试进行反跟踪，或者在上层网络设备上做好相应防护工作。
0x04 参考资料
(1)Kali Linux（二）案例：DNS Kaminsky缓存投毒
(2)DNS安全（一）DNS缓存投毒与防护
(3)一次出人意料而名留青史的DNS投毒攻击
(4)DNS(bind)服务器的安装与配置
(5)BIND9详解之日志篇