Sniffer

Sniffer（嗅探器）程序是一種利用以太網的特性把網絡適配卡（NIC， 一般為以太網卡）置為雜亂（promiscuous）模式狀態的工具， 一旦網卡設置為這種模式， 它就能接收傳輸在網絡上的每一個信息包。 Sniffer分為軟件和硬件兩種， 一般指的是軟件， 但功能有限， 硬件價格比較貴。

Sniffer可以用來監聽任何網絡信息， 在此 我只關心http/https數據的監聽。

下面我以登錄126為例， 運行了在網上隨便找的一個嗅探工具， 我這里為了更清楚的說明問題沒有選"SSL安全登錄"選項。 這里我們也該體會到的一點是防止嗅探攻擊的最好方式就是加密數據。

在圖片的末尾我們可以看到下面的內容：

[email protected]&user=xuanhun521&password=xuanhun&style=-1&remUser=&enter.x=%B5%C7+%C2%BC

用戶名和密碼都可以被嗅探到。

13.2 會話劫持

下面改編了一下網上的相關資料， 介紹一下會話劫持。

　1、會話劫持原理

我們可以把會話劫持攻擊分為兩種類型：1）中間人攻擊(Man In The Middle， 簡稱MITM)， 2）注射式攻擊（Injection）；并且還可以把會話劫持攻擊分為兩種形式：1）被動劫持， 2）主動劫持；被動劫持實際上就是在后臺監視雙方會話的數據流， 叢中獲得敏感數據；而主動劫持則是將會話當中的某一臺主機"踢"下線， 然后由攻擊者取代并接管會話。

（1）中間人攻擊

要想正確的實施中間人攻擊， 攻擊者首先需要使用ARP欺騙或DNS欺騙， 將會話雙方的通訊流暗中改變， 而這種改變對于會話雙方來說是完全透明的。 不管是ARP欺騙， 還是DNS欺騙， 中間人攻擊都改變正常的通訊流， 它就相當于會話雙方之間的一個透明代理， 可以得到一切想知道的信息， 甚至是利用一些有缺陷的加密協議來實現。

（2）注射式攻擊簡介

　　這種方式的會話劫持比中間人攻擊實現起來簡單一些， 它不會改變會話雙方的通訊流， 而是在雙方正常的通訊流插入惡意數據。 在注射式攻擊中， 需要實現兩種技術：1）IP欺騙， 2）預測TCP序列號。 如果是UDP協議， 只需偽造IP地址， 然后發送過去就可以了， 因為UDP沒有所謂的TCP三次握手， 但基于UDP的應用協議有流控機制， 所以也要做一些額外的工作。

對于IP欺騙， 有兩種情況需要用到：1）隱藏自己的IP地址；2）利用兩臺機器之間的信任關系實施入侵。 對于基于TCP協議的注射式會話劫持， 攻擊者應先采用嗅探技術對目標進行監聽， 然后從監聽到的信息中構造出正確的序列號， 如果不這樣， 你就必須先猜測目標的ISN（初始序列號）， 這樣無形中對會話劫持加大了難度。

　　2、TCP會話劫持

如果劫持一些不可靠的協議， 那將輕而易舉， 因為它們沒有提供一些認證措施；而TCP協議被欲為是可靠的傳輸協議， 所以要重點討論它。

　　根據TCP/IP中的規定， 使用TCP協議進行通訊需要提供兩段序列號， TCP協議使用這兩段序列號確保連接同步以及安全通訊， 系統的TCP/IP協議棧依據時間或線性的產生這些值。 在通訊過程中， 雙方的序列號是相互依賴的， 這也就是為什么稱TCP協議是可靠的傳輸協議（具體可參見RFC 793）。 如果攻擊者在這個時候進行會話劫持， 結果肯定是失敗， 因為會話雙方"不認識"攻擊者， 攻擊者不能提供合法的序列號；所以， 會話劫持的關鍵是預測正確的序列號， 攻擊者可以采取嗅探技術獲得這些信息。

　　TCP協議的序列號

　　現在來討論一下有關TCP協議的序列號的相關問題。 在每一個數據包中， 都有兩段序列號， 它們分別為：

SEQ：當前數據包中的第一個字節的序號

ACK：期望收到對方數據包中第一個字節的序號

　　假設雙方現在需要進行一次連接：

S_SEQ：將要發送的下一個字節的序號

S_ACK：將要接收的下一個字節的序號

S_WIND：接收窗口

//以上為服務器（Server）

C_SEQ：將要發送的下一個字節的序號

C_ACK：將要接收的下一個字節的序號

C_WIND：接收窗口

//以上為客戶端（Client）

它們之間必須符合下面的邏輯關系， 否則該數據包會被丟棄， 并且返回一個ACK包（包含期望的序列號）。

C_ACK <= C_SEQ <= C_ACK + C_WIND

S_ACK <= S_SEQ <= S_ACK + S_WIND

　　如果不符合上邊的邏輯關系， 就會引申出一個"致命弱點"。

　　這個致命的弱點就是ACK風暴(Storm)。 當會話雙方接收到一個不期望的數據包后， 就會用自己期望的序列號返回ACK包；而在另一端， 這個數據包也不是所期望的， 就會再次以自己期望的序列號返回ACK包……于是， 就這樣來回往返， 形成了惡性循環， 最終導致ACK風暴。 比較好的解決辦法是先進行ARP欺騙， 使雙方的數據包"正常"的發送到攻擊者這里， 然后設置包轉發， 最后就可以進行會話劫持了， 而且不必擔心會有ACK風暴出現。 當然， 并不是所有系統都會出現ACK風暴。 比如Linux系統的TCP/IP協議棧就與RFC中的描述略有不同。 注意， ACK風暴僅存在于注射式會話劫持。

　　TCP會話劫持過程

　　假設現在主機A和主機B進行一次TCP會話， C為攻擊者， 劫持過程如下：

A向B發送一個數據包

SEQ (hex): X ACK (hex): Y

FLAGS: -AP--- Window: ZZZZ， 包大小為:60

B回應A一個數據包

SEQ (hex): Y ACK (hex): X+60

FLAGS: -AP--- Window: ZZZZ， 包大小為:50

A向B回應一個數據包

SEQ (hex): X+60 ACK (hex): Y+50

FLAGS: -AP--- Window: ZZZZ， 包大小為:40

B向A回應一個數據包

SEQ (hex): Y+50 ACK (hex): X+100

FLAGS: -AP--- Window: ZZZZ， 包大小為:30

攻擊者C冒充主機A給主機B發送一個數據包

SEQ (hex): X+100 ACK (hex): Y+80

FLAGS: -AP--- Window: ZZZZ， 包大小為:20

B向A回應一個數據包

SEQ (hex): Y+80 ACK (hex): X+120

FLAGS: -AP--- Window: ZZZZ， 包大小為:10

　　現在， 主機B執行了攻擊者C冒充主機A發送過來的命令， 并且返回給主機A一個數據包；但是， 主機A并不能識別主機B發送過來的數據包， 所以主機A會以期望的序列號返回給主機B一個數據包， 隨即形成ACK風暴。 如果成功的解決了ACK風暴（例如前邊提到的ARP欺騙或者其他方式）， 就可以成功進行會話劫持了。

3.http會話劫持

Web應用程序是通過2種方式來判斷和跟蹤不同用戶的：Cookie或者Session（也叫做會話型Cookie）。 其中Cookie是存儲在本地計算機上的， 過期時間很長， 所以針對Cookie的攻擊手段一般是盜取用戶Cookie然后偽造Cookie冒充該用戶；而Session由于其存在于服務端， 隨著會話的注銷而失效（很快過期）， 往往難于利用。 所以一般來說Session認證較之Cookie認證安全。

會話型cookie也是可以通過程序獲得的， 換句話說我們進行TCP會話劫持的時候如果針對http會話劫持的話可以截獲所有http內容包括Session信息。

下面我們一個具體的例子。 這個例子中我使用的是一個非ARP欺騙方式的工具SSClone。 本機ip是192.168.1.107， 我在ip地址為192.168.1.105的機器上打開126郵箱。

之后在ip是192.168.1.107的計算機上我們截獲了這個會話， 而且可以直接進入郵箱， 不用登錄。

哎呀， 好累， 還剩點內容， 留到明天吧， 歡迎各位讀者踴躍批評。