https://newera17031.activehosted.com/index.php?action=social&chash=19de10adbaa1b2ee13f77f679fa1483a.2906&nosocial=1
https://newera17031.activehosted.com/index.php?action=social&chash=19de10adbaa1b2ee13f77f679fa1483a.2906&nosocial=1

觀點

打造個資大盜痛恨的企業網站

2012 / 06 / 18
Benson, Birdman
打造個資大盜痛恨的企業網站

一直以來,台灣所遭遇的網路攻擊與資安事件屢見不鮮,而各單位基於同仁與長官在資安意識的提升與緊急應變的落實,逐年提升資安防護佈署的廣度與深度。這兩年因為個資法的推動,公務機關與一般企業更積極地評估、檢討與加強如何因應個資洩漏的風險與個資法施行所帶來的影響。在個資法中,第十八條指出「公務機關保有個人資料檔案者,應指定專人辦理安全維護事項,防止個人資料被竊取、竄改、毀損、滅失或洩漏」,以及第二十七條指出「非公務機關保有個人資料檔案者,應採行適當之安全措施,防止個人資料被竊取、竄改、毀損、滅失或洩漏。」因此,不論公務單位或一般企業均要善盡個資蒐集、處理或利用之安全維護工作。在施行細則草案第九條的條文內容明確指出應採取的資安控制措施,其中作為程式開發人員,可將重點工作放在第四項(事故之預防、通報及應變機制)、第七項(認知宣導及教育訓練)、第八項(設備安全管理)、第九項(資料安全稽核機制),以及第十項(必要之使用紀錄、軌跡資料及證據之保存)。

 

在過去幾年,筆者相信讀者們,尤其是網站程式開發人員,應該可以發現當在討論Web應用程式相關的資安風險評估與防護時,普遍是著重在OWASP Top 10的範疇,譬如SQL InjectionSQL注入攻擊)與XSS(跨站腳本攻擊, Cross-site Scripting)等資安風險。所以,本篇文章會跳過OWASP Top 10不講!直接切入正題,如今個資法來勢洶洶,筆者認為最大的困境很可能會在於單位不管有事沒事,只要在技術上還沒準備好如何預防個資洩漏,就容易因訴訟氾濫卻難以舉證自清而變通通有事。故藉此文提出一些事前預防個資洩漏的防護觀點與各位讀者交流,而非事後鑑識調查的作業流程與技術細節。

 

在面對個資洩漏議題時,完整的配套應從單位的「預防」、「通報」與「應變」機制做三階段建置與佈署,其中筆者認為網站開發人員最應注意「預防」這個面向,其次才是通報與應變,因為通報與應變通常必須配合其他軟硬體系統的使用記錄與軌跡資料做交叉比對分析,比較不容易單從網站本身的「程式撰寫」來加強。是的,這篇文章會跟讀者分享程式片段做案例說明,筆者認為「看不見、撈不走、進不來」是防護個資洩漏教戰守則的最高指導原則。說穿了,財不露白不能讓壞人輕易撈走,而就算被撈走也不讓壞人有利用價值,最後絕不能讓壞人住進來有機會到處亂逛閒晃。他肯定會幹什麼壞事的!

 

個資防護第一招:「去識別化」讓個資看不見

何謂機敏資料?這裡讀者們應保護的標的應是個資法第二條定義的個人資料,即「自然人之姓名、出生年月日、國民身分證統一編號、護照號碼、特徵、指紋、婚姻、家庭、教育、職業、病歷、醫療、基因、性生活、健康檢查、犯罪前科、聯絡方式、財務情況、社會活動及其他得以直接或間接方式識別該個人之資料」。可以發現,所謂個資並不侷限在列舉的這些,而是任何「得以直接或間接方式識別該個人之資料」。因此,有網購習慣的讀者,在各大購物網站所輸入的信用卡號碼也算是個資,也應被廠商妥善安全處理。譬如當我們登入網站瀏覽金融交易明細或電子月結單,敏感資料都應預先被應用程式給去識別化,或所謂的遮罩起來。



 圖一:某銀行呈現給客戶的畫面已將信用卡號碼去識別化。

這是怎麼做到的呢?當網站在呈現任何敏感資料時,都應假設這些資料是需要去識別化的,不管其原本在資料庫或其他來源是否已經有處理過,都在呈現給使用者時,適當地將部分欄位遮罩,譬如圖二的程式碼片段只保留信用卡號碼最後四碼(有的國家或地區有法規會要求需要幾碼),其餘號碼則去識別化。

 


 圖二:將信用卡號碼做適當的去識別化(PHP)。

不過,圖二這樣的去識別化作法過於死板,缺乏彈性,讀者在處理敏感資料的遮罩時,應該分兩個步驟:1)將敏感資料正規化,全部轉換為統一的格式;2)將正規化後的敏感資料進行去識別化。


在圖三,我們展示兩種不同去識別化的效果,簡單直接取最後四碼的做法僅適用於指定格式的信用卡號碼,而較彈性作法則是可處理不同發卡銀行的信用卡號碼格式,先是利用正規化整理成每4個數字即補上一個「-」"-"符號做間隔(以符合原先使用者預期看到的格式),再經遮罩函數把最後四碼保留,其餘號碼則取代為「X」字元。



 圖三:將不同信用卡號碼格式的資料做去識別化。


讀者不難發現,去識別化並不困難,在機敏資料呈現時讓良善使用者能約略知道這些是屬於其的個人資料,但透過遮罩網站能做到讓惡意使用者「看不見」,至少無法完全看見。圖四是筆者的拋磚引玉,還請讀者著手把其他的個資都一一做適當遮罩吧!





 圖四:用於去識別化的正規化與遮罩程式片段(PHP)。
 

個資防護第二招:「明文加密」讓財寶撈不走

 

本文所介紹的第一招去識別化固然好用,但這樣的遮罩防護並沒有辦法加強資料本身在儲存或傳輸的機密性。這裡我們要介紹第二招:「明文加密」,也就是機敏資料除了要讓使用者看不見之外,也要將其加密加料後才儲存至資料庫,讓壞人帶不走。

 

說到這,筆者不得不提及「我的密碼沒加密」(http://plainpass.com/)這個網站。它是台灣Chroot資安社群的好友Allen Own所費心整理的,作為重度網路使用者的大家,當然要懷疑有哪個網站不夠用心,沒有好好保護我們的個資。試想連密碼這麼祕密的資料居然儲存為明文,這不是等著給駭客看嗎?一旦遭受入侵那可是整碗端走的。在Allen的網站也提到yftzeng (Ant) 部落格中有一篇" Best Practicing for Password Protection"文章寫得非常好,解釋了各種密碼加密的方式來讓開發人員比較,其中也包括筆者在本文會提到很強大的加鹽巴雜湊法(Salted Hash)。

 

首先,密碼絕對不能是以明文方式儲存的。在2011年底中國大陸爆出一波數十個知名網站的用戶帳密外洩事件,被揭露的明文密碼竟然累積到有上億組,這些密碼肯定都會被駭客收錄為字典檔,被用於未來進行更有效的暴力破解密碼。圖五對遭洩漏的大量密碼做統計,發現最常用的密碼竟然可高達數十萬人之譜,每個人都以為自己選取夠複雜但又好記的密碼,殊不知有很多人也都選同樣的密碼由於這些外洩資料都進了駭客口袋,通通都變成弱密碼。在這些不用心的網站,所有明文密碼就都擺在資料庫裡,駭客肯定會躍躍欲試、欲罷不能。所以在第二招我們絕對要將機敏資料做到「明文加密」!

 

圖五:各種網站規模的用戶常用密碼之排行榜

 

對於用戶密碼的加密工作,一種做法是將明文密碼加以雜湊(Hash),譬如透過sha1md5等雜湊演算法做單向轉換,使有心人士光憑雜湊值難以逆推回去原始的明文為何。但是這樣的做法其實很害怕彩虹表(Rainbow Table)破解法。由於雜湊演算法都是公開已知的演算法,攻擊方可事先產生大量的各種明文的排列組合,計算出其相對應的雜湊值,並整理成一個彩虹表,這樣可讓麻煩的雜湊破解變成一個簡單的查表工作。 


要避免彩虹表破解,就要讓產生出的雜湊值與所使用的雜湊演算法沒有直接的對應關係,而是加入其他外部變數,這個變數稱之為鹽巴(Salt)。圖六是一段加了鹽巴的sha256雜湊運算,所產生的雜湊值在不預先知道鹽巴為何的情況下,攻擊方難以事先準備有用的彩虹表。

 

圖六:產生加鹽巴雜湊值(PHP

 


圖七展示一般雜湊值與加鹽巴雜湊值的差異,可明顯看出當所有用戶都使用12345678作為其密碼時,Hash1欄位所呈現的數值是一般sha256運算產生的雜湊值,五位用戶的Hash1全部都一樣。而Hash2欄位所呈現的數值則是加鹽巴雜湊值,由於每位使用者的鹽巴不同,所以運算出的Hash2全部都不一樣。如果有一天攻擊方偷取到這份密碼檔,Hash1不僅容易被彩虹表破解,也讓攻擊方知悉還有哪些人也是使用相同的密碼;反觀Hash2不僅難以使用彩虹表,也無法看出哪些人係使用相同的密碼。

 

圖七:雜湊值加不加鹽巴的差異 

 

圖八是在JSP實作加鹽巴雜湊運算,筆者在註解中提到使用的演算法應至少為sha256以上,主要是長度太小的都很容易被彩虹表破解,一般會建議sha256sha512以上。鹽巴的長度則建議至少為64位元,而加鹽巴的雜湊運算應該進行迴圈幾次呢?筆者會建議至少好幾百次,甚至在安全強度十分要求的環境,針對每個加鹽巴雜湊值都是迴圈運算個上千次是很普遍的。眼尖的讀者可能會發現稍早在圖六的PHP實作,所使用的亂數產生器是mt_rand(),即任意的系統時間,這其實是一個可被預測的亂數產生器,嚴謹來說不能算是最安全的作法。在這個範例,筆者改採用SecureRandom來產生亂數,是普遍公認安全的亂數產生器。最後每一組加鹽巴雜湊值與鹽巴都連同使用者帳號儲存在資料庫當中,以便於將來可以驗證使用者是否輸入正確的密碼!

 

圖八:產生加鹽巴雜湊值(JSP

 

處理完系統中明文密碼的安全儲存之後,這樣就結束了嗎?不是的。還有一大堆涉及機敏內容的文字也需要進行「明文加密」。譬如資料庫當中儲存的是密等公文,則公文內容絕對不應是以明文形式儲存在資料庫當中;同樣地,個資法條文中列舉的那些個資更是要加以明文加密,譬如我們稍早所舉例的信用卡號碼。有的讀者或許會有疑問,為什麼網站要儲存我的信用卡號碼?多半是為了方便下次直接調閱使用或帳務稽核比對而儲存的,雖然不是每個網站都會主動告知是否有蒐集這項資料。不論如何,這些個資都應加以「明文加密」,否則一旦資料庫遭到入侵,這些機敏資料都會全部清清楚楚地被駭客帶走。

 


圖九是在PHP程式實作的AES加解密,這邊所使用到的RIJNDAEL實際上是AES標準的加密演算法名稱。 

 

圖九:AES加解密程式片段(PHP

 

圖十展示利用上述的AES加解密程式片段所能達到的效果,可以看到先透過金鑰產生一段AES加密文字,再利用金鑰成功解回原始明文。因此,為達到機敏資料的機密性,應在資料庫裏面將其儲存為AES加密文字,而非原始明文。

 

圖十:明文內容透過AES-256加解密

 

至於在JSP上面的實作方式,讀者可參考圖十一的程式片段,在此範例還多了之前的加鹽巴觀念,讓攻擊方的破解成本大大提高。

 

圖十一:有鹽巴的AES加解密程式片段(JSP

 

 

個資防護第三招:「後門清查」讓壞人進不來

 

攻擊方在Web前端的頁面看不見機敏資料,殺進Web後端的資料庫也撈不走,這時候還有兩個防護重心不能掉以輕心,要避免網站出現任何的惡意程式與惡意文件。這些攻擊會直接或間接在網站上或使用者端開啟後門,進而導致個資洩漏。

 

首先,網站上的惡意程式(筆者會介紹一句話木馬,這種類型是網站開發人員需特別注意的)普遍是利用網站本身的漏洞來植入,譬如知名駭客網站Zone-h (http://zone-h.org/archive/special=1)每天都會揭露全世界(包括台灣)一大堆遭駭客入侵的網站,其網頁伺服器版本、作業系統版本,以及遭置換的頁面。這些遭駭頁面幾乎都是駭客自己登錄的,很妙吧!要防堵這類網站入侵攻擊,讀者必須要經常注意伺服器的版本更新,以及Web應用程式碼盡量避免具有任何OWASP Top 10風險,因為這些都可能讓門戶大開,給駭客有機會把木馬牽進來單位的網站。由於這部分的風險在過去幾年已談論許多,又筆者相信許多單位也已佈署佈署Web應用程式防火牆,單位的這些加固作業都會讓駭客的攻擊成本大為提升,相對地,他們一旦進來就很有機會留下後門,才能下次進出方便!另一種仍比較罕見,是利用網站上提供的檔案上傳或轉寄功能夾帶惡意文件,拜這兩年的APT (Advanced Persistent Threat)風潮之賜,這種攻擊手法的隱匿性與威力不容小覷。

 

攻擊方使用一句話木馬的動機來自於方便埋入不容易被發現的後門,以便於能持續輕易入侵收刮資料。其攻擊原理是寫一小段能夠被外界「惡意」使用者觸發進而得以啟動木馬的程式代碼,譬如說,該惡意使用者會去瀏覽特定頁面,或在瀏覽特定頁面時,額外在網址列輸入一些字串來啟動後門並輸入指令。我們研究網路上各種一句話木馬的呈現方式,討論最熱烈的以中國大陸的論壇居多,而範例代碼的比例以ASPPHP居多,有數十種之譜,JSPASP.NET很少(注意,也是有喔~)。圖十二是筆者認為最致命的三種典型一句話木馬形式,真的都是一句話(一行程式碼)就能產生一個後門來準備迎接將來的一匹木馬,也就是說所有的攻擊指令都會是在觸發後才動態地發生的,而非事先寫在程式碼當中,不然那樣肯定會超過一句話。

 

圖十二:三種高隱匿性的PHP一句話木馬


圖十三展示GET/GET形式的一句話木馬可輕鬆執行駭客自行撰寫的PHP程式代碼,譬如phpinfo(),進而瀏覽到該伺服器的諸多環境配置參數。

 

圖十三:GET/GET形式的一句話木馬可躲避源碼檢測工具

 

圖十四是encode形式的一句話木馬,其巧妙結合base64編碼解碼,搭配檔案寫入與檔案讀取所呈現高隱匿性效果。當特定頁面(test.php)被訪問即生成木馬頁面(a.php),木馬頁面的檔案內容可為任何攻擊程式,此例所寫入的內容是eval形式的一句話木馬。 

 

圖十四:encode形式的一句話木馬將隱匿性發揮至極致

 

我們也舉個JSP的例子給讀者們參考,請見圖十五,其原理也是利用檔案讀寫的方式動態生成攻擊程式碼。

 

圖十五:JSP一句話木馬也很殺

 

除了網站頁面可能被偷偷埋入一句話木馬,攻擊方也可以光明正大的利用網站本身就提供的檔案上傳或轉寄功能來夾帶惡意文件。甚麼是惡意文件?在過去多半的惡意程式是以執行檔的形式誘騙使用者點選,但隨著使用者的資安意識抬頭,在APT目標式攻擊時代,就改以將惡意程式搭配軟體漏洞一起放進文件之中,使其看起來像是一般的靜態文件,開啟後也多半仍有正常內容,但實際上使用者已默默觸發漏洞,而遭植入木馬。這也是為何在這兩年發生非常多的APT攻擊事件都是以電子郵件的方式直接寄送給目標對象,因為這樣的手法同樣具備高隱匿性,難以偵測阻擋。


圖十六展示的惡意文件植入方式是透過Web網站本身提供的上傳功能,像是申辦資料上傳,或者在其他網站也可能會有首長信箱、民意反映,甚至今年我們研究團隊在日本實際看到的履歷表上傳已經開始在被APT攻擊方濫用。這些都是網站開發人員應該要開始特別注意的。

 

圖十六:某銀行網站提供外界上傳申辦資料

 

筆者建議凡來自Web介面或電子郵件方式傳送過來的文件都要多加留意,可利用APT線上檢測服務來避免開啟APT惡意文件。

 

 

結論

 

在個資防護第一招我們介紹「去識別化」,這對於想冒充善良用戶的攻擊方,有一定的防堵作用,因為不論是呈現給使用者頁面或供下載的檔案,攻擊方都收集不到完整資料,因為所有從單位主機傳送給使用者的內容均經過去識別化,讓攻擊方「看不見」。

 

接著在個資防護第二招我們又介紹「明文加密」,因為資料既然稱之為機敏,本來就應該透過加鹽巴雜湊和AES加密等方式來安全地妥善保存,讓攻擊方「撈不到」任何有利用價值的資料。

 

最後在個資防護第三招「後門清查」,我們提醒開發人員與讀者務必要留意網站上突然多出來的程式片段或寄送過來的外部文件,前者可能是一句話木馬,後者則可能是APT惡意文件。唯有避免中木馬,才能盡可能讓網站或單位其它主機沒有後門,讓攻擊方「進不來」。

 

編註:相關文章請見「網站系統大變身,穿上個資保護新衣」

 

 

本文作者專注研究目標式攻擊威脅與防護,如您對本文有任何感想,歡迎來信交流:isnews@newera/messefrankfurt.com