避開 Android 權限機制：您應該知道的事

Android 裝置的權限機制設計，是為了讓未事先宣告並取得權限的 App 程式無法做出任何可能傷害裝置的行為。但真的是如此嗎？

Android 權限機制的運作方式

在深入探討進一步細節之前，讓我們先來看看 Android 的權限機制如何運作。

Android 的 App 程式對系統資源的存取是受到管制的。要存取一些敏感的應用程式介面 (API)，App 程式首先必須在 AndroidManiflest.XML 檔案當中宣告它所需要的權限。這些所謂敏感的 API 包括了相機功能、GPS 定位資訊、藍牙與電話功能、SMS/MMS 簡訊功能，以及網路/資料連線功能。

在安裝 Ap 程式時，程式安裝器 (App Installer) 會將這些程式宣告的權限顯示給使用者看，由使用者決定是否要接受並安裝該程式。

若使用者決定接受，那這些權限就永久授予給該程式，直到它解除安裝為止。執行時，系統不會再通知使用者這些程式正在使用一些敏感的 API。反之，若使用者決定不接受，那應用程式就無法安裝。

假使有某個 App 程式嘗試使用這些受保護的功能卻未事先宣告，系統在執行該應用程式時就會出現安全性錯誤，並終止應用程式。

在這樣的設計下，要避開權限機制似乎不太可能。但不幸的是，一些聰明的程式設計人員就是有辦法開發出一些能避開這些權限機制的 App 程式，方法就是濫用某些功能。

濫用預設瀏覽器來上傳資訊

在 Android 系統中，一個 App 程式可以呼叫另一個 App 程式的元件，然後透過一個名為「Intent」的抽象資料結構來描述其所要執行的作業。每一個 Intent 資料結構當中都包含了要執行的動作，以及執行該動作需要的資料。當一個 App 發出一個 Intent 時，行動裝置作業系統會選擇一個適合的應用程式來處理該資料。

例如，一個內含「Intent.ACTION_VIEW 」這個檢視動作的 Intent，再配上「Uri.parse(“https://www.google.com”)」這串資料，就代表該 App 程式希望檢視 Google 首頁。當此資料結構傳出來時，作業系統會決定該啟動哪個瀏覽器。

在這樣的設計之下，意圖不良的程式開發人員，就能在自己的 App 程式當中透過一個 Intent 資料結構來開啟一個瀏覽器並將竊取到的資料上傳至遠端的某個伺服器。譬如，惡意 App 程式想要將裝置的識別碼 (Device ID) 傳送至位於 https://example.com 的伺服器，其 Intent 內容將如下所示：

惡意 App 程式想要將裝置的識別碼 (Device ID) 傳送至位於 https://example.com 的伺服器，其 Intent 內容如圖

由於是透過瀏覽器來開啟這個網址，因此，惡意 App 程式自己根本不需宣告 android.permission.INTERNET 網際網路使用權限，因為瀏覽器已具備這個權限。

Logcat：功能遠超乎您想像

另一種濫用系統權限機制的方式是透過 Logcat這個系統內建工具。Logcat 是 Android 架構當中用來記錄系統事件的程式，可用來蒐集、檢視和過濾系統與 App 程式的除錯記錄。系統同時也提供了一組 API 來讓應用程式開發人員將自己的除錯資訊寫入其中。

要讀取這些記錄，App 程式只需取得android.permission.READ_LOG 讀取記錄檔權限即可，而這項權限對一般使用者來看似乎無害。

程式開發人員可以將任何資訊寫入 Logcat，大多時候都是一些程式除錯用的資訊。儘管這些資訊有時可能是一些敏感的資訊 (如：登入帳號密碼、信用卡資料)，但粗心的程式開發人員在 App 程式發表之前，很可能會忘了將這些資料關閉。如此一來，一些心懷不軌的 App 程式就能從記錄檔當中讀取到這類資訊，並且將這些資訊用於後續的攻擊。

同樣地，作業系統也會將某些資訊寫入記錄檔當中，因此也可能讓歹徒有機可乘。

例如，在某些版本的 Android 系統，當使用預設瀏覽器來開啟某個網站時，Logcat 就會記錄所開啟的網址。這樣的動作看似無害，但惡意程式卻能監控記錄檔的內容並擷取這些網址，進而發掘使用者的喜好。透過這樣的監控，歹徒就能知道使用者最常上哪些網站，進而知道該假冒哪些網站來進行網路釣魚攻擊。只要使用者再度瀏覽同樣的網站，App 程式還可能停止該網站載入並偷偷載入假冒的網站。

另一個例子是 GPS 定位。某些 App 程式在使用系統內的 GPS 定位服務時，會將當前的 GPS 定位資料寫入記錄檔。如此一來，惡意程式只要查詢記錄檔的資料，就能追蹤到使用者的最新位置。

濫用受保護的元件

Android App 程式通常由四種元件組成：活動、服務、內容提供者以及廣播內容接收者。因此，一個 App 程式可能會有多個進入點可以將它啟動。要保護這些元件，防止它們遭到別的 App 程式啟動，Android 便建立了一套權限機制。

例如，通訊錄資訊是由系統所提供，App 程式需透過「內容提供者」來查詢其資料，而要查詢這項資料， App 程式必須先取得android.permission.READ_CONTACTS 讀取通訊錄權限才能呼叫此功能。同樣地，App 程式必須先宣告 android.permission.INSTALL_PACKAGES 安裝套件權限才能安裝另一個 App 程式。除了系統預先定義的權限之外，App 程式也可以註冊自己專屬的權限。不論 App 宣告了哪些權限，要呼叫別的程式，App 程式必須先取得對應的權限才能執行呼叫。

但是，目前仍舊有太多的 App 程式在呼叫時並不會要求任何權限。這些通常是設計給某個 App 程式內部自己使用的元件。一些不夠謹慎的開發人員或許認為，這些是私人用途的元件，沒有其他 App 程式 (或歹徒) 會知道它們的存在。

不幸的是，這卻讓惡意 App 程式的作者有機可乘。這類程式設計者可能會刻意尋找所有隱藏或私人用途的元件，然後針對特定 App 程式進行反向工程，並透過 Intent 資料結構來加以啟動。

如此一來，若是有某個系統 App 程式在設計上出現瑕疵，將造成很大的問題。系統預載的 App 程式通常具備強大的功能，例如：安裝應用程式、讀取敏感資訊，甚至清除裝置上儲存的所有資料。此外，使用者也無法移除這些系統程式，除非先將裝置破解 (root)。

如同資訊安全研究專家 Andre Moulu 所發現，許多 Samsung Galaxy S3 預載的應用程式都有嚴重的功能漏洞。根據他的研究，某個服務具備了從某個目錄安裝 (回復) APK 檔案的能力，但卻未貫徹權限機制，也不會檢查呼叫者是否獲得權限。

Moulu 還發現，還有另一個服務會將 .APK 檔案複製到 SD 卡內的某個目錄，但也同樣不會貫徹權限機制或檢查呼叫者。透過這兩項漏洞，惡意 App 程式就能將自己的惡意 .APK 檔案放入對應的目錄，進而安裝到系統內，不僅神不知鬼不覺，當然更不需取得任何系統權限。

想要進一步了解有關權限的問題，以及如何保護您的裝置，您可參考我們的數位生活 e 指南：當 Android 應用程式要求的權限超過實際所需時。

◎原文來源

Bypassing Android Permissions: What You Need to Know作者：Yinfeng Qiu (行動裝置威脅分析師)
想了解更多關於網路安全的秘訣和建議，只要到趨勢科技粉絲網頁或下面的按鈕按讚