MOTS攻擊技術分析

新聞 06-08

*本文原創作者：feiniao，本文屬FreeBuf原創獎勵計劃，未經許可禁止轉載

背景

我們經常遇到這樣一個場景:在用戶現場通過埠鏡像方式對流量做鏡像，用來分析數據包或者審計的時候，疑心較大的用戶總是懷疑其數據會被篡改或客戶端信任的結果並非真實伺服器返回的值。我想大多數的技術兄弟可能都會和我一樣回復用戶:這是一台審計設備，是旁路部署，只能審計，不是串在裡面的，不可能對數據進行篡改；也不可能影響客戶端的最終請求響應的結果。這個理論我一直深信不疑，直到前段時間在分析DNS污染的時候才發現這句話並不完全對，難道旁路監聽的設備可以用來進行攻擊，並影響客戶端請求最終的響應結果。的確可以！下面我們來介紹MOTS的攻擊原理及常見的攻擊類型。

原理

MOTS的攻擊原理為：該攻擊可行的前提是攻擊者可以監聽到通信的流量，並且利用時間差優勢在正常的響應包返回之前插入精心構造的數據包，同時利用協議本身的弱點達到欺騙客戶端的目的。

舉個例子：

1、客戶端發起一個請求，由於攻擊者可以監聽客戶端，因此這個請求也會到達攻擊者，同時伺服器也會收到這個請求

2、攻擊者和伺服器都收到客戶端的請求，於是他們都進行了應答

3、攻擊者的響應報文先到達客戶端，因此客戶端接收攻擊者的應答

4、由於時間關係，伺服器的響應報文此時也送到客戶端，但是客戶端已經收到了響應報文，因此不處理伺服器的響應報文。

這裡面的關鍵有以下：

1、攻擊者能夠讀取流量信息並插入偽造的報文，但是不會修改或刪除通信方發送的報文。

2、當受害者發出請求時，攻擊者利用時間優勢讓自己發送的響應先於合法的響應到達受害者

3、TCP UDP協議本身不校驗消息的真實性，只接受先響應的。

常見攻擊類型

3.1 基於TCP的攻擊

我們學習過TCP/IP原理的兄弟們都應該了解：TCP是一種可靠的協議，其可靠性主要依賴TCP確認號。也就是說基於TCP的應用其可靠性一般嚴重依賴TCP做保證，以打開freebuf首頁為例：

67號報文(SYN)的序列號為2859590583，148號報文(ACK+SYN)的確認號為上一個報文的seq+應用層長度+1，這裡面上一個報文的序列號為2859590583，應用層長度為0，所以其確認號為2859590584。確認號是攻擊基於TCP應用的關鍵.

3.1.1 DOS

對基於TCP的應用做DOS攻擊可以在兩個層面做DOS，一般情況下只需要發送單向的Reset包即可。

1、三次握手時

2、對客戶端某些特定請求

? 對三次握手時做DOS

若客戶端請求某個埠或某個特定服務時，通過MOTS做DOS攻擊，攻擊者只需要監聽到客戶端的SYN包的序列號，然後發送一個Reset+ACK包即可達到DOS的效果。其對SYN包進行DOS的例子如下所示：

當客戶端收到攻擊者發送Reset+ACK報文以後，客戶端會主動釋放連接，此後當正常的伺服器的SYN+ACK報文過來以後，由於客戶端已經釋放了連接，因此客戶端一般情況下會忽略這個SYN+ACK報文，不做任何處理。

構造這種攻擊報文需要注意以下細節：

1、客戶端的IP、源埠、序列號

2、伺服器的IP、目標埠

3、IP和TCP校驗和計算，具體計算方法大家google一下，在這裡不做詳細描述。在這裡說一下：IP校驗和僅校驗IP頭部；TCP校驗和是必選的，其是對TCP頭部和數據的校驗；UDP的校驗和是可選的。

4、攻擊報文的源IP為伺服器的IP、源埠為伺服器的埠；目標IP為客戶端的IP、目標埠為客戶端的埠；ACK=客戶端SYN請求報文序列號+1，並且計算好相應的IP和TCP的校驗和，避免客戶端校驗時發現錯誤，而將該報文丟棄。

? 對客戶端某些特定請求進行DOS

這個場景是這樣的:攻擊者一直監聽客戶端的請求，並且前期做好相應的策略，一旦客戶端請求某些內容時，攻擊者主動發送Reset+ack報文釋放連接。這裡一般情況下可以對客戶端的請求進行異常釋放，也可以對伺服器進行釋放；考慮的比較深入的話可以雙向發送reset報文來雙向釋放。技術細節可參考上文。

3.1.2

TCP劫持

基於MOTS的劫持只要TCP的上層為明文傳輸就存在被攻擊的可能。基於MOTS的TCP劫持一般情況下都是劫持基於TCP的上層應用，如HTTP劫持。

大家可能對HTTP劫持了解的比較多，因為大家或多或少都遇到過打開網頁的時候運營商在正常頁面插入廣告或者尾巴的情況，這裡面運營商用的比較多的技術是HTTP劫持，當然除了HTTP劫持外還有其他的技術，如DNS污染等。忽略中間的設備，HTTP劫持如下所示：

在這裡說明一下HTTP劫持的相關原理和實現細節：

1、攻擊者一直需要監聽客戶端的請求

2、當有請求相關頁面時，攻擊者利用時間差優勢進行應答，如客戶端訪問www.freebuf.com時，攻擊者立即進行應答，此應答報文為攻擊者精心構造的報文，其效果可以用來進行推送廣告，也可以進行掛馬。

3、由於攻擊者的應答報文比伺服器的應答報文早到，因此客戶端接收一攻擊者的報文，丟棄了伺服器的應答報文。

技術細節：

1、攻擊者需要獲取客戶端的IP、源埠、序列號和伺服器的IP、目標埠

2、攻擊報文的源IP為伺服器的IP、源埠為伺服器的埠；目標IP為客戶端的IP、目標埠為客戶端的埠；ACK=客戶端SYN請求報文序列號+應用層長度+1，並且計算好相應的IP和TCP的校驗和，避免客戶端校驗時發現錯誤，而將該報文丟棄。

3、攻擊者的報文一定要比伺服器正常的響應報文早到。

針對HTTP劫持freebuf上有案例，大家自行參考，這裡我就不多說了。<點擊文末的閱讀原文查看>

3.1.3 如何發現和解決

其實了解了MOTS的攻擊原理以後，找到這種攻擊還是有很多種方法的，下面我來總結一下常見的發現MOTS攻擊的思路：

? 由於MOTS僅作監聽，不會篡改正常的應答報文，其只是插入新的應答報文。因此如果客戶端同一個請求，收到兩個應答報文，並且非重傳報文，基本上判定存在MOTS攻擊。對於基於MOTS的DOS攻擊和HTTP劫持可以通過這種方法分析。

? 通過IP的TTL和ID來判斷

一般情況下，每經過一個路由設備其TTL都會減一，若為HTTP劫持，其僅對HTTP劫持，並不會對次握手做劫持，因此我們可以通過判定三次握手的TTL和HTTP會話的TTL作比較，若為同一值說明不存在HTTP劫持，若不同則說明存在HTTP劫持。另外，僅僅通過三次握手的TTL和應用的TTL做對比，分析其變化來判斷TCP劫持有時候並不科學。因為很多代理設備也會更改TTL，做應用層代理的設備，有些只更改應用層的TTL，TCP 三次握手時其TTL並不更改，因此比較科學判斷劫持的方法是：

1、判斷三次握手的TTL和應用層的TTL，

2、多取樣分析應用層伺服器應答的TTL變動，如伺服器應用層的應答TTL變化則基本判定存在劫持（這裡面說的是基本，並不完全，這個因為不同數據包的返迴路徑可能不一致，因此導致TTL會變化）

附上一段使用tshark通過分析TTL的變動來檢測基於HTTP劫持的方法

tshark-i eth0 -n -Y "(tcp.flags.syn==1 and tcp.flags.ack==1) or(http.response)" -T fields -e"ip.src" -e "tcp.srcport" -e "ip.dst" -e"tcp.dstport" -e "ip.ttl"

IP ID默認也是遞增的，也可以根據IP ID的變化來分析是否存在劫持。不過使用IP ID這種方法在很多情況下會帶來大量誤判，因為很多安全設備、代理設備會改變及隨機生成IP ID。

使用Tshark過濾其中一個會話，分析IPID的變化情況，相應的Tshark腳本如下：

tshark -i 2 -Y "tcp.stream == 0" -T fields -e"ip.src" -e "tcp.srcport" -e "ip.dst" -e "tcp.dstport"-e "ip.id"

解決基於TCP的MOTS劫持的方法，個人總結了一下，大概有以下幾種方法：

1、會話加密，使用Https、VPN等方式，由於中間的數據是進行的，因此只要相應的加密演算法、證書等安全，理論上說是沒有辦法進行會話劫持的。

2、對TCP/IP協議進行改進，收到伺服器的響應包時，默認停留一段時間，如果再收到伺服器的響應，則分析這兩個響應包的TTL和ID變化，通過TTL和ID的變化來判斷哪個是伺服器正常的響應包。不過這種方法影響用戶體驗，做的不好的話可能是七傷拳，殺敵一千，自損八百。相對較合理的延遲處理時間及精確的分析TTL和ID可能會有較明顯的效果。

3、分片傳輸，中間攻擊者監聽到只是分片報文，為其還原真實查詢報文增加難度。伺服器收到後可以重組，然後得到正常的查詢報文。

3.2

基於UDP的攻擊

和TCP不同，UDP沒有面向連接的機制，其是一種不可靠的協議，沒有確認機制。也就是說只要其埠開放，有數據需要交互時直接進行數據交互，也不需要TCP的三次握手。這樣的話，基於UDP的攻擊比基於TCP的攻擊需要分析的條件相對少了一些。

3.2.1

DOS

由於UDP沒有三次握手，因此對基於UDP的DOS只能對其數據交互時進行DOS攻擊。如果客戶端在訪問某項UDP服務，攻擊者想達到DOS的目的，只需要偽造伺服器發送一個ICMP Port unreachable即可。ICMP port unreachable的報文格式大家自行google一下，這裡不做詳細描述。

技術細節：

1、攻擊者需要獲取客戶端的IP、源埠和伺服器的IP、目標埠

2、攻擊報文的源IP為伺服器的IP、源埠為伺服器的埠；目標IP為客戶端的IP、目標埠為客戶端的埠；ICMP port unreachable，並且計算好相應的IP校驗和，UDP的校驗和是可選的，因此可以關閉UDP校驗。

3、攻擊者的ICMP portunreachable報文一定要比伺服器正常的響應報文早到。

3.2.2

DNS污染

這個在運營商和GFW層面做的比較多，有的同學可能會把DNS劫持和DNS污染混為一談，其實DNS劫持和DNS污染是兩種完全不同的概念。DNS劫持是DNS伺服器的映射關係被改為錯誤的，如www.freebuf.com 正常映射的IP為120.55.226.207，DNS劫持就是攻擊者入侵相應的DNS服務方，把DNS的映射改為如1.2.3.4這種錯誤的關係；DNS污染是指DNS查詢www.freebuf.com時，DNS伺服器返回的是正常的120.55.226.207，同時攻擊者偽造DNS伺服器的響應包，其DNS響應包里的IP為如1.2.3.4這種關係。客戶端正常也可以接收到伺服器正常的DNS響應包，但是由於攻擊者偽造的DNS響應報文比正常的DNS響應報文早到，因此客戶端接收了攻擊者的DNS響應報文。

以攻擊freebuf為例，展示DNS污染的攻擊方法

1、客戶端發送一個DNS查詢，查詢www.freebu.com對應的IP地址

2、由於攻擊者對通信進行監聽，其可以收到相應的DNS查詢報文，同時伺服器也可以收到

3、攻擊者偽造伺服器發送一個DNS響應報文，其對應的A記錄為1.2.3.4

4、DNS伺服器查詢，返回的A記錄為120.55.226.207

5、由於攻擊者的報文比伺服器的報文早到，因此客戶端默認接收了攻擊者偽造的報文，丟棄了正常伺服器的響應報文。

技術細節：

1、前面說到UDP是一種不可靠的協議，DNS的傳輸層使用UDP，但是並不是說DNS不可靠，其實DNS的發明者考慮到這個問題，為了保證DNS的可靠性，設計了Transaction ID，這個ID查詢的時候是隨機生成的，響應報文的ID必須和查詢報文的ID一致，客戶端才認為這是伺服器的響應，如果不一致，客戶端默認丟棄這個DNS響應報文。因為進行DNS污染時一定要保證響應報文的Transaction ID和DNS查詢的Transaction ID一致。