iT邦幫忙

第 12 屆 iT 邦幫忙鐵人賽

DAY 17
15
Security

從 0 開始的 Web Security系列 第 17

Day 17 網路層攻擊實例 - IP Spoofing

昨天我們講到了 OSI L3 網路層的攻擊向量
而我們今天就要來實作其中一種
也就是在網際網路上最常見到的一種攻擊

IP Spoofing

IP Spoofing 的概念十分簡單,只要將不屬於自己的 IP
寫入 L3 IP 的封包來源,並將 L2 的目標,指向一台未驗證來源的路由器
因路由器是以 L3 目標搭配路由表查詢來做封包的轉送
這時候封包就會被轉送出去

我們實驗環境的網路拓樸大致如下圖所示
https://ithelp.ithome.com.tw/upload/images/20201002/20129897XEu6auyjSi.png

當攻擊者發送一個封包給 Upstream 的 Router 時
Router 接收到如果未驗證,就會被轉送到更上游的 Transit Provider 1
一路轉送最終到達目的地

那攻擊者要怎麼把封包發給 Upstream 的 Router 呢?
其實只要將 L2 的目的地位置改寫成 Upstream 的位置即可
這樣當封包成功被送到 Upstream 的 Router 後
Router 看到 L3 目的地 IP 並非自己本身所擁有的時候,就會根據路由表轉送封包出去

TCP 封包

我們可以用以下 python 的 scapy 腳本來發送 Spoofing IP 包

from scapy.all import *

macs = 'ce:9f:63:d4:de:e8' # Source MAC Address
macd = '8c:dc:d4:ab:57:7c' # Router MAC Address
ips = "207.154.233.176" # Spoofed source IP address
ipd = "207.154.209.154" # Destination IP address
sport = 12345
dport = 31337
payload = "AAAAAAAAAA" # packet payload

#while True:
spoofed_packet = Ether(src=macs, dst=macd) / IP(src=ips, dst=ipd) / UDP(sport=sport, dport=dport) / payload
sendp(spoofed_packet, iface="en10")

或者是這裡更為簡單,我們直接使用 RouterOS 內建的發送封包功能
將 Spoofing 包傳送出去
我們可以分別設定 L2、L3、L4、L4+ 的封包內容
以下設定等價於上面的內容
https://ithelp.ithome.com.tw/upload/images/20201002/20129897tXXjmAGEps.png
L2 (MAC)
https://ithelp.ithome.com.tw/upload/images/20201002/20129897P0ZlIWxAyp.png
L3 (IP)
https://ithelp.ithome.com.tw/upload/images/20201002/2012989761jVhXNChY.png
L4 (UDP)
https://ithelp.ithome.com.tw/upload/images/20201002/20129897Rv7KRPgCZA.png

接著我們直接使用 RouterOS 的發送功能發送以上封包出去
https://ithelp.ithome.com.tw/upload/images/20201002/20129897HGnKfVxTdg.png

我們在受害者 Server 上即可接收到來自 207.154.233.176:12345 的 UDP 封包
https://ithelp.ithome.com.tw/upload/images/20201002/201298979nRs1daLwE.png

而這時候,因為 Server 上的 UDP 31337 Port 並沒有提供服務
所以 Server 會回給 Source 跟他說沒有這個服務
但因為 Source 是我們偽造的,所以這個封包將會回到最終的受害者身上
(207.154.209.154 -> 207.154.233.176)
https://ithelp.ithome.com.tw/upload/images/20201002/20129897sz9MzFdMmI.png
這時候我們就完成了一次反射式的攻擊
https://ithelp.ithome.com.tw/upload/images/20201002/20129897zpgLH75NXn.png

這是 UDP 的狀況,TCP 會回應 ACK、RST 跟客戶端說這個 Port 沒有提供服務
兩者情況大同小異

UDP 放大攻擊

假設今天 Server 上確實有執行服務,假設服務是回應你傳入封包十次
這時候正常的情況應該長這樣
https://ithelp.ithome.com.tw/upload/images/20201002/20129897aqOIKO5i81.png
這樣回傳的封包就是傳入封包的十倍大小,而我們就可以利用這點來進行攻擊

https://ithelp.ithome.com.tw/upload/images/20201002/201298972oOrVMqK9W.png
這樣我們就利用 Server 成功傳送了 10 的流量傳送給受害者個
這也是 DDoS 放大攻擊常常使用的手法

防禦方法

其實防禦 IP Spoofing 的原理並不難,但在現實情況中執行卻十分困難
我們先來講講理想的情況好了,只要上圖拓樸中
Upstream、Transit Provider 1、Transit Provider 2、Digital Ocean
其中有足夠連接度的任一台路由器有開啟 uRPF (unicast Reverse Path Forwarding) 即可解決
那 uRPF 又是如何防禦這種攻擊的呢?
uRPF 會根據設備的路由表,來判斷這個來源的封包有沒有可能從這個介面進來
以上面那張拓樸圖為例,Upstream Router 想要將 185.1.166.172 的封包轉送到 Attack 那,所以路由表中會有

Interface CIDR
接往攻擊者的介面 185.1.166.172/32
接往 Transit Provider 1 的介面 0.0.0.0/0

我們可以根據這兩條路由來生成反向的規則
我們知道 IP 目的地為 185.1.166.172/32 的封包需要傳往攻擊者的介面
所以生成反向規則後也就是
「攻擊者的介面只能有 185.1.166.172/32 為 IP 來源的封包」

而接往 Transit Provider 1 的介面則可以接受來源為 0.0.0.0/0 的封包
由此可見,如果在靠近攻擊者近端下規則擋下會比在目的地擋下實際,因為基本上目的地的 ISP/Cloud Provider 不會同時接入太多的 AS,所以路由表中大多數也是來自 Transit Provider 的路由

小結

今天我們看到了 IP Spoofing 的攻擊與實作
筆者也對 Digital Ocean 內部網路沒有對外部進來的內部 Source 做過濾感到訝異
可以從外部送入內部的 IP


上一篇
Day 16 攻擊向量 (3) - 網路層 (OSI L3) & 傳輸層 (OSI L4)
下一篇
Day 18 OSI L1 ~ L3 綜合威脅
系列文
從 0 開始的 Web Security22

1 則留言

3
XZK
iT邦新手 5 級 ‧ 2020-10-07 14:16:30

uRPF (unicast Reverse Path Forwarding) 這段有點看不懂,講一下自己的理解,有錯再麻煩指正。

Router 收到封包後會檢查來源 (Source IP) 是否存在 Routing table 中 (不包含來源介面), if true 就有 IP Spoofing 攻擊的嫌疑,丟棄該封包。

seadog007 iT邦新手 5 級 ‧ 2020-10-07 14:25:19 檢舉

uRPF 其實有可能因為各家路由器導致邏輯不太相同
你說的是一種配對方法沒錯

但更常見的應該是如下圖

直接找路由表中該來源 IP 應該要被往哪裡丟
藉此找到反向合法介面(uRPF中的RP,Reverse Path)

我要留言

立即登入留言