實際演練說明，你的路徑安全嗎？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 「網路藍色藥丸？首支攻擊路由器之蠕蟲出現：再談路徑之安全性」


繼續閱讀全文...

網路藍色藥丸？首支攻擊路由器之蠕蟲出現：再談路徑之安全性

(picture source: http://www.fastforwardblog.com)

自從最近寫了幾篇關於路徑安全的文章後，短短幾天內，世界各地突然冒出了許多關於路由器安全的新聞。美國西岸時間三月22日凌晨，DroneBL首先發表了blog：「Network Bluepill - stealth router-based botnet has been DDoSing dronebl for the last couple of weeks（網路藍色藥丸：隱形路由器僵屍網路過去幾星期以DDoS攻擊DroneBL）」。先離題聊一下「藍色藥丸」吧！在1999年電影駭客任務(The Matrix)中，藍色藥丸（Bluepill）與紅色藥丸分別象徵了「虛幻世界」與「真實世界」。2006年六月，由那時還在COSEINC（與阿碼共同舉辦SySCAN前瞻資安技術年會的新加坡公司）的Joanna Rutkowska，證明了可以在MS系統（包含Vista）上，利用AMD的虛擬化機制，實做極隱密rootkit之可能性，並在她blog上貼了一篇：「Introducing Blue Pill（介紹藍色藥丸）」，並於同年先後在SySCAN 2006與BlackHat 2006（投影片下載）上發表。之後此rootkit程式有公開並可下載。其實當初Joanna取名藍色藥丸，主要是因為該rootkit乃利用了CPU虛擬化(virtualization)的機制來達成極度隱密之目的，故藍色藥丸暗喻「虛擬化(virtualization)」而非「隱密性(stealthiness)」，但是因為大家對於此rootkit之隱密性都有很深的印象，所以從此，「藍色藥丸（Bluepill）」便成了資安研究員形容各種「隱形」技術時喜歡用的代名詞。

這次DoneBL所發的「網路藍色藥丸」，主要描述NetComm NB5 這台 ADSL 路由器，會被蠕蟲「PSYB0T」自動攻擊並感染，成為botnet(irc)的一員，除了會接受指令參加DDoS攻擊外，也會自動掃瞄，攻擊並感染其他同型路由器，來散播該蠕蟲。「網路藍色藥丸」則指管理者不容易發現路由器已經遭受感染。DoneBL估計已經有100,000台路由器遭PSYB0T感染，並認為這是第一隻會自動感染路由器的蠕蟲，且對象可能不限於NetComm NB5這型路由器，而是任何以linux mipsel為平台的路由器都有機會被感染。
(picture source: http://www.teamtelco.com.au)

(picture source: http://www.beyondlogic.org)

隔天（三月23日），ZDNet的Zero Day blog上，Ryan Naraine就貼出了「Stealthy router-based botnet worm squirming（隱形路由器botnet蠕蟲散播）」，並引述了DroneBL的blog。Teamfurry blog上也貼出了一篇：「Botnet running on MIPS CPU devices（Botnet在MIPS CPU設備上散播）」，其中第一句就說：「Finally, something new :)（終於有新鮮事了）」。由於此二blog在資安界皆頗具人氣，又隔天（三月24日），SANS就發出了警告：「PSYB0T: A MIPS-device (mipsel) IRC Bot （PSYB0T：mipsel設備之IRC Bot）」，並引述了以上兩個blog。同時，英國最大IT媒體The Register也報導了：「Worm breeds botnet from home routers, modems--More than 100,000 hosts invaded（蠕蟲透過家用路由器與modem養botnet，超過100,000台遭入侵）」。

以上這些報導，都引述了Terry Baume在一月11日時所公佈的研究報告(PDF)：「Netcomm NB5 Botnet–PSYB0T 2.5L」。其實這篇中就已經把該攻擊描述得很完整了，並也開門見山地用紅字點出，PSYB0T應該有能力感染其他機型之路由器（但是僅限於linux mipsel，非CISCO IOS或Juniper freebsd）。Terry也指出，在他兩天的觀察其內，PSYB0T由一天感染兩台路由器，迅速加速到一天感染20台路由器的速度。Terry發現該蠕蟲有利用UPX加殼，解殼後可以利用MIPS的反組譯器（如RecStudio）來進行反組譯及分析。Terry也利用反組譯來分析了該蠕蟲並詳細說明了其行為。

「Teamfurry的blog上則指出，經過了三個月，PSYB0T已經有了演進，應該是看到了Terry的blog，所以雖然還是用UPX加殼，但是之後手動做了修改（駭客不看blog？不夠水準的blog當然沒人看）。Teamfurry的解殼法則是先手動將修改復原，然後一樣利用UPX解殼，分析後，發現版本字串已經從當初Terry看到的"2.5L"變成"2.9L"了。Teamfurry指出，該攻擊可怕的是，可以竄改DNS設定，也可以隨意轉址到非法的網站。

Dark Reading也於同日報導了此事件，並說：「Routers traditionally have been considered relatively immune to malware and attacks, and botnets traditionally used PCs and servers.（路由器以往是被視為比較不會遭受惡意程式攻擊的，僵屍網路以往則針對個人電腦跟伺服器）」。Dark「」 Reading並訪問了路由器安全專家FX(Felix FX Lindner，前一篇我們介紹過)，FX說：「惡意程式已經開始利用路由器了，但是在這個事件中，目標還只是簡單的linux。」

仔細看一下此事件使用之技術，NB5是用MIPS處理器，跑embedded linux，有Web的管理介面，也可以開啟telnet/ssh。有大量的NB5，出廠時，這些管理介面是對WAN端也開放的，並且不需密碼或密碼為出廠的"admin"/"admin"。PSYB0T之動作步驟如下：

1. 用多種方式設法取得shell(telnet/ssh)，包括嘗試出廠設定，以及用暴力法猜帳號密碼等（所以太弱的帳號密碼也會被攻入，如"netcomm"/"netcomm"）。
2. 利用http或tftp下載蠕蟲本體並於背景執行。
3. 關閉對外之所有port，避免他人進入或重複感染。
4. 連往某些特定之 IRC server，加入IRC botnet，開始回報並接受指令。
5. IRC 指令包含了攻擊其他NB5散播本體，攻擊MySQL，攻擊phpMyAdmin，各種DDoS攻擊，port scan，監聽流量並偷帳號密碼等。

無獨有偶，雖然兩件事無關，但又隔日（三月25日），Cisco發出了advisory，集合了8篇advisory，一次公佈了8個CISCO IOS的弱點，並提供更新程式下載。由於公佈的弱點頗多（包含了TCP、UDP、無線 IP以及VPN等），SANS也於同天發了一篇關於路由器的diary：「Cisco Releases IOS Bundle of Vulnerabilities（Cisco釋出IOS弱點修正集合）」。Dark Reading則似乎收到消息Cisco會於25日釋出advisory以及更新程式似的，於24日先長篇大論地討論了路由器的安全：「Hacking The Router Patching Conundrum（破解路由器修補之謎）」。

標題下面大大的黑字寫著：「最近的研究已經證實了路由器並不像以前想像的難入侵，企業以後若無法在不影響網路運作下，定期安裝路由器修補程式的話，將倍感壓力」。DearReading介紹了FX最近對路由器安全的研究（我們在前一篇有介紹），FX則表示，問題出在IOS目前沒有修補程式，每次都需要更新整個IOS image。但是更新整個IOS image後，常會導致設定或軟硬體不合等問題。Dark Reading表示，更新路由器軟體常常不被視為是高優先的工作，目前也少有企業有建立對路由器軟體更新之程序與規範。

去年因為在BlackHat / DEFCON 2008上公開DNS漏洞之超級紅人Dan Kaminsky（這裡有我們的報導，另外其實他一直很紅）則表示，他們（IT）從沒去考慮外頭那麼多的路由器。他們缺乏資源，工作量超過負荷，除非有很好的理由，不然不可能再去監控另一種問題（路由器）...但是FX的研究已經給了最好的理由。

FX則說：「所有我認識並談過的企業與電信業者，當有IOS的更新公佈時，沒有一個單位有去做更新，因為更新IOS所帶來的危險比被駭的危險更高。」Cisco的Russ Smoak則表示，部分的客戶會上更新，部分則不會。「我們的客戶廣布於每一個角落；有的遵循嚴謹的規範並勤勞地更新，有的則擁有老舊的平台。」Kaminsky說：「你不用緊張，但是廠商叫你更新時，你就是必須要更新。」

好了，談到這邊，我們來回顧一下，我們於三月8日第一次探討路由之安全，並於三月15日寫的「從大規模轉址事件看IP spoofing、ARP spoofing、ARP掛馬與路徑(route)安全」中有提到，2008年，對於路由器安全的研究突然很多，一個Black Hat 2008竟然有三場相關演講。又提到：

『
去年九月底，Alexandre Cezar在ISC2（推出CISSP認證的組織）的blog上寫了一篇：The most vulnerable device in the network，他說最近與朋友討論，整個網路（使用者機器不算）上，最脆弱的機器是什麼。「The answer of almost everyone in the table was: Routers...（所有人一致的回答都是：路由器）」。文章中他列舉了router上可能有的威脅，另外我很喜歡他回Tim Bass的留言（泰國OWASP分會會長，上次OWASP有來與大家見面）時說的：「And you're right when you said that there aren't many exploits for routers but my main point is that you don't need exploits to compromise a router, you just need to found a misconfigured one and the Internet in plenty of them（你說路由器的攻擊程式不多，我同意，但是重點是，入侵路由器並不需要用弱點攻擊程式，你只需要找到一個沒有設定好的路由器，而網路上多的是）」這根FX在演講中說的一樣，其實現在掃瞄路由器還是可以發現很多設定上的錯誤，弱的密碼等等，攻擊路由器不一定需要用到他們研究的這些新技術。
』

其實掌握資安威脅趨勢並不困難，許多事件的發生都有跡可尋。此事路由器蠕蟲事件，其實在一月時，Terry Baume公佈的研究報告(PDF)：「Netcomm NB5 Botnet–PSYB0T 2.5L」就已經分析得很完整了，可惜當時並未引起大家的高度關注，才會讓感染的機器不斷攀升。另外，這台NetComm NB5有蠕蟲出現，其實也不意外。這台很多人喜歡玩，早在2005年4月左右，如何編譯適合這台執行的程式之方法，就已經被公開得很詳細了。「Exploring the Netcomm NB5 - ADSL / ADSL-2/2+ Modem Router」一文中，將步驟一步一步地描述得很完整。

三月21日，活了三個月之久的路由器蠕蟲終於受到媒體與SANS重視，三月24日，媒體與SANS也因為Cisco即將發佈的安全更新而大幅探討路由器安全問題。三月初我們探討路由安全問題時，許多資安專家抱持懷疑的態度，質疑「何謂路由器被感染，什麼鬼東西，從沒聽過」，或「感染路由器後要做什麼」等。這顯示大家對於此類威脅比較陌生，可能是之前國內類似案例並不多（或公開的不多）。其實比較早進入資安研究的朋友，應該對這些network層的威脅都不陌生；在沒有Web的年代，這些很多都是駭客很熟的技術。加上這幾年路由器上之威脅不斷被公布，實際的案例也一一出現，負責的資安研究人員，應該要能隨時掌握最新的威脅趨勢，提早警告客戶與大眾，做好事前的預防，才是減少資安成本的關鍵。我們在做事件處理時，常覺得，事前與事後，在成本上真是天差地遠，只要充分掌握威脅趨勢，事前的預防其實不難，但是如果沒做好準備而讓事件發生了，真是客戶累，我們也累，雙方所花的時間，很多用於善後，而非提升資安水平，可說事倍功半。

作者 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 「網路藍色藥丸？首支攻擊路由器之蠕蟲出現：再談路徑之安全性」

繼續閱讀全文...

從大規模轉址事件看IP spoofing、ARP spoofing、ARP掛馬與路徑(route)安全

「優秀的鑒識人員除了要懂得物證的處理外，還要用科學的頭腦來思考。物證雖然能夠提供重要的線索與證據，但是要能解開整個迷局，就需要用頭腦串連所有的物證。在我處理過的六千多個案件中，就遇到單憑一件物證破案的案件」--李昌鈺

這次的大規模轉址事件，受到各界關注，我們也寫了兩篇（這裡、這裡）我們對事件的研究。大家這麼注意這次事件當然是有道理的，因為這麼大規模的轉址，持續時間又久--到底發生了什麼事？我們寫出我們的看法後，收到很多網友的問題，於是我們又寫了一篇回答，但是大家還是有很多問題，我們持續收到email與留言。我們在這邊將所有的問題與我們的回答整理成一篇，並也藉此機會，討論一下什麼是IP spoofing、none-blind IP spoofing、ARP spoofing、ARP掛馬 等，供大家參考。另外，我們收到很多網友寫信來或留言的鼓勵，我們真的非常的高興，也非常的感謝，各位的鼓勵是我們最大的動力，我們會繼續努力，謝謝各位對我們研究的肯定，也請不吝批評指教。

[事件最新發展]
1. Cisco於三月12日更新了alert報告，提及「可能是non-blind TCP spoofing或其他種類攻擊」，整個報告第一句：「Reports indicate that some TCP traffic that is passed through certain Taiwanese networks is being redirected to malicious websites.」（TCP流量經過台灣的某些網段時遭攻擊，部分使用台灣的使用者可能受影響）。這跟我們的研究結果是一致的，攻擊者位於route上。另外，我們沒有說攻擊程式位於route"r"（路由器）上，我們一直的說法都是，攻擊程式位於route上，差一個字差很多。

2. Juniper也同意我們的研究：「Juniper先進科技部資深技術經理林佶駿於今(12)日受訪時表示，從阿碼科技等提供的證據來看，神秘網頁轉址攻擊確實有可能發生在210.65.255.241到211.22.33.225這個路徑(route)上，但就此斷定中華電信的路由器(router)被動手腳或遭入侵的可能性並不高。」我們本來就沒有說一定是路由器的問題，我們一直強調攻擊程式在route上，並透過研究證明，有攻擊程式位於距離我們TTL=7以內。這個跟許多人分析說是DNS攻擊，Man-in-the-middle攻擊，網站遭攻擊或遭ARP掛馬，是很不同的，但是我們透過實際的資料與數據證實了我們的看法，也得到了CISCO與Juniper的認同。

3. 這次研究的重點不在於「究竟是否是路由器出問題」。結論重點在於，第一，確定有none-blind IP spoofing，而非DNS攻擊，也看不出有ARP掛馬，這跟其他人的看法很不同。第二，從錄到的封包以及攻擊內容（插入iframe方式）來看，推測攻擊者無法竄改原封包，無法避免原真封包還是抵達受害者，也無法避免真封包比假封包早到。第三，有攻擊程式存在於TTL<=7路徑當中。我們一直說 route 上出問題而沒有說一定是 route"r" 上出問題，大家看文章時麻煩要注意到。

[何謂 Man-in-the-middle (MITM)?]

首先我們定義文中何謂「Man-in-the-middle」（MITM），我們採wikipedia的定義：「In cryptography, the man-in-the-middle attack or bucket-brigade attack (often abbreviated MITM), sometimes Janus attack, is a form of active eavesdropping in which the attacker makes independent connections with the victims and relays messages between them, making them believe that they are talking directly to each other over a private connection when in fact the entire conversation is controlled by the attacker. The attacker must be able to intercept all messages going between the two victims and inject new ones, which is straightforward in many circumstances (for example, the owner of a public wireless access point can in principle conduct MITM attacks on the users).」

根據這個定義，MITM需要達成以下：攻擊程式負責在兩受害者中間「轉送」流量，並可以控制整個流量。

[何謂 ARP spoofing?]

我們採wikipedia的定義，ARP spoofing是在類乙太網路上，利用發假的ARP封包，達到把自己當成MITM的目的。在這邊要注意的是，要達到監聽封包，ARP不是唯一的作法，也並非最簡單之作法。第一，ARP spoofing只能用於類乙太網路上，第二，達成了ARP spoofing，就必須擔起「中間人」的責任，必須在中間轉送所有的流量，不然可能造成網路癱瘓，這需要一定的運算能力。

[何謂 ARP 掛馬？]

ARP 掛馬並沒有很明確的定義，因為這一個攻擊手法，一個手法會用到一個以上的攻擊技術，我們在這邊定義如下：攻擊者使用類似zxarps這種工具，先在類乙太網路（ethernet-like）上，用ARP spoofing讓自己成為MITM，然後（選擇性地）在HTTP response中插入惡意的iframe，達到攻擊的效果。根據這個定義，這樣的手法包含了兩個攻擊技術：

1. ARP spoofing攻擊，以取得MITM地位。
2. TCP session hijacking，以便修改TCP封包並插入iframe。這其實是zxarps值得注意的功能之一。zxarps的TCP session hijacking做得蠻完整的，因為他會處理到TCP層，修改TCP封包中的SEQ/ACK號碼等。由於其TCP session hijacking實做很完整，在大部分的情況下，看不出異常的流量，除了在同一個乙太網路的broadcast domain（或vlan）下，偵測流量之異常並不容易。

[何謂 None-blind IP spoofing?]

None-blind IP spoofing是指攻擊者可以監聽到TCP/IP流量，並發出TCP s/n對的假封包，並成功讓受害者以為是真封包。然而不同於做得好的TCP session hijacking，none-blind spoofing中真假封包都會同時送到受害者，故在路徑中或在受害者端，都可以利用監控流量之異常來偵測出none-blind IP spoofing。不同於因為監聽不到流量而必須發出大量封包的blind IP spoofing，none-blind IP spoofing通常可以很準確的發幾個甚至一個封包，就能達到效果--這是攻擊者喜愛它的重要原因之一。在無法達成好的TCP session hijacking情況時，或沒有需要（懶得做）時，攻擊者常退（改）而採用none-blind IP spoofing。由於None-blind IP spoofing需要能夠監聽到流量，故需配合其他監聽技巧。ARP spoofing是其中一種方式，但並非唯一方式，也並非最簡單之方式。

[為何你們判斷此次是 none-blind IP spoofing而非其他人說的，DNS攻擊或ARP掛馬？]

如果是DNS攻擊，使用者不會注意到被轉址了，瀏覽器的網址列會顯示對的網址，故排除是DNS攻擊。另外根據我們前兩篇（這裡、這裡）所公布我們錄到的資料，依據錄到的封包，確定有non-blind IP spoofing。至於是否伴隨ARP掛馬，目前看不出來有，沒有直接證據，故我們沒有說有，但也沒有說一定沒有。non-blind IP spoofing是錄到的事實，故我們會說一定有。

那麼為何我們沒有說是 ARP 掛馬呢？因為基於以下幾點：

1. 因為如果照上面的定義，利用類似zxarps這種工具做ARP掛馬時，第一，除非我們在同一個vlan下，不然很難偵測出流量的異常，也不會有真假封包同時被我們看到。

2. 由攻擊者的假封包內容來看，明顯地無法竄改原封包，沒有辦法避免真封包的到達，甚至沒有辦法避免假的封包比真的慢到達，所以對方試了很多種方式。如果能夠用ARP掛馬，這些都可免了--可是事實並不是這樣。以下是這次常見的一個假封包的內容：

<html><body><meta http-equiv="refresh" content="4;url=http://www.zhonglie.org"></body></html>

為何要用這種似乎很笨拙的iframe插入方式？原因就是，無法有效達到MITM地位，竄改原封包。我們再來想一想，根據我們收到的封包，確定：1.攻擊者在route中間，2. 攻擊者可以監聽到封包，3. 攻擊者可以發spoofed IP封包到受害者。那麼既然這些都可以做得到，為何不直接使用類似zxarps這種完整的TCP session hijacking呢 （ARP掛馬）？因為如果使用zxarps（ARP掛馬）的話，我們在家裡根本不會收到真假封包，這個攻擊就更隱密了，fyodor與wayne可能也就抓不到攻擊程式在TTL=7之內了。原因是，我們已經證明了攻擊程式位於TTL=7之下，表示位於route中段，而zxarps的使用，需要很多環境的配合，譬如要在類乙太網路上，要有足夠運算能力處理流量並修改TCP的seq/ack等等。如果你對一台路由器做ARP spoofing而自己沒有運算能力處理好所有的封包，那麼你就不是在做TCP session hijacking攻擊而是在做DOS攻擊了--網路有可能會癱瘓。另一方面，很多路由器周邊並沒有接ethernet，ARP spoofing派不上用場。

所以依我們的經驗，在以上三個條件都滿足下，還是有很多攻擊者會選擇用none-blind IP spoofing而不用ARP掛馬，因為後者需更多條件，也因此後者比較常見於使用者端或Web伺服器端，而非route中間。那有沒有同時伴隨ARP掛馬呢？我們只能說，我們沒能力監控整個台灣的網路，就我們自己的流量來說，我們沒有看到有ARP掛馬，再說，即使有發生，要在我們所在的route末端判定是ARP掛馬，也會有相當的難度，因為如果是用zxarps，大部分情況下並不會有流量異常（真假封包）產生。

[好，那麼ARP spoofing呢？]

要達成none-blind IP spoofing，必須要監控流量，而ARP spoofing是達成流量監控的手段之一。但是由於我們證明了攻擊程式位於route中間，在此位置要監控流量，有很多其他常用的方式（見下文），ARP spoofing並非最常用的，因為需要的條件比較多。

[那為何認定是none-blind IP spoofing呢？]

因為從錄到的封包來看，就是none-blind IP spoofing，這是事實，是否有伴隨其他攻擊，就我們錄到、網友錄到並公布於網路上，還有網友私底下傳給我們的部分，都可清楚看到none-blind IP spoofing，但是都沒有ARP掛馬的現象。

Route（路徑）上的安全性

其實雖然我們沒有直接斷定是route"r"被動手腳（我們都說攻擊程式在route上），我們蠻驚訝有些專家認為router或router附近被動手腳的機率很低。有些人提出這樣的問題：

「ROUTER 被感染？？「感染」ROUTER？？你是說「感染」路由器嗎？」

「如果是在路徑中間發生spoofing，流量要mirror到哪裡？」

「ROUTER被入侵？改設定？」

WOW，哈哈，似乎專家們覺得在router附近做這次的攻擊，幾乎沒有可能似的，真是讓我們很驚訝。我想這跟個人經驗有關吧...說實在的，雖然對外我們都說route上有攻擊程式，並證明在TTL=7之內，但是從一開始我們自己被攻擊並做初步封包分析後，我們肚子裡都有把「router被動手腳了」當作有可能的原因之一。大家不要又失焦去討論那是否就是ISP的責任，這不是重點，況且我們兩人都用同一家ISP，別的ISP有沒有被攻擊，我們也沒有測，另外有些設備的問題，非ISP責任所屬。追究責任，我們沒有興趣，我們只對弄清楚威脅有興趣。為何說與個人經驗有關？因為 hacking in router land，當初是蠻主流的。國小時我從我的300 baud modem開始碰網路，也記得大二時有幸參與資策會的Winking計畫，將一套Waterloo的TCP/IP實做（C寫的）porting到Windows 3.1，並在上面實做一個剛時剛定義出來的WinSock 1.0介面。Fyodor是snort最早的programmer之一。那時都還沒 有什麼SQL injection、Web掛馬這些。但是router一直是攻擊的目標--想想，如果控制了router，能做多少事？我們也經歷許許多多案件，都是router被動手腳，被建tunnel監聽流量（非用ARP spoofing）...我想這是為何我們肚子裡會把router被動過視為很可能的原因之一吧！可能近幾年，攻擊router的相關研究比較少，攻擊都在Web上，大家就把router land遺忘了吧...所以我們想在這邊探討一下路徑上的安全性，但是千萬大家別失焦，我們不是要說問題出在誰，我們只是想就技術方面來討論。

大家記得去年美國駭客年會BlackHat時我們有去並寫一些報導嗎？其實那時就注意到，哈，今年關於router的題目又回來啦！也記得那時IDG（全球最大IT媒體）也有報導（好友Robert寫的）：Cisco routers again take hacker spotlight（Cisco路由器又在駭客聚光燈下）（大陸：全球黑客聚会黑帽大会 Cisco路由器再成热点话题）。（當然因為是IDG報的，大部分主流媒體(world-系列)都會刊：PCWorld、InfoWorld、TechWorld）。談到Cisco要先說明一下，為何大家都鎖定Cisco絕對不是Cisco漏洞比其他家多，而是很簡單的理由--市佔率最高（我們家就有用Cisco三年了一直很滿意）。好了，言歸正傳，其實故事要回到又三年前，在2005年，當時在ISS工作的Michael Lynn，準備在BlackHat 2005上公布他找到的Cisco IOS弱點。他的演講題目為：The Holy Grail: Cisco IOS shellcode And Exploitation Techniques（聖杯：CISCO IOS shellcode 以及攻擊技巧）（這裡與這裡有人公布投影片）。原本ISS同意了Michael的演講，但是後來因為Cisco覺得不妥，ISS便與Michael以及大會商量，改講其他內容。由於原本的演講內容，投影片已經壓在大會給每個人的CD片中，講義也已經印了，大會只好同意CISCO小組在前一天進入大會，將已經裝入每人一個的背包內的CD片取出，並一本一本地將大會講義中Micheal的部分撕除（這裡有人公開當初撕書與沒收CD的錄影）。
在英文中，Holy Grail聖杯的意思就是終極境界，是所有人想達到而達不到的。在2002年四月18日的WinHec 2002開場演講上，比爾蓋茲曾說，靜態分析（源碼檢測）一直是是計算機科學的聖杯（"Software verification has been the Holy Grail of computer science for many decades"），但是我想對Michael來說，Cisco IOS shellcode，才是真正的聖杯吧！

演講當天，Micheal Lynn上台，原本要講另一個備胎題目voIP security，結果一開始講，觀眾馬上開始噓聲連連。他就問，OK，那你們要聽我原本的演講嗎？觀眾開始歡呼，於是他就講下去了！當然這最後結果是，Micheal被起訴，大會主席Jeff花了二十萬美金的律師費，而Cisco與ISS各花了上百萬的律師費。2007年美國駭客年會DEFCON 15，主席Jeff特別用了一個小時講了這整段事件（影片在這裡，重點約14分鐘後開始），而這邊要提到的是，他在48分30秒的時候說，當時Michael的研究，卡在跟FX（Phenoelit的leader Felix）同一個地方（可能是heap overflow為version-或configuration-dependent，無法做到universal）。結果猜猜Mike如何突破的？他在「一個中文的論壇上找到了答案，已經有中國人先研究出來了，於是他翻譯了內容，並有了突破」--所以你說，亞洲區對路由器的攻擊不熟嗎？

2007年，大會主席Jeff Moss特別在DEFCON上花了一小時講當初之事件
講到FX，他在Cisco IOS上的研究比Michael Lynn可能更為出名。除了更早期的研究以外，他在BlackHat Federal 2003（BlackHat DC的前身）上，有一篇「Cisco Vulnerabilities - Yesterday, Today and Tomorrow（Cisco弱點--過去，今天與未來）」與同年在BlackHat USA 2003上的一篇「More vulnerable embedded systems（更多有弱點之嵌入式系統）」中，已經把Cisco IOS當時被發現的許多弱點，做了很完整的分析，奠定了他在這方面權威的地位。其實不論是FX或Micheal Lynn的研究，都是在討論Cisco IOS的binary exploitation，也就是如何遠端的可以送shellcode給Cisco，讓這些shellcode執行起來並植入後門。在這個領域很重要的研究，是FX在去年年底，於25c3大會上（很棒的資安會議，推）發表的「Cisco IOS--Attack & Defence, the State of the Art（Cisco IOS--攻擊與防禦，當今最高水平）」（投影片在這）（錄影在這裡）：

在這個演講中，FX先聲明為何他都針對Cisco IOS而非其他廠牌的路由器做弱點研究：1. 因為在超過一千五百元美金的路由器市場中，Cisco的市佔率大於92%，2. Juniper其實就是FreeBSD所以他沒興趣，3. 其他家用router基本上都是embedded linux。接下來FX提到了入侵路由器的動機，而我覺得特別的是他在動機中所提的三點：1. Windows / Linux 系統現在比較難攻，2. 很多Cisco IOS攻擊程式（exploit）現在反而比Windows攻擊程式便宜，而且生命比較長。Windows的漏洞現在不容易活長，但是很貴，以及3. 如果可以選擇的話，當然是要入侵border路由器而非底層的路由器。接下來FX介紹了Cisco IOS的架構，如何做鑑識，以及他開發的鑑識工具CIR（Cisco Incidence Response）。然後，FX開始解釋如何達成穩定的緩衝區溢位攻擊並執行shellcode。他解釋，之前公布的攻擊方式，最大的問題都還是跟IOS的版本有關係，沒有辦法做到在多數版本都可穩定的將shellcode執行起來。在這方面，FX用了很類似去年加州UC Sandiego大學Shacham等人在美國駭客年會BlackHat USA 2008發表的「Return-Oriented Programming」技巧，並找到可穩定執行shellcode的記憶體區間ROMMON，成功實做出了穩定且跨IOS版本的緩衝區溢位攻擊。精彩的部分是，FX並當場用他帶來的Cisco路由器做了demo。他利用了該路由器IOS在解碼IP options欄位時的緩衝區溢位錯誤，利用一個單一的ICMP封包（等於一次ping），就達成了溢位成功並執行shellcode的目的。

接下來是如何撰寫可穩定執行且跨版本的shellcode。FX提及了早些日子，Andy Davis提出的「Version-independent IOS shellcode（跨版本IOS shellcode）」並不夠stable，然後提出了他自己的作法，並說明為何該方法可使shellcode穩定並跨平台的執行。接下來他提出了，一旦可以穩定並跨版本的溢位攻擊Cisco IOS並執行shellcode，可以做的事情有哪些。最後他說，如果我說我是Cisco IOS的第一人，那就太自大了。其實外面有很多人都跑得比我前面，所以這些攻擊在外面應該都有出現了。

好，回到去年IDG在BlackHat USA 2008前的報導：Cisco routers again take hacker spotlight（Cisco路由器又在駭客聚光燈下）。報導中說，在Michael Lynn之後，路由器的弱點研究似乎就不太被公開了，一直到去年，BlackHat USA 2008大會竟然同時出現三場有關路由器弱點的演講。這時的Cisco對2005年Lynn的事件已經持很開放的態度了。Cisco的CSO John Stewart非常誠實的說，當時Cisco有理由，但是做得太過了。「那時我們做了一些愚蠢的事情，這是為何我親自決定今年當白金贊助商，因為我覺得我們應該做些補償。」主席Jeff則認為這幾年沒有研究員再公開Cisco漏洞，跟Lynn事件並無關係。他認為這是因為地下經濟成熟了：「Lynn那個弱點直二十五萬美金。」BlackHat USA 2008中，Core的研究員Ariel Futoransky給了一場「Viral Infections in Cisco IOS（病毒式感染Cisco IOS）」（投影片）。對，你沒看錯，他用了「Viral（病毒式）」與「infection（感染）」這兩個字。用在路由器上很奇怪嗎？其實也還好啦！這個研究是他與同事Gerardo Richarte與Sebastián Muñiz共同完成的，而他們其實在稍早的EUSecWest上，就已經先發表了一篇：Killing the myth of Cisco IOS rootkits:DIK Ios rootKit（Cisco IOS rootkit解密：正宗IOS Rootkit）（PDF paper 下載），並宣稱他們的方法可達到高度的隱密性--這個應該是第一個被公開的Cisco IOS rootkit。Cisco隨後發表了「Cisco Guide to Harden Cisco IOS Devices（Cisco官方強化IOS設備手冊）」；媒體報導可見：英文：The Register, Rootkits on routers threat to be demoed--Networks own3d，台灣：Digitimes，可入侵思科路由器的Rootkit軟體近期內將公開亮相，大陸：1. Rootkit兵临城下 思科忙为路由器打补丁，2. 思科发布路由器补丁程序，但忧虑仍在。

Gyan Chawdhary與Varun Uppal，則發表了：Cisco IOS Shellcodes/Backdoors（講義下載），他們認為Cisco並沒有真正把Lynn發現的漏洞修補好，並提供了三段shellcode來證明他們還是可以繞過Check Heap防禦機制並執行shellcode。不像FX的shellcode，當時這三段都還有寫死的記憶體位置，故應該無法很穩定及跨版本的執行。最後，FX也在會上給了一場演講：Developments in Cisco IOS Forensics（Cisco IOS鑑識的近期發展）（講義下載）。這裡他發表了先前介紹的Cisco IOS鑑識工具CIR（Cisco Incidence Response）。

至於控制了路由器後如何監聽流量呢？既然已經可以控制路由器，當然就不需要用到ARP spoofing了--tunnel或mirror都可以。2000年的Phack 56中gauis寫得蠻簡單清楚的：Things to do in Ciscoland when you're dead（這裡有大陸的翻譯）。另外要攻擊路由器也不一定要植入shellcode這麼複雜--外面這麼多SNMP bruteforcer不是沒有原因的。Wolfgang 2003：Exploiting Cisco Routers，Hidalgo 2005:Cisco SNMP configuration with a GRE tunnel都可以參考。

去年九月底，Alexandre Cezar在ISC2（推出CISSP認證的組織）的blog上寫了一篇：The most vulnerable device in the network，他說最近與朋友討論，整個網路（使用者機器不算）上，最脆弱的機器是什麼。「The answer of almost everyone in the table was: Routers...」。文章中他列舉了router上可能有的威脅，另外我很喜歡他回Tim Bass的留言（泰國OWASP分會會長，上次OWASP有來與大家見面）時說的：「And you're right when you said that there aren't many exploits for routers but my main point is that you don't need exploits to compromise a router, you just need to found a misconfigured one and the Internet in plenty of them。」這根FX在演講中說的一樣，其實現在掃瞄路由器還是可以發現很多設定上的錯誤，弱的密碼等等，攻擊路由器不一定需要用到他們研究的這些新技術。

寫了這些最近有關路由器的研究，我們希望表達的是，這次大家研究台灣大規模轉址事件時，應該要先研究收集到的事實，例如錄到的攻擊封包等，而非說：因為這兩年大陸很多人研究ARP掛馬，ARP掛馬工具很成熟，ARP掛馬網路上資料很多，最近很多ARP掛馬事件，就斷定是ARP掛馬，然後說但是IDC一定不會承認，大家忍一忍事情就過去了等等。如果要這樣想，那麼去年突然迸出許多關於路由器弱點的研究，媒體也開始報導路由器攻擊重成焦點，穩定且跨版本的的溢位與shellcode執行也被公開，第一支公開的rootkit也出現了，那是否就斷定這次是路由器的問題？當然不是。我們可以根據事實來研究，到底是什麼樣子的攻擊？可能出現在哪裡？這樣才知道要怎麼預防，才可以避免下次可能的損失。我們公布的研究結論，都是先根據我們錄到的封包，不是先根據最近這些新聞與研究。最後，我們一直說"route"（路徑）上出問題，但是沒有說判斷一定是route"r"（路由器）出問題，因為我們沒有任何證據，另外路徑上還有很多其他可能。Futoransky去年在BlackHat 2008發表的Viral Infections in Cisco IOS（病毒式感染Cisco IOS），是他自己取的名字。

[收集的一些問題]
（「回答IP Spoofing 的問題」中已經有收錄部分問題與我們的回答）

問：IP spoofing和 arp spoofing你好像搞錯了。IP Spoofing指的只是單純偽冒IP。而你單就route尾巴的封包是不可能判斷出IP spoofing的，要做session hijacking，ARP spoofing是要用到的，而不是IP Spoofing。

ARP Spoofing，是現今網路環境作snffing的第一步，藉由了解受害網站與其gateway間的訊號傳送，來控制受害網站間傳輸的資料流，包含偽裝同一來源IP發出相似的封包(是的，這叫ARP spoofing不叫IP spoofing)。不過相對來講，傳統ARP spoofing會製造出大量的ACK/DATA封包。但配合MITM/ARP掛馬，還可以再降低無效的封包量。

只有在同機房有人被佔領，就可以對所有機器進行ARP Spoofing。

答：恩，不是這樣子的，剛好相反，如果攻擊程式在route中間，我們在end端只能看到IP spoofing而看不到arp spoofing。另外arp spoofing不能說是監聽封包的唯一方法，有很多其他方法（見上文）。有些路由器兩兩之間根本沒有ethernet，如何做ARP spoofing？但是還是有其發方法可監聽流量。依我們自己事件處理的經驗，當攻擊程式為於route中間時，使用ARP spoofing來監聽的並不常見，其他方把反而比較常。最後，ARP spoofing不會製造出大量ACK/DATA封包。ACK/DATA是TCP層（OSI第二層）的，而ARP spoofing是第二層的，大量ACK/DATA在TCP session hijacking時可能會出現，但是不是在ARP spoofing時。ARP spoofing會看到很多重複的ARP frames。zxarps這種工具做得遠不只ARP spoofing，他的man-in-the-middle實做了完整的TCP session hijacking，並且有去改seq/ack number，故降低了無效的封包量。所以zxarps這種攻擊並不只包含了ARP spoofing--你講的這些都是TCP session hijacking非ARP spoofing。這些技巧都用了十年以上了，完整的TCP session hijacking的實做以前就很多了。要做session hijacking，ARP spoofing只是其中可能用到的一步，但並不一定會用到。另外，如果真的做了session hijacking，我們在route尾巴就看不到假的IP packet了--但是我們有看到，所以我們說是none-blind IP spoofing，可能有伴隨ARP spoofing，但是也可能沒有。

問：那個.241的推論其實看不太懂，該不會因為兩者匯流於.225，所以直接推斷前一個hop，或TTL=7以下的hop必定是問題點吧?

這樣的推論好像太武斷了，因為B支會收到spoofed封包，只代表B支符合被spoofed條件，而非一定是發生在A支與B支不同的子路徑上。

例如，攻擊條件可能是以來源地區作判別條件，或針對機房中數台分流主機的其中一台作arp spoofed，都會有B支被 spoofed但A支沒事的情況。

另，如果不是man-in-the-middle，則應該會收到大量失效的真封包，包含真正的首頁內容，亦即GET / 後會收到兩個頁面，一個為spoofed host回的，一個為real server回的。但是似乎後者的封包量在測試時出現太少了些。

答：恩，不是這樣子。推論攻擊在TTL=7或以下，是因為TTL=7時，出現IP spoofing，回來的TCP s/n也對，故判定攻擊點一定在TTL=7或以下的route上（請注意我們當初是寫「route」上而非「route"r"」上），這跟另一個route有被攻擊或沒被攻擊，沒有關係。另一個route只是畫出我們實際上的測試環境--兩條route，一條一直有spoofed封包，一條則沒有。這個測試的方法（原本不想講太明，因為攻擊者很容易破解），是我們修改traceroute程式，變成發出不同TTL的HTTP GET封包，而封包跟IE發出的GET封包長得一樣。因為在TTL=6時，不會收到假封包，但是在TTL=7時會，故判斷有攻擊點位於從我到TTL=6的這段route上。不論另一條有沒有被攻擊，都不會影響我們的判定--攻擊的方式是none-blind IP spoofing，而攻擊程式位於離我TTL=7以下的route上。如果如你所說的，攻擊程式在更上方，而利用來源地區選擇攻擊與否，那麼就不會TTL只等於7時，我們就收到了假封包（s/n正確）--因為TTL只等於7，封包不會再往上走。

最後關於您說，「如果不是man-in-the-middle...」這段，簡單回應如下。如果是像zxarps這種把TCP session hijacking實做得很完整，會改TCP seq/ack，那麼網路上幾乎看不到異常的封包，也不會有現在我們看到的spoofed IP packet。那麼如果不是MITM，就一定會有大量的假封包嗎？不一定，看攻擊程式想如何做。一開始，我們看到只有一個封包，並帶FIN把連線中斷。這樣優點是乾淨俐落，比較不會被監控程式發現，但是缺點是，因為沒有含原內容，故使用者很容易發現。

我們來想一想，根據我們收到的封包，確定：1.攻擊者在route中間，2. 攻擊者可以監聽到封包，3. 攻擊者可以發spoofed IP封包到受害者。那麼既然這些都可以做得到，為何不直接使用類似zxarps這種完整的TCP session hijacking呢？因為如果使用zxarps的話，我們在家裡根本不會收到真假封包，這個攻擊就更隱密了。

原因是，zxarps的使用，需要很多環境的配合，譬如要在ethernet上（ARP spoofing只能在ethernet類的網路上用），要有足夠運算能力處理流量並修改TCP的seq/ack等等。如果你對一台路由器做ARP spoofing而自己沒有運算能力處理好所有的封包，那麼你就不是在做TCP session hijacking攻擊而是在做DOS攻擊了--網路會癱瘓。另一方面，很多路由器周邊並沒有接ethernet，ARP spoofing派不上用場。

所以依我們的經驗，在以上三個條件都滿足下，還是有很多攻擊者會選擇用none-blind IP spoofing而不用zxarps這種ARP spoofing+TCP session hijacking，因為後者需更多條件，也因此後者比較常見於使用者端或Web伺服器端，而非route中間。

None-blind IP spoofing被攻擊者喜愛的另一個原因，就是因為他需要的封包少。例如在一開始的案例中，只用一個封包就可以達到轉址的目的了，而不用實做整個複雜的TCP session hijacking。

問：我錄到了ARP spoofing攻擊！這是否代表就是伺服器端有ARP spoofing或甚至ARP掛馬？
答：方便把錄到的流量寄一份給我們嗎？ARP是在layer 2，一般不會跨出vlan，您不太可能錄到伺服器端的ARP封包。如果真的有錄到ARP spoofing，那建議先檢查您vlan內的設備。

問：看這次錄到的封包，假的就只有一個封包，這怎麼會是none-blind spoofing？
答：None-blind spoofing被攻擊者所喜歡的原因，就是因為需要的封包很少。Blind spoofing則需要很多封包。

問：據說TTL可以造假，那你們的實驗有意義嗎？
答：就跟其他的IP封包欄位一樣，在IPv4下，IP封包整個本來就是誰都可以發，欄位怎麼填都可以。但是除非路由器特別被改過，不然每轉送一次會將TTL減去一，所以當TTL=7時就已經有假封包回來，可以讓我們大略知道攻擊程式所在區域。例如這個例子中我們可以知道，這個被我們測到的攻擊程式，不太可能位於Web伺服器附近（Web伺服器附近有沒有其他攻擊程式，不知）。

問：據說TTL不論等於幾，都可以傳到Web伺服器那邊？
答：你聽誰說？:)

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

下一篇系列文章：
2009/03/27 「網路藍色藥丸？首支攻擊路由器之蠕蟲出現：再談路徑之安全性」

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

繼續閱讀全文...

回答IP Spoofing 的問題

最近的大規模轉址事件，由於影響範圍廣大，引起了各方的討論，我們也做了研究與分析。針對這些研究，網友有一些問題與看法，我們在這邊簡單回復。

問1：Non-Blind Spoofing這個攻擊，需要監聽封包並搶在真正封包回應前，傳送惡意封包至client端。這真的有可能嗎？

答1：第一，這是錯誤觀念，non-blind spoofing，尤其是用在HTTP協定上時，並非一定要搶在真封包前，才能達到目的。即使在之後才到達，只要連線還沒有斷，並在sliding window以內到達，要插入iframe還是有可能的。這關係大部分作業系統的TCP/IP實做，這邊不多著墨，但是後來幾天我們已經錄到攻擊者做這方面的嘗試了--如何設計封包，即使在真封包之後到，還是能插入iframe。第二，我們確實錄到的就是這樣，既然已經有錄到的封包，IP spoofing有發生以經是事實（而且還成功達到轉向效果），況且也還有其他網友錄到並放上網路。這是典型的IP spoofing，應該沒有疑問才是。第三，我們也錄到很多spoofed的封包是在真封包到達後才到達的，這次的攻擊並不是每次都能成功。第四，可能您不常見到IP spoofing，或不常處理相關事件，但是我們遇見很多次了，IP spoofing要在route中間達成，並不困難。zxarps有很多很強的技巧，但是並不是有了zxarps才有spoofing，spoofing自90年代至今已經歷史悠久了。我還記得2006年二月時讀Dancho Danchev的blog，他將spoofing的問題嚴重性描述得很好，並從ANA Spoofer Project中拿了一張表來秀，大致上，網路有四分之一是可以被spoof的：

source:Dancho Danchev's blog, taken from ANA Spoofer Project

問2: Non-blind spoofing必須能夠聽到封包。那麼spoofing點會在哪裡呢？有可能是在route中間嗎？在伺服器端使用arp spoofing來監聽封包不是比較容易嗎？
答2：恩，好問題。在伺服器端用arp spoofing來達到監聽封包並發送假封包，比起在路徑中利用入侵路由器或其他網路設備來達成，誰難誰易，要看路徑的網路架構與伺服器端的網路架構而定。這就像是問，ISP/電信業者的資安做得比較好，還是msn.com/cnet.com的資安做得比較好？今天大量民眾被上網被轉址已是事實，問題有可能發生在每個各別的使用者，或中間的線路業者，或網路的設備，或伺服器端的網站farm。這次被轉址的網站都很大，中間的電信業者也都很大，大家都是很專業的公司，我們沒有否定任何一方的專業能力，我們只是就我們所研究出的事實，進行分析。就我們的分析，TTL=7時，就已經有spoof封包，而且每個封包的s/n都很準，故我們推論：1.攻擊程式可以看到封包，2.攻擊程式在路徑TTL=7以內。

問3：某ISP是天天檢查網路的，都沒有發現異常，你覺得有可能中間有spoofing程式嗎？
答3：這次被轉址的都是大型網站，msn.com、cnet.com等等，而ISP也都是很大，很專業的。我們相信不論是網站，或是ISP，一定都是每天檢查網路，我們也很相信這些單位的專業度。然而世界上最高機密的單位/組織，幾乎都曾被入侵過，資安就是這樣，在先天不安全的架構上，與駭客的戰爭是不對等的：防守難而攻擊易（IPv6會好些但是不知等到何時），而在台灣，大規模轉址的事件也還是發生了。既然已經發生了，重點不是討論責任歸屬：有可能是這些網站，也有可能是ISP，也有可能是某個設備，也有可能是使用者本身。但是我們要用科學的方式去研究這個事件，才能在未來避免重複的事件發生。這次沒有大規模轉址到攻擊力強的惡意網址，但是下次呢？難道要等大家都被轉址到惡意網址，被感染了，才來討論誰的責任？為何不事先研究，預防，來減少損失？我們只不過將我們所錄到的，加上我們的經驗，公布出來，並表達我們的看法。這對大家都有幫助。什麼是科學的方式？就是根據事實的研究。根據錄到的封包，IP spoofing發生了，這是事實。

問4：如果是在route中間發生spoofing，流量要mirror到哪裡？
答4：有很多方式，我們自己就有碰過tunnel到第三方的。在大部分的路由器上，設tunnel並不難。其實這樣子的攻擊，以前還蠻常見的。有些網管會把switch/router設mirror到IDS，此時如果該IDS失守，流量也就可以監聽了。如果路由器有與其他設備或電腦在同一個collision domain的話，那就可以利用如ARP spoofing的方式來達到監聽，也就不需要mirror流量。依據架構的不同，有很多不同的可能性。然而在路徑中使用ARP spoofing，對象是路由器，這跟在伺服器端使用ARP，對象是web server並不一樣--對路由器使用arp spoofing比較難（不造成混亂比較難）。

問5：你們這次有依循responsible disclosure嗎？
答5：有的，在公開前，我們已經用電話與網路與相關單位聯絡，並有討論如何公開。另外，responsible disclosure一般是針對對於弱點的揭露，尤其針對0day的揭露。Responsible disclosure遠在沒有網路時，在鎖匠的社群中就廣為被討論了，現在大家也有了很明確的共識。揭露弱點需要依循負責的揭露程序，因為一旦弱點揭露後，會讓更多惡意人士了解此弱點並加以利用，造成更大的損失。但是我們今天談論的是一個事件，非一個弱點。這就像大砲開講Roger會討論某某網站被植入惡意程式一樣。大家是否注意到，Roger從不針對某某網站如何被掛馬進行討論？因為這就變成是討論弱點而非事件了。事件已經發生，我們可以就事實討論。針對此大規模轉址事件，我們是很後期才加入討論與研究的，之前已經很多網友與專家發表看法，並錄下封包公布。針對此事件，大家都在討論，到底是msn/cnet網站出問題？還是ISP出問題？還是設備商？這是一個選擇題，但是我們也沒有直接選了答案。我們覺得，至少我們自己的監控中，大規模轉址時並沒有轉到具有高度攻擊性惡意程式的網址（小規模測試時則有，前一篇有說），故此事件除了造成大家不便與猜測外，並未有太大實質的損失（想一想如果轉址的網站是具有高攻擊性的惡意程式或甚至0day，現在會是什麼局面？）。重點應該是討論出事件的手法，把時間花在找出問題，避免往後更大的損失才是。另外，如果問此問題者本身過去有不負責的揭露0day，或甚至販賣0day獲利的話，這個道德性的問題，應該自己多想想，不是來問我們。

問6：那這次到底是non-blind IP spoofing還是ARP spoofing還是ARP掛馬？
答6：依據錄到的封包，確定有non-blind IP spoofing。至於是否伴隨ARP spoofing，沒有直接證據，故我們沒有說有，但也沒有說一定沒有。non-blind IP spoofing是錄到的事實，故我們會說一定有。Non-blind IP spoofing需要能監聽流量，其中ARP spoofing是可以達到監聽流量的方式之一，但不是唯一方式，且在路徑中使用困難度高。ARP掛馬的定義則還沒有那麼嚴謹。我們只能說，依據封包的特性分析，這次並不太像是大家手上的zxarps這個工具所發出的封包。另一方面，如果能夠ARP spoofing，攻擊會漂亮得多，因為可以直接man-in-the-middle，可以直接竄改封包，植入想植入的東西（例如iframe），不會有真假封包之分，也不會需要搶先真封包來提高成功的機率，我們在偵測與研究上也會更困難。可是這次的攻擊，就我們錄到的內容，很明顯的，攻擊程式無法直接man-in-the-middle修改封包，才會試了很多麻煩又不漂亮的技巧。這些上一篇都有提了這邊就不重複贅述了。（見上篇圖五--多麼辛苦的iframe插入方式啊！）

問7：這一兩年大陸的駭客充分探討研究了ARP掛馬，工具也成熟，有很多資料可以參考，是最有可能的方式，為何你不認同？
答7：我們當然了解這兩年ARP spoofing或ARP掛馬，在大陸很流行，工具也很成熟。但我們並沒有假設攻擊者一定來自大陸！另一方面，IP spoofing是從90年代就很常被用的手法，太多人會了，也太多很成熟工具了，ARP spoofing亦然，這些都不是這一兩年的知識。我們做研究，看得是事實，這次看到的，攻擊者沒有辦法竄改封包，沒有辦法避免真封包的到達，甚至沒有辦法避免假的封包比真的慢到達，所以對方試了很多種方式。如果能夠用ARP掛馬，這些都可免了--可是事實並不是這樣。我們在講的並非什麼最有可能，不是說ARP掛馬很流行就最有可能，我們是探討我們錄到的事實，我們做研究一向如此。

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

下一篇系列文章：
2009/03/15 「從大規模轉址事件看IP spoofing、ARP spoofing、ARP掛馬與路徑(route)安全」

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

繼續閱讀全文...

大規模網頁綁架轉址之水落石出篇

山高月小，水落石出、清風徐來，水波不興！

最近的大規模轉址事件，由於影響範圍廣大，引起了各方的討論，o0o.nu的fyodor yarochkin（聯絡方式：fygrave 鼠 o0o 點 nu）與阿碼科技的Wayne，之前針對此事鍵做了一些研究，並在前一篇post「大規模網頁綁架轉址：威脅未解除，但專家都猜錯了」中，依據我們錄到的封包，詳述了我們對事件的看法。我們不覺得此事與DNS有關係，也沒有證據顯示此次與zxarps工具的ARP掛馬手法有關。從我們錄到的封包來看，這是典型的，從90年代一直用到現在的IP spoofing。

這兩天，經過一些研究與測試，我們可以在route上準確的指出攻擊程式的所在位子，昨天也已經充分通知相關單位，今天在這裡把結果與各位分享，另外也謝謝Peter Yen與其他朋友提供的寶貴資訊。

最近攻擊有轉緩的趨勢，大部分大型網站的流量已經不再被轉址，但是我們這幾天觀察下來，一直到昨天（今天尚未測試），攻擊程式都還存在，只是不再針對大型網站spoofing，而針對某些特定網站做spoofing，並且不斷更改行為，故我們認為對方正在做許多測試與校調，試圖盡量讓spoofed封包看起來與正常流量類似，以便下次發動攻擊。我們的測試方法是利用一個小程式發送TCP封包，封包裡是HTTP GET request，而再透過TTL的設計，就可以知道當封包經過哪一個節點時，有spoofed IP packet發送回來。當然我們這種測試方法是可以被偵測到的，所以現在公開之後，預計也將增加往後類似測試的困難度。

[攻擊所在位置]
我們從兩個端點進行測試，其中一個端點A是會被攻擊的，而另一個端點B是不會被攻擊的。這兩個端點的匯集處是211.22.33.225這個路由器，而我們同時在兩端點跑測試程式，對目前仍會遭受攻擊的網域送GET封包。測試結果，端點B不會收到spoofed封包，而端點A則每當封包經過第六個節點210.65.255.241（也就是連到211.22.33.225的前一個節點）時，我們就會收到spoofed封包。我們因此可以肯定，在210.65.255.241這個分支中，有攻擊程式。由於資源有限，我們只測試了A與B兩個分支。


（圖一）

（圖二）

[攻擊手法改變]
在我們貼出了「大規模網頁綁架轉址：威脅未解除，但專家都猜錯了」一篇後，立刻觀察到對方在攻擊手法上不斷調整，我們做紀錄於下：

1. id已經不像之前我們觀察到的，固定在0x0100，開始隨機了。其實我們之前沒有明講，但是相信許多網管人員一看到我們的post，就了解到了，裡頭的資訊可以直接用來設定IDS/IPS/Firewall，有效阻擋攻擊吧？像是id固定是0x0100、或FIN與payload同時存在等，可惜我們每次一公開，對方也會跟著改變。下圖錄於三月11日10:30am，第五個封包是spoofed，第六個是正牌的封包：

（圖三）
2. 已經不再是一個封包完成攻擊了。一個封包同時設FIN與帶payload，是很大的特徵，很容易被IDS/IPS/firewall抓到，故這幾天錄到的流量中，對方不斷改變方式，已經不再採此手法了。但是也並不是一次發兩個封包，一個payload一個FIN，而是還是只發一個，而讓正牌的FIN來結束連線。這樣的作法，每個攻擊仍然只有一個spoofed封包（payload），比較俐落，但是由於沒有立刻結束連線（不帶FIN），故根據各作業系統TCP/IP stack實做之不同，可能造成假封包與正封包內容被系統合而為一，因此payload需要特別設計，以免轉址失敗而瀏覽器出現亂碼。我們測試時，對方正不斷調整payload的設計。上圖中，第五個封包的FIN沒有設了，第六個是正牌repy，第七個則是正牌網站送出的FIN。

3. 開始轉向確定有惡意程式的網址。之前雖然轉址網域過去都有許多不良紀錄，但是就這次攻擊事件的範圍，之前沒有看到確實具有攻擊力的惡意程式存在於這些網址中。然而如上圖又下方所示，最新的攻擊中，所轉址的其中一個網址：hxxp://61.218.245.190/_vti_access/index.htm，確定含有四支具有攻擊性，可觸發之攻擊程式（以下為免費網站惡意程式監控服務HackAlert畫面）：

（圖四）
4. 開始想辦法隱藏攻擊。見下圖，錄於三月11日10:30am。下圖中，第51封包是spoofed，我們看右下角的payload，這會讓瀏覽器載入一個隱形的iframe（目前是google），而過了四秒後，瀏覽器會reload。由於沒有轉向，這會讓受害者只覺得等了比較久，但是正確網頁最後還是會載入，故不容易發現蹊蹺，而到時候把iframe改成指向惡意網頁而非google，這四秒足夠惡意程式攻擊受害者電腦成功，植入木馬了。

（圖五）
5. 同一個被感染的網段，可能有不只一個的攻擊程式。圖五中，第51封包是spoofed，id=0x0100，ttl=115，payload是隱藏的google iframe，並在四秒後重新載入原網站的內容。第54個封包也是spoofed，id=0xccbb，ttl=113，內容是直接轉向到惡意網址。正牌的回應封包則是第56與58。這很可能是兩組不同人馬所植入之不同攻擊程式，也有可能是同一組人在測試不同版本時忘記把其中一個版本關閉。

（圖六）
6. 攻擊之工具是否是zxarps的改版延伸？這我們一開始就測試過了，然zarpx可實際做man-in-the-middle竄改封包而這次並沒有，另外封包特徵差異非常大（ttl/id/service filed/行為等），故我們覺得應該使用了其他的攻擊程式。

[結論]
針對我們錄到的資料，我們可以做出以下結論：
1. 至少可以測出攻擊程式仍位於210.65.255.241這個節點。另外可以確定並非網站本身受感染。
2. 對方目前不斷測試不同攻擊方式並使得此攻擊完美化，明顯為下一波攻擊鋪路。
3. 在初次很粗糙的測試中，對方可以造成大量轉址，但行為明顯，使用者很容易察覺。在新一波觀察到的手法中，對方一直致力調整成使用者無法察覺之方式。
4. 對方針對我們公布的特徵進行改良，欲使IDS/IPS/firewall無法輕易認出假造的封包。
5. 在小量的測試中，已經含有具有攻擊性並能攻擊成功的惡意網頁。
6. 由於是基礎架構問題，一般使用者無能為力，只能盡量使用https，等待基礎架構修復。
7. 有問題的網段可以檢查路由器與路由器相通的他機器是否遭侵入或竄改設定。

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

下一篇系列文章：
2009/03/13 「回答IP Spoofing 的問題」

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

繼續閱讀全文...

大規模網頁綁架轉址：威脅未解除，但專家都猜錯了

（續集見：「大規模網頁綁架轉址之水落石出篇」
）

從三月初開始，網路上陸續有消息，連往tw.msn.com、taiwan.cnet.com等網站時，會被自動轉址到www.dachengkeji.com。一開始心裡想，大概又有誰的DNS沒有上patch吧，要不然就是又有DNS 0-day或又有人玩BGP了。過了幾天，威脅還是沒有解除，媒體也都紛紛報導了：

神秘網頁轉址事件 疑為新型態攻擊手法，ZDNet 2009/03/05
DNS遭攻陷，多家知名網站慘被攔截轉址，網路資訊 2009/03/05
[教學]遭遇不明網路劫持該如何自救？網路資訊 2009/03/07
追蹤：轉址攻擊仍持續且惡意碼手法日趨成熟，網路資訊 2009/03/08
微軟MSN首頁遭轉址　疑上層DNS被入侵，IThome 2009/03/06

恩，這麼多的專家都說是DNS被綁架了，跟我的直覺一樣...我那時這麼想。

三月七日中午，我用一台電腦上網，剛好這台的IE首頁沒有改，設的是MSN，結果一開就真的被綁架到dachengkeji了。這個dachengkeji.com，真是厲害，我心裡想，過了這麼多天，威脅都還沒解除。就在這個時候，o0o.nu的fyodor yarochkin（聯絡方式：fygrave 鼠 o0o 點 nu）從MSN上傳訊息來，跟我說最近號稱「DNS綁架」造成網頁轉址的事件，根本跟DNS無關，引起了我的好奇，於是我用WireShark看了一下封包，赫然發現這絕對不是一般的DNS綁架，駭客所有的手法犀利，影響的範圍應該非常大！我在這邊將fyodor與我的研究與各位分享，希望各位如果有想法，也可以讓我們知道。

這一個攻擊利用了兩個技巧：

(1) None-blind spoofing，而這也表示攻擊程式位於從受害者到受害網站之間的路徑上，可以監聽流量。

(2) 有些 TCP/IP stack 在實做上的缺失（bug），目前測試結果微軟的系統有此缺失，但是預計還有其他作業系統會有此缺失。

我用我借WireShark錄下來的封包來解釋這個攻擊手法，當時我正試圖連往http://www.gogrok.com（因為網友說這個網站也會被鎖定轉址）。我當時的IP是192.168.1.129，而gogrok的是202.157.128.202。
以下我們看frame 15--我的機器對gorok送SYN。




Frame 16中，對方送SYN/ACK，注意對方的TTL是56。



Frame 17，我送ACK，three way handshake完成，連線成功。Frame 18，我送http request，request（get）不會特別長，所以都在一個封包裡。注意TCP s/n=752：



Frame 19，對方回應，s/n是對的（752），可是id=0x0100，太巧了吧？TTL也突然變成=115。重點是這個封包設了FIN，另外http response內容--meta refresh轉向。FIN表示對方要中斷連線，而meta refresh則會導致我的瀏覽器轉向到www.zhonglie.org。這個這個封包其實沒有符合RFC 793：SYN/FIN封包不能帶其他payload；所有的payload應該在three way handshake完，FIN之前交換。



Frame 20-21，我方確定中斷連線。Frame 23是正牌網站送來的ACK，s/n是對的（752），TTL也是56，id=0x2087不是0x0100。但是比較晚到，我機器已經認為此連線中斷了，瀏覽器也被轉向了。



這個攻擊的特色是，第一，有正確的s/n號碼，表示攻擊程式位於route上，可以看到封包。第二，利用了有些作業系統（例如微軟）在TCP/IP stack實做上的缺失，使得整個攻擊，一個封包就搞定，乾淨俐落。

很多網友都有在網路上討論：
「連tw.msn.com就被導向http://www.dachengkeji.com/article/index.htm」
「連MSN首頁會轉址到www.dachengkeji.com/article/index.htm」
「進入 iThome Blog網址自動跳轉廣告網址」
「[求助] 連tw.msn.com就被導向http://www.dachengkeji.com/article/index.htm 」
「有辦法檢查本站是否 DNS 有被駭嗎？」（此網域本身被鎖定，點選要小心！）
「tw.msn.com被攻陷了嗎？」
「胡亂轉址」
「封鎖惱人的"www.dachengkeji.com"大乘科技」
「網站新聞 : 關於tw.msn.com被導向到dachengkeji網站的反應已經漫延到我們客戶了」
「[重要]連MSN首頁會轉址到www.dachengkeji.com/article/index.htm」
「[求教] 台服官方网站是不是被别人内链了，看图说话」
「電腦警報:非中毒的網頁自動轉址(3/10更新)」
「連tw.msn.com就被導向http://www.dachengkeji.com/article/index.htm」
網頁劫持

這些討論與報導，但部分訪問專家說的，都不正確。這次的攻擊跟DNS沒有任何關係。另外，目前為止，威脅並沒有結束或降低！三月七日兩點到三點，我用那時的電腦做了些測試，發現每一次我連tw.msn.com都被轉向。但是下午約四點開始，突然不轉向了，我想大概威脅解除了，被感染的路由器修好了。可是三月八日中午，我發現威脅依然存在，但是對於每一個被鎖定轉向的網址，都只轉一次！也就是說，假設你在家裡，那麼只有在你第一次連往被鎖定之網站時，會被轉址，第二次就完全不會了。這是為何我錄的是gogrok.com而非tw.msn.com，因為轉了一次以後就不轉了。我試了很多被鎖定的網址，都是一樣，只有第一次會轉。

網路上判斷比較接近我們的，有Blue在資安之眼所貼的「關於這兩天的轉址攻擊事件」，還有richliu所blog的「某些 ISP 疑似被 hijacking攻擊」。另外，在mobile01上，powerpcer有貼出他的pcap dump，我們看過手法跟我們錄的是一樣的。

Cisco也在三月六號貼出了alert:
CISCO:TCP Traffic on Chinese Networks Redirected to Malicious Websites

我們在這邊整理整個事件相關資料，如果有網友有可以補充的，歡迎留言或email（wayne鼠armorize點com）提供我們！

[攻擊技巧]
(1) None-blind spoofing，而這也表示攻擊程式位於從受害者到受害網站之間的路徑上，可以監聽流量。
(2) 有些 TCP/IP stack 在實做上的缺失（bug），目前測試結果微軟的系統有此缺失，但是預計還有其他作業系統會有此缺失。

[攻擊特色]
(1) 攻擊程式位於route中，很可能在backbone上，故影響範圍廣大。
(2) 一個封包就可以攔截session。
(3) 改版後，一個網址只會轉址一次，造成追蹤困難。
(4) 手法並非目前很多專家說的「DNS感染」。

[遭鎖定轉址的網域]
根據網友的回報，目前已知遭鎖定轉址的網域有：
tw.msn.com （我們自己有測試成功）
www.msn.com.tw
www.gogrok.com （我們自己有測試成功）
taiwan.cnet.com （我們自己有測試成功）
www.orzteam.com
www.92an.com
www.wowtaiwan.com.tw
www.ioage.com
www.ithome.com.tw

[轉址到的網域]
轉址到的網域有：
www.dachengkeji.com
www.zhonglie.org
www.yyge.com
www.ganji.com

[pcap封包下載]
我們有msn.com、cnet.com以及gogrok等三份被spoof時錄下來的封包，可以聯絡我們索取（wayne鼠armorize點com）。

[如何防護]
由於為路徑中有節點遭控制，使用者不容易自保，建議利用https而非http連結網站(如果網站有提供https的話)。如果擔心機器已經因為被轉向而遭受攻擊，被植入惡意程式，可以來信索取阿碼科技的免費Archon Scanner：info鼠armorize點com。

[資安廠商alert]
CISCO:TCP Traffic on Chinese Networks Redirected to Malicious Websites

[相關新聞]
1. 神秘網頁轉址事件 疑為新型態攻擊手法，ZDNet 2009/03/05
2. DNS遭攻陷，多家知名網站慘被攔截轉址，網路資訊 2009/03/05
[教學]遭遇不明網路劫持該如何自救？網路資訊 2009/03/07
追蹤：轉址攻擊仍持續且惡意碼手法日趨成熟，網路資訊 2009/03/08
微軟MSN首頁遭轉址　疑上層DNS被入侵，IThome 2009/03/06

[相關網路討論]
「連tw.msn.com就被導向http://www.dachengkeji.com/article/index.htm」
「連MSN首頁會轉址到www.dachengkeji.com/article/index.htm」
「進入 iThome Blog網址自動跳轉廣告網址」
「[求助] 連tw.msn.com就被導向http://www.dachengkeji.com/article/index.htm 」
「有辦法檢查本站是否 DNS 有被駭嗎？」（此網域本身被鎖定，點選要小心！）
「tw.msn.com被攻陷了嗎？」
「胡亂轉址」
「封鎖惱人的"www.dachengkeji.com"大乘科技」
「網站新聞 : 關於tw.msn.com被導向到dachengkeji網站的反應已經漫延到我們客戶了」
「[重要]連MSN首頁會轉址到www.dachengkeji.com/article/index.htm」
「[求教] 台服官方网站是不是被别人内链了，看图说话」
「電腦警報:非中毒的網頁自動轉址(3/10更新)」
「連tw.msn.com就被導向http://www.dachengkeji.com/article/index.htm」
網頁劫持

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

下一篇系列文章：
2009/03/12 「大規模網頁綁架轉址之水落石出篇」

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


繼續閱讀全文...

破解點閱綁架手法(Crack Clickjacking)

看完「模擬實戰點閱綁架手法」一文，是否有心得感想呢？沒...挖勒！！

這裡寫些我的心得囉。既然整個「點閱綁架(Clickjacking)」的關鍵在"點選(Click)"動作，如果要靠防護設備或工具，可以選擇如 NoScript 或 WRS ...等，來提升瀏覽環境的安全性，但是都有萬一擋不住的問題，靠別人實在不可靠的。

所以在這裡提供靠自己的解決方案：
1.善用「複製連結」方式
　別忘了滑鼠的右鍵(對慣用右手的人)，如後面數個瀏覽器的附圖可參考。然後貼到瀏覽器的網址列上，這樣還可以檢查及確定要連往的網站。
2.還有「標記(Mark)->複製(Copy)->貼上(Paste)」一式
與前項有異曲同工之妙。
總之，「關鍵時刻」讓食指離滑鼠左鍵遠一點。






也許有人說這樣瀏覽網站會很累人。的確，我不否認。我也絕對不會這樣幹的。
方便與安全總是在天秤的兩端，但也不能因噎廢食，所以這也取決你身處風險，來決定使否該使出絕招的。當發現身處危險環境時，該如何自處？該有何因應呢？至少，在不可信任的網頁或環境(IM or E-Mail...)中，該用這招的。

另外，值得一提的是：對付釣魚手法的觀念與技巧
1.若「我的最愛」中有的連結網址，決不使用其他超連結。
如果「我的最愛」中的連結網址有釣魚網站，這我就不知該說啥了...XD。常見的郵件或網站中連結、IM 送來的連結...等，都是常見會被利用的釣魚網站連結，所以都要特別注意。
2.若是連結不熟悉的網站，一定要選用防護強化的瀏覽環境
你一定要有安全的瀏覽環境，例如 Firefox 3 + NoScript 是個不錯的選擇，當然還有其他強化瀏覽安全的軟體或元件，這是你上網的一個課題，一定得去了解的，透過了解的過程也能熟悉威脅所在。
3.輸入帳密前要先想一想
無論何時，要在網站上輸入帳密時，都要想想是否被騙了？是否連上釣魚網站？很多地方在騙帳密資料的，可以參考這裡，還有這裡。
4.騙術終究是騙術
畢竟騙術中一定有它的梗、釣魚得有它的餌，前面一定都會有很多鋪陳，看多了自然能識破，所以要強化個人敏感度。如果上當了，第一線交由防護設備查覺，對於防禦工事的任何警訊都要加以注意的。第二線也是最後的個人警覺性了，看是否能在最後踩住剎車或進行應變處理。
5.事後補救措施
總是有上當的時候，我也曾經上當的，常常都是因為心急、貪快，現在就知道「戒急用忍」，你呢？你的原因是啥？你一定得去分析、了解，才能知道弱點在哪。所以，查覺上當之後，當然要有因應措施，例如進行密碼變更、系統檢查...等。

現在有很多「虛擬機器」如 VMWare、VirtualPC...等，或許在虛擬環境中上網或進行一般操作，不失為一選擇，即使出問題也可以即時復原，當然在虛擬環境中也應該與重要資料做切割，必要時進行帳密修正，達到一定的安全性。

繼續閱讀全文...

模擬實戰點閱綁架手法(Challenge to Clickjacking)

啥是點閱綁架(Clickjacking)呢？
用講的太慢啦...直接來親身體驗最快。
這裡有我們實作的體驗網站 （IE 已經可被利用）。畫面如下：


實戰點閱綁架，這網頁並無惡意攻擊，只是導向到另外一個 Blog 網頁，請放心。主要在於讓大家了解何謂「點閱綁架(Clickjacking)」，將滑鼠移到超連結處，檢查左下角落的連結網址，發現哪有不一樣嗎？明明是應該要連結到 google 網站的不是嗎？你連到哪了呢？目前已知可以成功的瀏覽器：
1.Firefox 3.0.5
2.Chrome 1.0.154.43
3.Safari 3.2.1 (for windows)
4.IE 7.0.6001

手法剖析：
1.如果瀏覽器有問題(上述瀏覽器)，該連結將不會連結至 google 網站，而是其他網站。
2.如果正常連結至 google 網站，表示不受影響。
3.有心人士可以利用此手法將惡意連結夾帶其中，偽裝成銀行或一般正常連結(URL)。

之前還有一篇文「模擬實戰釣魚網站」，都是希望大家能有些防禦觀念，了解攻擊、詐騙手法，自然就會多一分小心的。

本文同步張貼於「資安之我見」。

繼續閱讀全文...

阿碼團隊跟各位拜年，祝各位牛年大吉、牛運亨通！（另含2008年阿碼大事記）

今年是牛年，對阿碼來說，會是很好的一年，因為牛代表了台灣人努力耕耘的那股勤勞，那股韌性，那股一步一腳印的踏實，那股辛勞耕耘後，牛背飄來一陣涼風都是無比的快樂，很符合阿碼的文化，所以今年，會是阿碼的好年。

去年對阿碼來說，是指標性的一年，也是我們蓄勢待發的一年。回首去年，我們心中除了感謝，還是感謝，感謝產業、學術、政府各界的長官與前輩，給我們在各方面的支持與鼓勵，讓我們這麼一個年輕的團隊，能夠順利地突破許多難關，乘風破浪，創出了連我們自己也驚訝的成績。

我們的 R&D 全部都在台灣，連所有的外籍同事，領的也是台灣的薪水，付的是台灣的稅，看的是台灣的健保。可是台灣的軟體業並不像硬體業那麼發達，台灣的軟體公司，能夠做出產品，在國際上有好成績的，屈指可數。三年前公司成立時，雖然投資人不常提，但是我們知道他們都暗自憂心著，這樣一個高科技的軟體公司，是否真的能在台灣生根？這樣一個年輕的團隊，是否真的能做出成績？是否能支援全系列的 Web 語言？做出的產品，使否真的能讓美國、歐洲、印度、日本的大客戶買單？

去年九月，碰上了百年難見的金融危機，那時我們剛好去紐約參加 OWASP 美國年會，直接感受到了紐約的人心惶惶，我們也不禁憂心，我們的募資是否會受到影響？市場是否會突然萎縮？但是就是這個金融風暴，讓我看到了阿碼的團結與韌性。我想當時大家不說，但是心裡一定緊張，但是沒有人退縮，沒有人埋怨，大家只是更團結，拼了命的往前衝。業務團隊說，可能金融與製造業會受影響，但是沒有關係，我們會拼命從其他地方做業績來補。R&D 說，我們再想辦法讓 SDL 變得更 agile，一定即時滿足客戶的需求，只要客戶還有需求，還有預算，我們就能滿足他們。

就這樣到了年底，一方面我們產品目標：PHP、ASP、J2EE(Java)、.NET(ASP.NET、VB.NET、C#)等支援全部達成，一方面我們業務也竟然超過 forcast，在惡劣的環境中逆勢成長，不只投資人驚訝，說實在我們自己也很驚訝。今年放年假前，我們一算，光一月的業績，就達成了今年第一季 forcast 的九成！這麼好的成績，一方面感謝每一位阿碼同事的努力，一方面感謝台灣與全球行銷伙伴對我們的支持與信心，然後最重要的，就是我們的客戶--我們很榮幸成為各位選擇的 Web 資安廠商，各位對阿碼的支持，讓我們有用不完的精力，我們一定會更加努力，不論在我們的服務、產品的改進或技術的研發上，我們會精益求精，不斷努力，也會珍惜各位給我們的寶貴意見，讓阿碼一天比一天更好！

去年的尾牙上，團隊成員接二連三的上台說了你們的感想，讓我很欣慰，阿碼真的建立了非常不一樣，非常優良的文化，每一個人都這麼在意自己的進步，自己的學習，自己在團隊中的貢獻。很多同事過年前打電話跟我再三的說，真的很高興有機會加入阿碼，阿碼的文化真的很好，這幾年下來學了好多。我聽了當然也很高興，我能說的尾牙上都說了，對我來說，很榮幸能夠跟各位共事，阿碼是大家共同建立起來的，我很高興，也很榮幸我是其中的一份子，跟各位工作，真的非常愉快，也從各位身上，學了很多，真的很謝謝各位。

阿碼準備了很久，從 2001 年我在中研院跟 Walter 開始研究黑箱技術 WAVES，到 2002 年 Chris 從德國加入，到後來我們一起投論文... 到後來 Matt 加入，我們募資，在董事長沙正治先生的領軍下我們成立了公司，後來 R&D 的各位加入，為我們的產品開發注入了能量。去年，產品日趨成熟，Jordan 率領的老外國際業務團隊日有斬獲，在各國都拿下了指標性的客戶，也一步一步把經銷代理伙伴訓練了起來。實力堅強的 X-Solve 團隊的加入，為我們帶來了新的產品線：HackAlert，也為我們帶來了專業的業務團隊。多位資安界的資深朋友的加入，讓我們得以成立了 ASF (Armorize Special Forces) 資安團隊。國內資深的業務前輩，Vincent、Sunrise、Eric 等人願意放棄原本的好工作，加入阿碼跟我們一起打拼，帶來了他們寶貴的經驗，讓我們更有信心，我們一定能提供好的服務給客戶，把支持我們的客戶照顧好。在這邊我也特別感謝阿碼的另外三位創辦人--技術長 Walter、研發總監 Chris、營運長兼財務長 Matt。Walter 還在唸書時就跟我一起做研究寫論文了，是整個團隊跟我最久的一位，能力非常好，但是一路上配合我，在後面當我隱形的伙伴，讓我在前面衝，自己則在後面支援。Chris 是德國人，願意為了阿碼放棄微軟的好工作，不但搬來台北，也把好朋友一起從歐洲挖過來，離鄉背井，幫我們帶著 R&D 打拼；新年期間，看到他們都在線上，知道他們沒地方去，心裡很過意不去。Matt 是我弟弟，能力不比我差，擁有 Stanford 企管系的MBA，待過麥肯錫顧問公司，擁有各種的好履歷，但是一樣，總是站在我後面，給我一切的支援，這次金融風暴，Matt一個人胸膛一挺，一面扛起整個募資的責任，一面繼續擔任營運長，打點公司大小事物與跑國外的大客戶，沒有一點怨言。三位，我想如果沒有來阿碼，三位現在成就可能都超過我，但是每當掌聲響起，我從沒有忘記三位為阿碼的犧牲；其實我從沒忘記阿碼任何一位同事的努力，阿碼是大家一起做出來的，謝謝你們，謝謝大家！

年後將有更多新同事加入阿碼，去年是阿碼蓄勢待發的一年--經過了這麼多年的努力，今年我們將要起飛，我們會讓世界看到，在 Web 資安界，台灣有頂尖的技術能量，有來自各國的菁英團隊，台灣不是只有硬體製造代工業，我們能夠做出符合潮流的的頂尖軟體技術，我們有自己的品牌，我們有一流的軟體人才，我們有國際化的行銷團隊。

最後我們要感謝阿碼的個人與法人投資人，特別是董事長沙正治先生。當初我們一無所有，只有幾篇得獎的論文，是你們給了我們機會，並一路給我們建議、輔導與幫助，我們才能有今天的成績。在金融風暴周遭公司裁員倒閉的情況下，你們繼續支持我們，並以實質股價的成長來肯定我們的成果，給了整個團隊無比的信心，今年我們氣勢如虹，我們一定做出好成績，對於支持我們的投資人，各界前輩，經銷伙伴，還有我們的客戶，我們不會讓各位失望的！我們希望成長，但是我們不想做搶錢的公司，我們想一步一腳印做出我們的成績來，做出我們的價值給客戶，並賺取我們該得的。我們去年不就是這個精神嗎？結果證明我們業績超乎預期的成長。現在資訊發達，客戶都很聰明，懷有僥倖想法的業務團隊，很快會被客戶唾棄。我們慶祝去年的好成績，但是我們絕對不會因此而驕傲，是否是台灣第一，亞洲第一，並不重要，重要的是我們每個人都會虛心學習，不斷提升。我深切體會過自視第一的同行的那種傲氣，那種把同業當笨蛋，把客戶當凱子的不成熟的文化，阿碼絕對不容許有那種文化。我們的策略很簡單，就是我在尾牙上說的，我們很清楚，我們必須謹守我們最有價值的兩項：技術與服務，我們的研發團隊會馬不停蹄地提昇技術與產品的功能，ASF 資安團隊會不斷研究、分析新的攻擊趨勢，充分掌握新的威脅與各種解決方法，業務團隊會無時無刻想著我們還能如何為客戶提供更好的服務，更低的價錢，與更節省成本的產品。技術與服務是阿碼這個年輕團隊僅有的，我們很清楚，我們會盡一切努力提升。謝謝大家一直以來對我們的支持，也希望大家能繼續支持我們，給我們意見，讓阿碼能夠陪伴各位一起耕耘，一起前進！

阿碼全體在這邊跟各位拜年，祝各位新年快樂，牛年大吉，翠柳迎春千里綠，黃牛耕地萬山金！

黃耀文 代表阿碼科技團隊 敬賀

阿碼去年大事記：

1. 完成 CodeSecure 源碼檢測系統於 J2EE 語言支援，ASP支援與全 .NET 系列語言支援（ASP.NET、VB.NET、C#）


2. 推出能與源碼檢測整合之 SmartWAF Web 防火牆


3. 完成 HackAlert 產品開發，並推出含網頁爬行與竄改監控等功能之企業版


4. 獲選新創公司最大獎，Red Herring Global 2008 Innovator's Pit，並於西雅圖發表演講


5. 獲選道瓊 Dow Jones VentureWire 2008 Technology Showcase 技術大展，並於 Redwood City 發表演講


6. 於全球贏得超過五十個指標性大客戶，包含：
   
   
   
   • PriceGrabber（美），全球最大比價網站
   
   
   • MyYearBook（美），全球前三大社群網站
   
   
   • GMO（日），日本最大上市之 hosting 集團
   
   
   • HDB（新），東南亞在資安界最具指標性之客戶
   
   
   • POSCO（韓），韓國最大鋼鐵集團
   
   
   • Innotronic（德），歐洲領先之 ISP
   
   
   • Bank of India（印），印度最大公有銀行
   
   
   • 台灣大哥大，台灣電信業重要指標客戶
   
   


7. 在全球挑選並訓練起超過十家之專業 Web 資安經銷伙伴


8. 參展世貿資安展（台北）、OWASP US（紐約）、OWASP Asia（台北），OWASP India（印度），RSA Conference（美國）


9. 與 COSEINC 共同舉辦 SySCAN Taipei


10. 被 Forrester 與 Aberdeen 等重要分析集團報導為重要 Web 資安廠商

（台灣世貿資安展 2008）

（美國 RSA 2008）

（美國 OWASP AppSec US 2008）

（台灣 SySCAN 2008）

（印度 OWASP AppSec India 2008）

繼續閱讀全文...

雅虎搜尋引擎遭掛馬利用

平常用 Yahoo 搜尋引擎的人要特別注意了。搜尋結果會出現帶有 XSS 攻擊的連結，若是連結目標網站存在 XSS 漏洞，會導致網頁掛馬的攻擊手法，瀏覽者的瀏覽器軟體會遭受攻擊，系統有被植入惡意程式的風險。這可能是網頁掛馬手法的翻新利用，或者是 Mass SQL Injection 攻擊的後遺症。該惡意連結與先前<駭客集團於新年假期展開罕見之大規模SQL Injection攻擊>一文的惡意連結相同。
下圖可以看到"84."的搜尋連結明顯夾帶異常字串。


詳細分析"36."的搜尋連結：


直接搜尋"inurl:daxia123"，可以找到很多有問題的連結：

可以看到很多搜尋連結夾帶攻擊碼，如果點選連結，配合 XSS 漏洞，會導致瀏覽者遭受攻擊。

直接搜尋"inurl:jxmmtv"的連結也是：

手法跟 daxia123 幾乎是一樣的，當然，因為是一夥的。

研判可能原因有兩個：
1.大量掛馬的網頁，造成雅虎搜尋引擎抓到網頁連結時，就是已經被掛馬的連結，導致搜尋連結帶有惡意網址。
2.有人大量餵給雅虎搜尋引擎掛馬連結，導致搜尋結果的連結，帶有惡意網址。

先前 google 也有遭利用，被用來進行掛馬攻擊，可以參考鳥毅-<Googlt Bot會找漏洞>一文。

繼續閱讀全文...

SmartWAF v3 的釋出與新功能介紹

產品前進的腳步是不停歇的，三個月前還在 SmartWAF v2.5 的階段，轉眼間 SmartWAF 已經釋出第3版啦！

如果說 SmartWAF v2.5 是 SmartWAF 2 的強化版，不如說是 SmartWAF v3 的嘗鮮版。 SmartWAF v3 可以說是總合 SmartWAF v2 時代許多客戶的需求以及 SmartWAF v2.5 上的一些實驗性新功能，所推出來的新版本。 SmartWAF v3 整體介面風格並沒有多少改變(預計3.5版會改頭換面)，但是有幾項主要改變與新增功能特色：

1.集中更新派送
其實 SmartWAF 的更新已經很簡單了，有安裝過的人都知道，只是 Web Server 一多，一台台連進去更新總是不夠方便。集中更新派送的功能主要提供給大量使用 SmartWAF 的客戶，透過管理介面就可以遠端更新各台 Web Server 上的 SmartWAF ，就像是企業防毒軟體的中控台一樣，這樣一來，無需一台一台 Web Server 遠端登入然後手動進行更新，版本更新也變得更加方便，另外也可以遠端停止 SmartWAF 運行或是重新啟動。
之前總是會有人會把 SmartWAF 與免費產品拿來比較，這個功能應該在免費的 WAF 產品上找不到吧。

2.支援多處理器
支援多處理器是 SmartWAF3 的一個重要里程碑。過去 SmartWAF 啟動時會同時生出多個 process ，但是並不支援多處理器模式，在多處理器環境下只能為每個 process 分配處理器來利用 CPU 資源。現在 SmartWAF v3 已經支援多處理器模式，甚至還可以指定要使用幾個處理器，一些比較繁重的工作如統計、過濾 response body 等就可以分散給多個處理器同時處理，不再只是佔用特定的處理器，其他處理器卻是閒得發慌。
相較之下，許多免費產品使用單一 process ，也不能充分利用 CPU 資源， process 一旦異常就整組報銷，而流量大一忙碌時，也沒辦法有效運用系統資源。

3.偵測模式與保護模式
在 SmartWAF v3 以前，如果想先觀察規則的嚴密程度，是否有誤擋情形，都必須使用 SHADOW Rules 。許多客戶在試用階段僅需要使用 SHADOW Rules ，另外有些客戶則是把 SmartWAF 當成 WebIDS 來用，一般用戶則在上線前都需要觀察一陣子，因此從 SmartWAF3 開始，提供了兩種模式，分別為偵測模式(Detection Mode)與保護模式(Protection Mode)，用以提供使用者更直觀的操作體驗。
細部的實際操作與過去的 SHADOW Rules 與 ACTIVE Rules 相差不大，只是現在預設都處於偵測模式，相關規則設定、學習、匯入完成並觀察運行一陣子並微調完畢後，只需要切換到保護模式即可上線提供保護，攔阻違規的網頁存取行為。

4.異常警示
異常警示功能在 SmartWAF v2.5 就有了，到了 SmartWAF v3 又有了強化。過去僅能做到系統級別的警示，例如 SmartWAF 總存取量異常增加等，現在可以進一步到 Application 級別的警示，也就是說當某個 Application 內所保護網站的總存取量異常增加時，一樣可以發出示警。另外，現在示警的方式也增加了 SNMPTrap 這種方法，許多有使用用網管系統，或是有 NOC 或 SOC 的單位都可以接收 SNMP Trap。
目前系統層級的警示類型包含：
a. Cluster State - 例如叢集成員斷線或是系統異常無法回應
b. Requests Per Minute - 例如 DoS 或是弱點掃描
c. Denied Requests Per Minute - 例如弱點掃描
而 Application 級別的警示類型包含：
a. Requests Per Minute Per Application
b. Denied Requests Per Minute Per Application
c. New Sessions Per Minute Per Application - 例如弱點掃描或是 Session 猜測

目前發出警示的方法則包括：
a. Mail - 寄送警示至相關信箱
b. Post - 傳送警示至特定網頁
c. LogFile - 儲存警示至特定紀錄檔
d. SNMPTrap - 透過 SNMP Trap 送出警示

預計下個版本還會增加更多的警示類型與方式。

另外還有許多改進如新增的 Preconditions 、新增的 Handlers 、許多 Handlers 內的新增參數、每週及每月 PDF 統計報告、叢集成員系統狀態統計與特定 Handler 狀態統計等，功能強化不少，我就不一一列出了，有興趣試試看的，歡迎進一步連繫囉。

作者 Wisely 為 阿碼科技 產品經理

繼續閱讀全文...

駭客集團於新年假期展開罕見之大規模SQL Injection攻擊

阿碼科技新聞稿 2009年1月5日

此次罕見之大規模資料隱碼(SQL Injection) 掛馬攻擊，於2008年12月24日開始展開，許多知名企業網站均受其害。犯罪集團趁著民眾休假時上網時間增加，以及網管人員可能無法立即處理，本次攻擊從12月24日持續至今，根據本公司SmartWAF所攔截的記錄顯示，此波攻擊中單一網站就遭受來自179個不同攻擊來源，高達500多次的攻擊記錄。相較於先前2008年五月之大規模掛馬攻擊，只有不到 20 個攻擊來源相比，此次規模相對龐大。

此外，此波攻擊之網站掛馬已經含有先前本團隊公布之微軟 IE 7 0-day 漏洞 (微軟已經緊急修補)，故不排出此次大規模攻擊，目的之一為散播此一新 IE 7 掛馬。本次攻擊手法仍然針對後端資料庫使用微軟 SQL Server 的網站為主，透過Google抓出 ”id”、”msgid” 或 “classid” 等關鍵字做為攻擊點，再進行資料隱碼攻擊。本公司估計此波攻擊至少造成百萬以上網頁受害。



攻擊特徵：
(1) 罕見之大規模 SQL Injection 攻擊，單一網站遭受來自179個不同攻擊來源，高達500多次的攻擊記錄。
(2) 掛馬中含有最新的 IE7 0-day 攻擊碼。
(3) 標準假日型攻擊，於2008年12月24日持續至今。
(4) 目標以大中華區的網站為主。
(5) 攻擊來源5筆來自台灣IP，137筆來自於南韓，31筆來自於中國大陸。

攻擊碼：
樣本一：

解碼後為：



樣本二：


解碼後為：



建議處理方式：
A、網站網管人員：
(1)是否遭受攻擊？以攻擊字串中的關鍵字 (例如 “dEcLaRe” 或 “0x4445434C”) 搜尋 Web 伺服器的 log記錄，看看是否遭受類似攻擊。

(2) 是否遭受攻擊成功？以惡意網址中的關鍵字 (例如 “daxia123” 或 “jxmmtv”) 搜尋網頁內容以及資料庫。

(3) 如何預防攻擊？網站遭受攻擊，是因為有 SQL Injection 漏洞。採用CodeSecure源碼檢測，找出漏洞並修補之。如果沒有資源或時間修補，可以使用SmartWAF網站防火牆來阻擋攻擊。

(4) 如何監控網站是否被掛馬？可以使用免費 HackAlert 24小時網頁掛馬監控服務，網址：http://hackalert.armorize.com

B、ISP 網管人員：
(1) 保護一般民眾 – 對於 outbound HTTP 流量，封鎖目標為此次掛馬之惡意網域之流量。本次攻擊所使用的相關網域名稱如下：daxia123、jxmmtv.com、lhaham.cn、daxia123.cn、ghahah.cn、dayoo.com、hhahai.cn、 ihahaj.cn。
(2) 保護網站遭受攻擊 – 對於 inbound HTTP 流量，封鎖來源為此次179個攻擊來源 (IP) 之流量。可來信向本公司索取此次惡意 IP 清單：pr小老鼠armorize.com。


繼續閱讀全文...