android webview 漏洞背後的節操

by superhei 2013/09/06 

[注：本文提到的都是我我的的觀點，該行爲也是私人行爲，與任何組織、公司無關。另：水軍請自重！]

1、前言
  這兩天，一個2＋年前的android webview的nday就像一面「照妖鏡」同樣，直接暴露了不少我的和公司的節操...

2、流程

有白帽子在8月29日開始提交各類android平臺上的「遠程命令執行」漏洞，隱隱感受到這是一種通用漏洞類型，經過聯繫並請教獲得這類漏洞的技術細節。該漏洞
是android中webview組件裏的addJavascriptInterface引發的。主要目的是爲了實現java與js的交互操做。不過一個 經過getClass()的方法直接調用java. lang. Runtime接口執行系統命令，讓android的這個設計節操碎一地！

這個問題最先是能夠追溯到2011年的一篇paper《Attacks on WebView in the Android System》 http://www.cis.syr.edu/~wedu/Research/paper/webview_acsac2011.pdf 這篇文章指出 了addJavascriptInterface的方式在功能上帶來的一些風險，好比你的app裏實現了一個讀寫文件的類，而後使用 addJavascriptInterface藉口容許js調用，那麼就可能致使攻擊者直接調用這個class實現讀寫文件的操做。這種方式是最原始的風 險，並無直接指出getClass()方法的利用。

直到2012年12月21日老外一篇blog出現 《Abusing WebView JavaScript Bridges》 http://50.56.33.56/blog/?p=314 可能因爲這麼個性話的ip訪問blog形式（域名都沒有）因此關注的可能很少，好比我這 樣的常常處處翻東西的人也沒注意到這個。也有可能不少人看到了這個頁面，知道技術細節後考慮到危害或者利益本身偷偷雪藏了！不知道有沒有集團偷偷使用這個 漏洞。 ：）

對於這個漏洞android官方其實給出個「修補方案」的：http://blog.chengyunfeng.com/?p=483 這個是一個奇葩的 修補方案，直接忽視了android碎片化的問題，不少app開發廠商或者我的爲了兼容低版本的android是不可能直接使用這個方案的。另一方面很 多的產品過渡考慮的是用戶體驗問題，不少不必使用的webview的非要使用，有的地方根本不須要java與js交互的，非要交互。美其名曰：一切爲了 用戶體驗！

wooyun平臺有個積極的效應，讓一類一類的問題獲得充分的暴露，因而就有了《WebView中接口隱患與手機掛馬利用》http://drops.wooyun.org/papers/548
因爲本文裏詳細的演示，「一石激起千層浪」 各類官方加班修補，各類android開發叫苦連篇，還有就是各類「妖氣」開始橫生... 

而靠譜的修補方案卻不多有人給出！

3、「妖氣」來了

「妖氣」一來真是烏雲密佈...

"萬能妖"：

首先某數字旗下CDN產品微信發佈消息稱：「xx能攔截此類惡意代碼，保護用戶不受侵害」，而後就是xx工廠旗下CDN廠商，發佈多條微博、微信開始熱炒 該漏洞：「紅色預警：安卓webview遠程執行漏洞 移動應用速速接入xx保護，從雲端保護您的用戶不受此漏洞影響」  ... 當時我看這些的消息就 很是納悶，難道tmd大家都是整的萬能藥？CDN你說你防入侵還說得過去，雜這個andriod的漏洞也能防，真tn的高科技～～～ 後來有人說這個是產 品營銷。營銷也要靠譜點，過渡忽悠、多多泡沫是會害死人的～～～

奇怪的是各個移動安全廠商都沒有啥動靜，可能都去修補本身產品漏洞去了吧！：） 順便提一下這個漏洞在線檢測的問題，經過遍歷dom的方法是能夠找到這些 交互接口class的，這個也是通用exp的方法。騰訊TSRC也是經過這個來實如今線檢測的，他們推出的時候可能並無考慮到這個「雙刃劍」問題，固然 也沒有過多的不妥，由於有不少人已經意識到這個方法了。 這個代碼後來直接被xx工廠旗下CDN廠商copy後並自覺得的推出了一個2維碼的檢測！ 看上 去這個方式是很拉風的，是TSRC以前沒有意識到的，是咱們對產品的微創新... 而這個是個實足的「泡沫「、」博眼球」的玩意。 你掃瞄這個2維碼打開 這個URL提示的只是這個app自己有沒有被這個漏洞影響，而不能說明其餘app是否是受這個漏洞的影響，不是全部支持URL訪問的都有2維碼掃瞄，另外 還有一個坑的地方就是來自中間人的攻擊... 若是你掃一次2維碼就說明你手機安全了，那恭喜你，你已經被「妖氣」迷惑了！

「狐妖」：

一直以科普、質疑而聞名的xx調查員，每次出現都給人以「專業」、「有理有據」的感受，這個是「狐妖」最擅長的魅術。在這個「照妖鏡」下直接照出了原型：

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝引用＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
若是JS引擎容許調用Java類（基於JSInvokeClass），應限於可信瀏覽，不然存在安全隱患。這不是祕密，不是安卓平臺漏洞，而是已知的應用 策略問題，其被惡意利用的場景要求高，等級應爲[低]。媒體鼓吹安全軟件牛B時在場，誇大安全問題影響時也從不缺席，吃了原告吃被告。烏雲吆喝「緊急！」 實乃譁衆取寵。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

這個是否是「譁衆取寵」，懂點安全常識的人就知道。雖然我認爲這個漏洞要實現完美的利用，還須要一些其餘東西配合下.


「豬妖」

「豬妖」是很強大的，很容易攻擊他人，星爺的《西遊降魔》就充分說明了這點。再強大的妖怪也敵不過「照妖鏡」，化身爲某數字公司的「豬妖」直接現行了...

再一次說明了「豬妖」的強大，此漏洞大致在1月份在該公司的產品裏進行一些修補策略。因而基於他的「易攻擊」性，怎麼可能放棄這個機會呢？因而大勢攻擊競 爭對手產品存在漏洞。「成也'豬妖'、敗也'豬妖'」，他們忽視了另一句名言「豬同樣的隊友」！ 一個「str2.contains」就把本身給坑 了～～～


還有一羣跟着起鬨的「小妖」化身爲「**粉」～～～


4、漏洞修補方案


其實在老外的blog文裏提到了幾個修補方案：

＊ Use addJavascriptInterface only if the application loads trusted content into the WebView component (Internet || IPC == sketch).
＊ Develop a custom JavaScript bridge using the shouldOverrideUrlLoading function.  An application could check the newly loaded URL for a custom URI scheme and respond accordingly, but be careful about what functionality you expose via this custom URI scheme, and use input validation and output encoding to prevent the standard injection attacks.
＊ Reconsider why a bridge between JavaScript and Java is a necessity for this Android application and remove the bridge if feasible.


第1個方案是設置信任域，這個問題實際上是不太靠譜的，在我以前在kcon裏演講《去年跨過的瀏覽器》裏有不少信任域帶來的安全問題
第2個方案是使用 shouldOverrideUrlLoading 的方式，聽說這個方案仍是比較靠譜的，只是可能代價比較大。
第3個方案就是教育那些開發商，沒有必要用webview的時候就不要用，不要java與js交互就不要用。

其實我我的認爲是android官方能夠出個金融全部版本的靠譜的解決方案，不過就android風格及安全意識來講基本是不可能的。