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(“http://www.google.com”)」這串資料，就代表該 App 程式希望檢視 Google 首頁。當此資料結構傳出來時，作業系統會決定該啟動哪個瀏覽器。
在這樣的設計之下，意圖不良的程式開發人員，就能在自己的 App 程式當中透過一個 Intent 資料結構來開啟一個瀏覽器並將竊取到的資料上傳至遠端的某個伺服器。譬如，惡意 App 程式想要將裝置的識別碼 (Device ID) 傳送至位於 http://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 應用程式要求的權限超過實際所需時。
from http://blog.trendmicro.com.tw/?p=3432
-----------------------------------------------------------
bypassing-android-permissions,what-you-need-to-know
The permissions in Android devices are designed to guarantee that those Android apps without any declared permissions cannot do anything harmful to the mobile device. Or can they?
How Android Permissions Work
Before we get into the details, let’s see how Android permissions work.
An Android app can access limited system resources. To access sensitive APIs, the app must declare permissions required in AndroidManiflest.XML file. These sensitive APIs include camera function, location data (GPS), Bluetooth and telephony functions, SMS/MMS functions and network/data connections.
Once an app is installed, the App Installer shows the declared permissions to the user who either accepts or refuses them.
If a user chooses to grant the permissions, these are applied to the
app so long as it is installed. During runtime, the system will no
longer notify the user when sensitive APIs are being accessed again.
Declining these permissions, on the other hand, aborts the app
installation.
Once an app attempts to use a protected feature but failed to declare the required permission, the runtime system typically throws a security exception, which then terminates the app.
Given these facts, it appears that the chances of bypassing
permissions is slim. Unfortunately, some crafty developers may create
apps that can circumvent permissions by abusing the following.
Misusing the Default Browser to Upload Information
In Android, an app can launch another app’s component using an intent, an abstract data structure that describes the operation to be executed. Each intent consists of action (the action to be performed) and data required to execute the action. When an app sends out an intent, the mobile OS chooses the appropriate app to handle it.
An intent with action Intent.ACTION_VIEW, for example, paired with data Uri.parse(“http://www.google.com”) indicates that the app wants to view the Google webpage. If this intent is sent out, the mobile OS determines the best choice to launch the browser.
With this in mind, a shady developer can develop an app with an intent to open a browser and upload any stolen data to the desired server. Should a malicious app want to upload the Device ID to server http://example.com, the developer can craft the intent this way:
Since the browser opens the URL, the malicious app does not need to declare android.permission.INTERNET because this was already acquired by the browser app.
Logcat: Far More Capable than You Think
Another way to abuse permissions is through the misuse of Logcat. Logcat is a logging system provided by the Android framework and can be used to collect, view, and filter system and app debug output. A set of APIs are also provided for application writers to write debug log into the buffer.
To read the logs, an app will only need to request android.permission.READ_LOG, which appears to be harmless for an ordinary user to be aware of.
Developers may write any information into Logcat, which in most cases are debug information. While some of this information are sensitive in nature (e.g. login credentials, credit card numbers), careless developers may forget to remove these when releasing their products. This can be problematic, as malicious apps may read these information from the log message poll and may use these information in their next attack.
Similarly, the OS also log certain information, which a potential attacker can use to his/her advantage.
For example, in some versions of Android, when opening a website using the default browser, Logcat logs the URL being opened. Though this act may seem harmless, a malicious app can monitor the log to get URLs and determine user’s preference. This monitoring then enables an attacker to choose the phishing version of the users’ most-visited site. Should users browse the site again, the app may stop the loading site and instead ask the browser to load the phishing version instead.
Another example is GPS. When using the GPS service provided by system, some apps will log the current GPS data. A malicious app may get updated location information just by auditing the log, to track user.
Abusing Unprotected Components
Android apps typically have four components: activity, service, content provider, and broadcast receiver. Because of this, an application may be invoked via multiple entry points. To protect these components from being invoked by arbitrary apps, Android implemented the permissions system.
Contacts information is provided by system through the use of a content provider and to successfully query data from that content provider, the calling app should acquire android.permission.READ_CONTACTS. Similarly, to install another app, the app need to declare android.permission.INSTALL_PACKAGES. Apart from system pre-defined permissions, apps can also register their own permissions.Whichever permissions are declared by an app, the calling app should acquire those permissions to call the desired app.
However, there are still too many apps that do not require permissions. This is typical of components designed to be used inside the app. Unwary developers may think that since these are private, no other app (or possible attackers) will know the existence of these components.
Unfortunately, this gives malicious app writers an opportunity to make their move. A developer may intentionally look for all hidden and private components along with the intent to invoke them by decompiling the targeted app.
This becomes a grave concern if the flawed app is a system app. Pre-installed system apps usually have powerful capabilities such as installing app, reading sensitive information and even wiping all data stored in the device. Users also cannot uninstall system apps, unless their devices are rooted.
As found by security researcher Andre Moulu, many pre-installed apps in Samsung Galaxy S3 have serious capability leaks. Based from his research, one service has the ability to install (restore) APK files from a specific directory, but does not enforce permissions and check caller’s authority.
Moulu also found another service that copies .APK files to a specific directory in the SD card, but failed to enforce permissions or check the caller. Using these two vulnerabilities, a malicious app can drop its payload and use these services to copy the .APK file to a specific directory and install it – all without user’s attention and certainly without the need to acquire permissions.
To know more about permissions and how to secure your devices, you may read our Digital Life e-Guide When Android Apps Want More Than They Need.
from http://blog.trendmicro.com/trendlabs-security-intelligence/bypassing-android-permissions-what-you-need-to-know/
Android 權限機制的運作方式
在深入探討進一步細節之前，讓我們先來看看 Android 的權限機制如何運作。
Android 的 App 程式對系統資源的存取是受到管制的。要存取一些敏感的應用程式介面 (API)，App 程式首先必須在 AndroidManiflest.XML 檔案當中宣告它所需要的權限。這些所謂敏感的 API 包括了相機功能、GPS 定位資訊、藍牙與電話功能、SMS/MMS 簡訊功能，以及網路/資料連線功能。
在安裝 Ap 程式時，程式安裝器 (App Installer) 會將這些程式宣告的權限顯示給使用者看，由使用者決定是否要接受並安裝該程式。
在安裝 Ap 程式時，程式安裝器 (App Installer) 會將這些程式宣告的權限顯示給使用者看，由使用者決定是否要接受並安裝該程式。
假使有某個 App 程式嘗試使用這些受保護的功能卻未事先宣告，系統在執行該應用程式時就會出現安全性錯誤，並終止應用程式。
假使有某個 App 程式嘗試使用這些受保護的功能卻未事先宣告，系統在執行該應用程式時就會出現安全性錯誤，並終止應用程式。
濫用預設瀏覽器來上傳資訊
在 Android 系統中，一個 App 程式可以呼叫另一個 App 程式的元件，然後透過一個名為「Intent」的抽象資料結構來描述其所要執行的作業。每一個 Intent 資料結構當中都包含了要執行的動作，以及執行該動作需要的資料。當一個 App 發出一個 Intent 時，行動裝置作業系統會選擇一個適合的應用程式來處理該資料。
例如，一個內含「Intent.ACTION_VIEW 」這個檢視動作的 Intent，再配上「Uri.parse(“http://www.google.com”)」這串資料，就代表該 App 程式希望檢視 Google 首頁。當此資料結構傳出來時，作業系統會決定該啟動哪個瀏覽器。
在這樣的設計之下，意圖不良的程式開發人員，就能在自己的 App 程式當中透過一個 Intent 資料結構來開啟一個瀏覽器並將竊取到的資料上傳至遠端的某個伺服器。譬如，惡意 App 程式想要將裝置的識別碼 (Device ID) 傳送至位於 http://example.com 的伺服器，其 Intent 內容將如下所示：
惡意 App 程式想要將裝置的識別碼 (Device ID) 傳送至位於 http://example.com 的伺服器，其 Intent 內容如圖
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 應用程式要求的權限超過實際所需時。
from http://blog.trendmicro.com.tw/?p=3432
-----------------------------------------------------------
bypassing-android-permissions,what-you-need-to-know
The permissions in Android devices are designed to guarantee that those Android apps without any declared permissions cannot do anything harmful to the mobile device. Or can they?
How Android Permissions Work
Before we get into the details, let’s see how Android permissions work.
An Android app can access limited system resources. To access sensitive APIs, the app must declare permissions required in AndroidManiflest.XML file. These sensitive APIs include camera function, location data (GPS), Bluetooth and telephony functions, SMS/MMS functions and network/data connections.
Once an app is installed, the App Installer shows the declared permissions to the user who either accepts or refuses them.
Once an app attempts to use a protected feature but failed to declare the required permission, the runtime system typically throws a security exception, which then terminates the app.
Misusing the Default Browser to Upload Information
In Android, an app can launch another app’s component using an intent, an abstract data structure that describes the operation to be executed. Each intent consists of action (the action to be performed) and data required to execute the action. When an app sends out an intent, the mobile OS chooses the appropriate app to handle it.
An intent with action Intent.ACTION_VIEW, for example, paired with data Uri.parse(“http://www.google.com”) indicates that the app wants to view the Google webpage. If this intent is sent out, the mobile OS determines the best choice to launch the browser.
With this in mind, a shady developer can develop an app with an intent to open a browser and upload any stolen data to the desired server. Should a malicious app want to upload the Device ID to server http://example.com, the developer can craft the intent this way:
Another way to abuse permissions is through the misuse of Logcat. Logcat is a logging system provided by the Android framework and can be used to collect, view, and filter system and app debug output. A set of APIs are also provided for application writers to write debug log into the buffer.
To read the logs, an app will only need to request android.permission.READ_LOG, which appears to be harmless for an ordinary user to be aware of.
Developers may write any information into Logcat, which in most cases are debug information. While some of this information are sensitive in nature (e.g. login credentials, credit card numbers), careless developers may forget to remove these when releasing their products. This can be problematic, as malicious apps may read these information from the log message poll and may use these information in their next attack.
Similarly, the OS also log certain information, which a potential attacker can use to his/her advantage.
For example, in some versions of Android, when opening a website using the default browser, Logcat logs the URL being opened. Though this act may seem harmless, a malicious app can monitor the log to get URLs and determine user’s preference. This monitoring then enables an attacker to choose the phishing version of the users’ most-visited site. Should users browse the site again, the app may stop the loading site and instead ask the browser to load the phishing version instead.
Another example is GPS. When using the GPS service provided by system, some apps will log the current GPS data. A malicious app may get updated location information just by auditing the log, to track user.
Abusing Unprotected Components
Android apps typically have four components: activity, service, content provider, and broadcast receiver. Because of this, an application may be invoked via multiple entry points. To protect these components from being invoked by arbitrary apps, Android implemented the permissions system.
Contacts information is provided by system through the use of a content provider and to successfully query data from that content provider, the calling app should acquire android.permission.READ_CONTACTS. Similarly, to install another app, the app need to declare android.permission.INSTALL_PACKAGES. Apart from system pre-defined permissions, apps can also register their own permissions.Whichever permissions are declared by an app, the calling app should acquire those permissions to call the desired app.
However, there are still too many apps that do not require permissions. This is typical of components designed to be used inside the app. Unwary developers may think that since these are private, no other app (or possible attackers) will know the existence of these components.
Unfortunately, this gives malicious app writers an opportunity to make their move. A developer may intentionally look for all hidden and private components along with the intent to invoke them by decompiling the targeted app.
This becomes a grave concern if the flawed app is a system app. Pre-installed system apps usually have powerful capabilities such as installing app, reading sensitive information and even wiping all data stored in the device. Users also cannot uninstall system apps, unless their devices are rooted.
As found by security researcher Andre Moulu, many pre-installed apps in Samsung Galaxy S3 have serious capability leaks. Based from his research, one service has the ability to install (restore) APK files from a specific directory, but does not enforce permissions and check caller’s authority.
Moulu also found another service that copies .APK files to a specific directory in the SD card, but failed to enforce permissions or check the caller. Using these two vulnerabilities, a malicious app can drop its payload and use these services to copy the .APK file to a specific directory and install it – all without user’s attention and certainly without the need to acquire permissions.
To know more about permissions and how to secure your devices, you may read our Digital Life e-Guide When Android Apps Want More Than They Need.
from http://blog.trendmicro.com/trendlabs-security-intelligence/bypassing-android-permissions-what-you-need-to-know/
