實際演練說明，你的路徑安全嗎？CERT: 攔截式代理伺服器有漏洞、SANS：小心你的路由器！

（本文中你將看到實際的演練，在真實的網路上，我們會示範如何藉由攔截式代理伺服器的漏洞，取得路由器與其他內網伺服器的管理介面與登入prompt。測試點不在台灣。）

這篇之中我們繼續討論路徑上之安全性，但開始之前，我們先做一下聲名。本文章宗旨在於探討在現今複雜之網路架構中之路徑安全性，內容與任何資安事件皆無關連性。三月初於台灣發生的大規模轉址事件，目前相關各單位與我們的結論大致一樣，我們的研究正確，TTL=7以下為攻擊發生點，但是TTL=7這台路由器並非屬於國內任何一家ISP所有。我們的研究一樣沒有指出責任歸屬，我們說過我們有興趣的是技術面。但是大家看到我們公佈的IP可能就開始猜測是哪家ISP。攻擊者位於路徑border沒有錯（就是不同ISP交會處），而在border上的路由器一般都有多個介面，各對應不同ISP所給的IP，我們從台灣trace，看到的介面IP會屬國內ISP沒有錯，但是並不表示此台路由器就歸國內ISP所管。事實上如果各位看我們當初traceroute畫面上的時間差就可以發現，TTL=7應該已經出台灣了，事後經過求證也如此。所以如果把矛頭轉向國內ISP並不正確。另外也不表示是路由器出問題，只確定是TTL=7那台路由器以下都有可能，但是絕不像其他專家所說，是ARP掛馬以及發生點位於網站端。當然我們也得知了，出問題之設備為網路設備但是非路由器，至於究竟是那個廠牌的什麼設備，這邊就不繼續討論了。我們的研究價值，主要不在於探討究竟是國內還是國外的ISP出問題，還是哪一家設備商的產品出問題，我們是在探討，究竟威脅存在於哪裡？駭客可以使用哪些技術？

那時根據我們的經驗，以及最近SANS，CERT以及各知名資安專家近期的研究，懷疑的威脅包括了：
(1). ARP 掛馬，發生於網站端
(2). 路由器出問題
(3). 路徑中的proxy出問題或cache被poison
(4). 其他L3或L4 switch出問題
(5). 流量被mirror到的其他地方（IDS、流量統計設備等）被ARP掛馬

但是後來經過種種實際的封包實驗與分析，先排出了(1)，後來又排除了(2)與(5)。至於到底起因為何，由於後來事件不是我們調查的，我們不適合發表，只能說，事件發生點在TTL=7以下，但TTL=7已經不在台灣。ARP掛馬由於用在乙太網路上，唯一般人很容易接觸到的攻擊，但是資安專家看得面象要夠廣，並根據實際測試或證據來判斷威脅。2008開始，路徑上的威脅與研究都明顯增加，CERT、SANS、各資安研究員都不斷發表報告或警訊。會猜測是ARP掛馬，主要原因是ARP掛馬攻擊實在太氾濫了。但是同時，駭客要改網路設備的設定來mirror流量，其實並不難，若注意最近國外知名研究員，CERT，SANS都在說路由器怎麼被感染的。網路上攻擊形形色色，無時無刻在進行，駭客無時無刻在進步。由於種種ARP工具，隨處都抓得到，也隨處都能玩（有乙太網路就好），於是之後的直接反應就是，各種轉址綁架攻擊，都一定是ARP掛馬所致，而當我們說可能是路由器出問題，或路徑上其他設備出問題時，則表示不可思議，路由器怎麼被入侵？感染？有這種技術嗎？路由器可以mirror traffic？L4/L7 switch會被入侵？

[SANS: 小心你的路由器！]

的確，路徑上的種種設備，不是一般人容易接觸到的，我們也常覺得自己研究起來辛苦，跟在電信業上班，每天穿梭機房的工程師比起來，我們對於網路的熟悉度要弱很多...但是至少我們也摸了不少，見了不少，透過關係「借測」了不少，並且常做功課。因為如果覺得駭客只會乙太網路上的一些普遍的基本功，那就太小看駭客了。各位不知是否還記得2007年被判刑入獄的23歲路由器駭客Robert Moore的名言：「It's so easy. It's so easy a caveman can do it（太容易了，野人都會）」。Robert專門入侵VoIP路由器，然後販賣頻寬獲利，入獄前一共駭了15家VoIP ISP業者。他受訪時表示，大約45%到50%的VoIP業者的網路都是不安全的。最大的問題在哪？「我會說，85%的問題出在沒有設定好的路由器，很多設備都用了內定的密碼（I'd say 85% of them were misconfigured routers. They had the default passwords on them）」。「你不會相信網路上有多少路由器的密碼是"admin"或"Cisco0"」，他說。三月30日，SANS發佈警訊，標題是「小心你的路由器！（Watch your Internet routers!）」，報告中詳細介紹了剛發生的一個剛發生的路由器入侵事件（這裡指的是企業級路由器，非之前我們提的家用路由器感染事件），並說：「他連進來還沒五分鐘，已經建好一個tunnel回他家了（Barely five minutes after connecting, and he has configured a network tunnel back to his home base.）」。修改網路設備的設定，開tunnel，其實做過的人就知道，可能比執行zxarps還要容易，也不太會增加設備的loading，只是一般人不容易玩到就是了。

[CERT與SANS: 攔截式代理伺服器有漏洞]

2009年三月初，台灣與新加坡之間有流量被綁架，而由於二月底時，CERT針對攔截式代理伺服器有公佈警告：「Intercepting proxy servers may incorrectly rely on HTTP headers to make connections(VU#435052)」 ，於是我們做了一些測試，並發現了路徑上的一些問題。後來根據我們做的種種測試與研究，我們的結論是，以下探討的「攔截式代理伺服器」漏洞，不太可能與轉址事件有關連。在事件過後，我們覺得當初做的研究仍有參考價值，故在週末抽空記錄一下當時的研究。我們這篇以探討技術為主，我們拿來實測的有弱點的proxy，依了解並不位於國內。

當初對CERT這篇有興趣，主要是CERT中列了許多大廠牌的代理伺服器，都還是有此問題，而我們記得此問題在2002年時就已經炒熱，沒想到事隔多年，問題並沒有改，而今年又吸引了研究人員的注意。我們先直接來看這個威脅究竟在講什麼。現在的網路環境複雜，不但有各家專做content delivery network(CDN)的廠商如Akamai、Amazon CloudFront等負責幫各大網站在世界各地提供資料，路徑中也有各式的攔截式代理伺服器（intercepting proxy）、透通式伺服器（transparent proxy）、L4/L7 switch等設備。對於常常出差的我們來說，常可以感受得出把資料放在CDN上的方便性。有使用類似技術的大站如Google、MySpace、Amazon或甚至BestBuy等，不論在哪裡（例如印度偏遠地區），當別的網站變成龜速時，這些架構於CDN上之網站，總是能維持相當的速度；網路不穩無法連回公司mail server時，就立刻感受gmail之好用。各地的ISP也為了降低長距離的流量，而建置了各式的L4/L7 switch，WCCP路由器，Web加速器（cache），代理伺服器等等。在方便之餘，也不禁讓我們想到，我們在網路上做這麼多事情時，我們的資料到底經過了誰？我們接收的資料又來自誰？譬如這次三月份台灣大規模轉址攻擊事件，其實我個人並不在意被轉址到惡意網站，反正我有很多保護措施（而且我們的工作本來每天就接觸許多惡意網站），但是攻擊者明顯可以看到我的流量，這是我很在意的。攻擊程式如果沒有解除，而只是不主動送假封包轉址，而改成監聽流量，那麼平時上網時之心理壓力就會倍增了。

今年路徑安全之研究真的很紅，上，今年（2009）三月16-20於溫哥華舉辦的CanSecWest 2009資安會議上（投影片下載），Dan Kaminsky講的，就是有關路徑安全的研究。去年因為在BlackHat / DEFCON 2008上公開DNS漏洞之超級紅人Dan Kaminsky（這裡有我們的報導，另外其實他一直很紅），於會前（三月9日）在他的部落格上說：「似乎我們在2000-2002年間做了很多相關（網路層）的研究，然後...我們好像就停止了。今年在我的CanSecWest演講中，我就要來討論在deep packet inspection的年代的中間人威脅（paper：WORD下載、PDF下載）...從位於路徑中的設備（middle of networks）上，我看到了種種的威脅」。隔一天，SANS立刻針對此發出警告：「Browser plug-ins, transparent proxies and same origin policies」。

Dan在文中也表示，在這個研究中，他與Paypal的Robert Auger合作密切。其實這次CERT的警告，最相關的就是Kaminsky的這篇研究以及Rober Auger於同一天（三月9日）公佈的paper：「Socket Capable Browser Plugins Result In Transparent Proxy Abuse（支援socket的瀏覽器外掛會導致代理伺服器之濫用）」，其中用了很具體並圖文並茂的例子，說明了CERT提及的弱點，在何種情況下可以被攻擊者利用。

Kaminsky的討論比較針對使用DPI(deep packet inspection)的設備，如防火牆與IPS等。要能在網路上偵測出這些設備的存在，目前並無太多現成的工具，但是Kiminsky的paper中給了許多不錯的方法。CERT與Auger的報告則以討論代理伺服器為主，代理伺服器的存在一般比較容易看得出來，我們就用實際的例子來說明。從我家到www.ebay.com中間，存在著攔截式代理伺服器（大家別討論屬於哪家ISP的，這不是重點，我們這邊只講技術）。如何證明？用ICMP與TCP SYN做traceroute，可以看出明顯的差別，來看看實際的測試。在以下的真實測試中，我們會示範如何藉由攔截式代理伺服器的漏洞，取得路由器與其他內網伺服器的管理介面與登入prompt。首先，我們發現我們在某位置（不在台灣），www.ebay.com對應了五個IP：
圖1--ebay對應五個IP
但是不論採哪個IP，UDP的traceroute結果大概都差不多：
圖2--UDP traceroute
那麼TCP traceroute在port 25上呢？也差不多：
圖3--TCP port 25 traceroute
可是TCP traceroute在port 80就不一樣了：
圖4--TCP port 80 traceroute
用nmap的tcp traceroute功能跑一下nmap，也是差不多的結果：
圖5--nmap -sS --traceroute
很明顯有攔截式proxy位於此路徑上，其作用很可能是加速使用者對於www.ebay.com的存取，以及節省長途的流量。我們用CERT公佈的方法測試一下，發現該路徑上有proxy有弱點，導致攻擊者可以利用該proxy連線至任意其他網站。該路徑上之proxy不只一台，有些沒有弱點，但是有些有。以下我們讓該proxy連到www.google.com.tw：
圖6--利用 GET HTTP/1.1與Host:之攻擊
這個攻擊非常簡單，也很容易了解。我們明明是連往www.ebay.com的port 80，但是因為我們心裡知道，接受連接的是一台proxy，所以我們就在【Host:】欄位，改填了"www.google.com.tw"，而結果該proxy在我們的操作下，往google連去了。很多攔截式proxy都會攔截多個網站，所以在判斷往往不從連線的目的IP來看，而從HTTP request中的【Host:】欄位來看（也就是從L7來看而非從L4來看）。其實這是很直覺也很合理的設計，並且要修正也不容易。為何不容易修正？我們來看看一個很常見的網路架構（topology）：


從上圖可以看出，不容易修正的原因包括如下：
1. proxy前端如果是具有WCCP功能的路由器在負責攔截port 80的流量給proxy，那proxy可以知道使用者的IP封包原本希望連哪裡，但是很多時候是L4/L7的switch在負責攔截，這個時候就不一定了，另外proxy也很有可能串接好幾台，那麼通常除了第一台知道以外，之後的都得靠【Host:】欄位。
2. 即使有IP目的地資訊，大的網站，大部分都是一個網址對應很多IP，如果根據當初要連往的IP而非【Host:】欄位，那可能減少快取（cache）的hit rate，除非要有辦法知道，哪些IP是屬於哪些網站的，但是由於此對應關係屬動態，故在proxy端不容易分析清楚。
3. 從IP來看究竟是要連往那個網站，如果用DNS反查，則可能會因為各地DNS之不同（proxy所用之DNS與使用者所用之DNS不同），而導致無法正確判斷使用者所想要連往的網站。這中間所消耗的時間也是另一個問題。

但是這樣一個弱點，就讓此「代理www.ebay.com之攔截式伺服器」，有效的變成了「公開的匿名伺服器」，根據CERT、Auger、與Kaminsky的報告，可以被利用來掃瞄或入侵內網，click fraud攻擊，發送垃圾信以及當作跳板等。這種弱點一般算是設備的弱點，而非設定上的弱點，但是同常也可以用設定來彌補。我們用古老的方法讓該proxy自首一下，到底是哪家的設備：

圖7--用古法之一來辨認設備廠商
辨認出來是一台CacheFlow。CacheFlow早於2002年就被BlueCoat併購了。早在2003年（被併購之後），Tim Kennedy就於Bugtraq公佈了該設備的類似弱點的了（BID 8584）：CacheFlow CacheOS HTTP HOST Proxy Vulnerability，當時Kennedy用的範例是利用該proxy發垃圾信。根據Bugtraq，廠商一直並未修復此弱點。再翻一下，更早在2002年，就有類似但更嚴重的弱點（BID 4143）：CacheFlow CacheOS HTTP CONNECT TCP Tunnel Vulnerability，原來也可以利用HTTP CONNECT來讓該設備連往任意網站之任意port。該報告說，解決方法是CacheOS（CacheFlow的平台）5.0版，已經將出廠值設為CONNECT只能連往port 443。電信等級設備特色是，超級穩定耐操壽命又長，但是通常更新不易，所以很多弱點的壽命也都很長。

其實我記得這些網路層的攻擊在2002年左右是高峰。一直往上爬就沒有所謂「高峰」，要有往下掉才有「高峰」--事實上正是如此，2002年後，SQL injection / XSS這些變得非常紅，大家的注意力也就從網路層的威脅慢慢轉移了。其實威脅一直存在，也一直被利用，只是不是媒體的焦點罷了。此類proxy弱點於bugtraq上有一篇很著名的，一篇打死近所有廠商的（2002年，BID 4131）：Multiple Vendor HTTP CONNECT TCP Tunnel Vulnerability（看看下面廠商清單有多長），與今年（2009）二月底的CERT報告，講的其實是差不多的事情，只是過了七年，路徑安全又在今年受到了重視，所以CERT等於重講了一次。在CERT報告中我們可以看出，BlueCoat於1月被通知，並已經於3月4日終於修改了這個七歲以上的已知漏洞。不過置於外那麼多超級強壯可以活10-20年的設備何時會真的被更新，就很難說了。既然有HTTP/1.0漏洞以及HTTP/1.0 CONNECT漏洞，我們也順便測試一下，該位於我們與ebay之間的CacheFlow，是否有類似弱點。我們先測HTTP/1.0漏洞：
圖8--HTTP/1.0漏洞
測試結果是漏洞存在，可以用HTTP/1.0指令讓該proxy連到www.google.com.tw。那麼CONNECT呢？
圖9--HTTP CONNECT www.google.com.tw成功
答案是肯定的，HTTP CONNECT也可以成功。那麼會不會是沒有真的連線，而只是剛好該proxy也暫存google的網頁呢？那我們測試叫他連到www.armorize.com好了，結果也成功，立刻連過來了：
圖10--HTTP CONNECT www.armorize.com成功
通常大家看到攔截式proxy可以bounce，直覺可以被駭客利用的就是打內網，或這次Auger提到的繞過same origin policy(相同來源政策)等。其實有一個應用是常被忽略的：如果攔截式proxy可以bounce，就會透露該proxy對外的IP。當然剛才該proxy已經連到我們網站過了，所以看log就可以看到IP，但更快的是，讓它連到像http://www.ipaddressworld.com這種會回報訪問者IP的網站，這樣就得到了該proxy對外的IP：

圖11--取得對外IP
我們連往該IP，果然看到了CacheFlow的管理頁面，上面有該設備的型號，內網IP，MAC硬體位置與OS序號等資訊。
圖12--對外的管理介面
最後的問題是，這一台CacheFlow（暫稱A），與位於我們與ebay中間的那一台（暫稱B），是同一台嗎？因為有可能是B攔截後，發現cache miss，於是串接A，讓A去取資料。由於圖12中我們可以看到A的內網位置，於是我們透過B的弱點，讓B透過內網連線A，發現是相通的，但是這只能確定，A與B其卻透過該內網相通，但是否A與B就是同一台，我們認為極有可能，但無法確定。
圖13--外網連內網
恩，連到內網了，由於圖12中的對外管理介面，讓我們得知了內網的IP，我們也於圖13中，證明了可以經過該漏洞，從外網連到內網。那是否可以連到路由器呢？一般路由器的IP都是設成.254，然後管理介面設在port 23(telnet)吧？那我們演練看看好了：
圖14--外網連內網，最後連進路由器

故事說到這，其實已經從外網連到內網，然後連到路由器的CLI介面了。當然這不算是有弱點，因為我們沒有密碼，但是這示範了最近SANS/CERT/Kaminsky/Auger在講的威脅。那麼再繼續看呢？試一試.253好了，結果.253是一台伺服器，login畫面出來了：
圖15--外網連內網，取得login畫面

這個攻擊很古老，但是為何CERT、Kaminsky、Auger等人又在最近重提呢？原因有二，第一，最近路徑上的威脅倍增，大家重視；第二，Kaminsky與Auger有效地提出了該弱點如何可以被利用。我們拿Auger報告中的圖來做說明：
圖16--Auger的說明（thesecuritypractice.com）
Auger主要假設使用者瀏覽了一個被掛馬的網站，其中惡意iframe指向www.evil.com。此時第一步，使用者機器連往DNS，詢問出www.evil.com的IP為1.1.1.1。第二步，使用者連往www.evil.com，www.evil.com丟給使用者一個flash。此flash有權力開socket連回www.evil.com，於是第三步，flash先詢問www.evil.com是否可以開socket連回（flash保護機制Security.loadPolicyFile()）。第四步，flash開socket連回www.evil.com，但是由於socket開在port 80內容也為標準HTTP GET封包，故連線被中間的proxy攔截。步驟五，由於封包中之【Host:】欄位並非指定www.evil.com而是指定www.site.com（該proxy之弱點），該proxy向DNS詢問www.site.com之IP，並於步驟6連往。此時，瀏覽器上之same origin policy(相同來源政策)就被成功的繞過了。

最後我們還是要特別強調，測試之環境不在台灣，我們也已經通知對方，對方也把問題修復了。希望這些技術面的討論，對大家有幫助。

路徑安全大事一覽表：

2003/07/30	Black Hat US 2003，FX（Phenoelit的leader Felix）發表：「更多有弱點之嵌入式系統（More vulnerable embedded systems）」（投影片）
2003/10/01	Black Hat Federa 2003，FX發表：「Cisco弱點--過去，今天與未來（Cisco Vulnerabilities - Yesterday, Today and Tomorrow）」（投影片）
2005/07/27	Michael Lynn於Black Hat 2005上發表：「聖杯：CISCO IOS shellcode 以及攻擊技巧」（這裡與這裡有人公布投影片），遭Cisco沒收大會所有講義與CD(這裡有人公開當初撕書與沒收CD的錄影）
2007/07/22	Black Hat / DEFCON主席Jeff在DEFCON 2007，講了Lynn&Cisco整段事件（影片在這裡），並說當時Michael卡住，結果：他在「一個中文的論壇上找到了答案，已經有中國人先研究出來了，於是他翻譯了內容，並有了突破」。
2007/09/26	專門駭入路由器偷VoIP頻寬之駭客Robert Moore被判刑，他駭入了15家電信業者，並說：「太容易了，野人都會」
2008/05/15	The Register: 路由器rootkit上演，網路將被操控(Rootkits on routers threat to be demoed--Networks own3d)
2008/05/17	Cisco官方強化IOS設備手冊 (Cisco Guide to Harden Cisco IOS Devices)（此乃針對以下之演講發表）
2008/05/19	台灣Digitimes:可入侵思科路由器的Rootkit軟近期內將公開亮相
2008/05/21	EUSecWest 2008--Core的研究員Ariel Futoransky: Cisco IOS rootkit解密：正宗IOS Rootkit（Killing the myth of Cisco IOS rootkits:DIK Ios rootKit）（PDF paper 下載）
2008/05/23	中国IT实验室：Rootkit兵临城下 思科忙为路由器打补丁
2008/05/26	网界网：思科发布路由器补丁程序，但忧虑仍在
2008/06/08	IDG: Cisco路由器又在駭客聚光燈下(Cisco routers again take hacker spotlight)
2008/08/02	Black Hat 2008 一共三場關於路由器安全之演講
2008/08/06	Gyan Chawdhary與Varun Uppal發表：「Cisco IOS shellcode與後門（Cisco IOS Shellcodes/Backdoors）」（講義下載）
2008/08/07	Core的研究員Ariel Futoransky--「Viral Infections in Cisco IOS（病毒式感染Cisco IOS）」（投影片）
2008/08/07	FX發表：isco IOS鑑識的近期發展（Developments in Cisco IOS Forensics）（講義下載）
2008/08/13	中国IT实验室：全球黑客聚会黑帽大会 Cisco路由器再成热点话题
2008/08/21	Andy Davis發表：「跨版本Cisco IOSshellcode（Version-independent IOS shellcode）」
2008/09/30	ISC2（推出CISSP認證的組織）blog：網路上最弱的一環是路由器。太多設定不好的路由器了。（連結）
2008/12/30	25c3 Conference，FX發表：「Cisco IOS--攻擊與防禦，當今最高水平（Cisco IOS--Attack & Defence, the State of the Art）」（投影片在這）（錄影在這裡）
2009/01/11	Terry Baume：「Netcomm NB5路由器僵屍網路（Netcomm NB5 Botnet–PSYB0T 2.5L）」。
2009/02/23	CERT針對代理伺服器發出警訊：「Intercepting proxy servers may incorrectly rely on HTTP headers to make connections」
2009/03/09	Rober Auger公佈paper：「支援socket的瀏覽器外掛會導致代理伺服器之濫用（Socket Capable Browser Plugins Result In Transparent Proxy Abuse）」，說明了CERT提及的弱點，在何種情況下可以被攻擊者利用。
2009/03/09	Dan Kaminsky於blog上表示今年在CanSecWest 2009上會講關於路徑安全之主題：「Staring Into The Abyss」（WORD下載、PDF下載）
2009/03/09	SANS針對二月時CERT之警訊以及三月時Kaminsky與Auger的研究發出警告：「Browser plug-ins, transparent proxies and same origin policies」。
2009/03/12	Cisco警告：「亞洲某些區域出現流量綁架，可能是non-blind TCP spoofing或其他種類攻擊，tw.msn.com與taiwan.cnet.com受影響」（連結）
2009/03/22	DroneBL發表：「網路藍色藥丸：隱形路由器僵屍網路過去幾星期以DDoS攻擊DroneBL（Network Bluepill - stealth router-based botnet has been DDoSing dronebl for the last couple of weeks）」，敘述了NetComm NB5路由器被感染並成為僵屍網路一員的整個過程
2009/03/23	ZDNet的Zero Day blog發表：「隱形路由器botnet蠕蟲散播（Stealthy router-based botnet worm squirming）」
2009/03/24	SANS警告：「PSYB0T：mipsel設備之IRC Bot（PSYB0T: A MIPS-device (mipsel) IRC Bot ）」
2009/03/24	The Register：「蠕蟲透過家用路由器與modem養botnet，超過100,000台遭入侵（Worm breeds botnet from home routers, modems--More than 100,000 hosts invaded）」
2009/03/24	Dark Reading：「路由器以往是被視為比較不會遭受惡意程式攻擊的，僵屍網路以往則針對個人電腦跟伺服器，但現在不同了。（Routers traditionally have been considered relatively immune to malware and attacks, and botnets traditionally used PCs and servers.）
2009/03/24	Dark Reading長篇大論地討論了路由器的安全：「破解路由器修補之謎（Hacking The Router Patching Conundrum）」
2009/03/25	Cisco發出了advisory，集合了8篇advisory，一次公佈了8個CISCO IOS的弱點，並提供更新程式下載
2009/03/25	SANS警告：「Cisco釋出IOS弱點修正集合（Cisco Releases IOS Bundle of Vulnerabilities）」
2009/03/30	SANS發佈警訊，標題是「小心你的路由器！（Watch your Internet routers!），詳細介紹了前幾天某台Cisco被入侵的過程：不到五分鐘，駭客已經建好tunnel回家了

作者 Fyodor Yarochkin 為 o0o.nu 成員
作者 Wayne 為 阿碼科技CEO

相關系列文章：
2009/03/08 「大規模網頁綁架轉址：威脅未解除，但專家都猜錯了」
2009/03/12 「大規模網頁綁架轉址之水落石出篇」
2009/03/13 「回答IP Spoofing 的問題」
2009/03/15 「從大規模轉址事件看IP spoofing、ARP spoofing、ARP掛馬與路徑(route)安全」
2009/03/27 「網路藍色藥丸？首支攻擊路由器之蠕蟲出現：再談路徑之安全性」