阿碼外傳-阿碼科技非官方中文 Blog: 2009

2009年12月1日

帳號密碼妙關聯,一般會員知多少

這篇文其實很早就想寫了,但總認為帳號密碼管理的殺手級應用,應該隔年就快出現了。但隔了一年又一年...@@,似乎遲遲不見相關應用。希望這篇文能引起大家對帳密管理重視與分級的觀念。

身為現在網路的一份子,你有多少組帳號密碼呢?E-Mail就好幾個,還有一堆會員帳號,不是嗎?很顯然的這裡面有很大的商機,但遲遲不見相關應用產品或技術。我大膽的說,帳密問題不解決,未來雲端將沒有安全性可言。

最近這個夯很大,來做個解說吧!

上圖,大家應該頗熟悉這畫面,帳號是取用電子郵件名稱,我甲意,你的密碼是啥呢?有沒想過幾個劇本呢?
一、電子郵件名稱就是密碼?生日?[太好猜,社交一下很有機會]
二、密碼是123456。[弱密碼,隨便猜猜]
三、電子郵件信箱也是這邊登入的密碼。[這劇本非常奧妙,不少人都是用這吧]

看完帳號部分,接下來也要看一下密碼復原機制。不忘密碼枉為人...XD。

很簡單的機制,我也頗喜歡的,忘記密碼也不用擔心,直接把密碼復原的連結寄到帳號,也是一電子信箱,亦無法變更信箱...讚。這可以玩某種 One-Time Password 的把戲耶,密碼設定到極複雜,用完然後就忘記...XD。

這裡面需要注意幾個問題:
1. 帳號設定使用的電子信箱必須永久有效,不然,密碼忘記可就麻煩了。
2. 帳號設定使用的電子信箱管理權被拿走,這可是一舉淪陷多個帳號。
3. 帳號設定使用的電子信箱密碼忘記,哪,看看信箱的忘記密碼機制能否救了。
4. 啥!密碼復原郵件被當垃圾郵件,收不到@@...XD
5. 這點才是我的重點,兩邊的密碼使用都是一樣的,應該有很多人都是這狀況的,會有啥問題呢?可妙了。

這時我們先切換到另外一個場景,你曾經填寫過哪些會員資料呢?不會都一五一十的寫吧!

填寫資料項目中,玲瑯滿目、五花八門,卻也可能處處充滿由網路世界跳脫至真實世界的巧門。填寫時需要多加以衡量其資訊的正確性與有效性,如非必要,能不填就不填,需要填就使用假設的一個虛擬個人資訊吧,網路是應該有另一個虛擬身份的。你是 Anderson 還是 Neo 呢?
每個網站的眾多資料項中,裡面有個幾乎是所有網站都會要必填欄位:"密碼"與"E-Mail"。如果在會員網站留下的"密碼",與"E-Mail"使用的密碼,是一樣的。那,無異於大辣辣的把另一組帳密告訴別人了嗎?

如果:
1. 這網站是釣魚、詐騙網站。
2. 這網站管理者盜賣個資、或加以濫用。
3. 這網站會員資料淪陷了、個資外洩了。

個資是可以做很多事的,電話可以發送詐騙簡訊、撥打詐騙電話,地址可以用來寄送中獎詐騙,E-Mail可以寄發各種社交郵件,有留下 IM 資訊的可能與留下的密碼是一致的(這個可以玩的花樣可多了...),這些都可以做很多運用的。

密碼管理也需要分級設定的,還在用一個密碼打通關嗎?這風險是極高的。我想多數網友是使用好幾組密碼的,但這還不夠,還需要注意資訊的彼此關聯性,
提供一些方向參考:
1. 會員網站能不留資料就盡量別留吧!這樣密碼掉了也不會痛。
2. 一般商業會員網站,除了留假資料外,如果有密碼復原機制的,密碼就隨興吧!反正重設密碼還頗容易。最好是利用 E-Mail 做密碼復原,且 E-Mail 一經設定是無法變更的最佳,這樣只要守好 E-Mail 帳密即可。
3. E-Mail使用的密碼一定不能在其他地方使用(與其他密碼重複的)。
4. 跟$$有關的帳號密碼,請務必以謹慎方式處理,或配合實體機制(如動態密碼鎖...等)來強化安全。

看到這邊,是不是該把 E-Mail 使用的密碼都給變更一下呢?

作者 Crane 為阿碼科技一員
本文亦張貼於「資安之我見」部落格

繼續閱讀全文...

2009年11月17日

OWASP Top10 2010版初探網站資安風險管理- 如何透過源碼檢測與網站應用系統防火牆控制風險等級


OWASP組織預計在2010年公佈新版的 OWASP Top 10,目前是RC1的階段,還沒正式公佈前可以拿來參考其代表的網站安全趨勢。對於OWASP Top 10的排名順序不感到意外,倒是從風險角度出發,將名稱變更為十大最關鍵的網站應用程式風險(Top 10 Most Critical Web Application Security Risks),而不僅是弱點,把Top 10的層級拉高,更符合實際狀況與業界的需求。風險是由弱點所造成的衝擊乘上威脅的發生機率,而剩餘的風險就是在安全控制下能降低弱點本身的脆弱性或者是發生的機率。面對最高危害的十大網站安全風險,企業可以採取的對策包含解決從網站應用系統本身源碼所產生的安全問題與漏洞、強化伺服器平台的安全組態或是透過網站應用程式防火牆(WAF) 將風險轉移。

在看前十大網站安全風險之前,我們可以先了解一下這樣的排名次序是如何被量化與評估的,本來是用網站弱點的發生率作為量化的單一因素,而這樣的做法僅針對弱點本身,所以在2010年版大幅地提升了Top 10的評鑑方法,項目如下:

1.攻擊與威脅來源 (Threat agent) 做出區隔,當然可以分為人人都有機會接觸的風險來源、也有受限的存取來源、或者僅有內部管理人員可以接觸的資料等。

2.攻擊的手法 (Attack vectors) 的多樣性與難易程度 (Exploitability) 決定攻擊是否容易成功,造成該像網站弱點被打穿,當然還包含現有攻擊工具取得之難易程度。

3.弱點的流行度 (Weakness Prevalence),越廣泛流行的網站弱點,其風險發生機率也相對提高,此項目分為不常見、常見及廣泛流行三種。

4.針對網站弱點所做的安全控制 (Security Control) 像是網站應用系統防火牆 (Web Application Firewall, WAF) 或者是網站的Log檔案,分別是預防型與偵測型的安全控制項目,而安全控制的強弱與類型則決定了此項弱點之可偵測性 (Weakness Detectability),由容易、一般、難分別給於1至3分。

5. 對於技術面的影響衝擊 (Technical Impact),上述之弱點與攻擊手法一旦成功,對於網站的資源、資產、保管的資料與系統功能,可能會造成不同程度之影響,此項包含嚴重、中等、次要三種。



而攻擊的手法、弱點的流行度、弱點之可偵測性之平均分數,即是計算出本項弱點被攻擊成功的可能性 (Likelihood),乘以衝擊的嚴重性就可以表現出本項弱點之風險程度。
在威脅來源與營運衝擊的部分,會因為此項弱點所在的環境、外在條件而有所不同,差易程度相當大,譬如線上購物網站的威脅來源會比一般個人網站或小型企業網站的威脅來源多;而且商業營運的衝擊倍數亦有極大的差距。因此以目前正式公佈OWASP Top 10 之前的版本來看,威脅來源與營運衝擊,並未直接列入量化的指標,而用文字敘述方式說明。

詳細的風險評鑑方法論可以參考風險評估方法論 (OWASP Risk Rating Methodology)

相較於2010年版,過去在OWASP Top 10 2007年版的評比方式就非常簡化,其以2006年的MITRE 弱點統計趨勢 (Vulnerability Trends) 為參考,找出與網站應用程式相關的前十大安全問題,但弱點發生次數頻繁卻不表示其風險就高,這也是為何此次2010年版導入嚴謹正規的風險評估方法論。

與前一版 (2007年版) 的差異在於從舊的排名移除兩個項目,再新增兩個項目
移除 A3 - Malicious File Execution (惡意檔案執行)
移除 A6 –Information Leakage and Improper Error Handling (不當資訊揭露與錯誤訊息處理)
新增 A6 –Security Misconfiguration (不當安全配置)
新增 A8 –Unvalidated Redirects and Forwards (未驗證的轉址與轉送)
仔細看所移除的這兩項仍是非常重要,以惡意檔案執行為例,當初被放進 OWASP Top 10 2007主要是因為PHP在建置時有太多的預設參數會讓此弱點非常普遍,而現在隨著新版PHP有更周延的預設配置,OWASP認為此風險相對會小很多。另外不當資訊揭露固然沒有直接風險 (通常不能直接用來做攻擊),但卻是進行攻擊時很好的參考資訊,很可惜這兩個項目都被擠出"十強"了,但我們還是要提醒大家注意。
至於新增加的不當安全配置,早是OWASP Top 10 2004年版的老面孔了,而未驗證的轉址與轉送更隨著近年流行的掛馬與零時差漏洞,讓這類無預警的轉址行為變得非常危險,是以風險大幅提高。

OWASP Top10 排名是一個象徵性的參考指標,像這一兩年在網站資安事件中,很大一部分是跟SQL Injection有關,同時這樣的攻擊所造成的衝擊比較嚴重,但是Dave也說他就是不理解為何還是有這麼多網站有這個問題,SQL Injection應該很容易可以修改的。不過這一兩年來新的攻擊手法演變,包含大量資料隱碼注入攻擊 (只要一行,跳脫原有只關閉錯誤訊息可規避之攻擊)、攻擊碼的變形及編碼、注入點的擴張 (Cookie、URL、檔案等)。所以,排名是一件事,而企業是否有採取相對應的安全控制則是更重要的議題,威脅手法在改變,千萬不要有一勞永逸的心態,安全控制項目也要跟著進化。像WAF要調整規則;源碼檢測要更新語言架構和新的驗證方式;網站掛馬檢測要更新因應新型態掛馬與攻擊 (exploit) 的偵測。

而網站應用系統防火牆可以提供的安全控制包括:A1 注入弱點、A2 跨站腳本攻擊、A4 不安全的物件參考、A5 跨站請求偽造、A6 錯誤或不安全的系統組態、A7 網址存取控制失當及A8 未驗證的轉址與轉送。同時也可以透過源碼檢測的方式把潛在問題在開發階段就先找出來。現在有很多資安工具與服務都提供這樣的風險評估模式,重點在於有沒有針對您所在的環境去調整基本參數 (作業系統、網站伺服器、網站架構、網站應用程式語言..等),以及歷史事件資料。

OWASP組織亦提供了許多對策,從開發的OWASP Developer’s Guide、測試與審查的OWASP Testing GuideOWASP Code Review Guide,而且還可以參考其OWASP Application Security Verification Standard (ASVS)和OWASP Software Assurance Maturity Model (SAMM)的標準與成熟度模型,作為大型網站環境的安全評估與實踐網站安全管理的參考。

下載OWASP Top 10 2010 RC1

本文作者Jack Yu
阿碼科技資安分析師
感謝Benson Wu(產品總監) 與ASF團隊之協助校正


繼續閱讀全文...

2009年11月9日

源碼檢測工具,怎麼比?美國國家標準局有研究:NIST SATE 2009 (源碼檢測工具研討會)

十一月初阿碼科技獲邀參加由美國國防部(DOD)國土安全部(DHS)美國國家標準局(NIST)所舉辦的SATE 2009 (Static Analysis Tool Exposition,源碼檢測工具研討會)發表演說。

SATE 2009 源碼檢測工具研討會是美國Build Security In ("內建安全")Software Assurance (軟體保證)計畫中的重點工作。



大會主席Paul致詞為研討會揭開序幕

阿碼科技發表「Addressing Software Security through Automated Static Analysis (以自動靜態源碼分析落實軟體安全之實務經驗分享」為題的演說

演講後回答問題,包括近一步說明 CodeSecure 如何呈現弱點追蹤(Traceback)、醒目語法提示的重要性、以及政府機關如何善用源碼檢測報告。

大會場地在靠近美國首都華府附近的一個小城市:維吉尼亞州Arlington(阿靈頓)的Crystal City (水晶市),緊鄰美國國防部所在的Pentagon City(五角大廈市),也正是此次公司所安排下榻飯店的位置,交通十分方便。

DC附近戒備深嚴



行前上網查詢發現研討會所在的飯店附近的停車費用一天要二十多元美金,但搭乘地鐵過去則只需要幾塊,因此一早七點半搭乘地鐵前往會場,一站就到達水晶市,之後沿著地下通道的大街小巷路牌指示,經過各式各樣的商店,居然就步行至會場,完全不需要離開地鐵站回到"路面上"!

SATE 2009真是一個匯集軟體安全領域先進、前輩、專家的會場,有好幾位過去在OWASP會議就結識的老朋友,像是來自NIST在軟體驗證、正規方法有諸多研究的PaulVadim,也有久仰的多位大師級人物包括C語言的Robert、JAVA語言的馬里蘭大學教授Bill,美國NSA (國家安全局)的高手,以及許多也對自動源碼檢測有高度興趣的同好,和各同業代表(Coverity、Klocwork、Veracode、GrammaTech、LDRA)等等。

在阿碼科技的簡報中,我們分享源碼檢測在SDLC中的實務經驗,以及討論此次SATE評比的結果,很可惜我們目前仍無法擅自對外揭露評比結果,即使是我們自己工具的數據,這裡面有很多有趣的觀察與發現。

與會成員討論非常多的數據,辯論很多觀念,也激盪出許多想法,此次SATE 2009源碼檢測工具研討會的主要目標(與成果):
1) 如何評估源碼檢測工具? (這對使用者是非常重要的)
2) 如何改善源碼檢測工具? (這對工具廠商是非常重要的)
3) 如何善用源碼檢測工具? (這對使用者和工具廠商都是非常重要的)

關於1): 市場成熟了,但工具成熟了嗎?廠商會大聲地說YES,但使用者要如何確認? 譬如,在評估的過程中,一個關鍵因素就是誤報率。不同的使用者是否清楚不同角色所認定的誤報? 不同角色(開發人員、QA測試人員、內部稽核人員、外部稽核人員、驗收人員、一般使用者)對於同樣的"弱點"會有不同的"價值觀",說穿了弱點是非常主觀的,在這些定義上要有一致的共識與標準,如此才能有效評估一個甚至多個工具是否能為企業與使用者帶來高效益的價值。

最重要的是,我們發現這樣的交流、互動平台不僅對整個軟體安全產業是正面的,對一般社會大眾在了解與熟悉源碼檢測工具有極大助益。在過去源碼檢測這塊是大眾比較陌生的,但我們可以看到這幾年不論是產官學或一般社會大眾,大家都認為資安是非常重要的議題,也是目前越來越困擾的嚴重問題。全球近年在推動軟體安全已逐漸有追根究柢、及早治本解決的趨勢,包括美國政府率先在推動的Build Security In ("內建安全")Software Assurance (軟體保證)計畫,強調安全是從內至外、從頭到尾重視、要求、落實,以及驗證。在這樣的過程中,自動化工具與源碼檢測分析技術的成熟與否是解決整體軟體安全問題非常關鍵的面向之一。

NIST將在2010年3月左右發表此次全球源碼檢測工具評比的完整報告。

作者 Dr. Benson Wu 為阿碼科技產品線總監

繼續閱讀全文...

2009年9月25日

[No Tech] 阿碼科技於DEMO Fall 2009發佈最新掛馬檢測技術HackAlert V2


在資策會的領軍之下,阿碼科技登上了DEMO的舞台,發表我們的第二代HackAlert網站掛馬檢測技術。HackAlert V2除了更準確地監控網站掛馬與網頁至換之外,更與SmartWAF配合,提供了即時修復的功能。HackAlert V2能夠準確地定位被插入的惡意元素(html、iframe、javascript等),一方面幫助網站管理者修復網站,一方面則將訊息即時地傳送給SmartWAF。收到指令後,SmartWAF會啟動即時掛馬修復功能,動態地透過修改http response,將被掛入之惡意成分移除,一方面保護網站的訪客,一方面也免於網站被列入Google或防毒廠商的黑名單當中。再加上CodeSecure可以掃瞄程式碼,幫助程式漏洞之修改,以及阿碼資安顧問團隊ASF所提供的各種服務,整個阿碼的Web資安解決方案,可說相當完整。

我們的六分鐘DEMO影片如下:

主流媒體報導:
Mashable: HackAlert: Web Apps Finally Get Secure
VentureBeat: DEMO: Armorize’s HackAlert notifies you if your web site is under attack
iThome: 阿碼科技HackAlert™ 世界肯定,受邀「全球創意DEMOfall 09」之展出
DEMO網頁上的阿碼

整個從參加資策會Ideas Show開始到DEMO,我的感覺是...「大難不死」...

怎麼說呢。不論是資策會的Ideas Show或者DEMO,都是非常棒的產品發表舞台。今年大廠如HP與Google,也都在DEMO上發表他們的新技術。DEMO的展示,因為只有六分鐘,所以內容都很精華,可以看到有些人緊張,有些人穩健,有些人背稿,有些人熱情...加上短時間內可以看到許許多多的創新,體驗創業家的那種熱忱,讓我很喜歡看DEMO的六分鐘影片。我的心得是,上場的如果是團隊的專業行銷部門,通常可以做得很流利穩健,一看就是訓練有素,一點不怕大場面。但是如果是創辦人或經營團隊親自出馬,因為不常上台,雖然會比較緊張,雖然講話比較不順,甚至有些笨拙,但是總能帶給觀眾更深切的感受。因為他們所散發出來的,是他們對於技術的熱忱,對於產品的信心,對於公司的驕傲--這種心情深深滲透在他們的血液裡頭,他們想要告訴觀眾,他們的東西有多好!這種感覺,不是專業的行銷團隊所可以訓練出來的。

去年讓我印象最深刻的DEMO團隊,後來也得了DEMOGod獎,是Plastic Logic這家公司,由CEO Richard Archuleta親自上場。Plastic Logic成立於2000年,募了超過兩億美金的資金,做的產品是電子書上用的超薄塑膠螢幕。Richard在台上蠻緊張的,DEMO中也出現一些小錯誤,但是產品真的很棒,技術門檻很高,加上大家都可以看出,他的展示中充滿了對公司的信心與驕傲,是我覺得他們得獎的主要原因。

今年得首獎的兩個團隊,一個是做MS Outlook外掛,來自澳洲的Liaise,另一個則是做超薄塑膠喇叭的EMO Labs--兩家公司做的都跟Web沒有直接關係。我看完EMO Labs的展示,就直接認為,今年他們一定拿獎!EMO Labs也是由CEO Jason Carlson親自上場,講得很慢,但是表達得很清楚:現在螢幕越做越薄,沒有空間能夠置入好的喇叭系統,成為目前超薄顯示系統的最大弱點。EMO Labs能夠用透明的塑膠材質,做出雙聲道的喇叭,直接黏在螢幕前面,不佔任何空間,而效果又好:

Jason忙著介紹公司的產品與技術,甚至往了介紹自己的名字,讓記者急著詢問,台上到底是誰?

阿碼這次一路從資策會IDEAS Show,參加到DEMO,可以說非常辛苦。困難之一,是這種產品平台上發表的東西,都很炫。可是要把資安的東西,對著台下都不是資安領域的聽眾,講得很炫,真的是一件很不容易的事。阿碼的核心技術,首推源碼檢測;從2003年寫的論文,一路做到現在,演算法也不知演進了多少代了,現在所用的資料結構與演算法,實在非常漂亮,可是,我們已經幾年沒有在台上講過這些技術了。這些東西講起來就是一堆演算法,畫一堆graph,然後推複雜度(complexity);不要說一般聽眾,就連資安專家,可能有興趣的也不多。講應用面呢?在一堆密密麻麻的程式碼中跳來跳去,解釋我們用什麼演算法來掃到什麼樣的複雜漏洞...除非台下對於資安與程式設計都有基礎,不然也是很難有效果。也許這就是源碼檢測團隊的宿命吧!永遠只能在一個很小的圈子中,才能因技術的分享而產生興奮的火花。

這也是為什麼,對於我們公開的演講或這類的展示平台,我們都盡量以HackAlert為主。當然還是遠不如超薄塑膠螢幕或塑膠喇叭所能帶來的驚奇,但是至少網站掛馬還是跟一般人有些關係,大家聽了比較有感覺。

困難之二,是我們大家都身兼數職,大家真的是騰不出時間來準備與練習。拿我來說吧,DEMO創辦人Chris Shipley應資策會邀請來到台灣,也約了我們碰面,我是創辦人兼CEO,理當去赴約,可是我實在太忙,公司大小事情堆積如山,每個小時對我都很重要,實在無法抽身,只好請創辦人兼COO兼CFO的Matt,以及Sales Director Volker與她碰面,並參與IDEAS Show的準備與上台工作。

結果雖然我們得了獎,也受到了DEMO的邀請,可是大家都說,實在沒空去。經過協調,只好請John代替需要全心投入歐洲市場開發的Volker,並還是請Matt與創辦人兼CTO的Walter上場。John來自加拿大,目前全家都在台灣,他在資安界做了近20年,除了擁有CISSP等證照,也是ISC2(發行CISSP的組織)與SANS的顧問,由資安經驗豐富的他出馬,幫我們重新設計展示內容與寫演講稿。

準備期間,資策會IDEAS Show的許多同仁,一路輔導我們,讓我們充分體驗了他們在這方面的經驗與專業。我們是第一次參加DEMO,他們則是經驗豐富,在他們的指導下,我們的演講可說是翻了又翻,改了又改,一直到上飛機的前幾天。整個過程中,我可以說是提心吊膽到了極點。因為我知道一個資策會不知道的秘密:他們眼前的這三個人,排演一結束,就會開始接電話,開會,Walter甚至還要顧HackAlert的技術部分,一次彩排完,我看過幾個小時,他們就什麼都不記得了,這是要如何上台?

日子過得很快,一下子這票人就到了聖地牙哥了,結果一到旅館,果然不出我所料,Walter立刻被台灣的研發團隊纏上,Matt也是電話講不完...輪到他們上台預演時,大家是拿稿子上去唸的...當然,看到其他隊伍似乎都準備充分,他們比我更緊張,於是我發了一封email給全公司,接下來一天,大家不准打給Matt或Walter,有事只能寫email。然後我說,我們上台前的CEO晚宴,說明會,開幕等,都交給同事Orion處理,Orion是美國人,他會弄得很好,要上台的三人,不准出門,趕快練!

DEMO開始了,我們是下午第一家,我晚上開始從台灣看網路上的現場轉播,一連幾家公司都出現網路問題,大會主席Chris Shipley也出面說,會場頻寬不夠,希望在場的大家不要連接現場轉播,會吃去頻寬。DEMO限定一定要live的DEMO,不能用錄影的,也不能用投影片。可是一旦現場頻寬不穩,狀況就會慘不忍睹。Chris雖然有答應受影響的團隊可以重來,可是,誰希望重來呢?於是我立刻與Walter聯絡,Walter說,他不怕,叫我不用緊張,他有多個方案,一站上台的前十秒,他會先測試,決定哪個方案後,會跟團隊打pass。

輪到他們上台時,台灣凌晨五點多,我在電腦前看著轉播,那六分鐘之間,我真的是緊張到忘記要呼吸。DEMO的網站上,實況轉播旁邊就是twitter上有關活動大家的看法。我們的DEMO進行到一半時,我發現,大家真的都很喜歡我們的DEMO!

其中兩個tweet真是讓人振奮:

「How these guys made security interesting, dont' know, but they did. Great job HackAlert- Armorize.com」(這些人如何讓資安變有趣的,不知道,但是他們做到了。做得好,HackAlert)
「Why do the security companies have the best presentations?」(怎麼最好的展示都是資安公司?)

從頭到尾,他們演出完美,沒有讓公司漏氣,更重要的是,在這個台灣軟體業邁向國際的接力賽中,我們沒有掉棒,我們盡力做到能力所及之最佳水準,沒有對不起前輩,也沒有讓資策會的長官失望。看著他們的展示,不但心裡幫他們驕傲,也幫台灣所有的同仁驕傲。四年前,我們有的不過是很多的論文,都寫在紙上;四年後,我們在DEMO上展示的CodeSecure與HackAlert,看起來是那麼的成熟,那麼的專業,我們舉出的指標性客戶,遍及全球,並都是最大的客戶。

最近,如何訓練新人,是團隊中常被提起討論的議題。看著他們的討論,想到四年前他們青澀的模樣,當時他們雖然技術好,但是缺乏經營的經驗。四年之後的他們早成了公司的棟梁,是源碼檢測與惡意程式的專家,仔細地設計出公司的各種流程與組織架構,用心地幫公司想未來。究竟是什麼樣的運氣,讓我們大家能相遇,讓阿碼能有這樣的團隊,我也想不懂。但是,恭喜大家,你們的努力,成果不凡!也再次謝謝資策會、研考會、技服中心、軟協等指導單位在各方面給阿碼的幫忙,我們會繼續努力,很高興在台灣的軟體界邁向國際的路上,我們能夠參與其中!

作者Wayne為阿碼科技一員

繼續閱讀全文...

2009年9月7日

另類XSS攻擊手法:利用PDF與Flash的XSS攻擊--Opera Unite安全性第一回


九月一日,Opera 10沸沸揚揚的登場了,新聞還真不少:

ITHome: Opera 10釋出 四小時下載超過20萬
ZDNet: Opera 10 正式版出爐 新增Turbo加速功能
網路資訊: Opera 10正式版推出開放下載
聯合新聞網: Opera 10 全世界最快的瀏覽器

眾多報導中我最有興趣的,是Opera推出了「Opera Unite」社交平台,上面有檔案分享,部落格等等社交網路服務(SNS, Social Networking Service)功能,並由Opera 10瀏覽器直接支援,計畫藉由其瀏覽器使用者之基礎,踏入SNS與UGC(使用者產生之內容,user-generated content),也藉由SNS與UGC,反過來穩固其既有的瀏覽器社群。在 my.opera.com上,Opera Unite宣稱提供1G的免費空間,並大力推廣部落格功能。Opera Unite的部落格直接有行動版,方便行動用戶利用Opera Mini閱讀(Opera市佔率以行動市場為最高)。




新裝好的 Opera 10 瀏覽器中,也直接有功能與 Opera Unite 整合,充分展現 Opera 這次進軍 SNS 的企圖心!



PDF XSS 跨腳本攻擊測試
我最喜歡裝新的瀏覽器了,因為我的工作跟Web很有關係,任何瀏覽器在速度上的提或新功能的發展,都可能對我有幫助。當然,另一點很重要的是,新瀏覽器的安全性。安裝完Opera 10後,我順便註冊了一個Opera Unite的帳號。隨手一測,WOW,漏洞真的很多!我有時覺得自己真是有職業病,每當朋友興高采烈的跟我介紹某新網站,某新軟體,某新產品時,我腦袋總是響著各種警鈴,WOW,這個不安全,WOW,這樣子的話漏洞大了,WOW,這功能誰設計的,根本沒考慮資安...當對方興致勃勃等我回應時,我腦袋卻總轉著各種資安問題,而沒有辦法用相同程度的熱忱與興奮來回應他們...不只如此,還會手癢開始測試問題。朋友常說我有職業病,我有時候也覺得,自己真的是職業病很嚴重。

無論如何,那麼來談談一些我週末找到的漏洞吧!每次一開始找到的漏洞不外乎SQL Injection、XSS、CSRF等,可是老是講這些似乎太老套了...那麼,來介紹一下稍微「另類」的XSS攻擊--透過PDF與Flash的XSS攻擊好了!

假設我是駭客,那麼對 Opera Unite 最有效且持久的攻擊是什麼?其中之一是,我來註冊一個免費的部落格,然後貼一篇文章。Opera Unite的部落格,支援基本的HTML語法,但是會(盡可能)過濾導致資安問題的語法,例如「javascript」或「iframe」等等。假設我能找到部落格中的「預存式XSS(stored cross-site scripting」(又稱「永久型XSS(persistent cross-site scripting」),那麼只要在登入狀態而來看我文章的 Opera Unite 使用者,都會被我攻擊,自動偷到他們的cookie,或甚至讓他們自動在他們的部落格文章中,插入一樣的攻擊碼,而造成蠕蟲式的散播。

由於 Opera Unite 對於具有威脅性的語法如「javascript」或「iframe」等,做了基本的過濾,於是如果要XSS,便要嘗試繞過其過濾函式。這種過濾函式很不好寫(見「弔詭的過濾函式」),絕對有機會繞過,但是要花時間。不如我們來用PDF吧!

藉由<embed>或<object>等tag,我們可以將PDF檔案內嵌於HTML頁面中。安裝Adobe Acrobat Reader時,Acrobat Reader會順便安裝瀏覽器plugin,而在嵌入有PDF檔案的HTML頁面被瀏覽器解析時,Acrobat Reader plugin會啟動,顯示出PDF的內容。PDF檔案格式支援表單功能,在表單中,我們可以放一個「HTTP送出按鈕(HTTP Submit Button)」,當被按下時,Acrobat Reader plugin會觸發瀏覽器開啟一個URL。

OK,重點來了,這個按鈕的URL protocol handler中,支援「javascript:」這個handler。為何PDF表單中需要支援「javascript:」?我也不知道,但是之前與Adobe總部互動討論後,得到的答案是短期內Adobe並沒有計畫要拿掉這個功能。

於是,我們可以做一個PDF,含有一個表單,於表單上放置一個「HTTP送出按鈕」,並把URL設成「javascript:cookie_stealer()」,其中cookie_stealer()就是我們偷cookie的程式。我做了一個放在www.openwaves.net上,其中表單的程式碼如下:

<field xmlns="http://www.xfa.org/schema/xfa-template/2.2/" h="22.225mm" name="HTTPSubmitButton1" w="38.1mm" x="171.45mm" y="3.175mm">
<?templateDesigner isHttpSubmitObject true?>
<ui>
<button/>
</ui>
<font typeface="Adobe Ming Std L"/>
<caption>
<value>
<text>送出</text>
</value>
<para hAlign="center" vAlign="middle"/>
<font size="36pt" typeface="Adobe Ming Std L"/>
</caption>
<border hand="right">
<?templateDesigner StyleID apbx2?>
<edge stroke="raised"/>
<fill>
<color value="212,208,200"/>
</fill>
</border>
<bind match="none"/>
<event activity="click">
<submit format="formdata" target="javascript:alert(document.cookie);" textEncoding="UTF-8"/>
</event>
</field>

接下來我們必須將此PDF嵌入我們在Opera Unite的頁面中。Opera Unite的部落格對於「<embed>」與「<object>」 兩種tag,都有支援。我們選擇用「<object>」,因為可以很容易地讓PDF秀出來時,不要有其它周邊的工具欄(toolbar)。程式如下:

<object data='http://www.openwaves.net/armorize_cht3.pdf#scrollbar=0&toolbar=0&statusbar=0&messages=0&navpanes=0' type='application/pdf' width='100%' height='70%'></object>

整個部落格文章成品請見:「PDF XSS 跨腳本攻擊測試」,畫面如下:

經過測試,此攻擊可以在Opera、Firefox、Safari、與Google Chrome等瀏覽器上執行成功,Opera的畫面就是本篇最開始的畫面,其它瀏覽器的畫面如下:(按下可以放大)

這種攻擊,要說是誰的弱點呢?我認為算是Adobe的,因為PDF表單沒有理由要支援「javascript:」這種protocol handler--或許Adobe有他們的理由吧!不過上次回報後得到的答案是,PDF跟HTML一樣,都是屬於動態文件,因此這個為「功能」而非「弱點」,所以短期內不會拿掉。既然這樣的話,只能說,網站如果有可以讓使用者自行上傳HTML的功能,那麼是否允許「<embed>」與「<object>」 等tag,需要審慎考慮。

阿碼外傳是放在Google的Blogger上,Blogger的作法則是利用javascript SOP(相同來源政策,same origin policy)與不同網域名稱來解決。Blogger的登入與管理介面是放在blogger.com上,可是實際顯示的部落格是放在armorize-cht.blogspot.com上,這樣可以達到兩種保護效果:
1. 偷到armorize-cht.blogspot.com的cookie,對於實際上管理用的blogger.com無效。
2. 由於每個部落格具有自己獨立的網域,所以即使blogspot.com有需要用到cookie,那麼偷到了armorize-cht.blogspot.com的cookie,也對於其它部落格無效。

這是很好的作法,因為要過濾HTML中的惡意字串,其實不是一件容易的事(見「弔詭的過濾函式」)。

Opera Unite的架構則不一樣,拿我註冊的測試帳號來說,部落格網址為:http://my.opera.com/armorize/blog,也就是說,每個人的部落格網址就是:http://my.opera.com/帳號/blog。如果是這樣的話,偷到別人的cookie,很可能整個Opera Unite(my.opera.com)的身份就可以盜用了。

所以,相較於 Opera Unite 努力parse使用者上傳的HTML,試圖保衛安全性,過濾惡意的元素,blogger則比較少。例如blooger對於「<embed>」與「<object>」 等tag,幾乎是不太過濾,反正偷了cookie也只是blogspot.com的cookie而已。當然cookie也有path機制可以利用,可是根據實際經驗,效果並不好,見以下「小結」中之討論。

(題外話,可是我試過,可以偷共同作者的cookie。因為blogger.com的管理介面,有預覽功能,所以我寫一篇,請其它作者幫我「改錯或檢查」,就可以偷到其它作者的cookie。)

Flash XSS 跨腳本攻擊測試

上述的PDF XSS 跨腳本攻擊法,威脅是,很多網站不知道可以這樣攻擊,所以不會限制PDF的嵌入。另外,Adobe的PDF是很流行的檔案格式,很多使用者都有裝Acrobat Reader,所以攻擊面可以很廣。可是缺點是,需要按一下按鈕才能觸發攻擊。當然,這個可以改,不過以後再寫了。現在,我們要一個更簡單的方式,最好對方一來我的部落格就中了XSS,那要如何做呢?我們可以利用另外一個安裝率可能更高的瀏覽器plugin:Adobe Flash。Flash中可以寫ActionScript,而getURL()這個函式,可以驅動瀏覽器前往某個URL,並且...對的,也支援「javascript:」protocol handler。Flash的這個功能,我看是更難拿掉了,因為很多的Flash程式,都是利用這個功能來彈出對話盒的(getURL("javascript:alert("xxx");")。

我做了一個flash的XSS攻擊程式,裡頭只有一行:「javascript:」protocol handler

onClipEvent (load) {
getURL("javascript:alert(document.cookie);");
}

我先將這個檔案放到www.openwaves.net上,然後新增一篇部落格,利用「<embed>」tag來嵌入此flash。但是Flash的保護畢竟比PDF多。在嵌入Flash時,要加註「allowscriptaccess」參數為「always」,不然「javascript:」protocol handler會被擋掉。allowscriptaccess從Flash 6就有了,Flash 7開始,如果沒有加註,則內定值為「sameDomain」。由於我們的flash攻擊程式不是放在my.opera.com上,所以我們必須將此值設定為「always」:

<EMBED href="http://www.openwaves.net/flash_xss.swf" TYPE="application/x-shockwave-flash" allowscriptaccess="always"></EMBED>

發佈部落格後,攻擊不成功,「view source」一看,原來Opera Unite認識「allowscriptaccess」,並把我們寫的「always」改成了「never」:

<embed href="http://www.openwaves.net/flash_xss.swf" type="application/x-shockwave-flash" allowscriptaccess="never">

恩,不錯,至少有基本的防禦力,那麼與其測試是否能繞過過濾函式,不如找其它的方法。我們試試「<object>」吧:

<object data='http://www.openwaves.net/flash_xss.swf' type='application/x-shockwave-flash' width='1' height='1'><param name="allowscriptaccess" value="always"></object>

結果Opera Unite並不檢查「<object>」tag中的「allowscriptaccess」值,就這樣讓我們的攻擊成功了。攻擊的部落格在:「Flash XSS 跨腳本攻擊測試」,畫面上沒有痕跡,也不需要對方按什麼地方,只要瀏覽,就可以偷cookie了。一樣,在Firefox、Opera、Safari、與Google Chrome上都能成功。


防禦方式

這邊示範了利用Adobe的兩個廣為使用的瀏覽器plugin--PDF與Flash,以Opera Unite為例,展試了如何達成XSS攻擊。這種漏洞算誰的責任?網站管理者沒有能力影響到廠商(Adobe)要如何設計他們的瀏覽器plugin,而大家卻都有安裝。PDF為何要支援「javascript:」protocol handler?我們無法知道。在這種模糊地帶,網站開發者只有自己採取錯失避免此類攻擊。過濾使用者上傳的HTML是一個方法,但是正確的過濾函式不容易撰寫。

對於利用XSS偷cookie的攻擊,另一個方法則是blogger所採用的,a)將管理平台與內容平台分開,與b)讓每一個使用者內容有其獨立的網域(user_name.blogspot.com),而非讓全部使用者的部落格都在同一網域下,例如my.opera.com。當然,cookie可有path的限制可以利用,但是事實上,單一網域的網站架構,到最後都很少利用到cookie path來限制cookie的有效範圍,Opera Unite也不例外:

SNS平台吸引人之處,就是其豐富的user-generated content;然而有效處理使用者上傳的資料並做好正確的過濾,一直都是一個很大的挑戰。針對PDF與Flash的XSS攻擊,網站開發者必須特別注意使用者上傳內容中內嵌的PDF、Flash或其它可以存取到DOM(document object model)元素的檔案。

對於一般使用者來說,最簡單的方式可以是使用多個瀏覽器(firefox、safari、chrome),負責進行登入的瀏覽器,不拿來瀏覽其它內容。Firefox可以透過--profilemanager參數來設定不同profile,也是大家常用的方式。對於PDF的XSS攻擊,使用者可以設定不要讓PDF於瀏覽器內開啟,一律以外部Acrobat reader獨立開啟:

作者Wayne為阿碼科技一員

繼續閱讀全文...

2009年8月8日

[No Tech] 從資策會 IDEAS SHOW 參展經驗談創業



今年阿碼報名了 資策會的IDEAS SHOW,星期三早上的決賽,我們與另外兩隊(HHOTTT-Island),拿到了最大獎--評審獎,讓全公司興奮不已!由於客戶量不斷快速增加,大家最近工作已經太忙了,而品質又是我們一向堅持的,在不願犧牲給客戶的品質下,竟然沒有一個人有多出的時間可以幫忙準備這場IDEAS SHOW!原本認真討論過是否放棄,但是又捨不得,只好利用晚上開會,協調讓剛從德國搬來台灣加入我們的Volker(前賽門鐵克歐洲發言人)與共同創辦人COO Matt及CTO Walter三人擔綱,並於週末練習與準備demo所需的環境。其間由於我們對於流程、場地、活動性質等有許多問題,頻頻資策會工作同仁互動,得到了很多的協助,也讓我們充分感受到工作人員對此次活動的熱忱,以及背後的艱辛,感謝各位,也感謝評審委員對我們的支持與給我們的建議,各位辛苦了!

比賽前一天,雖然租了樓下的大會議室做練習的場地,可是三人還是一直被工作干擾,一面練,一面總是有人手機響,這是要怎麼練?下午我去看他們預演時,可以感受到,還不行,大家都不熟,可是我也沒講出來,心裡覺得很對不起他們,明明沒有充分準備時間,又要逼他們上台。結果比賽完,Matt說,練了整晚,總算有成果,我們已經做到我們能力所及最好了,沒有任何失誤,概念也都充分傳達了!每一隊都很強,我們也沒把握能拿獎,但是想到我們已經盡所能,做到能力所及的最好演出了,得名與否,沒有什麼好遺憾的。看著一隊接一隊精彩的演出,台灣有這麼多優秀的軟體公司,在台下感覺真是驕傲!

完整參賽團隊名單在這裡

媒體報導都蠻正面的:
觀察:IDEAS Show閉幕 熱鬧才要開始
資策會idea show秀創意 32團隊展出web2.0新應用
台版DEMO展Ideas Show落幕 新創網站發聲
IDEAS Show網路創意展擴大規模 產業應用最夯
IDEAS Show網路創意展 發表
「2009 IDEAS Show」網路服務創意展 ~ 集結網路創意 鏈結三網效益 提供多元服務

評審寫的blog很有參考價值:[評審日記]2009 IDEAS SHOW網路創意展_校園組

網路上也有很詳細的活動報導整理:
2009 IDEAS Show 網路創意展精彩搶先看
2009 IDEAS SHOW 一些感想 (上)

不久候,朋友給我一個連結,PPT上有位網友對活動持比較懷疑的態度這裡有噗浪上的討論)。看了他的文章,我也思考了許久,就當作對於活動的小小回饋,我來寫一下我個人的看法好了,希望這些整理對以後參賽者來說有些參考價值。
首先,IDEAS SHOW的目的為何?我們看網站上的說明:

********************************
為協助國內網路服務進軍國際市場,進而在國際網路市場佔有一席之地,經濟部技術處委託財團法人資訊工業策進會執行「新世代網路創新服務發展計畫」,藉由媒合各界資源,建立新創網路服務培育機制,促成創新服務國際化發展機會,帶動網路產業發展。

IDEAS Show網路創意展,是資策會為網路新創公司提供的一個發聲管道,亦是國內第一個網路創意服務發表平台。去年資策會移植美國DEMO Show的舉辦、評選模式,舉辦了國內第一個網路創意展覽IDEAS Show,也深獲各方廣大迴響。

為了發掘國內更優秀並具潛力國際化之創新服務,今年將擴大舉辦IDEAS Show,在活動中除了邀請多位國外講者來台演講外,更加入了一場國際創投家的座談會議,期望藉由One Stop Shop的方式,匯集與推廣國內創新服務,吸引國際市場對國內創新網路服務的關注,未來也能幫助國內其他躍躍欲試的網路創業者進入。

DEMO Conference為發表創新產品、服務、點子,以及具新興市場開發的國際發表舞台,目前已有19年歷史,每一年都會受到來自全球數百位投資者和媒體的關注,是國際服務進入美國市場的最佳捷徑。包括地圖日記、citiport、Awind、YouGotPhoto以及meworks等國內網路服務也相繼於美國DEMO Conference及Webi中國北京DEMO China等國際舞台發表,並深獲國際媒體與創投給予肯定。
********************************

恩,所以是帶動網路產業發展,移植已有19年歷史的美國DEMO ConferenceDemo Conference的確是全球發表新產品的首選平台,歷經19年,好評不斷。資策會這次能邀到DEMO Conference的創辦人與執行總監Chris Shipley來台參加,實在是太棒了!

可是,DEMO Conference究竟都選怎麼樣的公司上去秀呢?這個秀又如何幫到這些參加的公司呢?我不是那麼熟最新的 Web 2.0 趨勢,其實我大部分時間都專心於把公司的事做好,所以對於這類的創業平台,只能說有聽過,但是平常都沒在follow,不能說熟。這次參賽前,為了能夠做出符合大會想要的demo,我們特別做了功課。首先我看了「What is DEMO」的影片,其中強調:

* 2004 年參展的 six apart,同年拿到一千萬美金的資金。
* 2003 年的 Oddpost,同年拿到兩百多萬美金,之後被 Yahoo 以三千萬美金併購。
* 2006 年的 GrandCentral,先是拿到創投資金,後又被 Google 併購。
* Webex、vmware、salesforce等,都是 DEMO 的畢業生。
* 過去五年,DEMO 畢業生共募了35億美金。
* 今年 1Q,金融風暴中,DEMO 畢業生共募了1.7億美金。
* 目前超過40個畢業生成功被併購。

恩,所以強調的是,被選來DEMO的隊伍,都會非常的成功。而DEMO幫助新創公司成功方式也很明顯:因為DEMO只選擇最好的團隊,所以創投都會來DEMO,全球媒體也都會來DEMO,所以能來DEMO的團隊,能夠立刻吸引創投的注意,與獲得媒體的曝光。所以好的團隊都會很努力的爭取來DEMO的機會,而整個DEMO就成了一個超級的媒合平台--團隊,創投,媒體。

好,那麼DEMO都選擇什麼樣的團隊呢?幾年的公司呢?多大的規模呢?剛起步的嗎?還是已經有募資過的?我無法一一看完全部團隊的資料,但是我看了一下今年DEMO 2009(spring)中得獎(DemoGod)的團隊

1. Avaak Inc:成立於2004年,去年底做第一次募資,募得七百萬美金。創辦人Gioia是多次成功創業家(serial entrepreneur),過去曾創立 SUMMIT Design Technologies,服務如 Motorola、Lockheed Martin、Texas Instruments、SAIC等。在之前,她創辦 MedSmart 並擔任 CEO。她擁有八篇專利。

2. Coveroo Inc:成立於2008年,第一次募資得250萬美金,創辦人Karl Jacob 為連續四次之成功創業家,過去14年皆致力於廣告產業,也於 Sun 與微軟等公司擔任過高階幹部。在他的職場生涯中,他成功從最頂尖創投中募得超過2億美金的資金。四次創業,皆是從零收入開始,做到成功被併購。其中 Dimension X 被微軟併購,而 Keen (Ingenio) 被 AT&T 併購。他為投資人創造了超過3億美金的投資報酬,這些公司過去平均一年營收超過1.5億美金。他也於 Facebook、Cloudmark、IMMI等公司擔任董事。(注意:他目前創辦的Coveroo只募資了250萬美金)

3. Ontier:成立於2008年,創辦人Mr. Rapport在業界又超過25年的經驗,於 Apple、CAM Systems、Revionics等公司擔任高階職務。

4. Purewire:(資安公司!)成立於2007年,由創辦人與家人共出資475萬美金,CEO Michael Van Bruinisse有15年業界經驗,為前 CipherTrust VP,從公司零收入,到後來一年6千萬美金,最後公司以3億美金被 Secure Computing 併購。更之前在 Sun 工作,為當時 Sun 最年輕的 Director,並協助 Sun 併購 NetDynamics,以及 Logic Works 的上市。

5. Silverstone Solutions:成立於2006年。創辦人自己出資,有25年相關業界經驗,

6. Skout:成立於2006年,只向個人投資人募資,共一百萬美金。CEO Christian Wiklund之前服務於 vmware,CETAC,以及 Chalmers Teknologkonsulter。

7. Technocopia (gwabbit):成立於2007年,不打算募資,創辦人Todd Miller為連續創業家,1998年創辦WebFeat,成功被Proquest併購。更之前成立Knight-Ridder,並與IBM合作,於1996年獲得Gartner最佳基礎建設獎。

從以上七家今年的DemoGod,我們可以看出,所有創辦人年紀都不輕,擁有很成功的業界紀錄,很多都是連續創業多次的創業家。有些公司有募資,有些沒有,有些也表明未來也沒有打算要募資。看到這些人的履歷,我覺得他們不論有沒有參加DEMO Conference,都會很成功。當然,能參加DEMO,絕對更加幫助他們,加速他們的成功,Chris的意見,輔導與牽線,也都會幫到他們。但是,即使落選,我相信他們最後都還是會成功的。這也讓我覺得,難怪創投都要去DEMO找投資機會,這麼好的團隊,這些創辦人手上都有錢,也都自己放下去,絕不是玩玩而已,要投資他們,創投可能還得多花心思溝通,看他們願不願意拿。

可是,如果DEMO Conference中得獎的團隊都是這樣等級的,那麼年輕人想要網路創業,要參加什麼活動?政府要如何幫忙?

我當然沒有答案,我又不是政府,也不是觀察家,也沒待過創投,要談經驗,其它人可說的比我多很多。不過我們可以來想想,年輕的創業團隊,要的是什麼?

如果有好的技術希望推廣,希望加速發展,開放源碼是一條很好的路。只要技術好,就很容易吸引到同好,進而慢慢建立社群,把技術發揚光大。如果是網站要長大,也有很多微型創業的方法,做一個好的網站,不一定需要很多的資金。這不就是Web 2.0吸引人的地方嗎?

此外,講到「創業」,其實意味著將技術變成你的事業,也就是你養家活口吃飯的依靠。那麼要創業,你想要從一場活動或一場比賽中得到什麼?

最好的資金來源不是投資人,而是客戶。有時聽有人說,我們很成功,一開始就募得資金,還都是很好的投資人。但是聽到這些我就想到,阿碼在美國有個可以算同業的公司,也是我私下的好友,同為寫論文寫到一半,出來創業,他們一開始就能獲利,等到公司很快地長到80人了,才以1.2億美金美金的身價,募了2500萬美金。這才是真正成功的創業團隊--一開始就能自給自足,錢是客戶心甘情願付的,募資時股價高,失去的股份少。

但是公司要抓住市場機會,如果不能一下子收支平衡,而又需要快速成長,就需要資金。可是創投不可能亂投,一個創業過四次並成功為投資人賺了3億美金的Karl Jacob(剛才介紹的 DemoGOD [2] Coveroo),與一個剛出社會的年輕人,投資人要選擇投誰?即使投資了,股價也絕對不會高,這代表了很可能第一次募資後,投資人已經持股過半了。此外,創投可能只信任創辦團隊的技術,而不信任原團隊的管理能力,行銷業務能力,財務規劃能力等等,而強行安插有經驗的管理階層進入。那麼,老實說,創業團隊不過是員工罷了,對公司的影響力大打折扣。這樣情況下,你還能依當初的理想來建立公司嗎?還能繼續影響公司文化與方向嗎?這要看你和投資人的互動如何了。

拿資金就像是結婚,員工相處不好你還可以fire,但是投資人永遠都是股東,相處不好只有一條路:你自己離開。

我認識很多有經驗的創業家,第一次都是自己出,等到做出股價了,才開始募資,一次也只募一點,等到又做到成績,股價又高了,才再募。當然,這要配合公司需要的成長速度,如果真的一次募很多錢,能夠搶到市場先機,那麼也要考慮。可是我看過的,這種想法下失敗的也不少,大家以為砸下去就能拿下市場,結果什麼都沒有。金融風暴後,創投模式(venturecapitalism)是否work,創投產業是否真能獲利,還諸多討論:
(source: forbes.com)


富比士:即將瓦解的創投(Forbes:Venture Capital's Coming Collapse
VentureBeat:創投模式有問題(VentureBeat:The VC Model is Broken
VentureBeat:跟創投募資:飛了,飛了,不見了?(VentureBeat:Venture fundraising: Going, going, gone?)
VentureBeat:創投縮水40%,tech boom真的停止了(Venture capital shrivels 40 percent — It really is the end of the tech boom
TechFlash:該要有新的創投模式了(TechFlash:Time for a new VC model

我不是說創投產業真的有問題,創投裡多得是頂尖的人才,他們經驗豐富,會不斷修改模式與進步,台灣就有許多好創投仍是獲利很高的,但我的意思是,目前的時局讓創投必須更加更加謹慎的挑案子了。

既然這次IDEAS SHOW主打Web 2.0創業,那來談談Web 2.0吧!看了DEMO今年得名團隊的履歷,我的感想是,矽谷過去這20年中,成功的放手硬體製造業,建立了軟體產業;目前紅的公司,Microsoft,Google,Apple,vmware,Amazon,eBay,Oracle,Facebook,都是軟體公司,IBM也賣了筆電部門,成功地買了Rational / Watchfire,轉型成了軟體公司,Sun 被 Oracle 買了,HP 最大敗筆是併購了 Compaq,但是目前也轉型得不錯,併了 Mercury / SPI Dynamics 等等軟體公司,漸漸轉型成功。

Web 2.0所帶來的機會,矽谷的團隊是早就準備好來接收了。整個過去20年的成功軟體產業,創造了無數對軟體有經驗的軟體創業家,中高階軟體主管,以及投資人。等到 Web 2.0 機會一出來,這些人風起雲湧,熟悉軟體產業的創投,可以很快地看懂技術,評估股價,之後也有各種管道幫公司,找人才,找客戶,找買主;熟悉軟體創業的創業家抓準機會,有了好的IDEA,立刻運用其經驗與人脈網路,創立公司搶佔市場。這些連續創業家通常也不是個人,而是一個團隊。這些團隊以前早就出生入死,打了很多的硬仗,彼此有默契,有信任,知道如何一起工作。

反觀台灣,我們的硬體製造業生態也是如此,絕對可以算是全球頂尖;投資人,創業家,中高階主管,都是身經百戰,實戰經驗無數。說實在我一直很喜歡台灣製造業的文化,謙虛,踏實,嚴謹,有辦法在低利潤中,穩定獲利成長。這是多麼紮實的文化,是我們這20年努力來的文化。我們的軟體產業,是否也有這種文化?

等到 Web 2.0 來了,看到了各種的機會,我們也想要掌握,可是我們不像矽谷,有過去20年的軟體基礎。熟悉軟體創業的投資人在哪裡?團隊在哪裡?都比較少。過去軟體產業並不那麼發達的我們,要如何搭上Web 2.0所帶來的機會?我感覺這是目前的挑戰。

Web 2.0 對於創業家來說,是一個新的好機會,尤其對於年輕人來說。Why?因為成功所需要的資源,相對少很多。硬體製造業,要建廠房,要設備,要原料,要庫存,資金都是用10億為單位在算的。Web 2.0 不用,只要掌握市場需求,很年輕的團隊就能做出很好的網站--台灣的無名小站大家都知道,另外MySpace於2005年賣給Fox時,創辦人Tom Anderson才35歲,Kevin Rose 27歲時創辦Digg,Joshua Schachter 29歲時創辦del.icio.us,Biz Stone 33歲時創辦twitter,Mark Zuckerberg 20歲時創辦Facebook,噗浪團隊平均年齡也在25歲以下

那麼為何年輕團隊仍然不易取得資金?以下是一些值得思考的數字:

* 創投每1000份business plan,平均只會選6份。
* 這六家「千中選六」的公司中,只有10%會上市。
* 這六家「千中選六」的公司中,30%(1.8家)會被低價收購或變賣資產。
* 10%才會成為高獲利,也就是一千家中,六家選中,然後只有0.6家可以高獲利。



資料來源:J.L. Nesheim (2000), High tech start up: Creating successful new high tech companies


加上自從金融風暴後,創投產業被媒體嚴重質疑,加上金融業大受影響,導致目前創投產業萎縮嚴重,裁員的很多,還有資金的,當然投資會異常小心。花資源去一次DEMO Conference,他們要找很有把握的團隊,即使不能中樂透,至少不會輸光,即使輸了,對金主(除了evergreen或corporate VC,大部分創投的錢也是跟金主募來的)也能交代:這團隊成功這麼多次了,怎料到會輸?如果賭上沒有經驗的年輕人,失敗後會更加被質疑。因此有成功紀錄與多年業界經驗的創業家,以及已經證明能成功獲利的新創公司,在DEMO Conference這種媒合平台中,更顯得吃香了。

可是 Web 2.0 所帶來的--低資金的創業,小團隊做大事的機會--年輕但是有很好點子的團隊要如何能夠搭得上?

我也沒有答案,畢竟我不是這方面的專家。但是我們想一想,即使有了資金,成功的關鍵在哪裡?我想一下幾點都是:

1. 對於市場與客戶的了解--客戶究竟要什麼?
2. 經營模式為何?如何能生存?
3. 對於關鍵技術的掌握。好的IDEA很重要,可是如果能配合高門檻的關鍵技術,不怕別人模仿,就更穩當了。
4. 人才是否到位了?技術人才?行銷/SEO人才?高階管理人才?資金規劃人才(如何與投資人互動)?整個團隊是否有默契,有一起出生入死的工作過?是否有一起經歷大風大浪,同甘共苦過?

以上這些,如果都有明確答案,會減少投資人的風險,增加他們的信心。而這些似乎都不需要資金來建立,平常就可以一步一步建立了。等到這些都建立了,如果run下去真的可行,那麼我想找資金並非難事,也不一定要靠哪個活動幫忙。相反,如果都還不具備,即是得了某某活動的第一名,還是不容易募得資金。即使募得了,投資人也會因為只信任團隊的技術能力,不信任管理能力,而要安插有經驗的管理階層,這不見得是團隊想要的。公司本身也不容易成為那六家公司中的那0.6家成功者。

沒有錯,Web 2.0讓年輕技術人在創業的過程中有了更多的優勢。但是不是說只要有好的點子,就一定容易募到資金,容易成功。以上提到的許多年輕的成功創業家,其實背後都有不少矽谷創業前輩的經驗分享與種種幫忙(投資人也會幫很多),公司內部也不乏非常有經驗的軟體管理人才協助年輕創業家所缺少的經驗。職場與創業,就像是網球比賽或賽車一樣,積分高的不用打會外賽,排在前面起跑。但是只要有實力,其實就沒什麼好怕的,大不了從會外賽開始打,一路打到冠軍,這種回憶不是更美好?

這樣想,只要能參加IDEAS SHOW,是否有得名也就沒那麼重要了。事實上有打球賽的都知道,比賽運氣也很重要,得名與否並不一定代表實力。阿碼目前運氣一直很好,被選上參加的創業平台包括了:2006 Venture Forum,2007 Red Herring Asia 100,2008 Red Herring Global Innovator's Pit Top 10,2008 DOWJONES VentureWire等。其中 Venture Forum 與 DOWJONES VentureWire都是資策會輔導我們參加的--這邊再次感謝資策會的長官!參加這些活動,我覺得最大的收穫是人脈的建立--而且不是創投,不是媒體,也不是任何有名的人。我指的是創業家的社群。創業需要太多的經驗,很多都是我們沒有的,可是這些書本上根本學不到,太多東西,除非你在圈子裡,不然別人根本不會跟你分享。一旦去了Venture Forum,你就是Venture Forum的alumni(校友),去了Red Herring,你就是Red Herring校友,去了IDEAS Show,你就是IDEAS Show的校友。我們因為去了Venture Forum,得以認識Taiwan Liposome的創辦人兼總經理George,那年他們不但上了Red Herring Asia,還是封面故事。等到隔年我們要投稿時,George超夠意思的將他去年的投稿文件直接給了我們,不但教我們如何投稿,更教我們投稿後要如何準備演講,以及活動中我們應該往什麼方向努力,合理的期待是什麼,值得花多少資源等等。之後我們也教了後來申請的團體。

我們去DOWJONES VentureWire時,認識了當時已經從skype創辦人創投ASI募資成功的AirDio創辦人Wen,後來我們跟ASI的互動過程中,Wen幫了很多忙,讓我們能很快認識這家創投,也幫助了雙方快速建立了合理的期望。

創業家的圈子就是這樣子。你要知道,你是創業團隊的一部份,你就流著創業家的血,你就會講一種語言,是只有創業家會講的,是別人聽不懂的。公司做什麼事情都資源不夠,怎麼辦?對手都比我們大,我們雖然技術好太多,可是品牌就是輸,怎麼辦?怎麼跟創投打交道?創投的招數有哪些?同事的父母常問他,明明能去IBM/Google,為何來我們公司,要如何回答?資金該如何規劃?沒錢打廣告,有什麼好的網路資源可以運用?我技術出身,管理經驗不足,該聘CEO嗎?

創業社群中大家總有聊不完的話題--而這些話題也只有這個社群能聊得起來,所以在這些活動中,或後,你可以盡量放馬問問題,對方通常會很願意回答。之後你遇到事情,也隨時可以問大家:這家創投好不好?這篇Gartner你有沒有?Red Herring上了,值不值得買機票去?要投入多少資源?能獲得什麼?多付錢可以擺攤,有必要嗎?Red Herring當期雜誌上可以買廣告,效果怎麼樣?我有時看到一個公司的business plan presentation,覺得真是做得太好了,會立刻上去問,你們花多久時間準備?怎麼練習的?簡報檔是誰做的?某某數據是哪裡來的?

我們自己簡報,也會看台下誰比較專心,然後事後問他,你覺得我們做得怎樣?你覺得我們有表達清楚嗎?你覺得哪裡讓你喜歡,哪裡讓你保留?如果對方也是創業團體,那麼給你的意見絕對會跟一般人不一樣。這次資策會辦的IDEAS SHOW,我們報告完,也很幸運地找DEMO Conference的總監Chris Shipley的空檔時間,希望她批評我們的簡報(感謝資策會能邀到她來台灣啊!)。她的批評可說是一針見血,幾句話表達了我們長久的苦處:「你們解決的問題,不容易簡單表達」。而更厲害的是,她竟然直接給了我們答案。她說,由於Web 2.0的蓬勃發展,導致網站如雨後春筍般出現並長大,但是資安問題無法解決,也讓Web 2.0商機受到了威脅。你們的HackAlert除了在技術上很創新外,商業模式也創新地利用了SaaS模式,走雲端的方式幫企業守護網站,監測網站掛馬。問題是,在這種場合,六分鐘內,你們要顧慮台下為一般end-user,不熟悉網站掛馬,所以你們要解釋,瀏覽被掛馬的網站,會被植入惡意程式,會偷密碼等等,這樣一般人比較聽得懂,但是回過頭來,你們的產品卻不是給end-user的,是給企業的。這中間必須有一個轉折,而你們是否能成功於六分鐘內清楚傳達觀念,關鍵就在於如何做這個轉折。此外,HackAlert只是監控掛馬,並不能解決問題,所以你們要強調,阿碼有源碼檢測CodeSecure,可以找出網站的漏洞,解決問題。

Wow!他才聽六分鐘,看過我們的資料,就很清楚HackAlert做什麼,CodeSecure又做什麼,還能講出源碼檢測(static analysis)、網站掛馬(drive-by downloads),比很多美國的產業分析師還猛,真是太強了,不愧是DEMO Conference執行總監!後來她給我們的建議也都是一針見血,讓我們覺得真是收穫很多。

不過,要有這些收穫,不但不一定要在IDEAS SHOW上得名,甚至也不一定要能去IDEAS SHOW這種平台--譬如之前HappyWeb辦的Demomo Show(規定就是「該網站/服務的程式開發團隊必須在三人以下),或bof.tw,都是很適合的活動,可以達到展示,交流與經驗分享的目的,或許認識到的人,還更懂Web 2.0之道,更有幫助。也許此類活動,到場的創投不比DEMO Conference或IDEAS SHOW來得多,但是Web 2.0吸引人的地方,不就是創業不需太多資源嗎?為何一開始就一定要找資金?還有,我覺得一些新創公司起來後能強很久,跟文化很有關:資源短缺會迫使團隊孕育出一些很好的文化(苦笑)。這邊介紹一些我覺得好的資源給各位,這些都能幫助創業團隊在最小的資源下達到最大的效果:

1. 創業家手冊:第一次創業家的59個資源(The Entrepreneur’s Handbook – 59 Resources For First Time Entrepreneurs)--從資金到BP範本到網站到行銷到HR到法律資源都有,整理得很完整,又不浮濫--台灣有類似的文章嗎?麻煩推薦一下,感謝!

2. TheFunded.com:創業家交流平台,註冊要經過審核,只有創業家與投資人兩種身份能註冊。不登入也能看到「public」文章但是「private」文章看不到。最寶貴的資源是創業社群對於創投公司與創投公司中每位個人的即時評論。律師、專利事務所與兼職美工都是常見的問題。另外每天都有團隊分享他們拿到的termsheet,所以你可以大概了解,在哪一區(歐美亞)的哪個產業的什麼樣規模的公司,目前拿到的股價大概如何。

3. 創投的前十大謊言(The Top Ten Lies of Venture Capitalists

4. 跟創投打交道的十個訣竅(10 Tips On Negotiating With VCs

有好的資源的讀者也麻煩不吝提供!

但要特別提醒一下,網路上的東西,由於是公開資訊,沒法太深談,所以創業社群中才是主要能學到東西的地方。有經驗的投資人,也是大寶藏,所以碰到他們時,不一定目標要設定為要他們投資,讓他們花時間給意見,也是很值得的。

雖然募資永遠不易,但令人慶幸的是,軟體產業正帶來前所未有的機會,Web 2.0創業不說,光是傳統的軟體公司,對創業家來說就有一個很明顯的好處:所需要的資源遠比硬體創業少,所以通常軟體公司中,團隊持股都很高,影響力也就高;畢竟,軟體公司的價值就在於人。以下圖表為知名傳統軟體公司於上市前之團隊/投資人持股比例,資料來源:Saratoga Ventures Finance

創業永遠是一條艱辛的路,但想要創業代表你有著豐富的信心、實力與創造力。在創業的過程中,每一步努力都會有一步的收穫,共勉之!

阿碼科技Matt與Wayne

Matt聯絡方式:matt__鼠__armorize點com

繼續閱讀全文...

2009年7月22日

暑假0day掛馬盛期,網友們要小心!

最近接二連三爆出很多 0day 漏洞,讓擅長利用網頁掛馬攻擊手法拓展「業務」的地下經濟,突然又熱絡了起來,也造就新一波的掛馬高峰期。這幾天聽到幾位朋友跟我說作業系統已經更新到最新了還中木馬,於是請他們丟些可疑網址給我看看,略為分析了一下某網站,上面主要是被插入這串: (網址加上*號,防止不小心點到)

http://ok**.org/z.js

,繼續追蹤發現主要的網馬都包含在這網頁裡面:

http://6****.com/aa/a3a.htm

,接著我發現了一件事情 「挖!好牛喔!」 以前看到的網馬裡面還會放一堆老舊的 Exploit,而這隻網馬我分析了一下,看到都是近期爆出的 0day 漏洞,主要攻擊以下的漏洞:

1.DirectShow的DirectX NULL Byte Overwrite Vulnerability 請參考 這裡
2.DirectShow MPEG2TuneRequest Stack Overflow Exploit 請參考 這裡
3.FireFox 3.5 (Font tags) Remote Heap Spray Exploit 請參考 這裡
4.Microsoft Office Web Components (Spreadsheet) ActiveX BOF (注意!微軟尚未更新)

以上網馬都是下載同一隻木馬,路徑在: http://ho****8.com/svchost.exe 。 (註:下載惡意程式的路徑會一直改變)




以下針對每隻網馬做觸發測試 (危險動作,請勿模仿)



1.DirectX NULL Byte Overwrite Vulnerability
2.DirectShow MPEG2TuneRequest Stack Overflow Exploit

可以在 test.htm 裡面看到有兩個 jpg 分別為 go.jpg 與 go1.jpg 就知道這是最近的 DirectShow 漏洞,go.jpg 利用的是 DirectShow 6月份爆出來的第一隻 0day ,可參考這裡 ,而 go1.jpg 利用的則是最近很紅的弱點,不過微軟上禮拜二已經修正了,我們同事之前也有談到相關內容: 3b3.org 在 0 Day 的大復活日記

以上弱點的解決方法:透過微軟更新。

3. FireFox 3.5 (Font tags) Remote Heap Spray Exploit

我在測試環裡面使用了 FF3.5 BETA5 版 成功觸發 Exploit,下面有一系列截圖。

he.htm 就是 FireFox 3.5 (Font tags) Remote Heap Spray Exploit

h.js 就是駭客的呼叫遠端惡意程式的 Shellcode。

此圖為利用 FireFox 3.5 beta4 瀏覽 he.htm 時,在 Process 可以看到在 FireFox 下悄悄的執行了惡意程式。


解決方法: 將 FireFox 更新為3.5.1 就可以了,但現在也有針對3.5.1的漏洞,所以我們自己還是要小心一點,隨時注意更新或使用第三方軟體(如 NoScript)防範!

4.Microsoft Office Web Components (Spreadsheet) ActiveX BOF

測試環境是安裝最新版Office 2003 版,並更新到最新,仍觸發成功。

一開始使用 IE 打開 of.htm 這個網頁,首先他會先判斷你有沒有安裝 Office ,假如有安裝 Office,且瀏覽器的安全性設定裡面的 執行 ActiveX 控制項與外掛程式設定為「啟用」,那瀏覽到惡意網頁時,會不知不覺直接下載一個 Microsoft 元件 owc10.dll,然後執行呼叫遠端的的惡意程式到本機執行,這樣就中木馬了!

假如執行 ActiveX 控制項與外掛程式設為「提示」,則瀏覽惡意網頁的時候,會跳出視窗詢問「你是否同意執行 ActiveX」,只是,一般使用者應該都會閉著眼睛直接按下同意吧!

而我的測試環境是在 IE 上裝了 add-ons 來測試,在瀏覽惡意網頁時一樣會在 IE 跳出一個 ActivX 請求在瀏覽器上安裝 owc10.dll,然後與絕大多數使用者的反應一樣按下 Run ,接著就觸發駭客寫好的 shellcode ,騎著可愛的小馬回家了!

解決方法:目前微軟尚未發佈更新,只能等待,使用者要提高警覺,不要看到對話框就按「是」!






總結:
1.這一次分析的網馬上面所利用的各種 Exploits 都是最近爆發出來的新弱點,雖然有些已經發佈更新了,但是我相信一定還有不少使用者還沒有更新系統,原因可能是盜版或是懶得更新等等,這樣造成了瀏覽網站的風險始終高居不下!

2.這次測試,比較花時間的部份都是在整理測試環境,這些網馬觸發的機率都很高,也不需要很嚴苛的條件,使用者要提高警覺,注意更新或使用第三方軟體(如 NoScript)來保護自己的瀏覽行為。

3.對於瀏覽網站過程中,出現莫名其妙要您的 IE 瀏覽器接受 ActiveX 下載 dll時,請千萬要注意,不要隨便同意 ActiveX 下載,以免遭植入惡意程式,騎著小馬回家!

4.擔心自己網站被掛馬,可以註冊免費HackAlert網站掛馬監控帳號

作者Sun為阿碼科技資安顧問


繼續閱讀全文...

2009年7月20日

誰在看我的噗?第四回:我噗誰在看!



微型部落格」在網路上已經熱鬧好一陣子了。你噗了嗎?噗!是噗浪還是叭噗咧!

誰在看我的噗?前三回已經介紹頗多的「微型部落格」本身經常會遇到的問題,我們部落格上之前也有詳細介紹「twitter」所遭遇到的攻擊問題,可以參考這裡OWASP 排行榜上的第一名看來並非浪的虛名。

這篇文將會從使用者的角度來看「微型部落格」所帶來的衝擊,在說明前還是要回顧一下「網站」發展的過程,回顧歷史才能展望未來。不過,這裡我還是要強調一件事:網站攻擊不是現在才有,它一直存在,只是當今其他問題(如蠕蟲、系統漏洞攻擊)大多獲得控制(如線上更新、入侵防禦設備),而你的網站卻一直沒有進步,當然成為標靶了。

「網站」發展的過程,我大概以兩個時間為分界點:2000年及2005年。在2000年以前談的網站大多是所謂的 ERP(企業資源規畫)、EIP(企業資訊入口)、CRM(客戶關係管理)、KM(知識管理)...等,況且哪時這類系統還有許多並非以網站來呈現的,且那時大多屬於封閉型的系統或網站型態,因此大部分躲過了威脅攻擊。

2000年後網路興起,「E化」是當時相當有名的名詞,也是動詞的哩,而網際網路公司可以說是紅到不行,當時股市衡量股價是否合理的方式是用本益比,但對網際網路公司是用「本夢比」,這樣你應該該可以想像網際網路公司即使虧錢,股價依舊高漲不歇,因為夢想多大、股價就有多高。這個時候大家談論的網站是啥呢?大家回想起來了嗎?B2B、B2C、C2C,還有物流、金流、資料流...,是否回想起來了呢?

B2B:大多是整合企業上下游之間的網站系統,這類網站大多封閉,是比較不容易出事,但不代表比較安全,因為會接觸到這邊的,大多可能屬商業間諜,行動隱密也低調;就算出事,業主本身也會相當低調,外界不會知道發生啥事。如果企業主發現你的對手對你的行銷、企劃...等有瞭若指掌的情況,可能要注意這類資訊系統的入侵可能性了。

B2C:簡單的說就是購物網站了,這點大家就應該很熟悉了吧。發生哪些資安問題呢?大家不會忘了吧...XD!google大神的開示。至於政府單位的 B2C ...XD,參考這篇吧。

C2C:簡單說就是拍賣交易網站了。造成哪些問題呢?簡單說就是「詐騙」、「詐欺」的社會問題。

在這個階段,另外有個神奇的東西,它本身不是網站方式呈現,但卻造就不少「釣魚網站」,對!就是 IM(Instant Messaging) 軟體,且它到現在還是很紅。
你!出賣朋友嗎?
網路上交朋友要小心
騙取MSN帳密的釣魚網站...真多!!

2005年之後,所謂的「網誌」大量出現,也就是所謂的部落格(Blog)、網路日誌、博客...等等。在前一波網路泡沫之後,Web 2.0 的觀念,帶動了許多網站的興起。這時你應該能想到很多網站吧!文字的部落客就像我們阿碼外傳一樣,圖片的無名相簿網站,影音的 YouTube網站。在這個時候產生哪些問題呢?其實機乎不是資安問題,大多是社會問題,文字部分涉及言論自由、圖片部分涉及個人隱私或私密、影音部分多是犯罪實錄...XD。可以發現網路與生活越來越緊密了。

Web 2.0 簡單說,就是有個網站提供一個平台,讓使用者可以自己產生內容,並與其他使用者之間進行互動的一個網站。

2008年後開始出現「微網誌」,讓使用者與其他使用者的互動更加緊密了。所以有 PlurkBuboofacebooktwitter...的出現。而 XSS 漏洞透過這類社群網站獲得重生了,因為社群網站使用者眾多,XSS 蠕蟲可以在一天之內感染數萬個使用者,甚至造成社群網站服務的效能崩潰。這只是資安問題的。我擔心的是另外一個問題。

B2C 的時代,大家已經把個資瘋狂的送到網路上,個資都已經外洩光了,Web 2.0的時代大家又把私密照片、或是犯罪實錄的影片給 Post 到網路上了。現在呢?噗阿噗!!大家把自己的行蹤、心情、喜怒哀樂、觀點...一大堆潛在人格特質給 Post 到網路上了。原來,在網路上要了解一個人好簡單啊。

微型部落格可能造成:陌生人比你媽還了解你,甚至,陌生人比你還了解你自己;而你卻還不認識隔壁老王。小心有心人的,當遇到難纏的對手,如果還涉及感情,哪可就麻煩了。

社交工程術的發展會將會更加極致,一旦詐騙電話更加了解你,不再是你熟悉的詐騙電話?一旦梁上君子熟知你的行蹤,不用在你的信箱、門牌做記號,上網就知道你在做啥?你該如何全身而退...網路真是讓人又愛又恨!!

作者 Crane 為阿碼科技一員
系列第一篇:誰在看我的噗?第一回:DOM沙盒 vs 跨網站腳本漏洞(XSS)
系列第二篇:誰在看我的噗?第二回:IE執行模式 vs 跨網站腳本漏洞(XSS)
系列第三篇:誰在看我的噗?第三回:弔詭的過濾函式
系列第四篇:(本篇)誰在看我的噗?第四回:我噗誰在看!

繼續閱讀全文...

2009年7月17日

誰在看我的噗?第三回:弔詭的過濾函式


(本文感謝 armorize parser 團隊 Chris, Eric, Steven, Wing 與 ASF 團隊 Kuon 的意見)

泡咖啡或茶的藝術,我稍微接觸過一些,很有意思,每一個部分都很講究,從水、豆子或茶葉、到器具、時間等,每一個環節的掌握,決定了最後享受的品質。

有在品嚐的朋友都知道,其中常被忽略但是卻是關鍵者,就是過濾方式。以茶來說,不好的濾網可以直接喝到金屬的味道,所以有些人會把沖泡器的濾網拆除,寧可茶中有些茶葉。以咖啡來說,紙濾網會有味道,另外吸油能力太強,會讓咖啡少了原本的濃郁。很多人因此喜歡用金(或K金)濾網,雖然貴,但是金穩定,比較不會有異味,泡出來的咖啡跟紙濾網喝起來完全不一樣。可是金濾網除了價格高以外,很多廠商的技術不到位,濾得不乾淨,常讓咖啡渣漏到咖啡中,那就大大破壞興致了。就連自己做豆漿,最難的部分還是過濾機制的設計。要做一個好的過濾器,並不容易。

在Web資安中亦是如此。前面我分享了「誰在看我的噗?第一回」與「誰在看我的噗?第二回」兩篇,裡頭提用了噗浪的一些跨站腳本攻擊(XSS)漏洞來做範例。當初噗浪雖然有過濾CSS中的「expression」,但是改其中一個字的大小寫,例如「eXpression」,就繞過噗浪的過濾機制了。

回報給噗浪後,改好了,我這次,恩,的確改好了,現在不論是「Expression」、「eXpression」或「exPression」,都會被阻擋起來。於是我就試了下面這個字串:

「ex/**/pression」

IE的CSS parser,會將「/*」與「*/」當成是註解,將中間的字串都拿掉,於是「ex/**/pression」還是變成了「expression」,會執行javascript。測試發現噗浪並沒有偵測這種形式(pattern),於是又回報他們。以下是一些可能的變形:

「ex/**/pression」、「ex/**/p/**/ression」、「e/**/x/**/p/**/r/**/e/**/s/**/s/**/i/**/o/**/n/**/」

噗浪改好後,我測試,嗯,真的改好了,以上這些形式都會被阻擋起來,確定改好了。接下來我測試「ex/*armorize*/pression」,發現繞過了噗浪的檢查。原來噗浪沒有注意到,「/*」與「*/」中間可以加任何的字串,於是又回報他們。以下是一些可能的變形:

「ex/*armorize*/pression」、「e/*A*/x/*B*/p/*C*/r/*D*/e/*E*/s/*F*/s/*G*/i/*H*/o/*I*/n」、「e/*/*/*****///"hello"*/*/*/xpression」

噗浪改好後,我測試,嗯,真的改好了,以上這些形式都會被阻擋起來,確定改好了。接下來我想,該不會噗浪的過濾機制,是以「行」為單位的吧?於是我測試:


ex/*
*/pression

中間換行,發現又繞過去了。註解中間雖然有換行,IE還是會執行expression後面帶的javascript,可是噗浪是以「行」為單位進行過濾,所以又被我繞過去了。於是我又回報他們。以下是一些可能的變形:

ex/*
armorize
*/pression

ex/*
XSS**/**/*/pression

噗浪改好後,我測試,嗯,真的改好了,以上這些形式都會被阻擋起來,確定改好了。這是我仔細想,噗浪是如何做過濾機制的呢?最直覺的作法,應該是用正規表示法(regular expression)來過去,並採以下步驟:

1. 以整個CSS為單位,移出「/*」與「*/」以及中間的字串(因為是註解)
2. 偵測「expression」的各種大小寫形式

恩,那麼,如果我用以下的一段CSS呢?

X{"/*"} expression() X{"*/"}

上面這樣的CSS,對於IE來說,由於文法是可以接受的,另外「/*」與「*/」被包在雙引號內,所以IE不會視為是註解。可是對於此時噗浪的過濾機制來說,過濾機制的第一步會將「/*」與「*/」以及中間的字串移出,所以經過第一步後,噗浪看到的是:

X{""}

沒有「expression」的存在,故判定是合法沒有惡意的CSS而接受。實際上測試,正是如此,而我這個新的CSS攻擊,又繞過了噗浪此時的過濾機制。於是趕緊回報噗浪,噗浪改好後,我測試,嗯,真的改好了,這種形式都會被阻擋起來,確定改好了。可是我仔細一想,不對,目前最新的過濾機制應該是這樣,那麼如果我寫這樣,應該又可以繞過,結果果然。於是我回報,不過到這次,已經不是那麼容易可以改了,甚至要考慮一下以正規表示法(regular expression)為基礎的CSS過濾機制,到底有沒有辦法做到安全?過了兩星期問題還是沒修好,我這邊就不探討實際的字串了。

算一算到目前為止,攻擊已經變形了七代了。如同Twitter Mikeyy蠕蟲變形了多代一樣,如果今天同樣有駭客要攻擊噗浪,那麼已經變形七代了,可以做七波的攻擊,每一次攻擊都可以是蠕蟲或是偷受害者的cookie(然後以該身份登入噗浪)。另外很有趣的是,噗浪的第二代過濾機制,其實是可以阻擋第六與第七代的變形攻擊的,因為該機制只是單純地檢查有無「expression」的各種大小寫形式存在。可是之後,噗浪為了要應付第三代攻擊形式(「ex/**/pression」),而導致改進後的過濾機制反而會被第六與第七代攻擊形式繞過(X{"/*"} expression() X{"*/"})。

從噗浪的一系列攻守中我們可以獲得以下結論:

1. 設計一個正確的過濾機制是不容易的。找到漏洞不表示可以正確修補。
2. 修補的過程中,很有可能導致新的漏洞產生。


在這邊順便問一下,有沒有網友有興趣寫一個CSS的過濾函式?如果願意與我們一起研究,我們可以一起公開一套針對CSS的開放源碼過濾函式。

CSS的過濾函式,真的可以用單純的正規表示法(regular expression)之字串比對機制來完成嗎?

我們先來研究一下,到底IE是如何處理CSS的。第一,「ex/**/pression」==「expression」到底是否合於CSS2的文法(grammar)與語意(sematics)?我們看一下W3C對於CSS2.1的定義中,註解(comments)這段

Comments begin with the characters "/*" and end with the characters "*/". They may occur anywhere between tokens, and their contents have no influence on the rendering. Comments may not be nested.

「註解以 "/*" 開始,以 "*/" 結束,可以存在於任兩個 token 之間...」既然是任兩個token之間,那麼「ex/**/pression」根本不應該等於「expression」,而要被分成「ex」與「pression」兩個token。實際上W3C對於CSS2.1的文法定義也反映了這點。

如果是單純用標準的lexer與parser來處理CSS的話,ex/**/pression一般來說會被切成兩個token,而要認識「ex/**/pression」為「expression」的話,需要特別花功夫重組token。我認為IE不是這樣做的。我認為IE目前的CSS處理模組,包含了一個或多個的preprocessor,然後才餵給一組lexer與parser。前面的preprocessor可能也是用lexer與parser組成,但更可能只是用正規表示法(regular expression)之字串比對機制來完成。這樣的設計造就了在IE裡,「ex/**/pression」==「expression」的錯誤。

可是說IE錯了,沒有用,因為「ex/**/pression」在IE中就是會執行javascript,攻擊就是會成功。所以我們這篇探討的過濾機制,重點變成了,「如何了解各家瀏覽器對於CSS的處理機制,並實做一個模擬函式,來做資安過濾」。

這個就難了,因為各種歷史因素加上一開始CSS的定義並不明確,各家瀏覽器對於CSS的處理可說各顯神通,怪招一堆。舉個例子,雖然CSS中並無定義,但是以往非IE瀏覽器(FF、Safari、Chrome)對於「//」這個註解掉本行的語法,也是支援的;IE則不支援。可是到了IE8時,突然決定在「IE8標準模式」下時,跟其他非IE瀏覽器一樣,支援「//」。於是以下CSS,用非IE瀏覽器瀏覽,以及用IE8在「IE8標準模式」下瀏覽,背景會是紅色的(支援「//」),但是用IE<8或IE8在「IE7標準模式」瀏覽,背景會是藍色的(不支援「//」):

body {
background-color:red;
// background-color:blue;
}

那麼我們在寫過濾器時,到底要不要把「//」當成行註解呢?

又舉一個例子,以下這個CSS,在IE5/MAC,以及在IE8 beta 1上,中間的「@import」會被執行,但是在其他瀏覽器,包含IE8正式版中,則會被當成註解:

/*\*//*/
@import...
/**/

這主要跟lexer/parser或proprocessor在處理CSS時所採用的優先順序(operator precedence)有關。IE5/MAC與IE8 beta 1 是如此解讀的(資料來源:stopdesign.com

(1)的「/*」被視為是註解的開始,(2)的「\」將(3)的「*」給escape掉了,所以一直到(4)的「*/」才被視為是註解的結束。(5)的@import在註解外,而(6)的「/*」與「*/」被視為一對註解的開始與結束。

其他的瀏覽器則是如此解讀:

(1)的「/*」被視為是註解的開始,(2)的「\」被視為在註解中所以沒有作用,(3)的「*/」被視為註解的結束,(4)的「/*」被視為第二個註解的開始,(5)的「@import」被視為註解內,而最後(6)的「*/」為結束註解,於是「@import」不會被執行。

反過來看,我們的過濾器如果需要正確識別「ex/**/pression」以及類似變形,就必須正確判斷註解的開始與結束,可是各家瀏覽器在CSS處理機制實做上的不同,增加了我們過濾器的困難度。

事實上,這些各家瀏覽器在CSS實做上的不同,不但大家早就熟悉,還早就被當成「功能」來使用--利用這些不同來有效判斷不同的瀏覽器,讓不同瀏覽器讀取不同的CSS檔。這種技巧叫做「CSS Hack」或「CSS Filter」,大家可以參考 Wikipedia 中的定義,這邊就不多著墨。

但是由於這些差異被當成「功能」來使用,讓錯的一方也不能修正,因為如果修正了,反而很多網站的顯示就要變得不正確了。於是目前瀏覽器廠商只能推出新一代瀏覽器(IE5 -> IE6 -> IE7)時,才對這些bug進行修正。

為何瀏覽器的lexer/parser或preprocessor這麼糟糕?事實上,很久以前大家不就發現,資料庫的SQL處理器也是一樣糟嗎?「se/**/lect」這種SQL注入(SQL injection)手法大家應該都很常用。事實上,MS SQL伺服器的T-SQL處理器以及MySQL的SQL處理器,在這方面也都是有名的...說複雜好了。

雖然攻擊手法並不新,但是從噗浪的七代實驗可以知道,老人雖然很熟,新人還是會不斷地重複採地雷,正確地過濾惡意字串,並非易事。

瀏覽器/資料庫的lexer/parser/proprocessor處理器的複雜與不穩定,不但增加了資安的過濾函式的難度,也同時增加了WAF(Web應用程式防火牆、web application firewall)在實做與設定上的難度。

這些也就是為何,在情況允許之下,程式中應盡量避免過濾機制,而採用參數化機制。你的過濾機制,真的安全嗎?

作者Wayne為阿碼科技一員
系列第一篇:誰在看我的噗?第一回:DOM沙盒 vs 跨網站腳本漏洞(XSS)
系列第二篇:誰在看我的噗?第二回:IE執行模式 vs 跨網站腳本漏洞(XSS)
系列第三篇:(本篇)誰在看我的噗?第三回:弔詭的過濾函式
系列第四篇:誰在看我的噗?第四回:我噗誰在看!

繼續閱讀全文...

2009年7月7日

談談 PHP, WordPress 與掛馬



惡意的PDF檔案一點都不是新聞,過去 doc、flash 以及圖片等都已經被大量利用在 PC 的感染中,但前一陣子在日本以及各地頻傳的事件 (1,2) 顯示,才發現一種綜合型的攻擊組合已經出現,也引起我對於了解後面原因的興趣。

我從 client, server 兩個方面來說明:

1. client

這次利用的攻擊瀏覽器方式稱為 JSRedir-R,它其實是一種攻擊方式的通稱,在友廠的分類說明中可以見到它是利用 PDF, Flash/SWF 的漏洞來讓瀏覽器, PDF reader 或 flash player 直接做為下載器 (downloader), 將後續的其他 binary 安裝到執行這個 JSRedir-R 的電腦上,隨後就開始進行自動側錄,這次側錄的通訊協定鎖定 Web hosting 使用者常用的 ftp,為何這麼做呢? 1. 明碼 2. 登入帳號密碼經常1~2個封包就可錄到。

網路上這篇討論描述了這個狀況,節錄如下:

"One of our clients computers was infected with the client-side portion of the virus. It’s a trojan that monitors all FTP traffic, sending the auth details back to the payload server (gumblar.cn).."

2. server: 這次駭客在想甚麼?



約3個月前,就開始有人在WordPress (咱們就簡稱為WP) 論壇上面歇斯底里的求救, "Seriously, I need your help! " ,很明顯的,他遇到了無論登入 wp-admin 後改密碼或是檔案移除,那一段攻擊程式碼都還是會再被自動加回去所有的 index-files,想必夜不成眠吧。

去年,我們監控到 Mass SQL Injection 的大範圍 SQL 注入,分析了原因是攻擊方利用 Google 的強大搜尋找攻擊對象,但這次不一樣,不需要這麼麻煩,這次駭客不辛苦的打 Mass SQL Injection 了,直接從 web 管理員的電腦直接掛馬側錄、傳回 Bot 監控主機、連到目標 ftp server, 接著自動竄改每一個 PHP 網頁,都可以自動化/半自動了, 然後去逛這些 WP, Drupal 網頁的人,都執行了 pdf 與 swf,若沒做自我保護,會繼續受到 JSRedir-R 的感染,然後被側錄,.. 就這樣一直循環下去, oh my goodness!!

慶幸的是,到目前為止,這並還未演變成 server 對 server 的病毒感染事件,否則可以想像機房內的網路、Web主機眾多的virtual host sites 會變成甚麼狀況,不過這跟 Web Hosting 的架構設計有關,這邊就有另外一種狀況。

既然被補上去 WP 與 Drupal 的源碼是 PHP,我開始將注意力轉向 WordPress 的源碼去,開放源碼的壞處就是容易成為下一個目標,事實上我的同事 Wisely 在兩年前就已經用我們內部的工具檢測過 WP 的兩個主要版本了,兩年多下來,我印象中看到針對 WP 本身新弱點的次數並不多,但 WP 畢竟做為全球著名的部落格發行軟體,為了服務廣大的使用者採用了開放式的架構,並有許多對應的外掛被開發出來,然而這些眾多的外掛卻成了另一大隱憂的來源,光在 milw0rm.com 上就至少有數十個 exploit 被公布,我從中取了一個做驗證,ID為 9048 的這個攻擊是利用 DM-albums 這個外掛:



這個弱點是 Remote File Dislosure Vulnerability,在 OWASP 的定義為 Resource Injection ,我們立即將 config.php 原始擋下載回來:



用 IDE 開來看,wow, 真的是 config.php,可以拿來分析設定與系統架構:



接著我用 CodeSecure 掃了兩次,分別是將 register_global 這個設定關閉:



以及開啟:



都找到跟 dm-albums.php 這個進入點有關的 Resource Injection,其中一條弱點問題追蹤列出如下,很明顯的,至少就有 currdir 這個變數沒有被處理好:



看到弱點這樣多,我真的開始覺得任意瀏覽網站的風險太高了。

以前打 client 端是拿個資、打 server 端是拿主機與 DB,做完就各自結束,但從 5月份的 Gumblar 開始,透過在 WP, Drupal 等 Blog 平台插入 PHP 程式碼的新掛馬手法讓感染來源成指數成長,如果你發現你的部落格的程式碼內出現奇怪的新程式碼,建議趕快用一台乾淨的機器上網改掉密碼並回復所有的 PHP 網頁,然後將受感染的電腦做進一步檢查,詳細做法可參考這篇,若剛好你的部落格也用了不少外掛,建議先搜尋一下有沒有已經被公布的弱點 (關鍵字: "exploit" "vulnerability),然後儘早因應,至少被公開的弱點一定得想辦法剔除。

作者: Walter Tsai 為阿碼科技CTO

繼續閱讀全文...