天天看點

《黑客大曝光:移動應用安全揭秘及防護措施》一1.2 移動風險模型

本節書摘來自華章出版社《黑客大曝光:移動應用安全揭秘及防護措施》一書中的第1章,第1.2節,作者 (美)neil bergman ,更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視

好的,目前我們已經确定了:

移動應用規模巨大;

移動應用看起來非常不安全。

那我們現在應該怎麼做?!

這裡有一個可能會讓我們感到震驚的答案:我們在之前做過同樣的事情!與天花亂墜的廣告宣傳相反,我們認為移動“似曾相識”。從根本上來說,我們仍在讨論“用戶端–伺服器”架構:

《黑客大曝光:移動應用安全揭秘及防護措施》一1.2 移動風險模型

好吧,我們可能有些但沒有過多誇大。讓我們通過更多的細節來做進一步的叙述或說明。思考一下,從用戶端的角度來看,下圖展現了我們将20世紀90年代和21世紀都使用的傳統三級架構修改成移動架構的情況:

《黑客大曝光:移動應用安全揭秘及防護措施》一1.2 移動風險模型

上圖對不同之處進行了強調,數字部分對應的描述如下:

本地代碼 本地應用的開發可使用不需要虛拟機或沙箱環境即可執行的程式設計語言。這些應用可能會涉及不安全的程式設計語言(例如:objective-c),并且與基于浏覽器的應用相比,增加了對其他應用和資源的通路。甚至當移動平台實作了應用沙箱時,使用者也可能很快就被迫同意一個高而廣的權限,這樣平台所提供的大量控制機制很容易就被繞過了。

作業系統通路 浏覽器中運作的軟體隻有有限的權限,可用于對底層的作業系統、庫、檔案系統的通路,或用于程序間通信和系統調用。

網際網路通路 無論是家用個人計算機,還是便攜式計算機,通常通過家庭網絡通路網際網路,而移動裝置通常使用移動網絡或者公共無線網絡去連接配接網際網路。這些通路方式能夠為中間人攻擊提供更多的機會。

 正如你在本書中看到的,大部分由中間人攻擊帶來的手機應用威脅是在變化的,無論是我們提到的mitb(浏覽器)、mitos(作業系統),或者是老式的mitm(網絡)。從應用角度看,關于移動模型有一個公認的結果—它被惡意(至少不可信)軟體所包圍。

我們必須開始重新使用我們曾經學過的課程,去了解安全的分布式計算機系統。即使我們還不能夠很好地真正實作它們(例如,對低級密碼的持久而廣泛的使用),但也不意味着我們應該不分精華糟粕全盤否定。當我們指出移動裝置在架構方面存在不同時,我們也應該使用以前我們學過的安全架構。

這種方法可以稱為堅持原則。原則是前人已經學習的東西,并且經過了實踐檢驗,由于采用這些方法比其他方法好很多是以一直堅持到了今天。

我們最喜歡的原則之一是安全從了解風險模型開始。本書第8章會對移動威脅模型進行深入分析和拓展,本章僅對該内容做一個簡短的介紹。

要了解風險模型首先要提出以下問題:誰是利益相關者?這是移動平台引入新觀點的一個關鍵領域。大量利益相關者都在争奪對典型移動裝置微小生存空間的控制,包括:

移動網絡營運商(mno、aka carrier、telcos和那些一直中斷我們通話的#$%&*公司);

裝置制造商(aka oem、硬體制造商等等);

移動作業系統(os)供應商,例如apple和google;

應用商店管理者(例如,apple、google、amazon等等);

it組織(例如,關注安全的移動裝置管理軟體);

移動應用開發者;

終端使用者。

上面清單顯示的是對個人使用者裝置感興趣的各類利益相關者。對于iphone,apple承擔了應用商店管理者、制造商和作業系統開發者3個角色。android裝置通常擁有更多的風險相關者。

當我們已經知道誰是利益相關者後,我們的下一個問題是,哪些因素對于這些利益相關者是有價值的呢?(我們稱之為資産(assets))。有趣的是,每個利益相關者在移動裝置資産中存在不同的價值。例如,作業系統制造商認為所有應用都是威脅。手機使用者對作業系統來說同樣也是威脅;使用者在拿到手機後會盡快對手機進行越獄。然而對于手機使用者來說,作業系統也可能是一種威脅,系統會為了“統計目的”而擷取資料并輸出,使用者認為這是侵犯了他們的隐私。mno預裝的應用就可發現類似情況。

各種威脅通過攻擊界面攻擊每個利益相關者持有的資産。基于浏覽器的網際網路應用大部分将攻擊界面局限于網際網路連接配接點、伺服器資料存儲或者浏覽器渲染和腳本引擎(還記得大部分移動開發架構定義了若幹機制用于顯示類似浏覽器的網頁視圖,與本地應用相對無縫嵌入)。為移動裝置建立的應用程式都共用這些攻擊界面,但是新增了幾個特别的,如下圖所示:

《黑客大曝光:移動應用安全揭秘及防護措施》一1.2 移動風險模型

上圖包括了一些特别針對移動裝置的攻擊界面:

實體竊取允許對使用者接口、實體存儲、輸入輸出總線和音頻進行通路。通過獲得通路實體裝置的機會形成威脅意味着移動裝置與其他用戶端有着非常大的差別。

應用程式釋出引入了一種威脅,在該機制下允許集中散播帶有特洛伊木馬的應用程式或者其他惡意軟體,這些軟體外表看起來一切正常,而且由移動應用商店授權釋出。就如我們已經提及的,帶有威脅的應用應該已經弱化了對作業系統資源的通路、程序間通信,在無沙箱的運作環境下攻擊它的目标對象,不過這取決于移動平台的狀态(已經越獄/獲得root權限)、應用權限配置存在缺陷和終端使用者的超權限設定等等。

在得到了可能的攻擊面之後,我們如果要完成風險模型,就會問第三個基本問題:從利益相關者的角度來看,與資産相關的威脅有哪些?隻有解決了這些基礎問題條件,你才能完善你的設計和開發,進而降低這些風險。

 對于這個過程,可能會有不一樣的名稱:風險模組化、設計審查、架構風險分析、威脅模組化。在這裡,我們不需要對專業名詞吹毛求疵,而僅僅是研究風險在安全會話中的基本角色。

一旦你确定了風險模型,就能基于它進行更加合理的設計和完善後續工作。(例如,使用代碼審查和滲透測試等方法對開發進行檢查)。你還需要從這個過程中不斷學習并確定受過教育訓練的人員不再發生同樣的錯誤。在相同點的典型過程方面,這開始有點像“安全開發生命周期”,如圖1-2所示。

《黑客大曝光:移動應用安全揭秘及防護措施》一1.2 移動風險模型

由于風險模型是最重要的,是以,讓我們對移動風險環境進行一個高層次的概述。通常,關于移動風險模型我們需要關注哪些因素呢?

盡管我們認為事物沒有發生本質的改變,但其實在移動平台上有些方面還是不同的。很明顯,由于混雜的通信方式(廣域域和内部)、實體通路,外加正常軟體攻擊和郵件、移動網頁應用程式等外聯因素,用戶端的威脅模型會更具有攻擊性。

折中的結果就是更加“人性化”:位置、照相機/照片、即時資訊—有大量讓人不安的公用資料需要去核實。weiner一定會有一個更不幸的姓嗎?以及有了好幾個不行的姓名?(不好意思,我們不能夠接受)。

擁有宇宙間無窮的力量……但卻擠在小小的燈裡。

但是再一次重申,這并不意味着移動安全工作在本質上與衆不同,隻是表明你必須了解風險模型的改變,同時能夠将這些變化明确告知所有利益相關者,并掌握實際的緩解措施。相同的工作,在不同的時間裡會産生不一樣的好壞利弊。我們對移動威脅模型已經有了一個比較高度的概括,現在讓我們對一些具體的不同點進行深入的講解。

圖1-3表示的是我們理想化的移動應用生态系統。當然,任何“實際的”風險模型都需要根據所給的場景進行定制,這隻是一個重點關注我們在調查和研究中已發現事物的通用模型。接下來我們更加詳細地讨論風險區域。

《黑客大曝光:移動應用安全揭秘及防護措施》一1.2 移動風險模型

圖1-3中的風險區域1說明了一個真理,這是通過我們在這個産業持續不斷的反複學習得到的:裝置的實體通路很難做長時間的防禦。大範圍的root權限擷取和越獄現象無疑證明了這點。因為這種方式非常難實作或者說基本不可能,即使是google和apple(兩個非常成功的公司)也未能做到。在我們的調查和研究中,我們一直在找一個我們不能阻止其已有實體通路的應用程式,包括很多基礎的反越獄機制,甚至還包括了移動裝置管理(mdm)軟體。如果你的移動風險模型假設資訊在移動裝置上可以絕對安全的儲存,那麼你可能開始于一個錯誤的假設,當遇到一個例外,你需要重新學習這個痛苦的課程。整本書都基于這個基本的假設,實體損害是一個高成功率的結果,你在每個章節都能看到它不可改變的事實。

 我們所舉的這些例子是顯而易見的:計算機安全準則第3條指出“如果一個壞人可以對你的計算機進行沒有受限的實體通路,那麼它也不再是你的計算機了,”technet.microsoft.com/en-us/library/cc722487.aspx。

再回到圖1-3,以将電線連接配接到手機底部為代表的實體攻擊方式,即本書中我們常常會談到的典型“調試”連接配接,再次說明了對裝置及裝置上軟體的直接通路對裝置擁有者和裝置上存儲的敏感資料來說,通常意味着“遊戲結束”。

這個規則一個經常被忽略的推論是,與移動裝置近距離的互動和實體攻擊是同等有效的。換句話說,如果攻擊者使用一個僞基站并保持與你足夠接近時,你的手機就會加入這個僞基站覆寫的移動網絡,同時攻擊者就從較低的層(基本上是完全)掌握了你的裝置。這樣整體上你什麼也不能做,隻能把你的裝置設定為飛行模式,将它作為一個昂貴的、無法連接配接的闆磚來使用。在圖1-3中,我們将這種危險作為#4,緊鄰“基帶”無線電晶片硬體和固件,将所有從移動網絡的連接配接轉到wifi、藍牙、gps、近距離通信(nfc)等等。我們會在第2章中進一步讨論僞基站(rogue cellular base station)攻擊。

讓我們看一下圖1-3中的風險區域2,下一個移動生态系統裡主要的風險産生區域是哪兒呢?不會在你想到的地方……

通常,絕大部分關于移動平台的焦點會集中在移動裝置以及與之相關的用戶端軟體。與這種關注相反,事實上我們在調查和研究過程中注意到更多的問題發生在伺服器端。例如,在最近一項長期的調研合作項目中,我們得到了這樣一個結果:65%的服務端bug對25%的用戶端bug。

當然,大部分代碼/邏輯也是在伺服器端,是以這是不希望發生的。同樣,如果你已經正确做了設計,那麼那裡也是有價值的資料存儲的位置。隻針對“錢所在的位置”進行攻擊的攻擊者威利•薩頓(willie sutton),是一個臭名昭著的銀行搶劫犯,在被問及為什麼要搶劫銀行時,他說 “因為那裡有錢”。我們在圖1-3中的#8中,突出強調了通用伺服器端風險。

另外通常被忽略的現代網絡應用中的一個因素是客戶支援。這種疏忽是不幸的,因為一個現代的威利•薩頓可能會為了複仇而利用這點:通過設計,支援幫助人們重新獲得對有價值資料的通路權限—一個黑客的夢想就此實作!從近20年來大多數災難性漏洞的經驗中我們看到,一些問題是由例如自助密碼重設等客戶服務相關的功能所導緻的;如果你在這裡犯了錯誤,那麼将會産生巨大的影響。設想這樣一個缺陷:允許匿名攻擊者通過網站重設賬戶密碼—能想到後果嗎?在之前提到的調研項目中,大概有12%的bug是與客戶服務相關的。然而,這些都有可能導緻最進階的風險,這與我們剛才談到的使用者密碼重置漏洞類似。我們在圖1-3中#9标注了此類風險,緊挨着微笑客服,甚至是非常有幫助的客戶服務代理商。

 舉一個内部關系出錯的真實案例,參考有線記者mat honande的噩夢經曆,這段經曆是關于黑客如何利用社會工程學從存在缺陷的客服功能中侵入他的gmail賬戶,并以亞馬遜資料為中心,遠端删除了他的iphone、ipad和macbook上的所有資料,同時受牽連的還有他的twitter賬戶。(wired.com/gadgetlab/2012/08/apple-amazon-mat-honan-hacking/。)

 這是一個反複發生而且很重要的問題,我們正在逐漸走出來:另外一個可怕的客戶服務漏洞的真實案例,可參考《verge》(theverge.com) 2013年3月刊,關于appleiforgot自助密碼重設工具嚴重漏洞的報道,這個漏洞允許任何人通過你的郵件位址和出生日期來重置密碼。哎!

如果服務端有銀質内裡,那麼性能好的ol安全網關仍然能夠在保護面向網際網路的服務方面有良好的表現。實際上,我們已經看到了vordel應用網關(vordel.com)有效地保護了移動終端xml服務,使其免受熟練的滲透測試者的攻擊。你完全可以考慮采用如vordel這類的産品,并将其作為你移動應用安全架構的一部分。

我們來到了在我們的移動風險區域裡最後但并非最不重要的部分,真正的接口——移動應用程式。

應用程式(符合平台特征的接口)是移動用戶端上的最主要的攻擊面。畢竟,應用程式和移動作業系統是終端使用者和其他軟體的基本接觸點,是以這也是所有問題發生的地方。

以應用程式為中心的當今移動風險模型,在某些方面反射出其他平台的安全演變,如桌面計算機:早期的攻擊集中在網絡層,然後轉移到作業系統(特别是最流行的作業系統,例如,microsoft windows)。最近,我們看到了大量已經公開的針對桌面應用程式的攻擊和利用,如網頁浏覽器、adobe acrobat和microsof office。在這種演變的頂端,我們看到了針對“第8層”的攻擊,換句話說,攻擊是針對使用這項技術的人。如網絡欺詐等社會驅動攻擊就代表了這種趨勢。

在移動平台,相對缺少公開的底層利用方式,表明供應商正在重新使用我們已經了解的網絡和作業系統安全。然而,甚至在移動平台上,第7、8層問題一直很難解決。也許特别是在移動平台上,使用者和應用之間被賦予了比桌面計算機平台上更加緊密的關系。經常線上的網絡連接配接會産生一個明顯的結果,任何人可與你的手機進行連接配接。這通常不是一個可取的事情,對“任何人”的一種可行的定義會包括圖1-4中的角色。

《黑客大曝光:移動應用安全揭秘及防護措施》一1.2 移動風險模型

事實上,很多人會不斷地連接配接你的移動手機,即使他們已經通知你了也很難判斷哪一個是友好的。你應該允許谷歌地圖擷取你的位置資訊嗎?當你在約會月曆中點選相關連結時,你會允許思科webex移動應用程式自動加載嗎?當at&t告訴你手機賬單已經準備好了,你會點選sms裡的連結嗎?

你可能希望能夠有一個直接解決所有問題的解決方案,進而帶來安全的移動體驗。這幾乎不可能,因為移動的發展速度如此之快,同時面臨如此衆多的危險問題(見本章開頭的資料),在行業中沒人真正能有足夠的時間一一去完成。讓我們來浏覽一些典型的移動應用程式的安全問題。

分化

我們多年來學到的一個安全原則是,為存在漏洞的系統快速打上更新檔,這樣做通常能夠降低風險。這種風險來自于在網際網路上傳播的本地惡意軟體,這類惡意軟體往往能夠利用未打更新檔的知名漏洞。不幸的是,為你的移動軟體打更新檔是極具挑戰的,源于目前市場的一個關鍵特點:分化(fragmentation)。

分化源于一個技術行業的古老争議:平台的開放與封閉,見圖1-5。在移動裝置領域,我們将看到這一幕會在當今兩個最大的競争對手:谷歌和蘋果之間上演。

在本書寫作的同時,甚至著名的手機黑客查理•米勒都認為蘋果ios系統更難被侵入,主要是由于該平台嚴格的控制機制:代碼必須獲得apple的簽名後才可運作,位址空間随機化(aslr)、更好的代碼沙箱、沒有shell等。與之相對應,在android平台上,由每一個裝置制造商開發各自特有的作業系統需求帶來的分化,直接導緻了安全方面一系列的負面結果。例如,android系統更新到最新版本依賴于裝置的硬體廠商和移動網絡營運商(mno)之間的合作,這就限制了如aslr等新安全功能,也使得分布式安全更新檔和其他重要的更新變得難以實作。

“封閉”的apple平台在智能手機的市場佔有率在早期一直處于領先。通過這樣一個被認為是副作用的設計,apple裝置的安全成績一直保持良好。相反,開放的android平台的安全成績是不理想的,但是它迅速成為市場佔有率的上司者可能因為它在數字上的優勢:谷歌,摩托羅拉,三星,htc,lg等等衆多廠商對唯一的蘋果。

我們之前看到過這一幕。盡管遭受了不良的安全信譽問題,但是微軟通過将自己的作業系統授權給多個硬體廠商進而成為個人電腦市場的主宰者。盡管有高品質的內建硬體和軟體設計聲譽, 蘋果最終被邊緣化。

我們重新理性地看一下市場,今天的消費者更傾向于接收邊緣化特征的事物,安全性的考慮則放在之後。事實上,許多android和apple的使用者破解/越獄他們的手機是市場中的一個不成熟的例子。微軟隻是用了10年之久的努力就使得個人電腦使用者不用高權限的管理者使用者登入。許多因素都在變化,但是對比是有趣的(我們當然不是第一個做這個對比的)。随着市場逐漸成熟,最終的赢家會是具有更高品質、更多控制和安全經曆的那個嗎?

有一件事跟過去有所不同:應用程式的市場,比如apple app商店和google play。這些集中的應用程式傳遞機制,又一次不是出于安全而是出于控制使用者體驗,用簡單的分布式模型吸引開發者,并且讓軟體下載下傳到裝置上。但是不管動機是什麼,結果都是:有一個中央應用更新檔管道,通過此管道開發人員可以很容易地定期更新他們的代碼,包括安全更新檔。pc甚至都沒有取得這類第三方軟體的集中目錄。

《黑客大曝光:移動應用安全揭秘及防護措施》一1.2 移動風險模型

當然這樣一個管道仍然不能保證更新檔能被制定出來。正如前面提到的,開發者擷取安全漏洞資訊仍然需要規則限制(微軟的windows系統的錯誤報告,又名“沃森博士(dr.watson)”,是一個很好的例子),制定好安全更新檔并且可以使用它們。

還有其他的管道颠覆了标準的應用程式市場。最受歡迎的當然是用手機裝置的網頁浏覽器直接下載下傳并且安裝程式,就是所謂的“旁加載(side-loading)”。也有能夠與标準的應用程式商店同時安裝的第三方的應用程式商店。

當今分化的手機軟體市場和過去微軟與蘋果之間競争的另一個不同之處是,大量的手機裝置制造廠現在仍然處于主導地位,多種的android個性化定制就是結果。這種多樣化能将安全漏洞引入具體裝置上,而不能被谷歌集中确定。比如,三星的touchwiz的android界面容易被惡意網頁的一行簡單代碼攻擊,進而可以消除在galaxy系列手機上的使用者互動資訊(檢視androidcentral.com/maior-security-vulnerability-samsung-phones-could-trigger-factory-reset-web-browser)。使用者不得不等待三星釋出新的固件,而且許多更老的裝置可能仍然易被攻擊。

敏感資訊洩露

敏感資料洩露是移動裝置最大的風險之一,因為在移動裝置上所有的資料本來就存在更大的危險。不幸的是,在移動裝置上設計了許多機制用于存儲各類資料。在我們的工作中,看到了如下的資料:

調試模式下google系統日志中的鑒權pin碼;

web view中緩存的會話辨別符和身份憑證;

本地資料庫sqlite中存儲的敏感資料;

當應用程式中斷時,帶有敏感資料的ios應用快照記錄;

敏感憑據如應用pin碼被記錄到ios鍵盤緩存

有一個公布了的例子:美國國土安全部旗下的電腦警備小組(us-cert)的攻擊記錄中,vu#251635“三星和htc安卓手機資訊洩露的漏洞”描述了如何确定三星和htc安卓手機在裝置驅動程式日志(所謂的dmeg緩沖)中存儲某些能夠被惡意程式通路的使用者輸入資訊。某些制造商在rom中配置錯誤的unix檔案權限,使得dmeg可以執行手機裝置上的任何應用程式。

而且,記住應用程式沙箱(又名重新授權許可)的可傳遞屬性,當一個應用獲得許可進行應用程式沒有權限執行的特權任務時,這個屬性就會出現。比如,如果善意的應用程式x有權讀取安卓系統日志,惡意的應用程式y可能請求x代表它來調用日志api(無使用者參與),這樣可能會看到一些x程式開發者不期望看到的東西。2011年底的carrier iq-htc監控軟體按鍵記錄事件是一個很好的例子,該事件發展到白熱化程度,以至于美國參議院也被卷入進去。這是一個有趣的話題,值得從以下幾個角度進行思考:

trevor eckhart,安卓系統安全研究者,最早研究這個話題,把carrier iq監控軟體稱為惡意軟體(androidsecuritytest.com/features/logs-and-services/loggers/carrieriq/)。

安全調查員dan rosenberg在他個人部落格上發表的一些相關主張“carrier iq監控軟體:一個真實的故事”(vulnfactory.org/blog/2011/12/05/carrieriq-the-real-story/)。

一個關于carrier iq監控軟體的詳細報告,基于trevo和dan的研究,介紹了這個軟體是如何設計的并且被網絡使用者利用的(carrieriq.com/company/pr.20111212.pdf)。

把最初的宣傳鼓動放一邊,carrier iq監控軟體事件表明複雜的生态系統如移動建立内置障礙物,以快速解決全球數以百萬計的部署裝置發現的問題。最終,我們不确定是否有人能夠真正學到一些有用的東西,但是關于carrier iq監控軟體可能在未來被濫用的輿論仍然繼續,即使這不是它們本身的過錯。

 在監控軟體事件發生後的一些時間裡發生了其他類似事件,美國聯邦貿易委員會提出一個對htc的指控,關于它的安全業務,特别是引用在其他事情上“重新授權許可”的問題。

這導緻了我們經常見到的另外一個同樣很典型的問題:應用輸入驗證。如果一個應用程式不能小心地處理輸入,那麼它可能被利用來攻擊其他應用程式。我們在這本書的許多章節中列出了基于這種缺陷的很多攻擊,包括:典型的javascrip teval函數濫用,通過javascript bridge不恰當執行本地代碼,發送惡意制作的javascript可執行代碼,使用url查詢字元串來執行應用程式功能。

裝置上的安全存儲

繼續我們的關鍵移動應用風險清單,正如我們已經多次提到的,認為秘密可以安全地存儲在手機軟體中是錯誤。我們可以把從寫死密碼到aes密鑰的一切從移動裝置上移除。這并不是指“不要這樣做”,但是你不得不把資料的價值與風險畫上等号。在裝置上這種風險是很高的,因為(我們現在都認同)攻擊者實體通路=高可能性=遊戲結束。

當然,一些應用程式需要在裝置上存儲高價值的資料。比如,移動支付應用需要一些方式來存儲支付手段,以確定像“點選購買”這樣的場景。我們為移動應用程式開發者提供幾個關鍵的建議。

不要這麼做。如果不需要在裝置上儲存敏感資料,那麼你的應用程式在設計上就更加安全。讓應用正确執行将會花費大量智慧和努力(見下面兩條建議)。這樣,你可能會超出原有預算。

使用已有的安全儲存設備;不要讓自己失控。舉個例子,apple的ios keychain在平台中用來安全地存儲敏感使用者資料,甚至當攻擊者對裝置進行實體通路時,也能夠保護敏感使用者資料。盡管不是完美的,通過使用ios5及其以後版本,并通過幾個最佳實踐(主要是設定一個6位字母數字鎖屏密碼),keychain就會比傳統的開發者自己編寫安全例程提供更多的保護。參見sit4.me/ios-keychain-faq,可以擷取ios keychain在健壯性和脆弱性上面更多的細節。

使用特殊設計的硬體區儲存秘密資料。安全元件(se)是一種可以內建在裝置硬體上或者sim、sd卡中的防篡改晶片(微控制器)中。由于在移動消費市場裡激烈的競争,se的可用性不斷增加,主要集中在谷歌錢包(sprint手機上)和isis移動錢包應用(由verizon、at&t和t-mobile合作開發)。晶片之間的通信基于已有的智能卡标準,例如,iso7816(接觸)和iso14443(非接觸)。如果實作正确,就很難被攻擊。“正确”意味着不會将秘密資料暴露給錯誤的接口。這裡沒有普通的場景給開發者去進行編碼,我們也發現了幾個存在錯誤的情況,允許我們不正确地通路se上的資料。我們甚至通過使用接收裝置上的應用程式(不良的完整性檢查),移除了裝置和被通路資料之間的安全元件;在已root的手機上通過惡意應用程式直接通路安全元件。

脆弱的認證

脆弱的認證通常來講是一個典型的應用安全問題,在移動平台上這種情況不會更好。特别是,我們發現一個趨勢,假設移動裝置上的序列号是“秘密的”。例如,移動裝置序列号(mdn)。我們曾經見過密碼重置服務中隻要求mdn用于重置賬戶密碼(不包括由其他重置操作要求的安全問題)。多少人知道你的mdn呢?多少應用程式可以通過手機上的許可通路mdn呢?

第6章将會對使用流行标準(如oauth和saml)的移動裝置身份認證進行更多詳細的描述,包括已知攻擊和對策。

未正确實作導緻的失效

我們同樣也看到了大量的問題,如果規範能夠被正确實作,這些問題就能夠避免。舉個例子,ws-security頭中使用了明文的使用者名/密碼,而不是散列值。舉另外一個簡單(非常不幸,很常見)的例子,調試模式在産品中未被重置,這将導緻如ssl/tls驗證失效等嚴重事件的發生,這對位于本地星巴克或類似地點的移動裝置來說非常嚴重,其非常容易遭受中間人攻擊。

更優秀開發者=更安全的代碼

你不能忽視一個事實,優秀的開發者能編寫更好的代碼,也就是更安全的代碼。這與我們經常看到的在移動開發過程中典型地追求速度是不同的。另外,我們看到在移動領域存在很多外包開發。甚至具有大型應用開發團隊的公司也不能足夠快速地應付移動開發以适應高速發展的商業創新,是以通常的措施是外包給某家專注于手機領域的第三方app開發商。要做好心理準備,花費更多的時間在移動項目上,因為這時你需要更加警惕。

byod、mdm、老虎和熊!

自帶裝置(bring your own device,byod)現象得到了許多關注,但是在it開發中對終端使用者的易用性方面,我們沒有看到有任何新的東西。我們在pc革命中“幸免于難”,是以看到隻具有非常差的安全防護的終端使用者裝置上的資料和應用程式時,就感到非常煩心。但是,可以考慮将byod作為能夠抓住資料治理的又一個機會,由于可能轉向惡意的環境,是以移動裝置上的敏感資料會帶來巨大的風險,這應該可以讓管理層暫停下來進一步進行思考。你有選擇的機會:對高安全性資料僅使用線上/虛拟機方式,或者在整個用戶端一側,對所有非敏感因素進行旁路控制。讓投資人做選擇,并讓他們負起責任。

移動裝置管理(mdm)經常被認為是一個解決移動安全問題的權宜之策。在隻針對paper-cut-class漏洞的多數情況下它确實是一個權宜性質的工作。在對一個主要的mdm營運商進行測試時,将一個調試器附加在手機上就可使我們繞開螢幕鎖。我們再一次提到,防止實體攻擊是非常困難的,你不應該期望mdm去解決這個問題,它隻能緩解一些征兆。我們不是說不使用它,而是確定能夠仔細評估這個解決方案并與你的組織實際的威脅模型相比對。

但是也不要低估它們。mdm及相關技術如移動應用管理(mam)和應用程式完整性保護(例如,反調試和混淆)一旦能夠被合理地設計和部署,将對整個移動安全形勢作出很大貢獻。我們将在第7章進一步介紹相關領域的潛能和缺陷。