IP欺騙原理與過程分析

IP欺騙攻擊法

原創：r00t <r00t@unsecret.org>

QQ: 22664566

http://www.unsecret.org

---------------------------------------------

作者：r00t

釋出日期：2002-3-15

上傳日期：2002-3-15

來源：http://www.unsecret.org

這是我到《公開化安全》的第一篇文章，很多不足的地方，希望大家來信指點^_*

什麼是IP欺騙？IP欺騙是不是用某種軟體把自己的IP隱藏起來？回答當然是NO！！！。這裡我要說的IP欺騙是一種攻擊方法，即使主機系統本身沒有任何漏洞，但仍然可以使用各種手段來達到攻擊目的，這種欺騙純屬技術性的，一般都是利用TCP/IP協議本身存在的一些缺陷。當然，這也是有一定難度的。下面我們看一下IP欺騙攻擊是如何實現的？

建立信任關係。

IP欺騙是利用了主機之間的正常信任關係來發動的，所以在介紹IP欺騙攻擊之前，先說明一下什麼是信任關係，信任關係是如何建立的。

在UNIX主機中，存在著一種特殊的信任關係。假設有兩臺主機hosta和hostb，上面各有一個帳戶Tomy，在使用中會發現，在hosta上使時要輸入在hosta上的相應帳戶Tomy，在hostb上使用時必須輸入用hostb的帳戶Tomy，主機hosta和hostb把Tomy當做兩個互不相關的使用者，這顯然有些不便。為了減少這種不便，可以在主機hosta和hostb中建立起兩個帳戶的相互信任關係。在hosta和hostb上Tomy的home目錄中建立.rhosts檔案。從主機hosta上，在你的home目錄中用命令echo “hostb Tomy”>~/.hosts實現hosta&hostb的信任關係，這時，你從主機hostb上，你就能毫無阻礙的使用任何以r開頭的遠端呼叫命令，如：rlogin、rsh、rcp等，而無需輸入口令驗證就可以直接登入到hosta上。這些命令將充許以地址為基礎的驗證，允許或者拒絕以IP地址為基礎的存取服務。這裡的信任關係是基於IP的地址的。

當/etc/hosts.equiv中出現一個 “+”或者$HOME/.rhosts中出現 “++”時，表明任意地址的主機可以無須口令驗證而直接使用r命令登陸此主機，這是十分危險的，而這偏偏又是某些管理員不重視的地方。下面我們看一下rlogin的用法。

rlogin是一個簡單的/伺服器程式，它的作用和telnet差不多，不同的是telnet完全依賴口令驗證，而rlogin是基於信任關係的驗證，其次到才進行口令驗證的，它使用了TCP協議進行傳輸。當使用者從一臺主機登陸到另一臺主機上，並且，如果目錄主機信任它，rlogin將允許在不應答口令的性況下使用目標主機上的資源，安全驗證完便基於源主機的IP地址。因此，根據以上所舉的例子，我們能利用rlogin來從hostb遠端登陸到hosta，而且不會被提示出入口令！

IP欺騙的理論根據

看到上面的說明，每一個黑客都會想到：既然hosta和hostb之間的信任關係是基於IP址而建立起來的，那麼假如能夠冒充hostb的IP，就可以使用rlogin登入到hosta，而不需任何口令驗證。這，就是IP欺騙的最根本的理論依據。

但是，事情遠沒有想像中那麼簡單！雖然，可以通過程式設計的方法隨意改變發出的包的IP地址，但TCP協議對IP進行了進一步的封裝，它是一種相對可靠的協議，不會讓黑客輕易得逞。不信？好，先來看一下一次正常的TCP/IP會話的過程。

由於TCP是面向連線的協議，所以在雙方正式傳輸資料之前，需要用“三次握手”來建立一個穩重的連線。假設還是hosta和hostb兩臺主機進行通訊，hostb首先傳送帶有SYN標誌的資料段通知hosta建立TCP連線，TCP的可靠性就是由資料包中的多位控制字來提供的，其中最重要的是資料序列SYN和資料確認標誌ACK。B將TCP報頭中的SYN設為自己本次連線中的初始值（ISN）。

當hosta收到hostb的SYN包之後，會傳送給hostb一個帶有SYN+ACK標誌的資料段，告之自己的ISN，並確認hostb傳送來的第一個資料段，將ACK設定成hostb的SYN+1。

當hostb確認收到hosta的SYN+ACK資料包後，將ACK設定成hosta的SYN+1。Hosta收到hostb的ACK後，連線成功建立，雙方可以正式偉輸資料了，整個過程如圖所示：

（黑色為hostb紅色為hosta）

（大家也就將就將就著看吧……本人的繪畫水平也說是這樣了……能看明白就行了哦J ）

看了這個過程，我們就很容易想到，假如想冒充hostb對hosta進行攻擊，就要先使用hostb的IP地址傳送SYN標誌給hosta，但是當hosta收到後，並不會把SYN+ACK傳送到我們的主機上，而是傳送到真正的hostb上去，這時……嘿嘿……露陷了吧？因為hostb根本沒傳送發SYN請請。所以如果要冒充hostb，首先要讓hostb失去工作能力。也就是所謂的拒絕服務攻擊，讓hostb癱瘓。

可是……這樣還是遠遠不夠的……，最難的就是要對hosta進行攻擊，必須知道hosta使用的ISN。TCP使用的ISN是一個32位的計數器，從0到4 294 967 295。TCP為每一個連線選擇一個初始序列號ISN，為了防止因為延遲、重傳等擾亂三次握手，ISN不能隨便選取，不同的系統有著不同的演算法。理解TCP如何分配ISN以及ISN隨時間的變化規律，對於成功的進行IP欺騙攻擊是很重要的！ISN約每秒增加128 000，如果有連線出現，每次連線將把計數器的數值增加64 000。很顯然，這使得用於表示ISN的32位計數器在沒有連線的情況下每9.32小時復位一次。這所以這樣，是因為它有利於最大於度地減少“舊有”連線的資訊干擾當前連線的機會。如果初始序例號是隨意選擇的，那麼不能保證現有序例號是不同於先前的。假設有這樣一種情況，在一個路由迴路中的資料包最終跳出迴圈，回到了“舊有”的連線，顯然這會對現有連線產生干擾。預測出攻擊目標的序例號非常困難，而且各個系統也不想同，在Berkeley系統，最初的序列號變數由一個常數每秒加1產生，等加到這個常數的一半時，就開始一次連線。這樣，如果開始啊一個合法連線，並觀察到一個ISN正在使用，便可以進行預測，而且這樣做有很高的可信度。現在我們假設黑客已經使用某種方法，能預測出ISN。在這種情況下，他就可以將ACK序便號送給hosta，這時連線就建立了。

“嗯，先喝口水（哇噻，3：30了耶）……說了這麼多，明白了點嗎？”

“不明白……兄弟，你在幹啥呢？上數學課啊？”

!@#$^^%&*&$^%^%@$^% 又眼一翻……口吐白沫……兩腿一蹬……站了起來……叫了聲：“接著看……”

IP欺騙攻擊過程解析

IP欺騙由若干步驟組成，下面是它的詳細步驟，（嘿嘿……小心點看哦……不明白的請舉手……，不再重複……我夠陰的吧……嗯嗯……沒煙了……不說了……大家自學吧……）晃鐺……一隻“義大利真皮”飛過來……正中腦瓜……唉……俺“眾”不敵“寡”，先忍著算了……真可憐……怎麼沒人用“中華”丟過來……

接著…首先假定信任關係已經被發現（至於如何發現，不是本章內容）。黑客為了進行IP欺騙，要進行以下工作：使被信任關係的主機失去工作能力，同時取樣目標主機發出的TCP序例號，猜測出它的資料序例號。然後，偽裝成被信任的主機，同時建立起與目標主機基於地址驗證的應用連線。連線成功後，黑客就可以入置backdoor以便後日使用J 。

使被信任主機失去工作能力

為了偽裝成被信任主機而不露陷，需要使其完全失去工作能力。由於攻擊者將要代替真正的被信任主機，他必須確保真正的被信任主機不能收到任何有效的網路資料，否則將會被揭穿。有許多方法可以達到這個目的（如SYN洪水攻擊、TTN、Land等攻擊）。現假設你已經使用某種方法使得被信任的主機完全失去了工作能力。

序例號取樣和猜測

前面講到了，對目標主機進行攻擊，必須知道目標主機的資料包序例號。通常如何進行預測呢？往往先與被攻擊主機的一個埠（如：25）建立起正常連線。通常，這個過程被重複N次，並將目標主機最後所傳送的ISN儲存起來。然後還需要進行估計他的主機與被信任主機之間的往返時間，這個時間是通過多次統計平均計算出來的。往返連線增加64 000.現在就可以估計出ISN的大小是128 000乘以往返時間的一半，如果此時目標主機剛剛建立過一個連線，那麼再加上64 000。（我靠……怎麼像在上數學課啊？）

一旦估計出ISN的大小，就開始著手進行攻擊，當然你的虛假TCP資料包進入目標主機時，如果剛才估計的序例號是準確的，進入的資料將被放置在目標機的緩衝區中。但是在實際攻擊過程中往往沒這麼幸運，如果估計序例號的小於正確值，那麼將被放棄。而如果估計的序例號大於正確值，並且在緩衝區的大小之內，那麼該資料被認為是一個未來的資料，TCP模組將等待其他缺少的資料。如果估計序例號大於期待的數字且不在緩衝區之內，TCP將會放棄它並返回一個期望獲得的資料序例號。

你偽裝成被信任的主機IP，此時，該主機仍然處在癱瘓狀態，然後向目標主機的513埠（rlogin）傳送連線請求。目標主機立刻對連線請求作出反應，發更新SYN+ACK確認包給被信任主機，因為此時被信任主機仍然處於癱瘓狀態，它當然無法收到這個包，緊接關攻擊者向目標主機傳送ACK資料包，該包使用前面估計的序例號加1。如果攻擊者估計正確的話，目標主機將會接收該ACK。連線就正式建立起了，可以開始資料傳輸了。這是，你就可以將cat ‘++’>>~/.rhosts命令傳送過去，這樣完成本次攻擊後就可以不用口令直接登入到目標主機上了。如果達到這一步，一次完整的IP欺騙就算完成了。你已經在目標機上得到了一個Shell貼，接下就就是利用系統的溢位或錯誤配置擴大許可權，當然如何搞到root已經不是本章的內容了。

總結一下IP攻擊的整個步驟：

首先使被信任主機的網路暫時癱瘓，以免對攻擊造成干擾。

然後連線到目標機的某個埠來猜測ISN基值和增加規律！！！（重點！難點！）

接下來把源址址偽裝成被信任主機，傳送帶有SYN標誌的資料段請求連線。

然後等待目標機傳送SYN+ACK包給已經癱瘓的主機，因為你現在看不到這個包。

最後再次偽裝成被信任主機向目標機傳送的ACK，此時傳送的資料段帶有預測的目標機的ISN+1。

連線建立，傳送命令請求。

擦屁股、開後門、下網、關機、睡覺。~~~zzzZZZzzz~~~

“Game Over”

“~~~zzzZZZzzz~~~”

“哎呀呀……你爺爺的（韋小寶），我在上面口水都說幹了，你們在下面夢周公（英語老師），走！到政教處去……”

“下課！”

“唰……老師再見！”

“嘿……睡醒了啊？每人照抄一百遍……下許檢查！”

俺今天要當足老師的癮……被他們訓了這麼久，多少也學會點了，嘿嘿……夠奸了吧？

看例子：

對於以上的理論，好多人都是將信將疑：一句話就是：這種攻擊方法是不是隻停留在一個理論階段？？？成功好像只是做夢而已吧？

不信？我也不信，但事實總是勝於雄辨！看下面這個被記錄的入侵例項，看你還有什麼；話說！TNND，老師的話都不信？吃米田共去……

下面是tcpdump------一個sniffer完全全記錄下來的一次入侵全過程。也正是IP欺騙的創始人米特尼客的作品，被一個名叫TsutomuShimomura的工作師記錄下來的。

說明：

Server:一臺執行Solaris的Sparc工作站；

x-terminal：被攻擊的伺服器

IP欺騙攻擊開始於1994年12月25日 14：09：32 米特尼客的第一輪探測來自於一臺名叫toad.com的主機，這顯然是他事先攻破的一臺系統，用來做跳板的。

他在toad.com上執行了以下命令：

 

1 2 3 4 5 6 7

toad.com#finger ?Cl @target toad.com#finger ?Cl @server toad.com#finger ?Cl root@server toad.com#finger ?Cl @x-terminal toad.com#shownoumt ?Ce x-terminal toad.com#rpcinfo ?Cp x-terminal toad.com#finger ?Cl root@x-terminal

 

 

這些命令的的作用顯然是在探測攻擊目標之間潛在的信任關係，因為只有在發現了信任關係才能進行IP欺騙。Showmount和rcpinfo的源埠探測又說明了攻擊者已經得到了root權（toad.com）。

大約在六分鐘之後，tcpdump檢測到一陣急風暴雨般的TCP SYN包從130.92.6.7猛烈的湧向Server 的513（rlogin）埠。很顯然，這是在使用SYN洪水拒絕服務攻擊server，目的當然是讓他失去工作能力了。這也就是前面提到的第一步。因為513埠是以root許可權執行的，所以現在server.login可以被用來作為進行IP欺騙的偽造源了。當然，這個的謂的攻擊方IP130.92.6.97 也是一個偽造的IP，這樣它才不會接收到server的回應包。

看記錄：

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

14:18:22:516699 130.92.6.97.600 > server.login: S 1382726960:1382726960(0) win 4096 14:18:22:566069 130.92.6.97.600 > server.login: S 1382726961:1382726961(0) win 4096 14:18:22:744477 130.92.6.97.600 > server.login: S 1382726962:1382726962(0) win 4096 14:18:22:830111 130.92.6.97.600 > server.login: S 1382726963:1382726963(0) win 4096 14:18:22:886128 130.92.6.97.600 > server.login: S 1382726964:1382726964(0) win 4096 14:18:22:943514 130.92.6.97.600 > server.login: S 1382726965:1382726965(0) win 4096 14:18:23:002715 130.92.6.97.600 > server.login: S 1382726966:1382726966(0) win 4096 14:18:23:103275 130.92.6.97.600 > server.login: S 1382726967:1382726967(0) win 4096 14:18:23:162781 130.92.6.97.600 > server.login: S 1382726968:1382726968(0) win 4096 14:18:23:225384 130.92.6.97.600 > server.login: S 1382726969:1382726969(0) win 4096 14:18:23:282625 130.92.6.97.600 > server.login: S 1382726970:1382726960(0) win 4096 14:18:23:342657 130.92.6.97.600 > server.login: S 1382726971:1382726961(0) win 4096 14:18:23:403083 130.92.6.97.600 > server.login: S 1382726972:1382726962(0) win 4096 14:18:23:903700 130.92.6.97.600 > server.login: S 1382726973:1382726963(0) win 4096 14:18:24:003252 130.92.6.97.600 > server.login: S 1382726974:1382726964(0) win 4096 14:18:24:084827 130.92.6.97.600 > server.login: S 1382726975:1382726965(0) win 4096 14:18:24:142774 130.92.6.97.600 > server.login: S 1382726976:1382726966(0) win 4096 14:18:24:203195 130.92.6.97.600 > server.login: S 1382726977:1382726967(0) win 4096 14:18:24:294773 130.92.6.97.600 > server.login: S 1382726978:1382726968(0) win 4096 14:18:24:382841 130.92.6.97.600 > server.login: S 1382726979:1382726969(0) win 4096 14:18:24:443309 130.92.6.97.600 > server.login: S 1382726980:1382726960(0) win 4096 14:18:24:643249 130.92.6.97.600 > server.login: S 1382726981:1382726961(0) win 4096 14:18:24:906546 130.92.6.97.600 > server.login: S 1382726982:1382726962(0) win 4096 14:18:24:963786 130.92.6.97.600 > server.login: S 1382726983:1382726963(0) win 4096 14:18:25:022853 130.92.6.97.600 > server.login: S 1382726984:1382726964(0) win 4096 14:18:25:153536 130.92.6.97.600 > server.login: S 1382726985:1382726965(0) win 4096 14:18:25:400869 130.92.6.97.600 > server.login: S 1382726986:1382726966(0) win 4096 14:18:25:483127 130.92.6.97.600 > server.login: S 1382726987:1382726967(0) win 4096 14:18:25:599582 130.92.6.97.600 > server.login: S 1382726988:1382726968(0) win 4096 14:18:25:653131 130.92.6.97.600 > server.login: S 1382726989:1382726969(0) win 4096

 

 

server 在連線序例被塞滿之前對前八個SYN請求做出了SYN+ACK回應，一旦沒有ACK包來回應它，server將週期性地重發SYN+ACK包。

接下來我們看到20個從apollo.it.luc.edu發出的連線請求被送住x-terminal.shell。這些連線請求的目的是預測server的TCP序例號生成器的行為。可以注意到每一個連線的初始序例號的增量提示了SYN包不是通過系統的TCP執行產生的。攻擊者立刻用RST包來斷 開x-terminal發來的SYN+ACK包，以使x-terminal的連線序例不至於被塞滿，因為畢竟x-terminal是黑客所要攻擊的目標。

下面是這個過程：

 

1 2 3 4

14:18:25.906002 apollo.it.luc.edu.1000 > x-terminal.shell:S 1382726990:1382726990(0) win 4906 14:18:26.094731 x-terminal.shell > appollo.it.luc.edu.1000:S 2021824000:20218240000(0) ack 1382826991 win 4906 ………………………………………………………………………………………………………

 

現在已經是5:33了，好累……大家體諒一下……。

x-terminal 發出的每一個SYN+ACK包的初始序例號都比前一個增加了128 000位元組。

Server.lgoin的偽造SYN請求發往了x-terminal.shell。推斷x-terminal可信任server，所所以會響應來自server 或者偽裝成server的主機的所有請求。

然後就是，x-terminal用SYN+ACK包回應了server的連線請求，這時因為server仍然處於癱瘓狀態，所以它當然不會響應任何來自於x-terminal的包。

正常情況下SYN+ACK包是用來期待正確的ACK確認包的。但是攻擊者能夠預測出x-terminal的TCP序例號生成器的包含SYN+ACK的序例號，所以他不用看到SYN+ACK就可以發出回應的ACK包，如下：

 

1 2	14:18:36.245045 server.login > x-terminal.shell: S 1382727010(0) win 4906 14:18:36.755522 server.login >x-terminal.shell .ack 2024384001 win 4096

 

到目前為止，偽裝成server的主機已經通過 IP欺騙與x-terminal.shell建立了一次正常的rsh連線，這時一旦x-terminal做出任何應答，攻擊者就可以維持連線並且發送出資料，下面他傳送瞭如下資料：

 

1 2 3

14:18:37.265404 server.login > x-terminal.shell: P 0:2(2)ack 1 win 4906 14:18:37.775872 server.login > x-terminal.shell: P 2:7(5)ack 1 win 4906 14:18:37.287404 server.login > x-terminal.shell: P 7:32(25)ack 1 win 4906

 

這些資料是由tcpdump記錄下來的，對應的命令其實就是：

 

1	server#rsh x-terminal “echo ++ >>/.rhosts”

 

即在x-terminal上建立起使得任何主機都可以無須口令而行訪問的/.rhosts檔案。然後，其實連線斷開了。

怎麼樣？看得心驚膽跳吧？看上去好像花了好長的時間，其實不然……從傳送第一個資料包，到傳送最後一個資料包僅僅用了16秒！！！這一過程，只不過是執行了事先寫好的程式而已。

注：文章多處用了比較搞笑的字眼為的是讓讀者看起來不那麼緊張、放鬆點能更容易理解。

如果讀者發現哪有不足之處請多多來信點評。

摘自：http://www.20cn.net/ns/hk/hacker/data/20020804015903.htm