阿碼外傳-阿碼科技非官方中文 Blog: 2009年4月4日

2009年4月4日

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


繼續閱讀全文...