libnet使用舉例(5)

libnet使用舉例(5)    2000-01-01     scz      技術文檔       這次以ICMP重定向封包的DoS為例繼續介紹libnet庫程式設計。ICMP重定向攻擊很久了， 長期不看又會對某些技術細節有所忽略，回顧一下。 -------------------------------------------------------------------------- 預設路由向發送者報告另一條到特定主機的更短路由，就是ICMP重定向。最初，網絡 路由重定向是被支援的，然而後來網絡路由重定向遭到異議而廢棄。除了路由器，主 機必須服從ICMP重定向。 下文引自W.Richard Stevens TCP/IP Illustrated, Volume I page 123: 一台4.x BSD主機接收到ICMP重定向封包，為了防止失常的路由、主機或者惡意的入 侵者不正确地修改系統路由表，做了如下檢查： 1. 新路由必須是直達的 所謂直達，就是本機到該路由無須經過其他路由，直接利用ARP尋址，利用MAC地 址投遞封包。 2. 重定向包必須來自去往目标的目前路由 比如，A欲去往Z，A和Z不在一個子網内，主機A目前選路規則下所經過的的第一個 路由是G，但G認為H比自己更優化，于是告訴A更改目前選路規則使得到Z時優先使 用H。這個重定向封包必須來自G，而不是其他主機或路由。 A目前的路由表裡可能有F、G兩條路由，都可以經其到達Z，但是G比F優先，那麼 A目前隻能接受來自G的重定向封包，來自F的重定向封包被認為無效而丢棄。後面 實驗中的很多現象都與這條規則相關，必須加強了解。 3. 重定向包不能通知主機用自己做路由 雖然這是合理要求，但Pwin98允許通知主機用自己做路由，實際上就造成了DoS。 其他系統尚未測試過。 4. 被改變的路由必須是一條間接路由 所謂間接路由就是我們平時所了解的路由，那麼什麼是直接路由呢，利用MAC位址 進行封包投遞而已，同一子網，明白了？是以若A和B在同一子網，A不可能利用 ICMP重定向使B發往子網内IP的包流向自己，但可以使B發往子網外IP的包流向自 己。 ICMP重定向提供了一種相當有效的DoS。不象ARP入口，這些特定主機路由入口永不過 期(就和你用route add指令手工增加路由一個道理，如果沒有重新整理出現，不存在過期 問題)。注意，攻擊沒有要求必須從區域網路内發起，事實可以從廣域網上發起。如果 子網所用DNS位于網關外，産生一個到該DNS的錯誤路由是很容易的，于是...... 我在Pwin98下測試過，由ICMP重定向包産生的路由都是掩碼為255.255.255.255的特 定主機路由，沒有辦法産生諸如255.255.0.0這樣掩碼下的網絡路由。此外，不知道 是不是系統實作有差别，反正Pwin98下，通過ICMP增加上來的特定主機路由會過期， 什麼情況下過期，據觀察似乎長期不使用就過期，route add增加的不會過期。通過 ICMP增加的指向自身的病态路由即使過期也會保留殘像，非病态路由從路由表中徹底 消失。 許多桌面作業系統線性搜尋自己的路由表，如果你利用ICMP重定向包加了太多特定主 機路由到它們的路由表中，嘿嘿。對于Unix系統，雖然搜尋路由表時不是線性搜尋， 但過多的特定主機路由會消耗大量的記憶體空間。這些都屬于DoS攻擊範疇。 現代作業系統或多或少提供了屏蔽ICMP重定向包的機會，具體如何實作我現在也很亂。 -------------------------------------------------------------------------- 這是我在華為的時候寫的，有些東西已經不大記得，一些實驗資料丢棄了，重新測試。 此次我們不考慮利用ICMP重定向進行監聽，僅僅考慮DoS攻擊。 僞造一個來自192.168.0.1的ICMP重定向包，從MAC層開始僞造。 1) 利用05 01重定向封包(針對特定主機)依舊可以修改2K的路由表！但是無法使2K的 特定主機路由指向自己(而Pwin98可以)，2K在這點上改進得不錯。被重定向過的 特定主機路由長時間不消失，可以手工route delete掉。如果已經重定向到某個 IP，再發重定向包企圖指向其他IP失敗。 其實最後一條實驗結果的本意可能不是你了解的那樣，注意到前面我們提到過， 重定向包必須來自去往目标的目前路由，否則重定向封包會被認為非法而丢棄。 這才是真正原因。我們無法利用ICMP重定向封包産生兩條特定主機路由，因為第 二次将是修改特定主機路由，而非增加特定主機路由。98下route add可以手工增 加兩條特定主機路由，但實際上隻有一條生效，否則選路規則相當胡亂，個人認 為這是route add指令本身實作上的缺陷。如果已經重定向到某個IP，需要重新構 造一個重定向封包使得其源IP是上次指定的路由IP，這樣的封包才會生效。 2K下可以用route add增加一條路由，使之指向自身，這和重定向包不能通知主機 用自己做路由不沖突。此時增加的路由可以被route delete删除。 2) Pwin98下，可以使特定主機路由指向自己。被重定向過的特定主機路由長時間不 消失，删除時分兩種情況，如果該特定主機路由不是指向自己，可以手工 route delete掉，如果指向自己，route delete的時候會報告找不到該路由， route change時同樣報告找不到該路由，netstat -nr卻還能看到該路由， route -f參數不能删除該路由，登出重登入也不能删除該路由，想其他辦法重新整理 路由表吧，沒有繼續測試如何删除該病态路由。 98下可以用route add增加一條路由，使之指向自身，此路由可以被route delete 删除。但是，重定向包導緻指向自身的病态路由就無法用route delete删除。98 對route指令的實作相當混亂，比如可以 route add 202.99.11.161 mask 255.255.255.255 192.168.10.3 route add 202.99.11.161 mask 255.255.255.255 192.168.10.4 route add 202.99.11.161 mask 255.255.255.255 192.168.10.5 此時用netstat -nr檢視會同時看到三條特定主機路由和一條預設路由，但 telnet 202.99.11.161 80的時候使用的僅僅是192.168.10.3，并不在失敗後嘗試 10.4、10.5以及預設路由，這使得DoS攻擊成立。 route change 202.99.11.161 mask 255.255.255.255 192.168.0.1 修改的是10.5對應的那條路由，telnet 202.99.11.161 80同樣會失敗，理由同上。 route delete 202.99.11.161後會同時删除這三條特定主機路由，此結論對ICMP 重定向導緻指向自身的病态路由無效。 通過ICMP增加的非病态路由與route add增加的路由效果一緻。如果先被人用ICMP 在預設路由基礎上增加過一條特定主機路由192.168.10.3，然後自己route add了 另外一條特定主機路由192.168.0.1，此時使用的還是第一條特定主機路由 192.168.10.3。再次僞造ICMP重定向包，源IP為192.168.10.3，目标IP為 192.168.10.60，可以繼續"修改"後者路由表裡的特定主機路由，不再是"增加"特 定主機路由。 對于前述病态路由，無法删除的情況下，依舊可以route add 202.99.11.161增加 另外一條特定主機路由，route delete可以删除後續增加的這條路由，病态路由 依舊。指向自身的病态路由增加上來，初期對IP尋徑造成很壞的影響，我不确定 這個影響會持續到什麼時候，何時過期等等。似乎通過手工route add一條特定主 機路由會"加快"病态路由影響的消失。該影響"徹底"消失後，route delete掉手 工增加的特定主機路由，繼續使用預設路由。但是用netstat -nr還是看到病态路 由，盡管這個時候沒有影響了，faint。這種情況下，除了殘像，其他都恢複到沒 有殘像的狀态，可以僞造一個源IP為預設路由IP的重定向包重新替192.168.10.60 增加特定主機路由。 測試中還确認，目标MAC不能是0xffffffffffff，目标IP不能是定向廣播位址，源 MAC不被檢查(任意)。 假如異己主機發送了一個ARP請求包或者響應包，包中源IP位址等于自己的IP位址， 那麼兩台之中必有一台錯誤配置了IP位址。Net/3偵測到這個錯誤并向管理者報告。 注意，隻有ARP封包(無論是請求還是響應)才會更新ARP Cache，才有可能引發ARP 沖突等等，是以在僞造ICMP包時無須過多顧慮源MAC。IP封包本身永遠都不會造成 事實上的ARP欺騙、沖突、重新整理效果。 ARP Cache總會過期，不會因為總在使用Arp Entry而不過期。可以這樣驗證，在 98下pint -t，然後用NetXray設定過濾規則抓取ARP請求封包，總是在固定間隔上 看到本機發出的ARP請求封包。ICMP增加上來的路由過期時限很長，比ARP欺騙危 害大。 3) 下面是一個示範封包，僞造成從網關192.168.0.1發往192.168.10.60的ICMP重定 向封包，使得後者産生一條到202.99.11.161的特定主機路由192.168.8.90。 00 10 FF 69 FF FF 00 50 04 BF 07 34 08 00 45 00  00 3C 5B 6E 00 00 80 01 53 C5 C0 A8 00 01 C0 A8  0A 3C 05 01 AF 8A C0 A8 08 5A 45 00 63 64 65 66  00 68 FF 01 51 E1 C0 A8 0A 3C CA 63 0B A1 75 76  77 61 62 63 64 65 66 67 68 69 把上述封包存入 redir1060.txt 檔案中，以 root 身份執行如下指令： ./linuxkiller -k redir1060.txt -w 5 -r 1000 測試過程中看到，如果在192.168.10.60上route delete 0.0.0.0、 route delete 202.99.11.161，則不受ICMP重定向包的影響，這個結論很正常， 前面我們提到過，重定向包必須來自去往目标的目前路由，如果根本就沒有合适 的目前路由，重定向封包會被認為非法而丢棄。 4) 如果是98，可以用如下系統資料庫設定打開路由功能，98單網卡就可以提供路由功能： REGEDIT4 [HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/VxD/MSTCP] "EnableRouting"="1" 5) 由于再三提及的原因，無法利用ICMP重定向封包憑空産生特定主機路由。同時被 更改的特定主機路由本身也會被ICMP重定向封包更改。啟動98路由功能後， 192.168.8.90會向192.168.10.60發送ICMP重定向封包，修正後者直接使用 192.168.0.1。注意，掩碼規則優先于特定主機路由。 必須明确了解路由優先級的概念。如果隻有預設路由，ICMP會導緻增加特定主機 路由。如果已經存在特定主機路由，無論它是如何産生的，僅僅會被ICMP修改， 而不是增加。 6) 目前的測試環境使用的是交換式HUB，拓撲結構大緻如下： -------------------------------------- <-- Smart Hub Or Switch | | | 192.168.10.60 192.168.8.90 ...... 192.168.0.1 (sygate) <--> Internet 255.255.0.0 255.255.0.0 255.255.0.0 下面觀察這樣做了之後發生什麼事情。從192.168.10.60上 telnet 202.99.11.161 80，此時192.168.8.90轉發了這個封包，轉發過程中修改 源MAC位址成000000111111(192.168.8.90的MAC位址)，源IP保持192.168.10.60。 192.168.8.90在轉發第一個發起TCP連接配接的SYN封包的同時會向192.168.10.60發送 ICMP重定向封包(掩碼規則下192.168.0.1更優化)，使得特定主機路由成為 192.168.0.1。于是後續的192.168.10.60到202.99.11.161的封包都直接經過 192.168.0.1，但是回來的封包始終是經過192.168.8.90的。這個現象很有意思。 在192.168.8.90和192.168.10.60上抓包觀察到的現象始終都是出封包直接經 192.168.0.1，入封包經192.168.8.90轉發而至。袁哥和ipxodi認為是sygate本身 實作的問題，比如sygate沒有使用标準ARP Cache，自己保留了MAC-IP對之類的信 息提高效率；換成正規路由器，應該不是這種現象。現在很多機關區域網路的拓撲 類似，估計sygate、wingate等支援透明代理功能的軟體都存在這樣的問題，說不 上是漏洞還是被非法利用，總之應該意識到該問題的存在，反正以前我是沒有料 到這個現象的存在。 我和ipxodi剛開始讨論這個問題的時候認為隻能抓到出封包(特定主機路由)，而 入封包因為掩碼規則直接投遞了。沒料到實際測試中，192.168.8.90本身會發送 ICMP重定向封包。可以想個辦法讓192.168.8.90的ICMP重定向封包不能發送出去， 比如個人防火牆、象袁哥那樣修改VxD等等。 先不考慮個人防火牆的介入，在我們這種拓撲下，ICMP重定向帶來的入封包經 192.168.8.90的問題很嚴重。想想看，192.168.10.60上很快就恢複了正常的路由 規則，ARP Cache與這個問題無關，也不表現什麼異常，唯一算得上異常的是 192.168.10.60的路由表中雖然已經有預設路由192.168.0.1，但還是出現了特定 主機路由192.168.0.1。沒看過這篇文章的朋友，有幾個會想到可能是出事了呢？ 由于入封包經過192.168.8.90，在這裡起一個NetXray，不用寫ARP欺騙程式、 "合法"利用ICMP重定向功能和98的IP路由功能，異常現象最小化等等。這裡無法 抓取出封包，于是無法監聽到諸如telnet密碼之類服務方不回顯的資料，參看後 面的讨論。上述描述适合于交換機情形，如果你對子網内每個IP用程式發送ICMP 重定向封包，并開啟本機路由功能，要比ARP欺騙容易實作得多，也持久得多。考 慮DNS伺服器位于子網外的拓撲，至少可以看到誰企圖解析什麼域名，算不算侵犯 隐私呢，sigh。強烈反對監聽，可為什麼總在給别人提供監聽的可能，也許又是 一次沖突選擇吧。 像ARP欺騙，一是容易暴露，二是需要高頻率重新整理，三是一般需要程式設計實作。而 ICMP重定向不容易暴露(考慮sygate的"特性")，不需要高頻率重新整理，如果經常使 用根本就不需二次重新整理，用NetXray發送一次重定向封包即可。無論如何，ICMP重 定向封包是潛在的安全隐患，現在傾向于不使用它。IDS系統應該高度敏感ICMP重 定向封包的出現，在區域網路記憶體在支援IP轉發功能主機的情況下，可能會出現非 攻擊性的ICMP重定向封包，不能一味告警，需要區分。 7) 在介入個人防火牆的情況下，192.168.10.60和202.99.11.161之間就完全經過 192.168.8.90通信，無論出入封包。需要注意，98不适合做路由功能，效率很低、 負載很高，再啟動一個NetXray的話更要命，尤其我這次測試時98使用的是單網卡。 上述技術僅僅限于理論研究以及純DoS攻擊，真正要做監聽不實際。還有，此時 192.168.10.60上特定主機路由192.168.8.90顯得很刺眼，容易暴露。 NetXray和ConSeal PC FIREWALL的啟動順序必須留心，建議如果要做協定分析， 無論如何都先啟動NetXray，尤其當出現異常現象的時候關閉二者，按照建議順序 重新開機動。 8) 迄今為止，都是用微軟作業系統測試，并沒有測試Linux/Solaris/FreeBSD，這些 系統的測試留待我寫個libnet程式來完成，總是手工構造ICMP重定向封包太累了。 微軟作業系統在沒有個人防火牆介入的情況下如何屏蔽ICMP重定向封包，尚不清 楚，誰知道了就貼一下(系統資料庫？)。 9) 因為前面測試是手工構造完整實體幀，是以才涉及到MAC位址，事實上ICMP重定向 封包與MAC位址無關，與源IP有關，但raw_socket上可以僞造任意源IP，至于資料 區就不在話下了。什麼意思？ICMP重定向攻擊可以跨路由進行，在廣域網上進行。 區域網路内攻擊不但可以DoS還可以sniffer，廣域網上就隻能DoS了(想想為什麼)。 還好，我這次被人抓住寫的也就是DoS工具，不想那麼多啦。 既然是DoS，最終目的是不讓目标活得舒坦。象98，就可以設定指向自身的病态路 由，其他系統，至少可以設定一個不存在的間接路由。通過大量增加垃圾特定主 機路由消耗記憶體空間、延長路由搜尋時間。某些實作不好的作業系統，還可能被 某些特殊重定向封包凍僵住。這些都會在我寫完libnet測試程式之後驗證一二。 曾經很喜歡的一句話，"死神之花已然開放"，現在淡了，喜歡"人不與天争"。 <待續>