[翻譯]DNS（域名服務器）欺騙技術
本帖被 fr.qaker 設置爲精華(2007-04-13)
文章作者：Spacefox, Secure Sphere Crew
譯文作者：Conan, OS3 (Open Source Software Society) / CICC Singapore(Center of International Cooperation for Computerization in Singapore)
信息來源：邪惡八進制信息安全團隊（[url]www.eviloctal.com[/url]）
概述：什麼是DNS欺騙？
DNS欺騙是一門改變DNS原始指向IP的藝術。爲了更好的理解，讓我們先來看一個例子。如果你想用瀏覽器去google搜索一些信息，毫無疑問的你會在地址欄裏輸入 [url]www.google.com[/url]的網址然後回車。
那麼在這背後又有什麼事情正在進行着呢？一般而言，你的瀏覽器將會向DNS服務器發送一個請求，從而要求得到與[url]www.google.com[/url]相匹配的IP地址，DNS服務器則會告訴你的瀏覽器google的IP地址，接着你的瀏覽器會連接並顯示主頁內容。哦，等一下，你打開的網頁說google因無錢支付網站費用而轉讓給CSite的消息。你可能會非常吃驚，並打電話告訴你的好朋友。當然你的朋友一定會笑你瘋掉了，因爲你的朋友是可以登陸google並進行搜索的。還確信正在和你通信的IP地址是友好的嗎？說不定你已成圈中之羊。當你在瀏覽器地址裏輸入http:// 66.249.89.99並回車時，你又會發現，其實[url]www.google.com[/url]還健在。
其實剛剛就是DNS劫持***時目擊者可能看到的情形。
譯文作者：Conan, OS3 (Open Source Software Society) / CICC Singapore(Center of International Cooperation for Computerization in Singapore)
信息來源：邪惡八進制信息安全團隊（[url]www.eviloctal.com[/url]）
概述：什麼是DNS欺騙？
DNS欺騙是一門改變DNS原始指向IP的藝術。爲了更好的理解，讓我們先來看一個例子。如果你想用瀏覽器去google搜索一些信息，毫無疑問的你會在地址欄裏輸入 [url]www.google.com[/url]的網址然後回車。
那麼在這背後又有什麼事情正在進行着呢？一般而言，你的瀏覽器將會向DNS服務器發送一個請求，從而要求得到與[url]www.google.com[/url]相匹配的IP地址，DNS服務器則會告訴你的瀏覽器google的IP地址，接着你的瀏覽器會連接並顯示主頁內容。哦，等一下，你打開的網頁說google因無錢支付網站費用而轉讓給CSite的消息。你可能會非常吃驚，並打電話告訴你的好朋友。當然你的朋友一定會笑你瘋掉了，因爲你的朋友是可以登陸google並進行搜索的。還確信正在和你通信的IP地址是友好的嗎？說不定你已成圈中之羊。當你在瀏覽器地址裏輸入http:// 66.249.89.99並回車時，你又會發現，其實[url]www.google.com[/url]還健在。
其實剛剛就是DNS劫持***時目擊者可能看到的情形。
Quote:
試想如果跳轉的頁面被無聲無息地掛着馬又會多糟糕
非常急切地相要知道着其中地玄機吧？是不是DNS服務器給了我們一個錯誤地IP地址？可能是吧。至少，這是我們腦中最符合邏輯地答案。
事實上，有兩種方法可以實現DNS劫持***。讓我們來看看第一種，“DNS ID欺騙”技術。
A)DNS 高速緩衝存儲器麻痹（DNS Cache Poisoning）
可以想象，DNS服務器不可能將所有現存的域名或IP地址存儲在本身的存儲空間裏。這就是爲什麼DNS服務器有一個高速緩衝存儲器（cache），它使得服務器可以存儲DNS記錄一一段時間。
事實上，一臺DNS服務器只會記錄本身所屬域中的授權的主機，如果它想要知道其它的，在自身域以外主機的信息，就必須向信息持有者（另一臺DNS服務器）發送請求，同時，爲了不每次都發送請求，這臺DNS服務器會將另一臺DNS服務器返回的信息又記錄下來。
那麼現在，我們就來看看是怎麼麻痹DNS的緩存的。
***者有自己的域（attacker.net）和一個已被攻陷的DNS服務器（ns.attacker.net）。注意！我說的是被攻陷的DNS服務器，因爲***者已經自定義了他自己的DNS服務器的記錄，比如，記錄可以是[url]www.google.com=81.81.81.81[/url]
1)***者向你的DNS服務器發送請求查詢[url]www.attacker.net[/url]
2)你的DNS服務器不知道這臺主機的IP地址，因爲他不屬於本身域，所有你的DNS服務器就會問此主機的所屬域的DNS服務器。
3)這時被黑DNS服務器就會回覆你的DNS服務器，在此同時它也會給出它所有的記錄（包括連接[url]www.google.com[/url]的記錄）
注意，這個過程叫做zone transfer.
4)這是你的DNS服務器還沒有被麻痹。***者得到了自己的IP地址，但是他的目標不是得到自己網絡服務器的地址，而是逼迫zone transfer進行以使你的DNS服務器麻痹直到其緩存不會被清楚或更新。
5)現在如果你再問你的DNS服務器關於[url]www.google.com[/url]的IP地址，它會告訴你172.50.50.50，這也正是***者的服務器所在！現在，***者就能爲所欲爲，例如掛馬什麼的……當然這也對google造成了相當的損失！
B)DNS ID欺騙（DNS ID Spoofing）
我們可以看到，當主機X要與主機Y聯繫是需要近來的IP地址。然而在絕大多數情況下，X只有Y的名字，這樣，DNS協議就是來解決名字到IP地址的問題的。
因此，X就會向它所在域的DNS服務器詢問Y的IP地址。其間，主機X分配一個隨即數，這個數也將會出現在從DNS服務器返回的信息裏。當X收到回覆後，X會對比兩個數字，如果一致，則收到信息被視爲有效。
那這樣一個模型是否安全呢？並非十分安全。任何人都可以組織一次***來獲得這個ID。舉例說如果你用LAN，別人就可以利用嗅探器捕獲你的請求ID，然後根據這個ID僞造一個回覆信息……但是信息裏含有***者所選的IP地址。然後，不加識別的，X會吧***者提供的IP地址當作Y的。
順便提一句，DNS協議的提出請求是依賴於UDP的（只有在zone transfer時才用TCP），這也就意味着發送一個僞造的包是極其簡單的，因爲沒有SYN/ACK號（不像TCP，UDP沒有提供一個小型防IP欺騙的防護）
但是，這樣的***是被侷限的。在我以上的例子中，***者用嗅探器攔獲ID，回覆構造過的包給受害主機。
換句話說，即使***者攔截了請求，數據包還是會傳去DNS服務器，而DNS服務器也照樣會回覆（除非***者攔截並阻止對網關的請求或實施ARP緩存麻痹纔可能在轉換網絡中***）。
這就意味着***者必須在真DNS服務器前回復，即爲了***成功，***者必須和被***者同一個LAN，只有這樣他纔可以獲得快速的ping並且捕獲對方的數據包。
實踐舉例（僅作測試目的）
看怎麼劫持我們本地網絡連接：
1、麻痹被***者的ARP緩存（具體的工具和說明可以在[url]http://www.arp-sk.org[/url]上找到）
2、此時，目標主機的出口數據包將會重定向到你的主機上，但是還必須轉發給真正的網關。我們可以用類似Winroute Pro的工具來實現。
3、爲了實施DNS ID欺騙我們用valgasu開發的工具WinDNSSpoof（在使用這個工具前請先安裝Winpcap，見[url]http://winpcap.polito.it[/url]）
命令行下輸入類似的命令：
wds -n [url]www.google.com[/url] -i 123.123.123.123 -g 00-C0-26-DD-59-CF –v
這個命令會使目標主機的[url]www.google.com[/url]指向123.123.123.123。
其中00-C0-26-DD-59-CF是網關或DNS服務器的MAC地址。
Tips: 在Windows NT內核下，查詢遠程IP的MAC地址可以在CMD裏用nbtstat -A xxx.xxx.xxx.xxx命令
警告：記住！在未授權的情況下使用這些手段是被禁止的！
C)藉助生日悖論的精確***
什麼是“生日悖論”？
“生日悖論”得名於一個能產生奇怪現象的數學模型，即如果有23人在一起，那麼很有可能其中的兩人有相同的生日。其實要理解也不是那麼困難。
假設現在你在一個派對問某人他的生日，那麼他跟你不同生日的機率就是364/365=0.997，則相同的概率就是1-364/365=0.003。
現在，如果你再問另外一個人，他的生日不同於前一人且不同於你的概率就是(364/365)*(363/365)=0.992，所以我們至少可以推得我們中兩人有相同生日的概率爲1-0.992=0.008。
如果我們繼續這樣的推算，很快就能算得23人中有兩人的生日相同的概率高達50％。我們可以通過以下的C代碼看出概率是如何趨近於1的。
C)藉助生日悖論的精確***
什麼是“生日悖論”？
“生日悖論”得名於一個能產生奇怪現象的數學模型，即如果有23人在一起，那麼很有可能其中的兩人有相同的生日。其實要理解也不是那麼困難。
假設現在你在一個派對問某人他的生日，那麼他跟你不同生日的機率就是364/365=0.997，則相同的概率就是1-364/365=0.003。
現在，如果你再問另外一個人，他的生日不同於前一人且不同於你的概率就是(364/365)*(363/365)=0.992，所以我們至少可以推得我們中兩人有相同生日的概率爲1-0.992=0.008。
如果我們繼續這樣的推算，很快就能算得23人中有兩人的生日相同的概率高達50％。我們可以通過以下的C代碼看出概率是如何趨近於1的。
Copy code
#define POSSIBILITIES 365.0
void main (void)
{
float chances;
int i, j;
for (i = 1; i < 100; i++)
{
for (j = 1, chances = 1; j < i; j++)
chances *= (float)((POSSIBILITIES - j) / POSSIBILITIES);
printf("For %d people, chances are %f\n", i, 1-chances);
}
}
沒法編譯的朋友可以看下面的結果：
| People |
2 |
9 |
16 |
23 |
30 |
37 |
44 |
65 |
79 |
| Chances |
0.0027 |
0.0946 |
0.2836 |
0.5073 |
0.7063 |
0.8487 |
0.9329 |
0.9977 |
0.9999 |
沒法編譯的朋友可以看下面的結果：
生日悖論普遍的應用於檢測哈希函數:N-位長度的哈希表可能發生碰撞測試次數不是2N次而是隻有2N/2次。這一結論被應用到破解密碼學散列函數的生日***中
生日問題所隱含的理論已經在[Schnabel 1938]名字叫做capture-recapture的統計試驗得到應用，來估計湖裏魚的數量。
好，下面我們還是回到我的***測試上來，在上述的最爲普遍的DNS欺騙***中，是在竊聽（嗅探）網絡以便得到來自X的ID號碼，然後回覆以相同的ID只是含有***者提供的IP。
就像我之前說的，這種***需要嗅探網絡中的X生成的DNS數據。那這是不是意味着***者不能不用嗅探器實施***呢？
試着“猜猜”ID怎麼樣？
爲什麼不呢，但是ID號是用兩字節構成的，這意味着有65535個可能的值！也就是說***者如果想要成功***的話，他要構造出65535個不同ID號的僞造回覆，這樣裏面至少有且僅有一個包是可用的。
如果這樣的***的話，我們需要相當好的帶寬，而且最重要的是我們不知道何時發送僞造的回覆。他就必須先知道對方有個請求，然後緊接着及時地（在真的來自DNS服務器的回覆之前）發送回覆。
讓我們來從另一個角度看問題，我們知道是有可能性去直接麻痹DNS服務器的。回憶一下，***者是想DNS服務器詢問解析[url]www.attacker.net[/url]，多虧有從ns.attacker.net來的惡意記錄zone transfer，***者纔可以麻痹DNS服務器的高速緩存器。值得重提的是，這種***的侷限在於***者必須在運行自己帶有惡意記錄的DNS服務器。
這樣的分析之下，如果***者沒有辦法嗅探你的網絡數據或者沒有自己的服務器，是不是就是說你就遠離DNS劫持技術了？
答案是，完全不是這樣。
我之前提到過，DNS協議是用UDP回覆，UDP是非連接狀態的協議，是沒有像TCP三次握手的過程的。所以，這也就使得可以非常容易地用你選的任意IP發送UDP包。所以爲什麼***者在可以從任意DNS服務器發送僞造包的情況下要辛辛苦苦地架設起自己地DNS服務器呢？他可以直接詢問受害者的DNS服務器解析[url]www.google.com[/url]，然後立即發送含僞造IP的包給[url]www.google.com[/url]的域名服務器。
好，這樣時間剛好，這樣是可行的，所以問題就只有受害者的DNS服務器將要向ns.google.com發送一次請求來得到[url]www.google.com[/url]的IP，同時有一個請求的ID號。所以又一次的，***者就必須發送65535個含ns.google.com的僞造包來做爲受害者域名服務器的源地址。至少有一個包是吻合的。所以看來這個可能會成功。
下面就是最有趣的部分了……如果***者向受害者的DNS服務器發送了100份請求來解析[url]www.google.com[/url]會發生什麼呢？那麼ns.victim.com也將會向ns.google.com發送100份請求，那然後如果我們發送100個從ns.google.com到ns.victim.com的僞造回覆會怎樣呢？如果你已經理解了剛剛提到的生日悖論原理，你就應該懂得相比之下衝撞（猜對）的概率已經有了可觀的提高。
除此之外，還有個必須注意的小細節——源端口！
試想，ns.victim.com將要向ns.google.com發送請求，UDP頭就應該像這樣：
Copy code
Source address : ns.victim.com
Destination address : ns.google.com
Source port : 1256 (choosed randomly and > 1024)
Destination port : 53 (DNS port)
Data : What is the IP of [url]www.google.com?[/url]
很明顯，***者必須ns.victim.com的源端口作爲目標端口發送僞造的DNS回覆，包的內容就像：
Copy code
Source address : ns.google.com
Destination address : ns.victim.com
Source port : 53
Destination port : 1256
Data : The IP of [url]www.google.com[/url] is 81.81.81.81
所以如果我們沒有嗅探又要怎樣猜測源端口呢？“不幸”的是，對大多數DNS服務器來說，源端口是不會爲每個客戶端而改變的，因此***者可以很簡單地通過看ns.victim.com的目前源端口來得到。比方說，如果他有一個域名服務器，他只要請求DNS查找他的域的一個站名，得到的返回查詢包就會包含現在在的被ns.victim.com用來發送DNS請求的源端口。
好，現在我知道如何得到源端口了，你可能會對***的成功率好奇。這也是我正要講的。我們的C代碼也有所改動：
Copy code
#define POSSIBILITIES 65535.0
void main (void)
{
float chances;
int i, j;
for (i = 0; i < 800; i+=50)
{
for (j = 1, chances = 1; j < i; j++)
chances *= (float)((POSSIBILITIES - j) / POSSIBILITIES);
printf("For %d fake replies, chances are %f\n", i, 1-chances);
}
}
結果如下：
| Queries |
50 |
100 |
150 |
200 |
250 |
300 |
350 |
400 |
500 |
550 |
650 |
750 |
| Chances |
0.0185 |
0.0728 |
0.1569 |
0.2621 |
0.3785 |
0.4961 |
0.6069 |
0.7048 |
0.8517 |
0.9008 |
0.9604 |
0.9865 |
我們可以看到，650個構造回覆有0.960411的概率成功，近乎100％！
欲知更多詳細信息，我建議閱讀以下文章：
[url]http://www.kb.cert.org/vuls/id/457875[/url]
[url]http://www.securityfocus.com/guest/17905[/url]
D)總結
在這篇文章裏，我用[url]www.google.com[/url]做例子，並不是因爲我真的對其的重定向***感興趣。這個問題在你訪問你的銀行賬戶，在線購書網站甚至是網頁電子郵件時尤爲重要。
而對於網站管理者來說，可行的防範措施有：
- 對高速緩存器加以限制，保證不保留額外的記錄。
- 不要用或依賴DNS構架安全體系。
- 使用SSL之類的加密技術，所以即使被***，難度也會加大（見Man in the Middle中的文章）
| [email][email protected][/email] Spacefox, SecureSphereCrew, |
[email][email protected][/email] Conan, CBlog, |
2007 April
[ 此貼被flux在2007-04-14 02:40重新編輯 ]