應用程式安全性漏洞已成軟體應用大威脅

天下沒有完美的事物，軟體會有Bug，就跟一般人會說錯話、寫錯字一樣，在所難免。然而，隨著當前行動應用與大資料技術蓬勃發展，我們對於應用程式與雲端服務的依賴程度日漸提升，對於系統的可靠度與軟體品質的要求也連帶水漲船高。

不論是硬體或硬體的因素，系統只要出一次包，就可能影響成千上萬使用者。不過，若是一般的硬體設備故障或網路服務停擺，我們尚且能搭配各種高可用性與備援機制，將受影響的程度降至最低，但其中執行的程式一旦有功能性的失誤，甚至有安全性漏洞，想要修正就沒那麼簡單，因為可能要先找到問題所在的程式原始碼、提出解決方法、重新發布調整過的程式或安裝修補程式，甚至有時必須要先讓應用系統離線，才能套用修正的方式，若是牽涉到伺服器端與用戶端程式或設定的重新部署，來來回回之間，往往又要耗費許多時間和人力進行。

對於軟體品質的判斷，通常我們分為功能性與安全性等兩大層面，一般應用程式或系統上線之前，多多少少都會檢核程式是否符合這兩種性質的需求，但比較偏重功能性的驗證，因為要判斷程式執行時是否能滿足需求，相對容易，至於安全性的部份，若開發時沒有考量到功能遭到濫用的可能性，而刻意限縮特定程序執行的條件，之後若被人發現有這樣的漏洞，可能會讓人乘虛而入。

軟體重大安全性漏洞越演越烈

對許多IT人員來說，持續關注系統資安弱點資訊、定期執行漏洞修補，已經成為例行公事之一。從2001到2003年之間，開始有許多惡意程式利用Windows、IE、Outlook Express、Outlook的安全性弱點發動攻擊，肆虐全球個人電腦與伺服器，像是Code Red、Nimda、Blaster、Sasser等蠕蟲，也是在那段時期，微軟強化了Windows XP更新機制與系統防護，並決定在每月第二週的週二定期發布系統更新。

除了微軟，在個人電腦使用率相當高的數位內容格式Adobe PDF和Flash在2009年之後，也因為漏洞而頻頻遭到攻擊，到了2012年、2013年，Java成為新的苦主，2013年1月，美國國土安全部電腦緊急應變小組甚至呼籲使用者，在甲骨文公司推出穩定Java版本前，應繼續停用瀏覽器上的Java功能，然而在2月時，幾家知名的網站和IT公司也都紛紛中招，包括推特（Twitter）、臉書（Facebook）、蘋果和微軟都宣布內部電腦因此遭駭的狀況。

到了今年4月，提供SSL/TLS加密傳輸功能的開放源碼套件OpenSSL，發布Heartbleed臭蟲的重大安全通告，這套應用上相當普及的函式庫，在TLS/DTLS 傳輸安全層的heartbeat（心跳）擴充功能之中，有程式臭蟲，若該漏洞遭駭客利用來發動攻擊，會造成記憶體存放資料外洩，有可能從伺服器端外洩到客戶端，或者由客戶端外洩到伺服器端。

受到該漏洞影響的OpenSSL版本，包含1.0.1到1.0.1f，以及1.0.2-beta，而目前有許多Linux和FreeBSD作業系統都內建OpenSSL，這些版本的OpenSSL已整合其中，因此Debian、Ubuntu、CentOS、Fedora、OpenBSD、FreeBSD及NetBSD當中一些版本，也都遭到波及。此外，因為許多系統與軟硬體產品也採用OpenSSL，或是內建整合OpenSSL的軟體平臺，例如開源的網站伺服器平臺Apache和nginx，所以牽涉到的範圍更廣泛。

例如，就連Google、Amazon的網站服務，以及Cisco、Juniper的網路設備都深陷安全漏洞的風暴，還有VMware的虛擬化平臺與管理軟體、MySQL、MariaDB和PostgreSQL等資料庫系統，以及Symantec、McAfee、Kaspersky、F-Secure、Sophos旗下一些資安軟體的特定版本，也受到影響。

由上面的例子來看，應用程式的安全性漏洞所引發的效應越來越大，而且日益複雜，要在短時間內修復，都需要時間，所牽涉到的軟體性質也日益多元化──從一開始針對個人端電腦的微軟Windows作業系統、IE瀏覽器與Office應用程式，以及PDF、Flash及Java，現在許多網站伺服器、雲端服務運作時所仰賴的重要元件，也被踢爆有軟體安全性漏洞的問題，除了事後要有完善的機制，儘速亡羊補牢，更重要的是記取教訓，做到事前預防，才能夠降低漏洞出現的機率，連帶地，後續駭客如果想要用漏洞來發動攻擊，也會越來越困難。但若要達到這樣的目標，從軟體還沒有釋出、正式上線之前的開發過程中，就要採取對應的作法，目前像是微軟、Adobe、Cisco等公司，都已經發展或導入了所謂的軟體安全開發生命週期（Security Development Lifecycle，SDLC），由於安全性也是軟體品質的一部分，因此，通常都會透過測試的方式，在軟體正式發布前，執行相關的功能與安全性檢驗。

行動裝置成為市場寵兒，也成為惡意程式橫行的新戰場

除了個人電腦和伺服器端會有應用程式安全性漏洞，行動裝置的作業系統平臺和App也都是由開發人員所寫出來的軟體，同樣不可能做到100％無漏洞，而兩個主要平臺Android和iOS，當然也是有心人士鎖定的目標。

以市占比例最大的Android裝置數量來說，市調分析機構Gartner和IDC均預測今年底將突破10億個，因為太過普及，所以，在這個平臺所發展的惡意、高風險或擾人App也是最多。根據趨勢科技全球技術支援與研發中心所發布的《2013年TrendLabs資訊安全總評》來看，2013年底已累積140萬個，單就2013這一年就出現了1百萬個新的App威脅，2014年底預估將突破300萬個，不過在趨勢科技最新公布的《2014年第一季TrendLabs資訊安全總評》當中，他們發現相關的App威脅現在就已經突破2百萬個。

除了App威脅，過去我們所熟悉的網路釣魚網站、垃圾郵件詐騙威脅，行動裝置同樣會面臨，值得注意的是，針對行動裝置平臺的漏洞攻擊也開始增多，例如去年Android平臺爆出MasterKey漏洞（CVE-2013-4787），已經安裝的正常App可能在不知情的狀況下被偷換成惡意程式；另一個攻擊是叫做Backdoor.AndroidOS.Obad的惡意程式，運用類似後門程式與rootkits的手法，透過作業系統漏洞──root與裝置管理者的權限，取得整臺Android裝置的權限；而蘋果的行動裝置平臺iOS6也傳出安全性漏洞，若iPhone或iPad接上駭客所改造、特製的充電座，這個弱點將會授與對方完整存取這個設備的權限。

有些漏洞則可以影響任何行動裝置作業系統平臺，因為問題出在跟所連接的周邊裝置有關，例如行動裝置搭配的SIM卡，當中所採用的舊型加密系統有程式臭蟲，駭客只需傳送SMS簡訊到這臺裝置，即可觸發裝置錯誤，進而釋出56位元長度的安全金鑰，而這把金鑰可以觸發下載惡意的Java Applet，以便散播簡訊和位置監控等惡意行為。

到了今年3月，趨勢科技發現了一個針對Android 4.0以上版本的系統漏洞，它要是遭到有心人士濫用，可能會造成系統不斷重新開機的狀態，如此等於讓行動裝置應提供的各種功能處於失效狀態，無法操作、通話。同月，又出現了另一個自定權限漏洞，它讓App能夠讀取其他App所保護的資料，而這可能會導致機密外洩。

iOS和Mac OS X今年初也出現安全性漏洞CVE-2014-1266，這是跟SSL/TLS加密連線有關的弱點，攻擊者可能擷取或修改連線過程中所傳輸的資料，問題在於傳輸時並未驗證連線的真實性。若未修補這項漏洞，蘋果的行動裝置在連上網際網路時，有可能因此受到監聽及連線挾持。

該漏洞影響的作業系統版本算是不少，包括iOS 6到6.1.4、iOS 7到7.0.5、Mac OS X 10.9和10.9.1，以及Apple TV 6.0和6.0.1。後來，蘋果為此陸續發出iOS 7.0.6、Mac OS X 10.9.2和Apple TV6.0.2的安全更新檔。

程式碼少了括號，系統安全性竟然就破功？

從上述來看，應用程式的安全性漏洞太多了，從個人電腦、伺服器，現在連雲端服務、行動裝置也都遭殃，簡直是野火燒不盡，春風吹又生，然而真的每一個問題都無法事先預防嗎？不能在軟體開發的過程中，就及早發現問題並解決掉嗎？

其實這是可以做到的，有的程式臭蟲之所以產生，甚至只是因為一些小疏忽所造成，前面提到的iOS和Mac OS X漏洞CVE-2014-1266，就是典型的例子，一些專家追本溯源後發現，原本的程式碼只是少了一個括號，若加上去，程式運作就安全了。

這個作業系統的安全性弱點很特別，很多人都叫它「goto fail」漏洞，因為，關鍵在這兩種作業系統資料安全元件SecureTransport安全傳輸功能的sslKeyExchange.c程式碼當中，一支SSLVerifySignedServerKeyExchange函式寫錯了，裡面有兩行的goto fail敘述緊接著執行，第一個goto fail是正確的，它對應到if敘述，但第二個goto fail就不是條件式，不論前面的if條件式是否成立，程式碼總是會執行到第二個goto fail，也就是回傳err，而且也不會執行sslRawVerify函式。

接下來會發生什麼事？Google資深軟體工程師Adam Langley在他的部落格《ImperialViolet》上，透過〈Apple's SSL/TLS bug〉這篇文章，提出了進一步解釋。他認為，這裡的err將會包含1個值，因為SHA1更新作業會順利完成，所以，驗證簽署的作業永遠不會失敗。

此外，這個驗證簽署的作業會檢查ServerKey Exchange傳輸訊息的簽名，這會用在DHE和ECDHE的ciphersuites加密演算集，讓連線能與臨時金鑰（ephemeral key）溝通，伺服器可以藉由自身憑證的暫時金鑰和簽署，讓用戶端知道連線是從這邊而來的。然而，如果臨時金鑰和憑證鍊（certificate chain）之間的連結斷了，一切的驗證和信任關係將會面臨崩壞。因為，在這樣的環境下，伺服器端有可能送出一個正確的憑證鍊給用戶端，卻是以錯誤的私鑰來簽署交握，或者根本就不用簽署就可驗證連線，伺服器無法證明它的憑證裡面擁有與公鑰匹配的私鑰。

基本上，這個安全性漏洞會影響任何使用SecureTransport的系統，但不包括Chrome和Firefox，因為它們都使用NSS for SSL/TLS，然而，這意義不大，因為更底層的作業系統軟體更新機制仍然是用SecureTransport來進行。同時，這個程式臭蟲，也會影響任何使用DHE或ECDHE的cipher suites加密演算法的站臺。

該漏洞倒是不會影響TLS 1.2，因為在當中負責驗證ServerKeyExchange訊息的函式是不同的，然而，為了讓用戶端能接受該訊息，攻擊者還是可以自行挑選任何的TLS版本。一旦用戶端只啟用TLS 1.2，就會解決這個問題，同樣地，如果用戶端只選擇完全以簡單的RSA演算集，也就等於沒有進行ServerKeyExchange的作業，此時，也可以解決該漏洞。

這類的臭蟲一旦出現，要如何偵測出來呢？Adam Langley說，若在蘋果的軟體開發工具平臺Xcode編譯這段程式碼時，可以加上-Wall的參數來啟用所有警示，可以隱約看見出問題的程式碼段落（即便不是使用2013年發布的GCC 4.8.2或Clang 3.3）。因此，他認為若有更明顯的警示，將有助於及時發現這個問題，但這麼一來，對於整體程式碼也會產生誤報率太高的狀況。

相較於每隔一陣子就撲天蓋地而來的各種應用程式安全性漏洞資訊，蘋果爆出這個嚴重危害SSL安全傳輸功能的作業系統漏洞，雖然只是滄海一粟，乍看之下，它似乎是個離譜的微小錯誤，卻能讓網路傳輸不再安全，同時，這個紕漏可能有許多開發人員就算用人工方式逐行檢查，未必能一眼識出，而且，就算透過整合式開發工具，或是程式碼安全檢測工具，也不一定能偵測出來。

此外，也幸好有蘋果願意開放部分版本的系統程式碼，還有發掘出該問題的資安專家，外界才有機會更全面地了解這樣的問題何以發生，並進行充分的討論，從而學到教訓，不再重蹈覆轍。雖然類似這樣的漏洞、甚至更難以發現的漏洞，未來可能還是會出現，但認真研究過這種問題的開發人員，想必將更有機會消弭掉這類漏洞。

除此之外，我們也必須意識到應用程式漏洞遭到濫用的方式，也在轉變。

例如，讓許多網站管理者都相當頭痛的目標式攻擊，駭客通常會設法尋找、利用網站的漏洞，以便取得系統控制權，並在站內植入惡意程式，以便感染瀏覽網站的使用者電腦。

而根據賽門鐵克4月發布的最近一期全球網路安全威脅研究報告（Internet Security Threat Report，ISTR），就2013這一整年而言，最常被有心人士利用的網站弱點是SSL與TLS網路安全傳輸協定的會談重建程序漏洞（SSL and TLS protocol renogotiation），這幾年以來，有不少攻擊事件都跟這有關，例如DigiNotar的數位憑證外洩、BEAST攻擊（Browser Exploit Against SSL/TLS Attack）、SSL會談重建程序攻擊（SSL Renegotiation Attack）、CRIME攻擊，以及Lucky 13攻擊。

這跟今年爆出的iOS、Mac OS X的SSL漏洞，以及OpenSSL的Heartbleed漏洞陸續被揭露，似乎都有一些關聯性，這樣的發展趨勢，軟體開發人員和資安人員需多加留意。

蘋果作業系統出現SSL處理漏洞的原始程式碼段落

在蘋果的開放原始碼網站上，我們可以找到裡面有SSL程式臭蟲的sslKeyExchange.c內容，在SSLVerifySignedServerKeyExchange這支函式中，出現了兩次「goto fail;」，第一個「goto fail;」敘述沒問題，但第二個「goto fail;」的前後，應該要分別加上「{」、「}」括號才對。

相關報導請參考「軟體品質控管亮紅燈 小疏忽可能釀成大災難」