2011年10月12日(水曜日)

AppLogSDKの脆弱性?

公開: 2011年10月16日15時40分頃

話題のAppLogですが、こんなリリースが出ましたね……「AppLogSDKの脆弱性に関する報告 (www.applogsdk.com)」。

脆弱性指摘の概要
現在 AppLogSDK につきましては、弊社サーバのとの通信内容を SSL(Secure Sockets Layer) を用いて暗号化しております。しかしながら、SSL の通信内容についてどのようなパラメーターで弊社サーバとの通信が行なわれているかが解析され、不正に第三者のAndroid端末に対して AppLog 送信の許可を行なう事ができるのではないかとの指摘を頂いております。

えっ? SSLとか何の関係もないですよね。

SSL/TLSは、サーバとクライアントとの通信を第三者に傍受されることを防ぐ役には立ちます。しかし、ユーザーが自らクライアントアプリケーションの挙動を解析することを妨げることはできません。まあ、解析が面倒にはなりますが、単に面倒になるだけです。SSL/TLSに解析妨害を期待するのは間違っています。

また、Androidアプリケーションは、もとより耐タンパ性が期待できるような状況にないので、挙動は解析され得るというのが大前提となります。解析されると困るような設計は、それ自体がNGです。

ご指摘を頂いた内容に関しましては、第三者から不正に AppLog 送信の許可フラグを操作される事も想定し、IPアドレスの監視を用いて不正検知を行うよう準備は進めておりましたが、指摘の通り第三者が不正に AppLog 送信に関する許可フラグを操作を試みる事自体は可能となってしまっております。

これ、どこからツッコミを入れれば良いのか……。

まず、「準備は進めておりました」というのはけっこうすごい話です。準備を進めていたのは、対応の必要性があると分かっていたからでしょう。つまり、指摘される前から問題を認識していて、にもかかわらずサービスを続けていた、ということになります。

そして、「IPアドレスの監視」というのが意味不明です。監視してどうするのでしょうか。

仮に、特定IPアドレスからの接続以外を拒否する、という意味なのだとすると、それは無意味です。たとえPCからのアクセスを制限しても、単にAndroid端末から指令を送れば良いだけだからです。

本来であれば、IPアドレスなどに依存しない認証の仕組みを考えておかなければならないはずです。それがされていないところを見ると、やはりオプトアウトする機能は最初から考えられていたわけではなく、後からおざなりに付け足したもののように思えます。

SSL の通信内容(パラメーター)が外部に流出する事で、AppLog 送信の許可フラグの操作を悪意を持った第三者が行う事が可能となってしまっている事を重く受け止め、IPアドレスの監視を用いた不正検知に加え、AppLog 送信の許可フラグを正規の Android端末が操作している事を確認した上で、実際の許可フラグの処理を行う等の対策を検討しております。

「正規の Android端末が操作している事を確認」って簡単に言いますけど、どうやるのでしょうね。端末固有IDの類はこの用途には使えないでしょうし、初回インストール時に鍵を生成して端末側に保存しておくような対応をしようとすると、既存のアプリとの互換性がなくなります。まあ、互換性を維持することはいろいろな意味で無理でしょうから、全てなかったことにしてやり直すのでしょうかね。

いずれにしても、脆弱性を修正するとかいうレベルの問題ではなく、仕組み自体を根本的に考え直す必要がありそうな気がします。