170919 網路 ARP欺騙原理及實現

1625-5 王子昂總結《2023年9月19日》【連續第352天總結】

a. arp欺騙原理及實驗

b. 0x00 楔子

為了招新的技術展示~

由於arp欺騙是很早以前的東西，記得大多數防火牆都帶arp防火牆功能了

所以本來想在控制路由器的前提下進行dns欺騙的

不過查了一下，雖然dns位址可以自己設定，但是本地搭dns伺服器才行，相對比較複雜，另外還需要自己開啟http服務，所以終歸還是玩了arp欺騙

0x01 簡介

0x02 示例

linux下存在arpspoof和ettercap兩個工具都可以完成arp欺騙

如果需要對方正常上網，則需要開啟流量**功能：

echo 1 >> /proc/sys/net/ipv4/ip_forward

ps：雖然據說在開啟ettercap以後，該工具會自動接管**，將核心的**功能關閉，所以不需要手動echo 1。但是實踐中似乎不敲該命令確實會使得資料報未**

arpspoof -t 192.168.1.106 192.168.1.1

或ettercap -tq -i wlan0 -m arp:remote /192.168.1.111/ /192.168.1.1/

就可以arp欺騙成功

在被攻擊機上輸入arp -a可以看到閘道器的mac位址已經與攻擊機的mac相同了

資料報**以後我們只需要解析就可以看到一些有趣的東西了：

例如driftnet 可以看到未經加密的

urlsnaraf可以看到連線的url

wireshark經過過濾可以看到所有資料報

未經加密的http連線將暴露所有資訊，包括cookies，明文傳遞的user和password

0x03 防禦

不過經過這麼多年的交鋒，伺服器方也不是等閒之輩

https加密就是為了防禦中間人攻擊的

https將領取伺服器的公鑰，將資料和自己的金鑰傳送給伺服器；

該資料報只有伺服器的私鑰才可以解密，因此中間人無法解密

之後伺服器用私鑰解密，再用客戶端的金鑰加密返回資料報

該資料報只有客戶端的金鑰才可以解密，因此中間人也無法解密

這樣有來有往，伺服器和客戶端的通訊就受到了加密保護

0x04 再攻擊

然而，雖然有了安全的https，黑客們仍然想到了突破的方法

1. 公鑰是基於證書的，中間人可以自行領取受信任的證書（這個過程實際並不簡單）來偽造伺服器，使得客戶端-中間人-伺服器兩條通訊鏈路都仍然使用https協議，但中間人仍然可以**資料報，使得客戶端和伺服器的通訊不受阻

2. https雖然是安全的，但網路中仍然存在許多http頁面；甚至很多大**是使用http頁面通過302重定向跳轉至https頁面的，在這個過程中中間人就可以劫持http頁面的入口來進行釣魚（偽造**）

不過https的證書級別不夠時，瀏覽器會自動在位址列左側提示，因此在重要**時常關注加密級別會是乙個良好的習慣

而http的劫持會使得瀏覽器提示「該連線不受加密」，注意這點可以避免受攻擊。（雖然好像也有一些大**會觸發這個提示使得人們不太重視它就是了……

c. 明日計畫

國賽wp