就是資安

前言 FindBugs 同樣是用來檢測 Java 程式的工具，其檢測的對象是 Byte Code (class 或是 jar 檔)。儘管如此，FindBugs 依舊是屬於靜態分析的方式。FindBugs 如其名，主要是利用 Bug Patterns 的概念，找尋出程式中有問題 (Bugs) 的程式碼 。在其官方的網站中提到 Bug Patterns 的產生可能有下列因素： 程式語言本身不容易使用的功能 (Difficult language features) 被誤用的 API (Misunderstood API methods) 當程式碼在維護時，不變的條件被誤解了 (Misunderstood invariants when code is modified during maintenance) 其他常見的錯誤，例如打錯字、或是使用了錯誤的布林運算元 (Garden varieity mistakes: typos, use of the wrong boolean operator)

前言 PMD 是來執行 Java 程式檢測的工具，檢測的對象是原始程式碼。雖然 PMD 看起來像是一個縮寫字，但是作者表示當初採用這個字純粹只是因為這幾個單字念起來很順口。根據網站上面的介紹， PMD 可以找出下列問題： 疑似的臭蟲 (possible bugs)，例如空的 try/catch/finally/switch 描述句。 無法執行的程式碼  (dead code)，例如未使用的 local 變數、參數、或是 private 函數。 不良的程式碼 (suboptimal code)，例如效率不良的使用 String/StringBuffer 過於複雜的語法 (overcomplicated expressions)，例如不必要的 if 描述句，可以用 while 迴圈取代的 for 迴圈。 重複的程式碼 (duplicated code)，剪貼的程式碼表示臭蟲也被複製了。

這幾年應用程式(尤其是網站應用程式，Web Application)的安全問題受到各方重視，一些新的、舊的概念，只要跟此議題有所關聯都因此而浮上檯面。包含SSDLC/SDL、WAF、Secure Coding、Application Security Scanner等在內的各式各樣工具或規範，試著從不同的面向去解決程式安全的問題。 Gartner 於今年年初出了一篇有關靜態程式安全掃描的市場分析，分析對象為目前市場上主要的玩家。但是這些產品大多所費不貲(除了整在 IDE 中的形式，可能會有免費使用的陽春功能)，而且甚至很多產品在台灣還沒有直接取得的管道。所以我們今天要介紹一些免費的工具，這些工具的共通點就是提供靜態應用程式檢測的功能，而且以 Java 程式語言做為目標。除了可以當作獨立的工具使用外，有些工具還可以透過外掛的方式整合至 IDE (像是 Eclipse)，使用上更加方便。除此之外，各個工具之間可說是具有相當的差異性。檢測的對象可能是原始程式碼，也有可能是 Byte Code。而著重的面向也不一樣，可能是原始程式碼的不良結構，也可能是針對程式不合常理的錯誤，又或者是針對不好的寫作方式。這些問題都跟軟體的品質有關，而品質當然也包含了安全的問題。 這些工具都不是以安全做為訴求的出發點，而且大多也不支援網站應用程式，所以僅能當作增進一般應用程式品質/安全的工具之一，而無法有效的面對現今網站程式開發所面臨的威脅。雖說如此，網站應用程式依舊是屬於應用程式的一種，所以其安全性的問題不應只是考慮到網路的部分，包含基本的程式結構等也是我們應當注意的項目。這些工具部分的檢測功能其實 IDE 本身可能就已經具備，但是以目前現況而言，IDE 主要的功能依舊還在不此，所以能夠偵測的項目相對較少。 在這篇文章中，我先列出這些工具的名稱與簡述。簡述皆為從官方網站截取的描述，所以是英文的形式。之後我會針對各個工具撰寫相關的使用說明，說明時除了做功能的介紹外，也會利用實際的應用程式作為範例。採用的應用程式有兩個，一個是 log4j 1.2.15 ，另外一個則是 struts 2.1.6。如果該工具支援 Eclispe 的外掛，我將會以 Eclipse 作為操作的 IDE 環境。因此我先將兩個應用程式的程式碼匯入為 Eclipse 的專案，透過畫面我們可以看到 Eclipse 本身就產生了很多的警告訊息。我個人認為 Eclipse 提供的警告訊息雖然跟程式錯誤與否無關，但是大多數的建議可以讓我們的程式碼更加清楚、更加容易明瞭。對程式碼而言，這是最重要的要求。因為錯誤不只在開發的時候會產生，在後續的維護中更容易產生。透過清楚而易了解的程式碼，可以大幅降低後續維護時產生錯誤的機會。也因此我個人建議這些警告訊息應該先進行處理，之後再利用其他工具找尋其他的問題。

根據 Trusteer 近日公布的一項報告分析顯示，幾乎所有的防毒軟體都無法有效地阻擋 Zbot 這個用來竊取網路銀行帳號/密碼的惡意程式。比較使用最新的防毒軟體與不使用防毒軟體的結果發現只改進了 23% 的阻擋效果。Zbot 利用了 rootkit 的技術來躲過防毒軟體的偵測。Zbot 除了會竊取資料外，也會讓受感染的電腦成為僵屍網路的一員，並且具有自我更新的能力。 而另外一份由 Trend Micro 所發布的研究報告中顯示，大多數的電腦一旦被惡意程式感染後，將會持續一段相當長的時間，其中超過 50% 的電腦在被感染 10 個月後依舊沒能將之移除。其實這也難怪，因為如果使用者已經安裝了最新的防毒軟體，通常就不會去考量系統被入侵的可能性。事實上，真要考量也可能無從下手。對於沒有安裝防毒軟體的電腦而言就更不用說了，被持續感染也只是”順理成章”。 針對一些比較刁鑽的惡意程式 (如使用 rootkit 技術加以隱匿)，往往我們必須透過其他的安全產品加以防範。例如使用其他開機工具以便進行完整的硬碟掃描，或是利用網路流量分析工具找出可疑的封包與流量。這些外加的方式在使用上可能不若防毒軟體一般方便，但卻是這組防禦體系中不可或缺的一環。傳統防毒軟體的重要性不是完全消失，而是因為其有效性隨著惡意程式的演進而降低，也因此我們再也不能光靠防毒軟體來保護我們的電腦。   相關連結：

根據 Websense 日前一份針對網路安全研究報告中提出的數據顯示，有高達 95% 的部落格留言、聊天室與論壇的內容是惡意或無用的資料。雖然使用者的參與 (尤其是提供資料) 造成了 Web 2.0 榮景，但是也同樣成了有心分子用來散佈惡意程式的重要方式之一。 這份報告收集資料的時間為 2009 年上半年，並將分為網站安全、電子郵件安全與資料安全三個部分，關於網站與資料安全有下列的發現： 惡意網站的數量較 2008 年下半年之數量成長了 233%，而跟 2008年上半年相較更是成長了 671%。 藏有惡意程式的網站中，有 77% 是屬於合法的網站。這些網站因為被入侵，而變成了散佈惡意程式的管道。 在前100大的網站中，有 61% 的網站中包含了惡意程式或是導像惡意網站的連結。 95% 的部落格留言、聊天室與論壇的內容是惡意或無用的資料。 提供有關 Sex 網站連結的網頁中，有 50% 藏有惡意程式。 提供像是 Sex、成人內容、賭博、藥物等內容的網頁中，有 69% 包含至少一個以上的惡意連結。 在 2009 年上半年所發現且提供像是 Sex、成人內容、賭博、藥物等內容的新網頁中，有 78% 包含至少一個以上的惡意連結。 網站攻擊行為中，有 37% 會進行資料的竊取。 資料竊取的攻擊中，有 57% 是透過網站進行的。

根據 SANS 於近日所公布的一份報告中指出，現今企業所面臨的資訊安全問題主要來自於兩個方面。一個是沒有及時更新的用戶端軟體 (Unpatched client-side software)，另外一個則是與網際網路連結的網站 (Internet-facing web sites)。 雖然目前作業系統已經多具備自動更新的功能，甚至企業也可能已經導入了更新的管理工具(如 WSUS)，但是更新依舊是一個令人頭痛的問題。因為現在網路服務越來越多樣化，各式各樣的文件、影音格式已經融入日常的應用中，而用來解析這些資料的應用程式(如 Adobe Flash、Adobe PDF Reader、Microsoft Office)就成了有心分子的重要目標。再加上這些應用程式之前不像作業系統那般容易受到攻擊，所以其開發廠商在安全防護的心力與經驗相對較低，進而造成較多的安全漏洞。 針對特定的應用程式，還有一些特定的問題。例如 Flash 的 Plugin 缺乏自動檢查並更新的機制，而且 Flash 的 Plugin 不但不同的瀏覽器需要分開安裝，甚至有些第三方的應用程式也會自行內附 Flash 的動態連結檔 (dll)。所以光要完全更新 Flash 就是一個艱鉅的挑戰。另外一個常見的應用程式 - Java ，則是因為更新時不會自動移除舊版本，所以會造成使用者產生已避免舊版程式問題的假像。 除了應用程式本身造成的安全問題，還有另外一個更需要急迫面對的問題就是部分企業依舊僅將眼光放在作業系統的更新，而忽略了應用程式更新的重要性。這麼多的問題，其結果只有一個，那就是有心分子絕對不會輕易放過這麼好的”機會”。

雖然有越來越多的廠商與產品試著去解決惡意程式所帶來的問題，但是不可否認惡意程式的威脅與影響依舊越來越大。除此之外，惡意程式也越來越有”創意”，讓這場官兵與強盜之間的遊戲更加精采。儘管惡意程式變化之多，我們仍舊可以將大多數惡意程式的行為(至少)分為兩個階段，第一個階段是感染 (Infection) 階段，第二個階段則是攻擊 (Attack) 階段。 在感染階段中，最重要的事項就是如何避免被發現。在此前提下，其次才是感染的速度與數量。而實際感染的途徑，也從早期的實體方式 (如磁碟片、光碟片等)演進到透過網路的方式。在網路的感染方式中，News Group、Email、IM、Web則陸陸續續被有心人士所利用。今天我們要談的是一種稱之為 Drive-by Downloads 的方式，簡單說來就是讓使用者在瀏覽網頁(或是閱讀HTML格式的信件)時，不知不覺地下載惡意程式並因而遭受感染。也許 Drive-by Downloads 這個名詞對許多人有些陌生，換個說法或許大家就比較清楚，這個說法就是網頁掛馬攻擊。聽起來也許很神奇，但是基本上所謂的”不知不覺”都還是得利用應用程式的漏洞加以遂行。只是跟傳統上利用作業系統漏洞加以感染相比較，現在會被加以利用的則包含了各式各樣的應用程式，尤其是像 Flash 、 PDF 、 影像播放器這類大量被應用在網際網路服務的相關軟體。此外，瀏覽器本身當然也是一個會遭受攻擊的明顯目標。

既然是資安的論壇，我們在這系列的最後一篇文章中就來看看資怎麼下手解決複雜的資安問題。我會用一個假想的例子來加以說明。 假設今天有一個抽獎系統，原本的設計是在每次抽獎時會從所有會員中隨機抽出特定數目的會員致贈出豪華獎品。因為每次抽獎的獎品數量、種類都不盡相同，所以順帶提供了一個後台介面讓有權限的人可以設定獎品的數量、種類、以及抽獎的時間。在一次的抽獎結果中，事後卻意外發現頭獎(百萬獎金)的中獎人與該系統的系統管理員竟是一家人，而此系統管理員已於此次抽獎後的隔天無故離職，而得獎者也已經把獎金領走了。進一步的追蹤發現，此系統管理員到職僅約半年的時間，而且之前的工作經驗都在別的地區。 為了追蹤問題發生的原因，我們必須先找到為何得獎者”剛好”是該系統管理員的家人。是抽獎程式被修改而未被發現，還是抽獎程式執行時被其他程式干擾而產生異常的結果，還是在公布結果前得獎者的資料被置換了，甚至有可能是公布後原先得獎者的個人會員資料被換掉了。經由我們的分析發現，原來是因為程式被修改而未被發現，所以抽獎程式在該次抽獎中”一定”會抽中特定的會員(原系統管理者的家人)。 這次事件發生的"直接”原因被發現後，我們可能的立即反應就是如何避免抽獎程式執行異常(如抽出特定的會員)的行為。但是如果這樣就開始要找解法稍嫌過早了。首先，抽獎程式被修改而未被發現，至少還可以衍生出員工素質不良、程式碼管控不當、沒有做好程式的完整性檢查、CM機制不足等更深層的原因。除了這些原因外，因為系統本身還有其它的管道可供有心份子做手腳，所以如果不一併加以考慮，就算今天補了第一個缺口，其他缺口依舊存在。這也是我在第一篇文章中提到有關解決問題的第四個階段 ─ 避免類似問題再發生。這個階段(避免類似問題再發生)對於資安議題特別重要，原因在於資安問題不像一般資訊系統，就算再小心問題還是會”主動”發生。如果沒有抱持未雨綢繆的心態來加以面對，恐怕不只是疲於應付問題，我想應該是連飯碗都不保才是。 事實上，我們認真的看待所有的可能性後，發現都有一個共通的原因，那就是素質不良的員工。為了因應這個問題，包含員工背景調查、責任劃分(Separation of duty)、Two-man control、定期輪調等管理措施或許是更有效的防範方法。對於程式碼管控，則有責任劃分、權限管控等機制可以運作。

在理想的世界中，我們只要想辦法找出最有效率的解法就天下太平了。但是在現實的環境中，除非問題本身很單純(不一定是簡單)，否則真正”問題”才剛開始。最大的可能性在於，邏輯性的問題變成了非邏輯性的問題，而背後的因素幾乎都跟”人”有關。 舉例來說，如果你是一個工程師，正在解決電腦主機板所造成的當機問題。經過一番努力後，你發現原來是主機板上的音效晶片在播放特定訊號時，會因為處理不當而造成當機。而且你也已經證明是晶片本身設計的問題，而不是主機板設計或相關軟體的問題。更糟的是，這種錯誤沒有辦法經由主機板或軟體的修改加以修正。正常來說，除非修改主機板的功能，否則唯一的(最佳)解法就是換一組晶片。但是很不幸的是此一音效晶片的上游廠商，是公司很重要的夥伴。所以要不要換，能不能換，已經不是單純技術性(邏輯性)的問題，而是政治性(非邏輯性)的問題。相關團體彼此之間的利害關係，成了左右問題解決方案的重要因素。 另外一個可能的因素就是時間因素。幾乎所有的問題都有其時效性，如果解法所需花費的時間大於該問題的時效性，那麼是否需要執行就有很大的思考空間。尤其是當外界對於解決問題充滿了急迫性的期待時， Quick Fix 往往就成了優先執行的項目，甚至有時候得做出一些沒有效果的”假動作”以杜悠悠之口。雖說是時間因素，但是時間的急迫與否同樣是以”人”的觀點才有意義。 除此之外，如果問題的解決方法涵蓋廣泛的範圍(如跨越多個不同的部門)時，為了減少初期遭遇的阻力，我們需要採用縮小範圍的解決方案。待達到一定的效果後，才做更全面的問題解決。縮小範圍的另外一個好處是，投入的資源相對較少，因此較容易獲得相關人士(尤其是CEO/CFO)的首肯。

在前一篇文章中，我們看到解決一個問題的基本做法。但是有一個必須注意的事項就是，通常原因背後還有其發生的原因，或者換個角度說問題後面還有問題(QBQ - Question behind Question)。所以我們必須發現的可能不是一個原因，而是一堆(可參考 Root Cause Analysis)或一連串的原因(可參考 Fault Tree Analysis)。既然如此，我們怎麼知道是不是該往下繼續找出原因背後的原因呢？除非發生問題的事物有明確的邊界，否則這個問題並沒有很明確的分界點，往往得靠自己的直覺加以判斷。不過，基本的準則是至少要把原因分析到你無法掌握或改變的事項。至於解決方法是不是一定要斬草除根呢？我認為倒是不一定，理由後述。 再以程式開發為例。當我們發現交付給客戶的產品 (軟體)有一個程式寫作的錯誤時，除了修改程式外，我們更可以(應該)分析為何這樣的錯誤沒有在交付客戶之前就被發現。所以問題變成了品管的問題，甚至是品質保證、流程管控等議題。這些議題涵蓋範圍之廣，已經足以影響整個工作的流程，而不僅僅是修改程式那麼單純。 當我們找到的是一堆原因時，問題就變得相當複雜。要解決最接近問題的原因、最根本的原因，抑或是有其他的選擇呢？我們都知道從最根本的原因下手，通常可以達到最好的效果，正是所謂的斬草除根。比較好的作法，往往還是從效率的角度來看，只是這時候除了必須評估所需資源與效果之外，也必須考慮到解法本身與原因的交互關係。原因很簡單，有時候一個解法可以同時解決多項原因。