DNS欺騙技術原理與安全防範技術

來源:互聯網
上載者:User

 

DNS欺騙技術原理與安全防範技術

 

概述:什麼是DNS欺騙?
DNS欺騙是一門改變DNS原始指向IP的藝術。為了更好的理解,讓我們先來看一個例子。如果你想用瀏覽器去google搜尋一些資訊,毫無疑問的你會在地址欄裡輸入www.google.com的網址然後斷行符號。
那麼在這背後又有什麼事情進行中著呢?一般而言,你的瀏覽器將會向DNS伺服器發送一個請求,從而要求得到與www.google.com相匹配的IP地址,DNS伺服器則會告訴你的瀏覽器google的IP地址,接著你的瀏覽器會串連並顯示首頁內容。哦,等一下,你開啟的網頁說google因無錢支付網站費用而轉讓給CSite的訊息。你可能會非常吃驚,並打電話告訴你的好朋友。當然你的朋友一定會笑你瘋掉了,因為你的朋友是可以登陸google並進行搜尋的。還確信正在和你通訊的IP地址是友好的嗎?說不定你已成圈中之羊。當你在瀏覽器地址裡輸入http:// 66.249.89.99並斷行符號時,你又會發現,其實www.google.com還健在。
其實剛剛就是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伺服器的記錄,比如,記錄可以是www.google.com=81.81.81.81

1)攻擊者向你的DNS伺服器發送請求查詢www.attacker.net
2)你的DNS伺服器不知道這台主機的IP地址,因為他不屬於本身域,所有你的DNS伺服器就會問此主機的所屬域的DNS伺服器。
3)這時被黑DNS伺服器就會回複你的DNS伺服器,在此同時它也會給出它所有的記錄(包括串連www.google.com的記錄)
注意,這個過程叫做zone transfer.

4)這是你的DNS伺服器還沒有被麻痹。攻擊者得到了自己的IP地址,但是他的目標不是得到自己網路伺服器的地址,而是逼迫zone transfer進行以使你的DNS伺服器麻痹直到其緩衝不會被清楚或更新。

5)現在如果你再問你的DNS伺服器關於www.google.com的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緩衝(具體的工具和說明可以在http://www.arp-sk.org上找到)
2、此時,目標主機的出口資料包將會重新導向到你的主機上,但是還必須轉寄給真正的網關。我們可以用類似Winroute Pro的工具來實現。
3、為了實施DNS ID欺騙我們用valgasu開發的工具WinDNSSpoof
(在使用這個工具前請先安裝Winpcap,見http://winpcap.polito.it)
命令列下輸入類似的命令:
wds -n www.google.com-i 123.123.123.123 -g 00-C0-26-DD-59-CF –v
這個命令會使目標主機的www.google.com指向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的。

#define POSSIBILITIES 365.0
void main (void)
{
float chances;
int i, j;
for (i = 1; i
沒法編譯的朋友可以看下面的結果:
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號的偽造回複,這樣裡面至少有且僅有一個包是可用的。
如果這樣的攻擊的話,我們需要相當好的頻寬,而且最重要的是我們不知道何時發送偽造的回複。他就必須Crowdsourced Security Testing道對方有個請求,然後緊接著及時地(在真的來自DNS伺服器的回複之前)發送回複。
讓我們來從另一個角度看問題,我們知道是有可能性去直接麻痹DNS伺服器的。回憶一下,攻擊者是想DNS伺服器詢問解析www.attacker.net,多虧有從ns.attacker.net來的惡意記錄zone transfer,攻擊者才可以麻痹DNS伺服器的快取器。值得重提的是,這種攻擊的局限在於攻擊者必須在運行自己帶有惡意記錄的DNS伺服器。
這樣的分析之下,如果攻擊者沒有辦法嗅探你的網路資料或者沒有自己的伺服器,是不是就是說你就遠離DNS劫持技術了?
答案是,完全不是這樣。
我之前提到過,DNS協議是用UDP回複,UDP是非串連狀態的協議,是沒有像TCP三向交握的過程的。所以,這也就使得可以非常容易地用你選的任意IP發送UDP包。所以為什麼攻擊者在可以從任意DNS伺服器發送偽造包的情況下要辛辛苦苦地架設起自己地DNS伺服器呢?他可以直接詢問受害者的DNS伺服器解析www.google.com,然後立即發送含偽造IP的包給www.google.com的網域名稱伺服器。
好,這樣時間剛好,這樣是可行的,所以問題就只有受害者的DNS伺服器將要向ns.google.com發送一次請求來得到www.google.com的IP,同時有一個請求的ID號。所以又一次的,攻擊者就必鬚髮送65535個含ns.google.com的偽造包來做為受害者網域名稱伺服器的源地址。至少有一個包是吻合的。所以看來這個可能會成功。
下面就是最有趣的部分了……如果攻擊者向受害者的DNS伺服器發送了100份請求來解析www.google.com會發生什麼呢?那麼ns.victim.com也將會向ns.google.com發送100份請求,那然後如果我們發送100個從ns.google.com到ns.victim.com的偽造回複會怎樣呢?如果你已經理解了剛剛提到的生日悖論原理,你就應該懂得相比之下衝撞(猜對)的機率已經有了可觀的提高。

除此之外,還有個必須注意的小細節——源連接埠!
試想,ns.victim.com將要向ns.google.com發送請求,UDP頭就應該像這樣:
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 http://www.520hack.com?
很明顯,攻擊者必須ns.victim.com的源連接埠作為目標連接埠發送偽造的DNS回複,包的內容就像:

Source address : ns.google.com
Destination address : ns.victim.com
Source port : 53
Destination port : 1256
Data : The IP of http://www.520hack.com is 81.81.81.81
所以如果我們沒有嗅探又要怎樣猜測源連接埠呢?“不幸”的是,對大多數DNS伺服器來說,源連接埠是不會為每個用戶端而改變的,因此攻擊者可以很簡單地通過看 ns.victim.com的目前源連接埠來得到。比方說,如果他有一個網域名稱伺服器,他只要請求DNS尋找他的域的一個站名,得到的返回查詢包就會包含現在在的被ns.victim.com用來發送DNS請求的源連接埠。
好,現在我知道如何得到源連接埠了,你可能會對攻擊的成功率好奇。這也是我正要講的。我們的C代碼也有所改動:

#define POSSIBILITIES 65535.0
void main (void)
{
float chances;
int i, j;
for (i = 0; i
結果如下:
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%!
欲知更多詳細資料,我建議閱讀以下文章:
http://www.kb.cert.org/vuls/id/457875
http://www.securityfocus.com/guest/17905

D)總結
在這篇文章裡,我用www.google.com做例子,並不是因為我真的對其的重新導向攻擊感興趣。這個問題在你訪問你的銀行賬戶,線上購書網站甚至是網頁電子郵件時尤為重要。
而對於網站管理者來說,可行的防範措施有:
對快取器加以限制,保證不保留額外的記錄。
不要用或依賴DNS構架安全體系。
使用SSL之類的加密技術,所以即使被攻擊,難度也會加大

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.