天下沒有完美的事物,軟體會有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;」的前後,應該要分別加上「{」、「}」括號才對。

 

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


Advertisement

更多 iThome相關內容