轉 微風
http://bbs.wefong.com/viewthread.php?tid=1713548&pid=23035628&page=1&extra=page%3D1#pid23035628
首先，萊因哈特必須先作兩點聲明，本文內容涉及ARP通訊協定運作原理，倘若您看不懂本文，請先自我充實。其次，本文內容無涉如何反制netcut，有心者請止步。謝謝！
一‧前言
本測試的目的在於觀察netcut v2的運作模式，藉此了解是否在個人電腦上單靠個人防火牆，或是利用arp –s指令鎖住重要的ARP table特定項目內容，即可獲得免疫的效果。
二‧測試環境
攻擊端：Microsoft Windows 2003 SP2主機，在個人防火牆部分，僅啟動系統內建防火牆功能。
被攻擊端1：Microsoft Windows 2000 SP4主機，無個人防火牆保護。本機功用在於觀察netcut的行為模式。
被攻擊端2：Microsoft Windows XP SP2工作站，個人防火牆採用COMODO Firewall Pro v3.0.14.276。本機功用在於測試個人防火牆能否阻擋netcut攻擊，並作為測試netcut自我防護功能時的攻擊端。
攻擊軟件：netcut v2.08
監聽側錄軟體：Sniffer Portable v4.90.104(MR4)
本測試之基本架構如下圖所示，只是在單純的區域網路上，利用一台Windows 2003主機及一台Windows XP SP2工作站充當攻擊端及被攻擊端，基於測試及側錄netcut封包的目的，萊因哈特在攻擊端及被攻擊端都安裝上netcut及Sniffer Portable程式。
725)this.width=725;" onmousewheel="return imgzoom(this)" border="0">《圖一》本測試之架構示意圖
三‧測試重點
本測試的觀察重點如下：
1. 觀察netcut的網路行為模式
2. 觀察COMODO對於netcut攻擊的防禦效果
3. 觀察arp –s指令對於netcut攻擊的防禦效果
4. 觀察netcut本身對於同類攻擊的防護效果
四‧測試結果
1. 關於netcut的網路行為模式
首先說明測試的網路環境，攻擊端的IP位址是192.168.1.240，被攻擊端的IP位址為192.168.1.200，至於閘道器的IP位址在192.168.1.254 / 10.1.1.254(因為本身區網分成192.168.1.0及10.1.1.0兩個網段，但閘道皆設在同一台路由器上，因此會有兩個閘道器位址)。
攻擊方法是在攻擊端的netcut主畫面中，先選擇192.168.1.200為攻擊對象，然後點選上方的切斷按鈕進行攻擊。
725)this.width=725;" onmousewheel="return imgzoom(this)" border="0" width="725">《圖二》在netcut主畫面選擇對象再點選切斷按鈕即可發動攻擊
同時間，萊因哈特利用Sniffer Portable的capture功能在攻擊端擷取所有進出封包進行分析，以下即是所探知的netcut攻擊行為模式：
a. 假造一組實體位址(MAC Address / Physical Address)，然後以此位址作為被攻擊端(192.168.1.200)的實體位址，發送一個偽裝的非典型ARP request封包給第一個閘道器(192.168.1.254)。此行為的目的在於欺騙閘道器，使閘道器誤以為真，將本機ARP table上正確的對映位址換成錯誤的對映位址，如此當有封包要傳送給被攻擊端時，都會被送往錯誤的實體位址去，導致被攻擊端不能再收到任何從閘道器送來的封包，直到切斷狀態解除，且ARP table上的對應資料恢復正常為止。
725)this.width=725;" onmousewheel="return imgzoom(this)" border="0" width="725">《圖三》偽裝成被攻擊端(192.168.1.200)向第一個閘道器(192.168.1.254)發送的非典型ARP request封包內容，請注意被Sender’s hardware address是假造的位址
請注意，典型ARP request封包的目的應該是廣播(Broadcast)位址，也就是FF:FF:FF:FF:FF:FF，並非單一主機的實體位址。下圖是正常ARP request的封包截圖，請自行對照與上圖的封包目的位址有何不同。
725)this.width=725;" onmousewheel="return imgzoom(this)" border="0" width="725">《圖四》這是典型ARP request封包的內容，請特別注意目的位址(Dest Address / Destination)欄顯示的是廣播位址，不是單一實體位址
b. 利用該假造位址作為第一個閘道器(192.168.1.254)的實體位址，同樣發送一個偽裝的非典型ARP request封包給被攻擊端(192.168.1.200)。此行為的目的在於欺騙被攻擊端，使被攻擊端信以為真，將本機ARP table上正確的對映位址換成錯誤的對映位址，如此當有封包要傳送給閘道器時，都會被送往錯誤的實體位址去，導致閘道器不能再收到任何從被攻擊端送來的封包，直到切斷狀態解除，且ARP table上的對應資料恢復正常為止。
725)this.width=725;" onmousewheel="return imgzoom(this)" border="0" width="725">《圖五》偽裝成第一個閘道器(192.168.1.254)向被攻擊端(192.168.1.200)發送的非典型ARP request封包內容，請注意Sender’s hardware address是假造的位址
由於在本測試環境中有兩個網段，netcut會依樣畫葫蘆用相同的假位址為被攻擊端(192.168.1.200)的實體位址，發送一個偽裝的非典型ARP request封包欺騙第二個閘道器(10.1.1.254)，使被攻擊端不能再收到從第二個閘道器傳來的封包，直到切斷狀態解除，且ARP table上的對應資料恢復正常為止。注意，若是僅有單一網段，則不會出現第三及第四個偽造的ARP request封包。
725)this.width=725;" onmousewheel="return imgzoom(this)" border="0" width="725">《圖六》偽裝成被攻擊端(192.168.1.200)向第二個閘道器(10.1.1.254)發送的非典型ARP request封包內容，請注意Sender’s hardware address是假造的位址
再一次利用相同手法，偽裝成第二個閘道器(10.1.1.254)，發送一個非典型ARP request封包給被攻擊端(192.168.1.200)，使第二個閘道器不能再收到從被攻擊端傳來的封包，直到切斷狀態解除，且ARP table上的對應資料恢復正常為止。
725)this.width=725;" onmousewheel="return imgzoom(this)" border="0" width="725">《圖七》偽裝成第二個閘道器(10.1.1.254)向被攻擊端(192.168.1.200)發送的非典型ARP request封包內容，請注意Sender’s hardware address是假造的位址
當被欺騙端收到傳來的ARP request封包後，會按照ARP通訊協定的運作原理，將自身的實體位址填入封包，並回傳給發送ARP request封包的主機，這種封包稱為ARP reply。由於上述的ARP request並非由表頭記載的發送端所發送，而且發送端實體位址也是假造的，因此這些ARP reply封包並不會真的傳送到另一方手裡，而是回到netcut攻擊主機手上。以下四個封包都是被欺騙端回傳的ARP reply封包，請恕萊因哈特不再贅言。
這是被攻擊端(192.168.1.200)回傳給第一個閘道器(192.168.1.254)的ARP reply封包。
725)this.width=725;" onmousewheel="return imgzoom(this)" border="0" width="725">《圖八》被攻擊端(192.168.1.200)回傳給第一個閘道器(192.168.1.254)的ARP reply封包，請注意Target hardware address是假造的位址，代表被攻擊端的ARP table內容已經被篡改
接著是第一個閘道器(192.168.1.254)回傳給被攻擊端(192.168.1.200)的ARP reply封包。
725)this.width=725;" onmousewheel="return imgzoom(this)" border="0" width="725">《圖九》第一個閘道器(192.168.1.254)回傳給被攻擊端(192.168.1.200)的ARP reply封包，請注意Target hardware address是假造的位址，代表第一個閘道器的ARP table內容已經被篡改
再來是被攻擊端(192.168.1.200)回傳給第二個閘道器(10.1.1.254)的ARP reply封包。注意，若是僅有單一網段，則不會出現第三及第四個ARP reply封包。
725)this.width=725;" onmousewheel="return imgzoom(this)" border="0" width="725">《圖十》被攻擊端(192.168.1.200)回傳給第二個閘道器(10.1.1.254)的ARP reply封包，請注意Target hardware address是假造的位址，代表被攻擊端的ARP table內容已經被篡改
最後是第二個閘道器(10.1.1.254)回傳給被攻擊端(192.168.1.200)的ARP reply封包。
725)this.width=725;" onmousewheel="return imgzoom(this)" border="0" width="725">《圖十一》第二個閘道器(10.1.1.254)回傳給被攻擊端(192.168.1.200)的ARP reply封包，請注意Target hardware address是假造的位址，代表被攻擊端的ARP table內容已經被篡改
因此，netcut的攻擊手法就是交互發送偽造的非典型ARP request封包到被攻擊端與閘道器，使兩者的ARP table記錄下錯誤位址而達成截斷兩者間封包傳送的目的，而且萊因哈特發現，netcut會持續變造實體位址，並且不斷發送偽造的ARP request封包，直到netcut使用者下達恢復連線的指令為止。根據相關封包的Relative Time顯示，其變造實體位址並發送偽造ARP request封包的頻率接近每秒一次。
725)this.width=725;" onmousewheel="return imgzoom(this)" border="0" width="725">《圖十二》netcut所發送的偽造ARP request封包一覽，請特別注意Source Address所顯示的位址有何規律性
netcut頻繁更換實體位址的原因何在？個人猜測可能是為了避免網管人員憑藉少數封包就追查到這些假造實體位址的偽造封包來源，並且加以封鎖。不過，經過反覆監聽後發現，其實netcut假造實體位址的法則並非無跡可尋，例如在第一個攻擊封包裡，假造的實體位址是以62開頭，後續的假造位址也將是以62開頭，接著改用63、64、65等等，以此類推，因此只要分析相當數量的攻擊封包，就不難發現它的規律性，此時再利用分段隔離的原則進行監聽過濾，還是可以追查出這些偽造封包的來源。
2. 關於COMODO對於netcut攻擊的防禦效果
首先來看看COMODO Firewall Pro對於ARP Spoofing攻擊有什麼設定選項。在COMODO FirewallPro>Firewall>Advanced>Attack Detection Settings功能設定畫面中，發現有Protect the ARP cache及Block Gratuitous ARP frames等兩個關於ARP防護的設定項目，由於要測試COMODO Firewall Pro對於ARP Spoofing攻擊的防禦能力，因此萊因哈特把這兩個防禦功能全都啟動。
725)this.width=725;" onmousewheel="return imgzoom(this)" border="0">《圖十三》COMODO Firewall Pro具有Anti-Spoofing的功能選項
接著直接來測試netcut攻擊能否突破COMODO Firewall Pro的防護吧！只要執行命令提示字元(也就是所謂的DOS視窗)，在發動攻擊前先執行arp –a指令列出正確的ART table內容，待發動攻擊後再執行同樣指令，兩相對照就能看出COMODO Firewall Pro的防護效果如何。在正常狀況下，閘道器的對映位址應該是永恆不變的，可是我們從下圖可以發現，前後兩次所列出的閘道器位址192.168.1.254及10.1.1.254，它所對映的實體位址已經被置換，而此時原先持續在PING Yahoo首頁的DOS視窗也變成滿滿的Request timed out訊息，這就證明了COMODO Firewall Pro對於netcut攻擊根本束手無策。
725)this.width=725;" onmousewheel="return imgzoom(this)" border="0">《圖十四》從攻擊前後的ARP table可以看出，COMODO Firewall Pro根本無阻檔netcut篡改對映資料的攻擊手法
其實，打從得知netcut的行為模式開始，萊因哈特就警覺到個人防火牆對於netcut攻擊可能無力抵擋，因為即使個人防火牆可以鎖住本機ARP table的內容不被置換，也無法阻止netcut篡改閘道器上ARP table內容的惡質行為，只要閘道器上的對映位址不正確，造成被攻擊端完全無法再從閘道器收到任何封包，同樣會讓被攻擊端電腦無法正常連網。
很慶幸自己不是用COMODO Firewall Pro嗎？先別高興得太早，因為根據上述原因，不管你用的哪一套個人防火牆，都註定無法在netcut的攻擊下存活，除非你能把閘道器的ARP table內容鎖死不讓修改。
3. 觀察arp –s指令對於netcut攻擊的防禦效果
既然COMODO Firewall Pro無法鎖死ARP record，那麼自行下達arp –s指令鎖住又如何呢？
萊因哈特在本機開啟一個DOS視窗，下了兩行指令鎖住閘道器的對映資料：
arp –s 192.168.1.254 00-09-0f-0a-cd-88
以及
arp –s 10.1.1.254 00-09-0f-0a-cd-88
接著跑一次arp –a指令，確定已經成功加入兩筆型態是static的ARP record在ARP table中，然後再開一個DOS視窗持續PING Hinet首頁，最後在攻擊端執行netcut對本機發動攻擊。
很顯然，arp –s指令可以成功抵擋住netcut欺騙本機意圖修改ARP table的行為，因為閘道器的記錄始終聞風不動，不過這時已經PING不通Hinet首頁，證明只要閘道器上的ARP table沒有被妥善保護，就依然會發生封包傳輸錯誤的問題而導致連線中斷。
725)this.width=725;" onmousewheel="return imgzoom(this)" border="0">《圖十五》下達arp –s指令後，無論netcut如何攻擊，10.1.1.254及192.168.1.254這兩筆閘道器的ARP record絲毫不受影響
725)this.width=725;" onmousewheel="return imgzoom(this)" border="0">《圖十六》沒有保護好閘道器上的ARP table，依然會發生連線中斷的現象
4. 關於netcut本身對於同類攻擊的防護效果
眼尖的使用者可能會發現，在netcut主畫面的左上方有一個保護我的電腦的功能選項，而且預設就是啟動狀態，那麼是不是只要啟動這項功能就可以保護自身不被同類攻擊造成斷線呢？在回答這個問題以前，我們先來分析一下它究竟在做什麼事情。
在側錄分析這些攻擊封包的時候，萊因哈特發現它同時也會持續發送包含正確實體位址的非典型ARP request封包給閘道器192.168.1.254及10.1.1.254，而且發送頻率為固定每秒一次。這種設計的用意，應該是想利用定時為閘道器ARP table更新正確資料的方式，去確保閘道器的封包能夠正確傳送到攻擊端，不過，這只是單一方向的防護措施，是否意味它也會保護本機的ARP table內容不被置換呢？且來測試看看吧！
725)this.width=725;" onmousewheel="return imgzoom(this)" border="0" width="725">《圖十七》netcut的自我防護功能，採用的依然是發送非典型ARP request封包給閘道器的方法，只是這回封包裡的位址是正確無誤的
725)this.width=725;" onmousewheel="return imgzoom(this)" border="0" width="725">《圖十八》請注意上圖出現兩筆192.168.1.254的資料，上方實體位址為1E:69:34:45:23:54者為假資料，下方實體位址為00:09:0F:0A:CD:88者為真資料，顯然netcut會將正確的閘道器位址儲存起來，因此儘管其他應用程式被欺騙，netcut卻能將自我保護的ARP request封包傳送到正確的位址去
為了證明它是否具備前述的防護功能，我們改從被攻擊端執行netcut對攻擊端發動切斷攻擊，同時利用arp –a指令觀察攻擊前後的ARP table內容是否會被篡改。很不幸的，netcut根本無法阻擋本機的ARP table內容被置換，因此，即使它依然能夠持續發送包含正確位址的ARP request到閘道器，使閘道器的ARP table內容得以糾正，卻也因為本身的ARP table被篡改，造成netcut以外的應用程式封包都被傳送到錯誤位址去，在這種情況下，原先的攻擊端就變得無法正常連線了。
725)this.width=725;" onmousewheel="return imgzoom(this)" border="0">《圖十九》請注意攻擊前後10.1.1.254及192.168.1.254兩個位址的Physical Address變化，就算已經啟動自我保護，netcut依然擋不住本機的ARP table被篡改而淪陷
既然netcut主機被別人發動同類攻擊，導致netcut以外的應用程式封包，再也無法將封包傳送到正確的閘道位址，那麼這時netcut主機還能切斷別人的連線嗎？答案是肯定的，因為在預設狀態下，他人的同類攻擊只是截斷netcut主機與閘道器間的封包傳輸，並未切斷netcut主機與同網段其他電腦間的通路，因此，netcut主機的攻擊封包還是可以送達其他電腦，造成這些被攻擊電腦的ARP table對映位址不正確而斷線。
五‧結論
經過前面的一連串測試，我們可以得到以下結論：
1. netcut 的攻擊手法就是交互發送偽造的非典型ARP request封包到被攻擊端與閘道器，使兩者的ARP table記錄下錯誤位址而達成截斷兩者間封包傳送的目的
2. netcut 在發動切斷攻擊時，約莫每秒鐘就會變更一次實體位址並發送欺騙封包進行持久攻擊，直到接獲恢復指令為止。
3. 由於netcut會分別攻擊閘道器及被攻擊端，因此在單一主機上安裝個人防火牆，或在單一主機上利用arp –s指令鎖住ARP table內容，同樣無法阻止連線中斷的情形發生。
4. 即使啟動netcut的自我保護功能，攻擊端電腦一旦遭受同類攻擊，同樣無法抵擋，顯然這是程式作者始料未及的事情。
5. 要追蹤netcut攻擊封包的來源雖非易事，不過也並非天方夜譚，只要分析出實體位址的造假規則，然後利用分段隔離的方法進行追蹤即可；若是使用具備網管功能的高階交換器，管理者甚至能夠利用實體位址的造假規則，直接在交換器上查出攻擊封包的來源並且加以封鎖。
最後，請不要忘記netcut不單可以用來截斷被攻擊端與閘道器間的連線，也可以截斷被攻擊端與DHCP主機、AD主機，甚至與網路上任何一台主機的連線，因此攻擊手法並非只有一種，可別以為只要顧好本機與閘道器就可以高枕無憂。假如你在自動分派IP位址的網路，發生跟DHCP伺服器失連的情形，照樣會讓你氣得七竅生煙的。
發表文章
