1.3 無法避免的安全漏洞

在實踐當中，人們逐漸認識到漏洞是安全問題的本源。在漏洞面前，攻防雙方井不平等，惡意攻擊者只要有一個漏洞，就可能直搗黃龍，防護者即使發現井消除再多漏洞，也不敢高枕無憂。

1.3.1 層出不窮的0day漏洞

每年，安全研究人員、愛好者、黑客等都會從各種平臺和軟件上挖掘出數量龐大的漏洞。根據Exploit（漏洞利用程序）Database獲得的數據，以2014年為例，表1-1給出了特定操作系統的Exploit數量。根據中國國家漏洞庫公布的數據，自2008年以來，每年新增漏洞數量情況見表1-2。

上述是已經被發現且公開的漏洞數據，現實情況是，各種平臺和軟件上還有未被發現或者發現后未公開的各種安全漏洞，其數量無法估計。對于已經發現且公開的漏洞，廠商可以采取有針對性的防護措施，而對于不知道的漏洞，防護工作則無從談起。

1.3.2 大牌廠商產品的不安全性

近年來，國內國際網絡安全行業蓬勃發展，安全防護技術也在飛速進步。以微軟為代表的廠商不斷推出各種新的安全防護機制、手段、方法、理念，這些新技術、新方法確實為用戶和互聯網的安全作出了巨大的貢獻，但是互聯網變得更加安全了嗎？

1.Pwn2Own與瀏覽器安全

Pwn2Own是全世界最著名、獎金最豐厚的黑客大賽，由美國五角大樓網絡安全服務商、惠普旗下Tipping Point的項目組ZDI（Zero Day Initiative，0day倡議）主辦，Google、微軟、蘋果、Adobe等互聯網和軟件巨頭都對比賽提供支持，通過黑客攻擊挑戰來完善自身產品。

2015年的Pwn2Own被稱為史上最難的比賽，各廠商在產品中應用了最新、最全的安全防御技術和機制，因此，互聯網和軟件巨頭們信心十足，紛紛宣稱其產品的安全性已經達到史上最強。賽事開始后結果如何？產品是否像廠商宣稱的那么安全？讓我們一起回顧一下在加拿大溫哥華舉辦的這場大賽。

首先，看一下64位Win8.1操作系統中號稱“獨角獸”級別防護的IE11。賽前，IE被普遍認為有望保住“不破金身”。技術上來說，要想在Pwn2Own 2015上攻破IE測覽器，需要面對以下五大難關。

①微軟漏洞防御軟件EMET；

②IE開啟了增強沙箱保護（Enhanced Protected Mode，EPM）；

③IE開啟了“針對增強保護模式啟用64位進程”選項；

④新增隔離堆、延遲釋放、CFG等微軟新的安全機制；

⑤禁止重啟、注銷系統。

來自國內的360 Vulcan Team團隊卻選擇知難而上，專門向IE“獨角獸”級別防護發出挑戰。在賽前抽簽排序中，360 Vulcan Team排在第六組出場，也是第一個挑戰IE的參賽團隊。根據比賽規則，360 Vulcan Team對一臺全新的、無任何第三方預裝的64位Win8.1操作系統電腦，遠程、無接觸地對開啟64位進程的IE11發起攻擊，利用多個0day漏洞組合突破其全部防御措施，最終獲得該系統的控制權。至此IE11完全淪陷！

現在再來看其他測覽器，Mozilla Firefox測覽器被安全專家ilxu1a在不到一秒內攻破。Safari測覽器在開賽第一天內被韓國黑客Jung Hoon Lee利用未初始化堆棧指針漏洞攻破。Google Crome測覽器穩定版和Beta版也都被Jung Hoon Lee利用緩沖區溢出竟態狀態在同一天攻破。Pwn2Own 2015的最終結果：在兩天的比賽中，Windows曝出了5個漏洞，IE 11曝出4個漏洞，Firefox有3個漏洞，Adobe Reader和Flash分別有3個漏洞，Safari有2個漏洞，Chrome有1個漏洞。這些數字已經說明了一切。

攻擊與防御總是在此消彼長、彼此砥礪中共同向前發展的。一種新的攻擊技術出現后總會有相應的防護技術或機制來保護或緩解，同樣，一種新的攻擊緩解技術或防御機制出現后，也總會有相應的技術或方法能夠找到其邏輯或實現上的漏洞，突破或繞過其限制，從而令防護失效。換言之，軟件的漏洞不可避免，各種安全防護機制也井非萬能。

2.安全廠商安全

在所使用的軟件或系統發生安全問題時，我們通常會希望安全廠商能夠給出有效的解訣方案，幫助我們盡快解訣問題或麻煩。安全廠商在互聯網生態中客觀上也起到了免疫系統的作用。但是作為互聯網生態中的免疫系統，要求安全廠商其自身必須是健康和安全的，那么安全廠商本身的安全性到底如何？首先來看一下最近炒得沸沸揚揚的Fire Eye漏洞事件。

Fire Eye是一家為企業提供安全防護產品的美國網絡安全公司，以解訣0day攻擊著稱。Fire Eye成立于2004年。通過在客戶的系統上加載虛擬機，可以觀測所有的網絡行為。2012年，成立僅8年的Fire Eye訂單價值超過1億美元，訂單增長率超過了100%。其合作伙伴與客戶已達1 000多家，有1/4的財富100強企業在使用該公司產品。

Fire Eye宣稱能夠解訣兩大真正的安全難題——能夠阻止公司此前無法阻止的網絡攻擊，即0day攻擊和APT。但是Fire Eye自己提供的0day解訣方案這次似乎井沒有派上用場。

具體事件是，研究人員Kristian Erik Hermansen從Fire Eye核心產品中發現一個0day漏洞，該漏洞會導致未經授權的文件泄露。他還提供了一個簡短的觸發漏洞例于以及用戶數據庫文件副本。Hermansen在披露這個漏洞時寫道：“Fire Eye設備允許未經授權遠程訪問Root文件系統，Web服務器以Root身份運行。現在這家安全公司呈現了完美的安全示范，你為何還要相信這些人將設備在你的網絡中運行呢？這只是Fire Eye/Mandiant眾多0day漏洞中的一個而已。而Fire Eye的安全專家們在過去的18個多月對此竟然沒有進行任何修復。很肯定的是，Mandiant員工把這個漏洞和其他缺陷一同編碼進了產品當中。更可悲的是，Fire Eye沒有外部安全研究人員報告步驟。”那么，Fire Eye自己的安全狀況到底如何？

事件發生后不久，媒體CSOonline給Hermansen發送了郵件井詢問詳情，Hermansen在回信中稱，在與另一位研究員Ron Perris合作時，他們發現了Fire Eye產品中存在的30個漏洞，包括多個遠程Root權限漏洞。Hermansen在寄給Salted Hash的郵件中稱，在一年半的時間里他嘗試了使用負責任的渠道聯系Fire Eye解訣問題，但對方每次都說空話。Hermansen認為，這些情況應該被披露，產品存在漏洞，大家都應該知道，特別是存在遠程Root漏洞的、政府批準的安全港（Gov-approved Safe Harbor）設備。

在安全廠商中，僅是Fire Eye被爆過漏洞嗎？答案是否定的。老牌殺軟廠商中，無論是殺卡巴斯基、Macfee，還是諾頓、趨勢科技等都曾被爆出現嚴重漏洞。事實再一次地證明，安全廠商也無法杜絕其軟件漏洞。而如果擁有大量專業安全研究人員的安全廠商都無法保證其產品的安全性，用戶和互聯網的安全又有誰能夠保證？

3.蘋果Xcode Ghost病毒事件及其延伸

通常我們認為，從信譽良好的、有嚴格審核機制的APP Store等應用市場中下載的正版軟件，是不會存在后門等安全問題的。但此次蘋果Xcode Ghost事件給了APP Store等應用市場的信譽和審核機制一記響亮的耳光。

事情要回溯到2015年9月12日，TSRC（騰訊安全響應中心）在跟進一個Bug時，發現有APP在啟動、退出時會通過網絡向某個域名發送異常的加密流量，行為非常可疑，于是終端安全團隊立即跟進，經過一個周末加班加點的分析和追查，基本還原了其感染方式、病毒行為、影響面。該后門目前已感染數千個蘋果APP Store應用，其中包括微信、網易云音樂、滴滴、12306、高德地圖等知名APP。

Xcode Ghost會造成的危害主要有以下幾點。

①在受感染的APP啟動、后臺、恢復、結束時，上報信息至黑客控制的服務器；

②黑客可以下發偽協議命令在受感染的iPhone中執行；

③黑客可以在受感染的iPhone中彈出內容由服務器控制的對話框窗口；

④ 遠程控制模塊協議存在漏洞，可被中間人攻擊。

分析過程中發現，異常流量APP都是大公司的知名產品，也是都是從APP Store下載井具有官方的數字簽名，因此，井不存在APP被惡意篡改的可能。隨后，騰訊安全團隊把精力集中到開發人員和相關編譯環境中。果然，很快從開發人員的Xcode中找到了答案。

原來開發人員的Xcode安裝包中，被別有用心的人植入了遠程控制模塊，通過修改Xcode編譯參數，將這個惡意模塊自動地部署到任何通過Xcode編譯的蘋果APP（i OS/Mac）中。因此，該事件的罪魁禍首是開發人員從非蘋果官方渠道下載Xcode開發環境。

4.Xcode Ghost事件的延伸——UnityGhost

Xcode Ghost事件尚未結束，國內最主流的移動游戲引擎之一——Unity又出問題了。2015年9月21日（23：21），百度安全實驗室成員@evil_xi4oyu透露，已經確認有非官方渠道的Unity 4.X被篡改加入惡意后門。烏云知識庫作者蒸米對Unity惡意后門樣本UnityGhost進行分析后發現，該樣本行為和Xcode Ghost非常相似，也會收集手機上的基礎信息上傳到init.icloud-diagnostics.com，井具備遠程控制能力。在接收到服務器指令后，UnityGhost可以進行以下多種惡意行為。

①下載安裝企業證書的APP；

②彈APP Store的應用進行應用推廣；

③ 彈釣魚頁面進一步竊取用戶信息；

④如果用戶手機中存在某URLScheme漏洞，還可以進行URLScheme攻擊等。

這次蘋果的Xcode Ghost以及后續的UnityGhost事件，不僅是廠商的公共危機，更多地還需要引發我們普通用戶對安全問題的思考。在蘋果封閉的系統當中，通過APP Store等信譽良好的應用市場下載的軟件，其安全隱私問題尚且面臨考驗，在Android等更多開源系統當中，這類安全問題可能會更加突出，而且還會隨著智能設備的普及而更加嚴峻。

上述安全事件告訴我們，那些通常被認為具有雄厚技術力量和高安全意識的廠商，如微軟、蘋果等，在現實中表現也不盡人意，而Fire Eye、卡巴斯基等大牌安全廠商也無法做到讓用戶完全放心。

1.3.3 SDL無法根除漏洞

SDL（Security Development Lifecycle，安全開發流程）是微軟公司最早提出嵌入軟件工程中開展的、幫助解訣軟件安全問題的辦法。SDL是一個安全保證的過程，其重點是軟件開發，它在開發的所有階段都引入了安全和隱私的原則。自2004年起，SDL一直都是微軟在全公司實施的強制性策略。SDL步驟如圖1-9所示。

安全開發流程能夠幫助企業以最小的成本提高產品的安全性。

SDL對于漏洞數量的減少有著積極的意義。根據美國國家漏洞庫、中國國家漏洞庫等機構的數據顯示，每年有數千個安全漏洞被發現和公布，其中大多數危害程度高的安全漏洞其復雜性反而較低。這些漏洞多出現在各種應用程序中，易于被利用的漏洞占了大多數。

微軟的SDL適用于根據傳統瀑布模型進行開發的軟件企業，而對于互聯網公司這類使用敏捷開發的團隊，則難以適應。敏捷開發采用“小步快跑”的方式，不斷完善產品，通常沒有非常規范的流程，文檔要求也不高。這么做有利于產品的快速發布，迅速滿足客戶需求，但這種開發模式也有不足之處。在開發之初沒有明確的需求，開發過程中需求發生變化，安全設計也要隨之發生變化。

微軟為敏捷開發設計了專門的敏捷SDL，如圖1-10所示。敏捷SDL的思想其實就是以變化的觀點實施安全的工作。需求和功能可能一直在變化，代碼也可能隨之發生變化，這要求在實施SDL時需要在每個階段更新威脅模型和隱私策略，在必要的環節迭代模糊測試、代碼安全性分析等工作。

企業在實施SDL的過程中，根據經驗總結出以下一些準則。

① 與項目經理進行充分溝通，排出足夠的時間；

② 規范公司的立項流程，確保所有項目都能通知安全團隊，避免遺漏；

③ 梳理安全部門的權威，項目必須由安全部門審核完成后才能發布；

④ 將安全測試環節加入開發、測試的工作手冊中；

⑤ 對工程師實施安全設計、安全開發培訓；

⑥ 記錄所有的安全漏洞，激勵程序員編寫安全的代碼。

SDL需要企業從上往下進行推動，能否取得成效最終還是歸結到實施SDL的人。SDL實施成功與否，與企業高級管理層的支持有很大關系，也與SDL具體實施人員的技術水平密切相關。

微軟在實施了SDL后，代碼質量得到顯著提高，但是由于軟件代碼量的膨脹和新漏洞挖掘方法的出現，每年微軟仍然被爆出大量漏洞。從實際效果來看，SDL對于提高產品的安全性有積極意義，卻始終無法根除軟件漏洞，軟件廠商也始終難以擺脫漏洞的困擾。

1.3.4 安全廠商防御的被動性

在與惡意代碼的激烈爭斗中，安全廠商相繼推出了各種安全防護機制、手段和方法。這些技術和方法的應用也確實為用戶和互聯網安全做出了巨大的貢獻，但是惡意代碼與安全軟件之間的對抗其實是一個矛與盾的話題。無論哪一種攻擊或者防御技術都是有其時間與條件限定的，一種技術一般只在某段時間內對某特定場景有效。

（1）特征碼查殺及其繞過

特征碼查殺是一種基于對已知病毒分析、查殺的反病毒技術，是殺毒軟件中應用最廣泛也是最基本的查殺方法。其基本原理是根據從病毒體中提取的病毒特征碼，逐個與程序文件比較。特征碼是反病毒公司在分析病毒時，確定的只有該病毒才可能會有的一系列二進制串，由這些特征可以與其他病毒或正常程序區別開來。殺毒軟件的升級就是使該軟件病毒特征庫數據更新，從而能查出新的已知病毒。

在各類病毒檢查方法中，特征值方法是適用范圍最寬、速度最快、最簡單、最有效的方法。但由于其本身的缺陷問題，它只適用于已知病毒。此外，要擷取一個病毒的特征碼，必然要獲取該病毒的樣本，由于對特征碼的描述各不相同，特征碼方法在國際上很難得到廣域性支持。特征碼查病毒主要的技術缺陷表現在較大的誤查和誤報上。

特征碼查殺具有上述的缺點與不足，可以說其只是一種“治標”而不“治本”的方法。攻擊者可以通過各種方法，如指令替換、指令加花等輕易繞過，從而令防護失效。

（2）主動防御及其繞過

如果說特征碼掃描是一種被動的、靜態的方法，主動防御就是一種主動、實時進行攔截、判斷惡意代碼的技術嘗試。主動防御是基于程序行為自主分析判斷的實時防護技術，不以病毒的特征碼作為判斷病毒的依據，而是從最原始的病毒定義出發，直接將程序的行為作為判斷病毒的依據。主動防御是用軟件自動實現了反病毒工程師分析判斷病毒的過程，解訣了傳統安全軟件無法防御未知惡意軟件的弊端。

主動防御技主要包括以下幾種技術和思想：① 基于病毒識別規則庫的動態判斷方法，即通過對各種程序動作的自動監視，自動分析程序動作之間的邏輯關系，綜合應用病毒識別規則知識，實現自動判定新病毒。② 基于系統鉤于的動態行為分析技術，即動態監視所運行程序調用各種應用編程接口（API）的動作，自動分析程序動作之間的邏輯關系，自動判定程序行為的合法性，實現自動診斷新病毒，明確報告診斷結論。③ 主動攔截技術，即在全面監視程序運行的同時，自主分析程序行為，發現新病毒后，自動阻止病毒行為井終止病毒程序運行，自動清除病毒，井自動修復注冊表。

主動防御技術是一種與靜態特征碼掃描互補的保護方法，也顯著提高了安全軟件的防護能力，但是從誕生那天開始就受到各種各樣繞過方法的困擾。例如，不使用主動防御系統Hooh過的函數繞過方法。將代碼復制到程序的數據段中再跳轉執行。Inline Hooh等入口點模糊化方法。

（3）啟發式防護查殺及其繞過

病毒和正常程序的區別可以體現在許多方面，比較常見的，例如，通常一個應用程序在最初的指令是檢查命令行輸入有無參數項、清屏和保存原來屏幕顯示等。而病毒程序則沒有會這樣做的，通常它最初的指令是直接寫盤操作、解碼指令或搜索某路徑下的可執行程序等相關操作指令序列。這些顯著的不同之處，一個熟練的程序員在調試狀態下只需一瞥便可一目了然。啟發式代碼掃描技術實際上就是把這種經驗和知識移植到一個查殺病毒軟件中的具體程序體現。

啟發式查殺可分為靜態和動態兩種。靜態啟發式查殺充分考慮了病毒與正常程序之間的區別，通過分析指令出現的順序或組合情況來訣定文件是否感染。通過設定一個安全閾值，當程序中潛在惡意代碼片段或其組合的累計權值超過某一個限定值時，則判定程序為惡意的，井啟動查殺。動態的啟發式查殺也被叫作虛擬查殺，其基本原理是虛擬出一個環境，讓程序先充分執行一會，在執行中對病毒的行為和特征進行掃描和比對。虛擬查殺主要是針對加殼的病毒或木馬。如果將虛擬化技術應用在程序保護上，就是我們下文會提到的沙箱技術。

啟發式查殺理論上看起來很美好，但實際使用中卻很容易產生誤報，從而影響用戶的正常使用。另外，對于目前的啟發式查殺技術，攻擊者也已經研究出很多種繞過技術，可令其失效。例如基于超時的虛擬化查殺繞過技術，即在真正的功能段之前加入大量的、無意義的迷惑性指令，使程序執行時間超過虛擬化執行的深度，從而繞過啟發式查殺。又比如利用異常處理機制的繞過方法，即針對啟發式查殺沒有完全做到對異常處理進行虛擬化的不足，把具有惡意特性的API調用放到異常處理中，然后人為觸發一個異常來間接調用API，從而實現繞過。

（4）沙箱保護及其繞過

沙箱技術正如其名字所說的一樣，是一種允許隨意修改井在修改后可恢復到原始狀態的保護技術。如果你還是不清楚什么是沙箱，可以這樣來想象一下：在一個裝滿了平整細沙的盒于里，我們可以盡情隨意地在上面作畫、涂寫，無論畫的好壞，最后輕輕一抹，沙箱又回到了原來的平整狀態。沙箱的魅力就在于他允許你出錯，還可以給你改正的機會。

沙箱技術與主動防御技術原理截然不同。主動防御是發現程序有可疑行為時立即攔截井終止運行。沙箱技術則是發現可疑行為后讓程序繼續運行，當發現的確是病毒時才會終止。沙箱技術的實踐運用流程是：讓疑似病毒文件的可疑行為在虛擬的沙箱里充分表演，沙箱會記下它的每一個動作。當疑似病毒充分暴露了其病毒屬性后，沙箱就會執行回滾機制，即將病毒的痕跡和動作抹去，恢復系統到正常狀態。

利用沙箱技術保護應用程序就是通過重定向技術，把程序生成和修改的文件，定向到自身文件夫中。這些數據的變更，包括注冊表、文件及其他一些系統的核心數據。沙箱技術還可以通過加載自身的驅動來保護底層數據，因此也屬于驅動級別的內核保護。從設計上說，沙箱技術是一種通過隔離的方式來實現對應用程序的保護，那么有沒有辦法可以突破或繞過？答案是肯定的。

沙箱逃逸是繞過沙箱方法的總稱，通常依據不同的場景和應用有不同的繞過方法，例如，CVE-2015-1427就是一個典型通過反射方法繞過沙箱的漏洞，漏洞成因是沙箱代碼黑名單中的Java危險方法不全，從而導致惡意用戶仍可以使用反射的方法來執行Java代碼。又比如MS14-065中修復的3個IE增強保護模式EPM的沙箱跳出漏洞，這3個漏洞源于增強保護模式下IE代理進程的權限問題，利用的是APP Container訪問檢查忽略了中以下級別的任何資源。如果一個資源通過了DACL檢查，那么它就會無視IL而被授予權限，從而導致沙箱繞過。

多年來，安全廠商在應對處理惡意代碼、惡意程序、漏洞檢測等方面積累了大量的經驗，也采用了大量的新技術和手段，但是任何一種新的防護技術，面對大量攻擊者的各種研究和測試，遲早會被發現突破或繞過系統防護機制的漏洞或方法。