Lie to Me: Abusing the Mobile Content Sharing Service for Fun and Profit
訳するなら「モバイルコンテンツ共有サービスを悪用して、楽して儲ける」とかだと思います
(for Fun and Profit は自己啓発書とかで使われるフレーズで、皮肉っぽさを感じる
Research Track: Web of Things, Ubiquitous and Mobile Computing
担当:楠
著者
Guosheng Xu, Siyi Li, Hao Zhou, Shucen Liu, Yutian Tang, Li Li, Xiapu Luo, Xusheng Xiao, Guoai Xu, Haoyu Wang
Guosheng Xu と Siyi Li が共同筆頭著者
大学は北京郵電大学 Beijing University of Posts and Telecommunications, China (BUPT)
Guosheng Xu: 主要論文は 2018 年の「A multi-server two-factor authentication scheme with un-traceability using elliptic curve cryptography(楕円曲線暗号を用いた複数サーバー二要素認証方式)」
Siyi Li: ML 系の人と名前が被っており(おそらく別人)、うまく検索できず...
Guoai Xu, Haoyu Wang が共同の共著者
Guoai Xu: BUPT 教授
ネットワークセキュリティ、複雑ネットワークの動的特性など
Haoyu Wang 華中科技大学 Huazhong University of Science and Technology, China 教授
ソフトウェア解析、プライバシー・セキュリティ、eCrime(ネット犯罪)、インターネットシステム計測など
論文を選んだ理由
元々セキュリティ系に関心があるため
アプリ機能(特に共有機能)への攻撃ということで、ニュースアプリとも関連がありそうな内容だったため
前提知識:アプリ間でのコンテンツ共有機能
特にユーザ間で情報をやりとりするようなメッセージサービス・ネットワークサービスで用いられる。他のサービスのコンテンツリソースにアクセスするためのリンクを、ユーザー間でスムーズに受け渡す仕組み
わざわざ共有したいコンテンツの URL を取得してコピペしたりしなくてもよく、情報共有の体験がよい
さらに、アプリ間の実装連携により自動でメタ情報を補ってくれるなど手動入力よりリッチな対応がされている
コンテンツ共有の例示
https://gyazo.com/1f87a2f015e9f858787f36caa3b1e428
https://gyazo.com/4f81ca85492f349e883c686695d5888e
図 1 (a) 共有ボタン
コンテンツ共有のイメージ
https://gyazo.com/722448248b6439f8a1e694ac481f2797
https://gyazo.com/127d42aef2bc0c6f21a34c4e71ae32d9
図 1 (b) 詳細カード。Weibo から WeChat への共有ならこのようになる。
これは Weibo が自身の共有情報(通称 SII)をWeChat 共有 SDK に渡す実装を書いているから。
_________________________________________________________________________________________________
論文まとめ Q&A
内容は?
Android アプリのコンテンツ共有機能の一部がハックされ悪用されていることを調査し、「Fake-Share Attack」と定義して初めて報告した
攻撃目的:ユーザーを騙して、意図しない飛ばしリンク(ポルノ・ギャンブルなどに関連するサイト)をクリックさせる
方法:信頼できる共有コンテンツ元(有名サービス)を騙ることでユーザーを誤解させる
再現実験したら市場の人気アプリで再現でき、有効性がある
特に WeChat SDK を悪用したものについての Fake-Share Attack 検知ソフト「DeFash」を作成し、攻撃が実際に検出できることを市場調査で示した
補足:WeChat は我々の使う LINE みたいなアプリ
先行研究との比較は?
アプリの不正利用的な側面での関連研究はあるが、アプリの「コンテンツ共有機能を悪用した攻撃」に関する発表は初であると主張している
この類型の攻撃が行われているという初の報告であることと、検出のためのツール開発に価値がありそう。
技術や手法のポイントは?
攻撃について:Android アプリにおいて、ネイティブ SDK のコンテンツ共有機能(Intent というアプリからアプリへの情報受け渡し機能をそのまま用いたもの)の上に、各 SNS 系のアプリが独自のリッチな共有機能 SDK(API)によるラッパーを噛ませている場合がある。この共有 SDK の部分の脆弱性が悪用されているというメカニズムを発見
WeChat では、共有時の情報元の識別として Sharing Identification Information (SII) というデータを用いる。しかし、これは「自身のアプリのもの」でなくても、「正しいアプリのもの」を渡せばそのアプリになりすませる(認証をすり抜けられる)
なので、別の有名なアプリの SII をゲットできれば、そのアプリに成り済ました共有情報を作成して送れてしまう
共有元として Twitter や YouTube を名乗っておきながら、リンク先では別の URL に誘導することができる
攻撃検出ツール DeFash について:二段階検出を行う
怪しいアプリの検知:Java コード解析ツールのデータフロー解析・静的解析フレームワークの手続き間解析の二つの既存手法を用いて、疑わしいアプリを検出
検知した怪しいアプリを動かしてみて、実際に攻撃しているところを再現:疑わしいアプリは実際に Android アプリ自動テストにかけて動かしまくりながら監視し、悪い挙動をするか確かめる
有効性は?
攻撃の有効性(現実性・脅威性):
コンテンツ共有機能を持った(中国における)主要なアプリ 35 個のうち、独自の共有 SDK がリリースされており、なおかつ著者による再現攻撃が成功したアプリが 7 つ存在することを確かめている
QQ, WeChat, DingTalk, Yixin, Alipay, KakaoTalk, Weibo
実際に Huawei 独自の Android アプリマーケット(Huawei AppGallery?)から 73,014 個の人気アプリを拾ってきて解析したら、24,515 個が Fake-Share Attack に利用可能だとわかった(つまり、有効な SII が入手できるので成りすますことができる)
作成した検出ツールの有効性:
実際に Huawei 独自の Android アプリマーケット(Huawei AppGallery?)のアプリ群 1,785 個に対して DeFash を使ったら、Fake-Share Attack を行なっているアプリが発見できた
攻撃の被害を受けているアプリの名前と不正アプリ内の出現頻度。多くの人気アプリが悪用されていることを示しており、評判を落とすことになると述べている。
https://gyazo.com/0681a4c299b68a48fe5b2dbb0146bb7b
議論は?
攻撃への対応策・緩和策の提案
コンテンツ共有サービス側
1. 共有コンテンツの説明カードに表示する情報は、Facebook や Twitter などアプリの情報をそのまま使うのではなく、実際に添付されているリンクの解析後のデータを使おう
2. ちゃんと認証機構を設計しよう
Android アプリ開発者側
自分のアプリが Fake-Share attack の詐欺対象にならないためには、本件で問題だった WeChat SDK の SII のような情報をソースコードに埋め込まないようにしよう。オンデマンドに暗号化ネットワーク経由で取得する設計を取ろう
限界について
DeFash は Java バイトコードの解析が前提なのでそれ以外には使えない点
実際にアプリを動かして攻撃を検出するテストは時間がかかり、多様な GUI にチューンさせるのが難しい点
7 つのアプリが標的になっていることはわかっているが、DeFash で攻撃を示せたのは WeChat のみである点
_________________________________________________________________________________________________
論文詳細
論文詳細:モバイルアプリにおけるコンテンツ共有
プリミティブな実装:
Android では Intent というリソース(go でいう channel に近いかも)に共有したいコンテンツの情報を詰めて StartActivity 機能に渡してやれば、すべてのアプリ間で共有のようなものは実装可能
ただ、ごく簡単なアプリ間ジャンプとテキストオートフィルしかないので、実質コピペの延長という体験
それに対して、各アプリは独自に Share-SDK を用意している場合がある。この SDK を組み込んだアプリでは、SDK 実装先アプリに対してよりリッチな共有をすることができる。
あるアプリの Share-SDK を用いたコンテンツ共有:WeChat Share-SDK の例
code:code_snippet_01.java
// WeChat Share-SDK にアプリ自身を登録
// NOTE: WeChat Share-SDK には WX という単語が使われるように見える
shareapi = WXAPIFacory.createWXAPI(this, APP_ID);
shareapi.registerApp(APP_ID);
...
// 共有するコンテンツに関する特定の情報を収集して、共有パッケージを構築
WXWebpageObject page = new WXWebpageObject();
page.webpageUrl = shareUrl;
WXMediaMessage message = new WXMediaMessage(page);
message.title = shareTitle;
message.description = shareContent;
message.thumbData = null;
SendMessageToWX.Req localReq = new SendMessageToWX.Req();
localReq.message = message;
...
// Share-SDK の sendReq 関数を呼び出して共有する
shareapi.sendReq(localReq);
たとえば KaKaoTalk なども同じような Share-SDK の作りになっている
論文詳細:Share-SDK の悪用について
コンテンツ共有全体の流れをまず理解する
(最初に ① の初期化時に渡した、緑の context、青の appId がどのように利用されていくのかを示している図)
https://gyazo.com/f176f3c3d0f28db14596f91f3f639f4d
送信側のプログラム
1. API 呼び出しくんオブジェクトを createWXAPI(param1, param2) で作成
param にそれぞれ現在の Context と APPID を引数に渡すとそのパラメタで初期化された API オブジェクトを作成する
2. 作成した呼び出しくんのメソッドApi.SendReq(req) でリクエスト送信
内部では端末の共有環境を確認している。
途中で URI を取得しており、 var3.m = "weixin://sendreq?apid=" + this.appId; で渡した APPID を含めている
3. 内部関数 Com.tencent.mm.sdk.a.a.a(param1, param2) で Android の Intent によるコンテンツ共有をラップしている
Intent オブジェクトを作成する
_mmesage_appPackage キーに現在のアプリのパッケージ名を詰める
_mmessage_content キーに APPID を含む URI を詰める
Intent に情報を入れたら、アンドロイド API の startActivity() によって WeChat にジャンプする
WeChat 側の Intent 認証
1. APPID について
アプリ管理プラットフォームに問い合わせてちゃんと存在して審査に合格したアプリの APPID か調査
パッケージ名も照会しておき、これが Intent に入っている packageName と対応するのかチェック
2. 署名について
アプリ管理プラットフォームに問い合わせて得られた APPID のアプリの署名と、ローカルデバイスから得られた署名を比較して一致を確認
この認証を終えると、APPID に対応する AppName がコンテンツ共有元となり、共有メッセージのカードに表示される
ポイントは、最初のオブジェクト作成時に呼んだ関数で入力するパラメータ param1, param2 に依存すること
createWXAPI(context = param1, appId = param2)
認証フローを見てみると、「渡されたパラメータ APPID, packageName が有効かどうか」は検証しているが、「その APPID, packageName が本当に共有元アプリのものなのか」は検証していない
つまり、ある正しい APPID, packageName の組を入手できれば、その組の主であるアプリを名乗って共有コンテンツカードを作成することができる
この「正しい APPID, packageName の組」をある種のクレデンシャル情報として、WeChat では Sharing Identification Information (SII) と呼ぶ
なので、この攻撃は「SII を使ったなりすまし攻撃」と要約できる
また、なりすまされる側、自分の SII を勝手に使われている側を「被害者アプリ victim app」と呼ぶ
論文詳細:攻撃の実装方法
論文詳細:攻撃の実装方法:その 1. getPackageName メソッドの上書き
SSI が {packageName: ".com.tencent.mobileqq", appId: ".wxf0a80d0ac2e82aa7" } であるようなアプリの Fake-Share Attack をしたい。
https://gyazo.com/f176f3c3d0f28db14596f91f3f639f4d
再掲。
③にあるように、他アプリにメタ情報を渡すための Intent を構築する際には V2 = context.getPackageName(); を呼んでいる( param1 = context )。
攻撃:偽の packageName をとるように、Context のメソッドをオーバーライドする
普通に自分の Context を渡せば、自分のアプリの packageName を参照されるだけなので攻撃にならない
なので、以下のように、入力用の ContextWrapper 型プロキシクラス(なりすまし用クラス)を作っておく
プロキシクラスの getPackageName メソッドをオーバーライドすることで、なりすましたいアプリのパッケージ名 ".com.tencent.mobileqq" を返す仕様にしておく
そして、このプロキシクラス ContextWrapper となりすましたいアプリの APPID である ".wxf0a80d0ac2e82aa7" で Share-SDK api を初期化する
code:code_snippet_02.java
api = WXAPIFactory.createWXAPI(new ContextWrapper(MainActivity.this){
@Override
public String getPackageName(){
return ".com.tencent.mobileqq";
}
}, ".wxf0a80d0ac2e82aa7");
これで SSI が {packageName: ".com.tencent.mobileqq", appId: ".wxf0a80d0ac2e82aa7" } であるようなアプリの Fake-Share Attack となる。
論文詳細:攻撃の実装方法:その 2. 悪意のある Intent を明示的に構築
再掲
https://gyazo.com/f176f3c3d0f28db14596f91f3f639f4d
ミソは、ターゲットとなる OSA(WeChat, KaKaoTalk など)が、現在のアプリ上で Intent を構築すること
攻撃方法1ではパラメータ渡しから間接的に Intent を書き換えていると言えるが、こちらでは直書きを考える
自分のアプリを低レイヤで解析していけば、Share-SDK がどのように Intent を構築しているかをカンニングできる
その形式を守るように Intent を自分で構築してしまえばよい
例えば SII を Intent の "_mmessage_appPackage" と "_mmessage_content" という key で保存していることが分かれば、それを構築してやればよい
Intent には .putExtra() で key-value 情報を渡せるので
.putExtra("_mmessage_appPackage", fake_packagename);
.putExtra("_mmessage_content", "weixin://sendreq?appid=" + fake_appid);
とすることで fake SII を挿入できる
code:code_snippet_03.java
Intent localIntent = new Intent();
localIntent.setClassName("com.tencent.mm", "com.tencent.mm.plugin.base.stub.WXEntryActivity");
...
localIntent.putExtra("_mmessage_appPackage", fake_packagename);
localIntent.putExtra("_mmessage_content", "weixin://sendreq?appid=" + fake_appid);
localActivity.startActivity(localIntent);
論文詳細:攻撃の実装方法:SII はどうやって漏洩するのか?
ところで、攻撃のためには SSI が {packageName: ".com.tencent.moblieqq", appId: ".wxf0a80d0ac2e82aa7" } である、というようなクレデンシャルに近いような情報を抜き取る必要がある。ここは現実的な条件だろうか?
実はこれは簡単である
Share-SDK で使用される APPID は一般に、あらかじめ定義された形式に則っている。これをマッチングすればよい
ある程度山勘でもいけるだろうし、解析ツールが使えるなら容易に文字列検索できる
APPID ごとに、アプリのパッケージ名を仮に作成することで仮の SII を作成し、共有を試みる。成功したら有効な SII だとわかる(ブルートフォースっぽい)
論文詳細:攻撃の実装方法:具体的な攻撃手順
Fake-Share Attack の実行環境となるアプリの作り方を含めて解説している
良性の Android アプリ .apk から、Apktool(リバースエンジニアリングツール)を使用して .smali コードを抽出する
NOTE: apk は画像などのリソースも含んだものなので、デコンパイルしてコード部分である smali のみに注目する
WeChat のような Share-SDK を利用しているアプリであることが前提
1. smali コードから、共有に関連する部分のコードを読み、APPID の保存場所を手動分析
2. smali コードを修正してアプリの実行モードを変更
つまり APPID を好きなものに変更する
packageName は先述した攻撃手法で上書きできる
3. 変更を加えたコードを再パッケージすれば Fake-Share アプリとなる
_________________________________________________________________________________________________
攻撃のみ解説することにします(時間なし...😢)
とはいえ検知ツールも逆攻撃という感じで同じく低レイヤを見ていて、リバースエンジニアリングしたら齟齬が見つかるよねって感じです
読んだ感想
日本の状況がどうかは気になる
中国(Huawei)アプリ市場での話だったため
基本的に Share-SDK のリバースエンジニアリングなので各社の規約とか違反しそうで、論文的にも中国の大学が中国のアプリに対してやってるからセーフなのかなと思った
こういうセキュリティ系ってどうなると論文として投稿可能なレベルなんだろう
CVE とかは運用されていると思うが、それらと学術論文の交差点ってどこらへんなのか気になる
USENIX Security とかもあるが、Black Hat とか DEF CON とかもあるのでそれぞれの文脈抑えたい
リバースエンジニアリングしてくる詐欺集団、怖すぎる
トレンドは eCrime などで調べるとよさそう
定数をプログラムに埋め込むのはやめよう