從TCP協議的原理論rst復位攻擊

安全劍客發表於2020-11-22
在談RST攻擊前,必須先了解TCP:如何透過三次握手建立TCP連線、四次握手怎樣把全雙工的連線關閉掉、滑動視窗是怎麼傳輸資料的、TCP的flag標誌位裡RST在哪些情況下出現。下面我會畫一些儘量簡化的圖來表達清楚上述幾點,之後再瞭解下RST攻擊是怎麼回事。
TCP是什麼?

TCP是在IP網路層之上的傳輸層協議,用於提供port到port面向連線的可靠的位元組流傳輸。我來用土語解釋下上面的幾個關鍵字:

port到port:IP層只管資料包從一個IP到另一個IP的傳輸,IP層之上的TCP層加上埠後,就是面向程式了,每個port都可以對應到使用者程式。

可靠:TCP會負責維護實際上子虛烏有的連線概念,包括收包後的確認包、丟包後的重發等來保證可靠性。由於頻寬和不同機器處理能力的不同,TCP要能控制流量。

位元組流:TCP會把應用程式傳來的位元組流資料切割成許多個資料包,在網路上傳送。IP包是會失去順序或者產生重複的,TCP協議要能還原到位元組流本來面目。

從TCP協議的原理論rst復位攻擊從TCP協議的原理論rst復位攻擊

從上面的TCP協議圖可以看到,標誌位共有六個,其中RST位就在TCP異常時出現,也是我這篇文章重點關注的地方。

透過三次握手建立連線

下面我透過A向B建立TCP連線來說明三次握手怎麼完成的。

從TCP協議的原理論rst復位攻擊從TCP協議的原理論rst復位攻擊

為了能夠說清楚下面的RST攻擊,需要結合上圖說說:SYN標誌位、序號、滑動視窗大小。

建立連線的請求中,標誌位SYN都要置為1,在這種請求中會告知MSS段大小,就是本機希望接收TCP包的最大大小。

傳送的資料TCP包都有一個序號。它是這麼得來的:最初傳送SYN時,有一個初始序號,根據RFC的定義,各個作業系統的實現都是與系統時間相關的。之後,序號的值會不斷的增加,比如原來的序號是100,如果這個TCP包的資料有10個位元組,那麼下次的TCP包序號會變成110。

滑動視窗用於加速傳輸,比如發了一個seq=100的包,理應收到這個包的確認ack=101後再繼續發下一個包,但有了滑動視窗,只要新包的seq與沒有得到確認的最小seq之差小於滑動視窗大小,就可以繼續發。

滑動視窗

滑動視窗毫無疑問是用來加速資料傳輸的。TCP要保證“可靠”,就需要對一個資料包進行ack確認表示接收端收到。有了滑動視窗,接收端就可以等收到許多包後只發一個ack包,確認之前已經收到過的多個資料包。有了滑動視窗,傳送端在傳送完一個資料包後不用等待它的ack,在滑動視窗大小內可以繼續傳送其他資料包。舉個例子來看吧。

從TCP協議的原理論rst復位攻擊從TCP協議的原理論rst復位攻擊

大家看上圖,標誌位為.表示所有的flag都為0。標誌位P表示flag為PSH的TCP包,用於快速傳輸資料。

前三個包是三次握手,客戶端表示自己的滑動視窗大小是65535(我的XP機器),伺服器端表示滑動視窗是5840(螢幕寬了,沒截出來)。從第四個包開始,客戶端向伺服器傳送PSH包,資料長度是520位元組,伺服器發了ack確認包。注意此時win視窗大小發生了改變哈。以此類推。

倒數第二、三包,伺服器在滑動視窗內連續向客戶端發包,客戶端傳送的ack 124同時確認了之前的兩個包。這就是滑動視窗的功能了。

如果談到TCP攻擊就需要注意,TCP的各種實現中,在滑動視窗之外的seq會被扔掉!下面會講這個問題。

四次握手的正常TCP連線關閉

先畫張簡單的正常關閉連線狀態變遷圖。

從TCP協議的原理論rst復位攻擊從TCP協議的原理論rst復位攻擊

FIN標誌位也看到了,它用來表示正常關閉連線。圖的左邊是主動關閉連線方,右邊是被動關閉連線方,用netstat 可以看到標出的連線狀態。

FIN是正常關閉,它會根據緩衝區的順序來發的,就是說緩衝區FIN之前的包都發出去後再發FIN包,這與RST不同。

RST標誌位

RST表示復位,用來異常的關閉連線,在TCP的設計中它是不可或缺的。就像上面說的一樣,傳送RST包關閉連線時,不必等緩衝區的包都發出去(不像上面的FIN包),直接就丟棄快取區的包傳送RST包。而接收端收到RST包後,也不必傳送ACK包來確認。

TCP處理程式會在自己認為的異常時刻傳送RST包。例如,A向B發起連線,但B之上並未監聽相應的埠,這時B作業系統上的TCP處理程式會發RST包。

又比如,AB正常建立連線了,正在通訊時,A向B傳送了FIN包要求關連線,B傳送ACK後,網斷了,A透過若干原因放棄了這個連線(例如程式重啟)。網通了後,B又開始發資料包,A收到後表示壓力很大,不知道這野連線哪來的,就發了個RST包強制把連線關了,B收到後會出現connect reset by peer錯誤。

RST攻擊

A和伺服器B之間建立了TCP連線,此時C偽造了一個TCP包發給B,使B異常的斷開了與A之間的TCP連線,就是RST攻擊了。實際上從上面RST標誌位的功能已經可以看出這種攻擊如何達到效果了。

那麼偽造什麼樣的TCP包可以達成目的呢?我們至頂向下的看。

假定C偽裝成A發過去的包,這個包如果是RST包的話,毫無疑問,B將會丟棄與A的緩衝區上所有資料,強制關掉連線。

如果發過去的包是SYN包,那麼,B會表示A已經發瘋了(與OS的實現有關),正常連線時又來建新連線,B主動向A發個RST包,並在自己這端強制關掉連線。

這兩種方式都能夠達到復位攻擊的效果。似乎挺恐怖,然而關鍵是,如何能偽造成A發給B的包呢?這裡有兩個關鍵因素,源埠和序列號。

一個TCP連線都是四元組,由源IP、源埠、目標IP、目標埠唯一確定一個連線。所以,如果C要偽造A發給B的包,要在上面提到的IP頭和TCP頭,把源IP、源埠、目標IP、目標埠都填對。這裡B作為伺服器,IP和埠是公開的,A是我們要下手的目標,IP當然知道,但A的源埠就不清楚了,因為這可能是A隨機生成的。當然,如果能夠對常見的OS如windows和 找出生成source port規律的話,還是可以搞定的。

序列號問題是與滑動視窗對應的,偽造的TCP包裡需要填序列號,如果序列號的值不在A之前向B傳送時B的滑動視窗內,B是會主動丟棄的。所以我們要找到能落到當時的AB間滑動視窗的序列號。這個可以暴力解決,因為一個sequence長度是32位,取值範圍0-4294967296,如果視窗大小像上圖中我抓到的windows下的65535的話,只需要相除,就知道最多隻需要發65537(4294967296/65535=65537)個包就能有一個序列號落到滑動視窗內。RST包是很小的,IP頭+TCP頭也才40位元組,算算我們的頻寬就知道這實在只需要幾秒鐘就能搞定。

那麼,序列號不是問題,源埠會麻煩點,如果各個作業系統不能完全隨機的生成源埠,或者駭客們能透過其他方式獲取到source port,RST攻擊易如反掌,後果很嚴重。

原文地址:

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31559985/viewspace-2735915/,如需轉載,請註明出處,否則將追究法律責任。

相關文章