有隙可乘 - Android 序列化漏洞分析實戰
一、背景
大家應該看到過一篇《2022年的十大安全漏洞與利用》的文章，文章中提到一個漏洞：
利用Android Parcel序列化和反序列不匹配，借助應用FileProvider未限制路徑，可以獲取系統級startAnyWhere能力，從而獲取用戶敏感信息，修改系統配置，獲取系統特權等等。
這里面有三個關鍵詞：
- Parcel不匹配漏洞
- startAnyWhere
- FileProvider未限制路徑
看到以上，大家可能會就其中涉及到的幾個點有些疑問：
- startAnyWhere是什么意思，是什么樣的能力？
- Parcel不匹配漏洞是什么原理，是如何產生的？
- FileProvider的作用是什么，未限制路徑又是什么問題？
- 這幾者之間存在什么關聯，又會帶來哪些風險？
二、FileProvider
2.1 功能簡介
首先我們來簡單講一下FileProvider，FileProvider其實就是用來進程間共享文件的。
上方左側圖是早期的應用間共享文件的方案，就是A應用把文件存在外置存儲，然后把文件的物理地址給到B應用，B應用去這個地址去取。
那么這樣的方式存在哪些問題呢？有以下幾點：
- 權限無法控制：文件存放的位置，要保證都能訪問，這樣無法精確控制權限；
- 權限無法回收：文件一旦共享，無法撤銷；
- 目錄結構暴露：文件共享需要公開原始的文件地址，暴露了目錄結構；
- 隱私內容泄露：部分私有目錄文件共享存在安全隱私泄露的風險。
基于以上問題，google基于ContentProvider設計了FileProvider，如上方右側圖，文件共享必須基于FileProvider，由AMS來管控權限，提供的協議也是定制的content協議。
2.2 使用簡介
了解了FileProvider出現的背景，下面介紹一下FileProvider的使用，使用FileProvider需要提供四個參數：
- Uri(文件地址)
- Action(接收方信息)
- Type(文件類型)
- Flags(授予權限)
如下面代碼，最終通過startActivity來發起共享，記住這個startActivity，很重要。
Intent intent = new Intent();
intent.setAction("");
Uri uri = FileProvider.getUriForFile(getContext(), "", file);
intent.setType(getContext().getContentResolver().getType(uri));
intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION | Intent.FLAG_GRANT_PERSISTABLE_URI_PERMISSION);
startActivity(intent);2.3 URI簡介
content URI和普通的Http協議一樣，也擁有scheme，authorities，path。
示例：content://authorities /XXX/xxx.txt。
Android提供了xml配置，如下代碼所示，把實際的路徑映射成一個虛擬的名稱，這樣的優勢就是限制了路徑，可以把指定目錄的路徑共享出去。
看到這里，大家就可以理解未限制路徑的含義了，簡單講就是把系統根目錄給共享出去了，正確的做法是只共享需要使用的目錄。
<provider
android:name="androidx.core.content.FileProvider"
android:authorities="${applicationId}.file"
android:exported="false"
android:grantUriPermissions="true">
<meta-data
android:name="android.support.FILE_PROVIDER_PATHS"
android:resource="@xml/******_paths" />
</provider><?xml versinotallow="1.0" encoding="utf-8"?>
<resources>
<paths>
<files-path name="test_in" path="/test/file" />
<external-path name="test_external" path="/test/file" />
</paths>
</resources>2.4 權限簡介
FLAG_GRANT_READ_URI_PERMISSION：文件讀權限；
FLAG_GRANT_WRITE_URI_PERMISSION：文件寫權限；
FLAG_GRANT_PERSISTABLE_URI_PERMISSION：持久授權，直至設備重啟或者主動調用revokeUriPermission；
FLAG_GRANT_PREFIX_URI_PERMISSION：相同前綴路徑統一授權。
2.5 授權方式
//第一種授權方式
intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);
//第二種授權方式
getContext().grantUriPermission("packageName", uri, Intent.FLAG_GRANT_READ_URI_PERMISSION);2.5.1 第一種授權方式：
一次授權，用完即止。
2.5.2 第二種授權方式：
- 不含持久授權flag的，權限依附于進程存活；
- 包含持久授權flag的，重啟或者主動拒絕權限才會消失。
2.6 小結
上面主要簡單介紹了一下FileProvider的設計思想、技術方案、使用方式，由此我們可以對文章開頭提出的一些疑問進行解答。
1、FileProvider的作用
答：跨進程共享文件，一般通過startActivity的方式。
2、未限制路徑
答：沒有指定需要共享的文件目錄，將系統根目錄共享出去了。
3、存在什么風險，如何進行攻擊
答：單針對FileProivider來看，風險較小，光依賴FileProvider這個問題還是沒法進行攻擊的，原因如下：
- 文件共享需要業務主動通過startActivity才能發起
- 讀寫權限交由系統來管理
三、startAnyWhere
接下來講一下上文中提到的startAnyWhere，顧名思義，就是應用想打開哪個頁面就打開哪個頁面，那么在Android系統中，誰才有這個能力呢？
3.1 實現原理
能夠實現startAnyWhere的只有系統SystemUid應用，這類應用在startActivity進行權限校驗的時候是直接放行的，無論Activity是否exported，都能打開，最常見的應用比如系統設置。
下面是一個系統設置打開第三方應用的案例，通過設置可以直接打開第三方的賬戶登錄頁。
3.2 實現流程
通過設置頁面的添加賬號的功能，可以直接拉起對應應用的界面，這個是今天漏洞的核心，我們來看一下系統調用流程。
如下圖，首先系統設置調用AccountManager的addAccount，然后通過SystemServer中的AccountManagerService，一直調用到目標APP本身的AddAccount實現。
由APP本身提供一個Bundle，Bundle里面本身包含了一個intent的由設置進行打開。
這個里面其實存在一個風險，第三方應用可以隨意提供一個惡意Intent，系統會直接調用startActivity，隨之而來的風險很大。
上圖中還存在一個第0步，即這個流程的發起方可以是三方應用本身，不一定需要從設置進入，那么這個整個流程就閉環了，完全無需用戶介入，用戶也可以完全無感知。
不過這個風險呢，google在Android4.4之后已經修復了，4.4之后增加了對intent內容的校驗。
代碼如下：
if (result != null&& (intent = result.getParcelable(AccountManager.KEY_INTENT)) != null) {
if (!checkKeyIntent(Binder.getCallingUid(),intent)) {
onError(AccountManager.ERROR_CODE_INVALID_RESPONSE,"invalid intent in bundle returned");
return;
}
}上面代碼就是取出外部傳入的KEY-INTENT進行校驗，這里面已經出現了今天的主角Parcel，整個攻擊也是通過Parcel漏洞使得惡意的KEY-INTENT繞過系統的檢查。
四、Parcel
下面我們看一下parcel漏洞及原理。
4.1 Parcel 簡介
parcel是專門為Android提供的一個序列化的類，parcel的原理其實很簡單，就是一個嚴格的對稱讀寫，如下代碼所示。
public void writeToParcel(Parcel dest, int flags) {
dest.writeInt(mSize);
}
public void readFromParcel(Parcel in) {
mSize = in.readInt();
}同時序列化遵循基本的TLV格式，也就是Tag-Length-Value，Tag代表類型，Length代表長度，Value代表值，當然一些特殊情況：
- Length不描述：有固定長度的類型可以不描述length，比如long，int等等；
- Tag不描述：bundle序列化時，key一定是string類型，所以不需要描述Tag。
回到對稱讀寫這一塊，如果這個代碼不對稱了會出現什么情況呢，google曾經在android源碼中出現了很多類似不對稱的錯誤，看一下下面幾個案例。
4.2 Parcel 不對稱讀寫案例
4.2.1 案例1
如下圖，這是一個典型且明顯的不對稱，writeLog&readInt，為什么不對稱，很簡單，int和long對應的長度不一樣。
4.2.2 案例2
這是一個比較隱晦的不對稱案例，是Android原生的WorkSource類，這個不對稱一眼無法看出，以致于最近的Android版本這個問題一直存在，這個類也是此次漏洞攻擊真正被利用的一個類。
下面簡單看一下WorkSource序列化和反序列化的流程。
序列化
如下述代碼，WorkSource序列化時，如果mChains是一個長度為0的空list，那么就會走else分支，此時序列化會連續寫兩個0。
序列化：
public void writeToParcel(Parcel dest, int flags) {
dest.writeInt(mNum);
dest.writeIntArray(mUids);
dest.writeStringArray(mNames);
if (mChains == null) {
dest.writeInt(-1);
} else { // 當mChains不為空的時候，這時候寫了兩個0
dest.writeInt(mChains.size());// 寫第一個0
dest.writeParcelableList(mChains, flags);// 寫第二個0
}
}反序列化
如下述代碼，WorkSource反序列化時，當讀到第一個0也就是numChains=0的時候，這個對應mChains長度為0，同樣也會走else分支，此時mChains直接被置為null，但是序列化其實是寫了兩個0，這時候后面還有一個0沒有讀，這樣序列化和反序列化就造成了不對稱。
反序列化：
WorkSource(Parcel in) {
mNum = in.readInt();
mUids = in.createIntArray();
mNames = in.createStringArray();
int numChains = in.readInt(); // 讀第一個0
if (numChains > 0) {
mChains = new ArrayList<>(numChains);
in.readParcelableList(mChains, WorkChain.class.getClassLoader());
} else { // 當讀到numChains=0的時候，這時候直接就將mChains置為null，第二個0還沒有讀
mChains = null;
}
}當然實際上不對稱的類還有很多，大家可以看下網上泄露出來的漏洞利用源碼，有很多這樣的類，這里就不列出來了，知道了漏洞的本質是因為Parcel讀寫不對稱，我們接下來看一下其中的原理。
4.3 parcel 漏洞原理
了解parcel漏洞真正的原理之前，首先來看一下系統校驗intent的序列化流程。
4.3.1 系統校驗序列化流程
首先攻擊者手動會序列化一次需要傳給系統的bundle，然后系統會反序列化一次進行校驗，校驗完之后又會重新序列化交給設置，然后設置真正去打開頁面的時候會再次反序列化，這樣就經歷了兩次序列化與反序列化，因為其中讀寫不對稱，所以給了攻擊者有機可趁的機會。
4.3.2 漏洞原理簡介
這個漏洞核心就是前后一共經歷了兩次序列化和反序列化。我們以上面4.2.1案例1的不對稱舉例（readInt()對應writeLong()），當出現不對稱讀寫之后，兩次序列化與反序列化會有什么后果？如下圖所示可以看到：
第一次序列化：輸入兩個int 1；
第二次反序列化：讀的時候是readInt()，讀出兩個int 1；
第三次序列化：寫的時候是writeLong()，這是分別寫了long 1和int 1，long的長度是int長度的雙倍；
第四次反序列化：讀的時候是readInt(),第一個long 1會被分成兩個int來讀，所以就一次讀成了101。
而攻擊者也正是借助這個不對稱，導致實際輸入和輸出不一樣，隱藏了惡意的KEY-INTENT，從而繞過了系統的校驗，以此打開任意一個頁面，實現startAnyWhere。
4.3.3 漏洞原理實踐
因為案例1比較明顯，google早已經修復該漏洞，而WorkSource因為比較隱晦，所以該漏洞一直存在，我們接下來看一下如何利用WorkSource來構造攻擊實現。
下面一張圖帶你搞明白如何通過兩次序列化和反序列化達到我們的目的：
由上述文章可知，最終給到系統校驗的是一個bundle類型的數據結構，bundle是存儲key-value類型的，而我們目的就是要將惡意的KEY-INTENT隱藏起來然后繞過系統的校驗。接下來詳細講一下實現步驟：
1、手動序列化：
如上圖左側第一列，手動序列化這個bundle，這個bundle序列化時攜帶了三個key-value：
- 第一個key-value：WorkSource相關的；
- 第二個key-value：經過精心構造；
- 第三個key-value：隱藏惡意的KEY-INTENT。
第一次序列化后的bundle通過16進制打印出來如下圖所示：
2、系統進行反序列化
經過系統第一次反序列化，沒有觸發不對稱，系統是讀不到這個惡意的KEY-INTENT的，所以自然校驗通過。
3、系統重新序列化
系統校驗完需要重新序列化，這時候由于讀寫不對稱，最終紅色區域【1，-1】兩個值變成了【0，0】。
4、setting反序列化
setting再次反序列化，上面也講到了，由于不對稱，原本兩個0只讀了1個0。
5、解析最終的key-value
- 讀第一個key-value：由于上述WorkSource的不對稱，原本兩個0只讀了1個0；
- 讀第二個key-value：由于讀第一個時少讀了一個0，剩余的0變成了第二個key-value的內容，整體內容錯位，由于遵循TLV的格式，錯位之后，0和13變成了第二個key-value的key，惡意KEY-INTENT前的所有值都變成了第二個key-value的value；
- 讀第三個key-value：此時真正惡意的KEY-INTENT變成我們需要的第三個key-value。
五、漏洞攻擊實戰
通過上面兩節，我們可以看到，借助startAnyWhere和parcel漏洞，可以繞過系統校驗任意打開一個頁面，下面來看兩個真實案例：
5.1 實戰案例1
可以看到在虛擬機上，通過這個漏洞直接就打開了鎖屏密碼的設置頁面，然后可以直接繞過密碼校驗將鎖屏密碼改掉。
5.2 實戰案例2
案例1已經足以反應出問題和風險，但是實際上國內的手機經過改造，基本不會存在這個問題，那么我們來看一下真機上的使用案例：
在講這個案例之前，我們要先額外講一下XXSDK中存在的一個AsistActivity，里面存在一段代碼，如下所示。
這個代碼很簡單，就是接受外部的intent的然后直接startActivity了，這里面又提到了startActivity，上面文件共享也是這樣調用的，正好符合了FileProvider的使用邏輯。
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
//此處省略部分代碼
Intent intent = getIntent().getParcelableExtra(Intent.EXTRA_INTENT);
int intExtra = intent == null ? 0 : intent.getIntExtra("", 0);
//此處省略部分代碼
startActivityForResult(intent, intExtra);
}借助這個類，我們便可以模擬一個完整的攻擊流程，如下圖所示：
- 第一步：攻擊APP構造一個intent1，這個intent1的意圖是打開上述AssistActivity；intent1中攜帶了惡意的intent2，這個intent2的意圖打開攻擊APP的指定頁面，然后讓應用共享指定文件了；
- 第二步：調用andorid系統添加賬號頁面；
- 第三步：業務APP中由于集成了AssistActivity，接受惡意的intent2會直接startActivity進行共享文件；
經過以上三步，直接就把APP的一些隱私文件共享給攻擊APP，同時攻擊APP可以在惡意intent中授權直接修改文件。
5.3 惡意intent的代碼
下面看一下惡意intent的代碼：
private Intent makeFileIntent() {
Intent intent1 = new Intent().setComponent(new ComponentName("XXX", "xxx.xxx.AssistActivity")); // 打開AssistActivity
Uri uri = Uri.parse("content://xxxx/xxx_info");
Intent intent2 = new Intent(mContext, SecondActivity.class); // 打開攻擊者的頁面并且共享指定URI的文件
intent2.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);
intent2.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
intent2.setType(mContext.getContentResolver().getType(uri));
intent2.setData(uri);
intent1.putExtra("key", intent2);// 惡意intent2放入intent1中
return intent;
}5.4 惡意序列化的代碼
目前漏洞均已修復，為避免風險，不展示所有代碼。
private static Bundle makeEvilIntent(Intent intent) {
Bundle bundle = new Bundle();
Parcel obtain = Parcel.obtain();
Parcel obtain2 = Parcel.obtain();
Parcel obtain3 = Parcel.obtain();
obtain2.writeInt(3);// bundle中key-va長度
obtain2.writeString("firstKey");
obtain2.writeInt(4); //VAL_PARCELABLE
obtain2.writeString("android.os.WorkSource");
obtain2.writeInt(-1);//mNum
obtain2.writeInt(-1);//mUids
obtain2.writeInt(-1);//mNames
obtain2.writeInt(1);//mChains.length
obtain2.writeInt(-1);
...此處省略一些構造代碼
bundle.readFromParcel(obtain);
return bundle;
}以下是視頻演示，通過上面這一段攻擊代碼，拿到了手機上某個APP存在應用私有目錄下的賬號信息， 同樣為了隱私，此處部分脫敏。
六、漏洞利用影響
通過上文的介紹，我們知道借助這個漏洞可以實現對系統任意文件的修改，下面列出了漏洞帶來的影響：
- 讀取用戶隱私信息；
- 安裝惡意應用；
- 改寫動態加載的代碼；
- 改寫系統配置；
- 獲取特殊權限。
七、漏洞修復措施
除了發現問題更重要的是解決問題，下面列出了修復這個漏洞對應的一些方案：
系統層：
- 修復pacel漏洞的不對稱；
- 系統校驗的時候，做兩次序列化與反序列化；
應用層：
- FileProvider增加路徑限制；
- 接受intent的Activity要著重注意校驗，設置黑白名單。
八、漏洞預防措施
漏洞其實是不可避免的，下面是面對層出不窮漏洞的一些預防措施：
- 組件能不導出就不導出；
- 可導出的組件建議增加簽名或者包名校驗；
- 接受intent或者url參數務必校驗；
- 文件共享務必遵循最小化原則；
- 敏感內容需要進行加密。
九、總結
接下來簡單回顧一下，本文主要講了5方面內容：
- 第1方面：主要描述了FileProvider，闡述了其出現背景、設計原理、使用方式、優缺點等；
- 第2方面：主要描述了startAnyWhere，闡述了其實現原理、實現方式；
- 第3方面：主要描述了Parcel不對稱漏洞，闡述了Parcel的設計原理、不對稱漏洞、漏洞案例、漏洞原理以及漏洞利用方案；
- 第4方面：主要描述了漏洞攻擊實戰，從模擬器到真機，從原理到代碼，演示了通過漏洞攻擊手機、獲取用戶隱私信息的流程；
- 第5方面：主要是講了漏洞帶來的影響、漏洞的修復和預防措施。
整體來講，這個漏洞波及了所有的Android手機，無論是對用戶，對企業都造成了巨大的損失。
作為開發者的我們需要從自身做起，守護好每一個環節，避免讓攻擊者有隙可乘。
