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，換我週末來玩這些！