Zenn
📱

モバイルアプリに対する脅威にはどのようなものがあるか

2024/01/25に公開
Android
iOS
Security
#
スマートフォン
#
モバイルアプリ
tech

はじめに

2007年に初代のiPhone、その翌年の2008年に世界初のAndroid搭載スマートフォンが発売されてからモバイルデバイスは爆発的にその台数を増やし、いまでは持っていて当たり前と言えるほどのツールとして普及しました。モバイルデバイスはその携帯性の良さから日常の様々なシチューションで利用されますが、それに伴って多くの脅威にもさらされています。しかし、その脅威についての理解はさほど広まっていないように感じます。

私はこれまでモバイルアプリの脆弱性診断を数年経験してきましたが、検出した脆弱性の報告を受けても脅威やリスクの分析を行わず、"とりあえず指摘されたから改修する"というスタンスのクライアントも多くいらっしゃいます。それ自体を否定するつもりはありませんが、あるべき姿としてはやはり、どのような脅威が存在し、どのような条件が揃った際に脆弱性を悪用されリスクが生じるのかを理解したうえで脆弱性の改修要否を判断する、といったフローを経るのが理想的であると思います。

そこで本記事では理解を深めるための一助となるよう、主に以下の方を読者として想定し、モバイルアプリ(Android・iOSアプリ)が直面する脅威にはどのようなものがあるのか、そしてその脅威によって実際に被害が生じるにはどのような条件が揃っている必要があるのか、ついて記載してみたいと思います。

▼想定する対象読者

  • モバイルアプリの脆弱性診断を依頼する側の方
  • モバイルアプリの開発に従事する方
  • その他、モバイルアプリのセキュリティについて興味のある方

セキュリティに明るくない方でもスムーズに一読できるよう、極力かみ砕いた表現となるよう努めていますが、わかりづらい、もしくは誤った内容の文章等がありましたら、コメント等でお知らせ頂けますと幸いです。

前置き

本記事では、モバイルアプリに対する脅威についてのみ記載しています。
Webアプリケーション(サーバサイド)等に対する脅威(HTTPリクエストの操作等)については、本記事のスコープ外ですのであらかじめご了承ください。

モバイルアプリに対する脅威の種類

前述したように、モバイルアプリはその性質上、様々な脅威にさらされます。本記事では、モバイルアプリが直面しうる一般的な脅威を以下のように分類し、次項から1つずつ説明していきます。なお、これらの脅威はAndroid・iOSどちらのアプリにも共通して存在します。

  1. ネットワーク上の第三者による脅威
  2. ユーザがインストールした不正アプリによる脅威
  3. アプリの脆弱性を悪用する攻撃ファイルによる脅威
  4. ユーザの近くにいる第三者による脅威
  5. デバイスを拾得した第三者による脅威
  6. ディープリンクを悪用した脅威
  7. 悪意あるユーザによる脅威

上記のうち1～6に分類した脅威によって行われる攻撃は、被害者となるユーザによる何らかの操作がトリガーとして関与する必要がある攻撃です。一般的にこのような攻撃を"受動的攻撃"と呼びます。攻撃を成功させるためには、被害者の関与が必要となる(被害者のモバイルデバイスに不正なアプリをインストールさせる、被害者がモバイルデバイスを紛失する等)ため、それに応じて攻撃側の手間も増え、難度も高まると言えるでしょう。一方、7に分類した脅威による攻撃は、攻撃側単独の操作で成立する攻撃であり、こちらは"能動的攻撃"と呼ばれるものです。攻撃に必要なのは、モバイルデバイスと攻撃対象のアプリだけですので、リバースエンジニアリングに関する簡単な知識と意欲さえあれば、障壁無く行える攻撃と言えます。

1.ネットワーク上の第三者による脅威

これは、モバイルデバイスが利用するネットワーク上にいる第三者によって、通信を盗聴・改ざんされることを想定した脅威です。モバイルデバイスは持ち運ぶことを前提としたツールであり、自宅や勤務先のように利用者が限られるネットワークだけでなく、移動中の電車や街中のカフェ、宿泊先のホテル等が提供するような、不特定多数の利用者に公開されたネットワークに接続する機会も多くあります。もちろん全てのネットワークが危険であるというわけではありませんが、特に後者のように公共の場で提供されている無料のWi-Fiスポットは悪意のある第三者が盗聴・改ざんのための状況を仕掛けやすく、以下のような危険性があることは広く知られているのではないでしょうか。

  • 接続時のパスワード(事前共有鍵, パスフレーズ)がない、あるいはパスワードがあっても公開されているWi-Fiスポットでは、第三者が容易に通信を盗聴することができる。
    (参照：日経クロステックActive「パスワードが公開された公衆無線LAN、暗号化されていても盗聴できる？」)
  • 正規のWi-Fiスポットと同じSSID・パスワードを設定した偽のアクセスポイント(EvilTwin)を第三者が設置することで、本来は正規のWi-Fiスポットに接続するつもりだった利用者を偽アクセスポイントに接続させる。これにより中間者攻撃が可能な状況が成立し、通信を盗聴することができる。


悪意のある第三者による通信の盗聴イメージ

ただし、これですべての通信内容を悪意のある第三者が読み取れるかというと、そうでもありません。通信を盗聴することはできても、その通信がHTTPS等により適切に暗号化されていれば、その内容を読み取ることはできないからです。そのため、悪意のある第三者がモバイルアプリからの通信を読み取るには、上記のように通信を盗聴可能な状況をつくったうえで、ターゲットとなるモバイルアプリに以下のような脆弱性が埋め込まれている必要があります。

  1. モバイルアプリがHTTP等の平文通信を利用して機密情報を送受信している
  2. HTTPS等の暗号化通信を行っていても、サーバ証明書の検証エラーを無視して通信を行うようアプリ側で実装されている
  3. HTTPS等の暗号化通信を行っていても、脆弱な暗号プロトコルを利用して通信を行えるようアプリ側で実装されている

上記1のように平文通信で機密情報を送受信している場合、悪意のある第三者がその通信をキャッチしさえすれば、その内容は丸見えとなります。また、上記2,3のようにアプリ側で不適切な実装がされている場合は、HTTPS等の暗号化通信を行っているつもりでも、中間者攻撃が可能な状況下であれば、悪意のある第三者がその通信内容を読み取ることができます。

モバイルアプリの脆弱性診断をする側の人間としての肌感覚ではありますが、最近は上記1のように機密情報を平文で送受信しているアプリはかなり減った印象があります。これは、暗号通信の重要性に対する理解が普及したことに加え、近年のAndroid・iOSアプリにおいてHTTPS通信がデフォルトとなり、例外的にHTTPで通信を行うためにはアプリ内に明示的にそれを許可する設定をしなければならなくなっていることが功を奏しているのかもしれません。

その一方で、上記2のようにHTTPSで通信しているけれどサーバ証明書の検証エラーを無視するよう実装されたアプリは時折見かけます。おそらく、開発時に自己署名証明書(いわゆる"オレオレ証明書")を利用するサーバと接続するためにあえてサーバ証明書の検証エラーを無視するよう実装したものが、脆弱性診断時にも有効なままとなっているものと思われます。本番環境へのリリース時や脆弱性診断を受ける際には、これらの実装を無効化し、サーバ証明書の検証が適切に行われていることをご確認ください。

※上記3は、アプリが脆弱性のあるバージョンのOpenSSLライブラリ等を利用して通信を行う場合に発生しうる問題ですが、私はまだ実際にそのようなアプリにお目にかかったことがありません。
(参照：ITmedia エンタープライズ「AndroidとiOSアプリ、まだ多数に「FREAK」の脆弱性が存在」)

なお、本記事では脅威が存在する典型例として無料Wi-Fiスポットを取り上げましたが、その他のWi-Fiでも、パスワードなしでアクセスできたり、周知のパスワードでアクセスできるよう運用している場合は同様の脅威が存在することを忘れないでください。会社内だけで利用するWi-Fi等のように特定の利用者だけがアクセスすることを想定したWi-Fiの場合、不特定多数の利用者に公開されているわけではないので外部の人間による盗聴は難度が上がるかもしれませんが、それでも悪意のある内部犯であれば盗聴可能な状況を仕掛けることが可能です。外部に公開していないモバイルアプリだからといって油断していると想定外の被害を被る可能性もあるので、分け隔てなく脆弱性に対処することを推奨します。

ちなみに、本記事はモバイルアプリに対する脅威について記載していますが、モバイルアプリに限らず、一般的に無料Wi-Fiスポットを利用した際に盗聴される可能性のある経路にはどういったものがあるのかについて以下の記事で詳しく解説されています。たいへん分かりやすい記事ですので、ご興味のある方は一読されるとよいかと思います。
参照：Qiita「フリーWi-Fiを使ったら秘密情報を抜かれる経路にはどのようなものがあるか」

2.ユーザがインストールした不正アプリによる脅威

これは、ユーザが利用するモバイルデバイス内にユーザ自身が誤って不正なアプリをインストールしてしまい、そこから攻撃を受けることを想定した脅威です。映画やドラマ等のメディアの影響からか、不正なアプリはモバイルデバイスのユーザが気付かないうちに勝手にインストールされるものと勘違いしている人もいるかもしれませんが、実際には、モバイルデバイス内に不正なアプリをインストールするには、ユーザ自身の手でインストールする必要があります。(モバイルデバイスを第三者に窃取・拾得され不正なアプリをインストールされるケースも考えられますが、本記事では、それは後述の「デバイスを拾得した第三者による脅威」の方に含めています。)


ユーザがインストールした不正アプリによる攻撃イメージ

"ユーザ自身が不正なアプリをインストールする"といっても、それはタップひとつで簡単に済むものではなく、Android/iOSデバイスでそれぞれ以下のように操作が必要になります。なお、不正なアプリを含む、提供元不明なサードパーティアプリをインストールするには様々な手法がありますが、本記事ではモバイルデバイスのユーザが誤って不正なアプリをインストールしてしまうケースを想定し、デバイス単体でインストールする手法のみ一例として記載します。

  • Androidデバイスの場合
    Androidデバイスでサードパーティアプリをインストールするには、事前に設定画面からインストールを許可するよう設定する必要があります。そのうえで、サードパーティアプリをデバイス内にダウンロードし、インストールを実行する際には画面上に許可を求めるアラートが表示されるので、それをユーザが許可することでインストールが完了します。
    なお、設定個所やアラートの表示有無に関しては、デバイスの種類やAndroidのバージョンによって異なります。(参照：Android Deelopers「さまざまな配信方法－提供元不明のアプリのインストールを許可する」)

  • iOSデバイスの場合
    iOSデバイスの場合、まず、サードパーティアプリを配布するストアアプリ(Cydia, Sileo等)を利用する方法が考えられます。ただし、この方法でサードパーティアプリをインストールするには、デバイスがJailBreak(脱獄)されている必要があります。JailBreakはセキュリティ上のリスクの伴う専門的な操作が必要となるため、一般のユーザにとってはかなり敷居が高いといえるでしょう。
    他の方法としては、AdHoc形式でサードパーティアプリの配布を受ける方法もあります。この方法の場合、デバイスがJailBreakされている必要はありませんが、サードパーティアプリを配布する第三者が配布先のデバイスのUUIDを知っている必要があります。悪意のある第三者は、被害者のデバイスのUUIDを登録した不正なサードパーティアプリを作成し、被害者を何らかの手段(メールやフィッシングサイト等)で誘導し、被害者のデバイスにインストールさせなければなりません。(参照：エンタープライズiOS研究所「AdHocとは何か」)

上記のことから、"ユーザ自身が不正なアプリをインストールする"には、ある程度のハードルが存在するといえるでしょう。そのため、この脅威に直面する可能性のあるユーザはかなり限定的である、と言えなくもない気がします。しかし、だからといって、それらのユーザを見捨てて悪用される可能性のある脆弱性を放置しておいてよいかというと、そういうわけにもいかないところです。どこまで対策するかはアプリの提供側の判断によりますが、ユーザがどのような環境におかれ、どのような操作を行ったとしても、可能な限りデータを保護できるよう対策しておくのが理想的です。

この脅威に悪用されるタイプの脆弱性としては、以下のようなものが挙げられます。

  • 対象アプリに向けて不正なアプリから命令が送信され、それにより対象アプリ側で想定していない動作を引き起こされる。
  • 対象アプリが送信したデータや本来受信するはずだったデータを不正なアプリに横取りされる。
  • 対象アプリが他のアプリから読取可能な領域に保存したデータを不正なアプリに参照される。
  • 対象アプリが利用するために受信したSMSの内容を不正なアプリに参照される。

なお、これもメディアの影響かと思いますが、不正なアプリがデバイスにインストールされると、デバイスが提供する機能や保管するデータに好き放題アクセスされてしまうと勘違いしている方も多いのではないでしょうか。実際は、他の正規アプリと同様、サードパーティアプリもOSが管理するサンドボックス内で動作することになるため、与えられる権限は限定的です。そのため、サンドボックス内で許可される動作やユーザの許可した範囲内の動作を超えて、好き勝手できるわけではありません。

3.アプリの脆弱性を悪用する攻撃ファイルによる脅威

これは、ユーザ自身の操作によってモバイルデバイス内に不正なファイルをダウンロードしてしまい、それをアプリが実行・処理する際に何らかの攻撃を受けることを想定した脅威です。主に音楽や写真、動画、文書などのファイルを参照・編集する機能を有するアプリにおいて、以下のような脆弱性が存在した場合、不正なファイルを処理させることでアプリの提供側が意図しない処理を実行させられてしまう恐れがあります。


ユーザがダウンロードした不正ファイルによる攻撃イメージ

これらの脆弱性を見つけ出すには、モバイルアプリに対する高度なリバースエンジニアリングが必要となります。一般的に、iOSアプリに比べてAndroidアプリのほうがリバースエンジニアリングが容易であるため、このタイプの脆弱性はAndroidアプリにおいて見つかるケースが多いように感じますが、原理的にはiOSアプリでも同様の脆弱性が存在する可能性はあります。

さて、不正なファイルをアプリで読み込んでしまうケースにはどのようなものがあるでしょうか。私のほうでパッと思いつくものとしては、以下のようなケースがあります。

  1. ユーザ自身がインターネット上から不正なファイルを誤ってダウンロードし、脆弱性のあるアプリでそのファイルを処理してしまう。
  2. モバイルデバイスで受信したメールに添付された不正なファイルを、脆弱性のあるアプリで処理してしまう。
  3. 悪意のある第三者が送信した不正なファイルを、脆弱性のあるアプリ上の特定の機能(ユーザ間でファイルをやりとりするチャット機能やタイムライン機能等)で自動的に処理してしまう。

上記1,2のケースは"インターネット上にある怪しいファイルや不審なメールで送られてきたファイルは処理しない"というセキュリティ上の原則を守るユーザであれば、偶発的に被害に遭うようなケースは避けられそうに思いますが、悪意のある第三者がユーザをうまいこと誘導し、正体を偽装したファイルであれば避けるのは難しいかもしれません。また、上記3のケースはSNSのように顔の見えないユーザとのやりとりが発生するようなアプリでは、ユーザ自身の努力で避けるのは困難と考えられます。

アプリの提供側としては、まずファイルを参照・編集するような機能がないかを把握しておき、ある場合は、ファイル処理における実装上の不備がないか、利用するライブラリに脆弱性が見つかっていないかを点検しておくとよいでしょう。このタイプの脆弱性も、実際に被害が生じるにはユーザ自身の操作が必要になるため、悪用成功にはある程度のハードルがあると言えますが、ユーザがどのような操作を行ったとしても可能な限りデータを保護できるよう対策しておくのが理想的です。

4.ユーザの近くにいる第三者による脅威

これは、モバイルデバイスを持ち歩くユーザの物理的に近くにいる第三者から、何らかの不正行為を受けることを想定した脅威です。モバイルデバイスはその携帯性の良さから様々な場所に持ち歩きますが、その分、多くの人間とすれ違い人の目に触れる機会も増えることになります。特定の人物を標的としてマークする攻撃者だけでなく、すれ違う人間のなかから攻撃可能な標的を探し、なかばいたずら半分のつもりで攻撃に及ぶ悪意ある第三者からも迷惑行為を受ける可能性があります。


ユーザの近くにいる第三者による攻撃イメージ

このタイプの脅威によって行われる攻撃の代表例としては、ショルダーハッキングが最もイメージしやすいところでしょう。攻撃者はユーザーが入力中のパスワードなどの機密情報を肩越しに覗き見ることで、重要な情報を窃取することができます。非常にアナログな攻撃手法ではありますが、これも立派な(?)ハッキングの一種で、誰でも簡単にできてしまいます。電車のなかなどで意図せず、他人のモバイルデバイス画面内に表示された機密情報を目にしてしまった経験のある人も多いのではないでしょうか。とはいえ、機密情報なら何でもかんでもマスクしたり非表示にしたりしてしまえば、アプリの利便性やユーザビリティの低下を招きます。どこまでを許容するかはアプリ提供側の判断になりますが、一般的には、パスワードやクレジットカードのセキュリティコードをマスクする程度で良しとすることが多いようです。

また、その他にもBluetooth等の近距離無線通信機能の悪用を試みる脅威も存在します。これまで、Bluetooth通信の仕組み自体にも多くの脆弱性が見つかってきました(BlueBorneやKNOB攻撃など)が、それらの脆弱性に対するセキュリティパッチを適用したデバイスであっても、Bluetooth通信機能を持つアプリの実装に不備がある場合に以下のような脆弱性が作りこまれ、被害に遭う恐れがあります。

  • アプリから送信されるBluetooth通信のデータを第三者に盗聴され、情報を窃取される。
  • 正規の通信先になりすました第三者のデバイスにBluetooth通信で機密情報を送信してしまい、情報を窃取される。

(参照：Flatt Security Blog「Bluetooth通信実装のセキュリティ観点を4ステップ + 1で理解する」)

5.デバイスを拾得した第三者による脅威

これは、ユーザが利用するモバイルデバイスを第三者に窃取・拾得されてしまった際に、対象アプリを不正操作されたり、対象アプリ内の機密データにアクセスされてしまうことを想定した脅威です。モバイルデバイスは携帯性に優れるが故に、PC等の大型デバイスに比べて盗難・紛失のリスクも高まります。ある意味、モバイルアプリだからこそ考慮しなければならない脅威と言えるでしょう。


デバイスを拾得した第三者による攻撃イメージ

デバイスを盗難・紛失しても、モバイルデバイスの画面ロックを設定しているから大丈夫、と考えている方は多いかと思います。確かに、悪意のある第三者にとって画面ロックの解除は大きな障壁となります。特に、デバイスの正規所有者に関する情報が何もない場合は、第三者がロックを解除するのは相当困難になるでしょう。ですが、絶対に安全と言い切ることもできません。誕生日などの分かりやすい数字や、よく使われているフレーズを画面ロックのPINやパスワードとして利用している場合、身近な人物であればロック解除にそう時間はかからないかもしれません。また、画面ロックに生体認証を使っている場合は他人によるロック解除は困難と思われがちですが、悪意のある第三者が被害者にとって極めて近い間柄にある場合(家族・恋人など)、かえって解除しやすいかもしれません。このように、ロック解除の可否・要する時間は状況によるため、一概に何がどの程度安全と決めつけるのは難しいところがあります。(画面ロックを有効化していないのは論外ですが…) そのため、アプリの提供側としては、画面ロックが解除されたとしてもユーザのデータを保護できるよう対策措置を講じておくに越したことはありません。
(参照：東洋経済ONLINE「スマホの画面ロックが即突破されてしまうワケ」)

さて、モバイルデバイスを入手した悪意ある第三者は、主に以下のような手法によってアプリが扱うデータへのアクセスを試みると考えられます。

  1. デバイスの画面ロックを解除し、画面上でアプリを操作することでデータにアクセスする。
  2. デバイス内のデータのバックアップを悪意ある第三者のPC等へ取得し、そのバックアップデータ内のデータにアクセスする。
  3. デバイスの管理者権限を取得(root化・JailBreak)し、デバイス内のデータに直接アクセスする。

1つ目の手法は、容易に想像がつくシンプルな手法です。デバイスの画面ロックを解除したうえで、アプリを起動し、画面上から操作しながら正規ユーザの機密情報にアクセスします。しかし、起動時に再認証を要求するよう実装されたアプリの場合、第三者はさらに再認証にも成功する必要があります。

再認証を解除できない、あるいは、画面上からではなく、アプリのストレージ内に保存されているデータをごっそり取得したい、という場合には、2つ目の手法を試すことになりますが、この手法はデバイスの設定によってその成否が異なります。ここでは、Android/iOSそれぞれのデバイスで一般的にどのような設定が必要になるのかを順に記載しますが、いずれの場合もデバイスの画面ロック解除が必要になってきます。

まず、Androidデバイスの場合、バックアップを取得するためには「USBデバッグ」機能が有効化されていなければなりません。これは、Androidの設定アプリで"開発者向けオプション"を利用することで有効化できる機能ですが、アプリの開発などに興味のあるエンジニアでもない限り、自身のデバイスで「USBデバッグ」を有効にしているケースは稀だと考えられます。「USBデバッグ」機能が有効になっていない場合、悪意ある第三者は自力でこの設定を有効化する必要がありますが、それをするためには、やはりデバイスの画面ロックを解除しなければなりません。
iOSデバイスの場合は、PCのiTunes等のソフトウェアを利用してバックアップを取得することになりますが、そのためには、悪意ある第三者が利用するPC等とiOSデバイスを接続したうえで、iOSデバイス上でPCとの接続を許可する必要があり、その際、iOSデバイスの画面ロックを解除しなければなりません。

なお、この手法でバックアップに成功したとしても、対象アプリの一部のデータはそこに含まれません。アプリに関わるすべてのデータを根こそぎ取得したいという場合は、3つ目の手法を行う必要があります。ここまでの手法は、どのようなデバイスでも画面ロックを突破しさえすればデータを入手できるようになりましたが、3つ目の手法では、画面ロック解除に加えて、入手したデバイスの機種やOSバージョンもその成否に影響してきます。

まず、Androidデバイスにおけるroot化の成否は機種に大きく依存します。Androidはさまざまな機種で動作しますが、root化が可能なのは一部の機種(主にGoogle製の機種)に限られます。
一方、iOSデバイスにおけるJailBreakの成否は端末のOSに大きく依存します。本記事の執筆時点(2024年1月時点)では、iOS16以降のOSに対するJailBreakの方法はまだ見つかっていないようです。

少し長くなりましたが、ここまで、デバイス内のデータへのアクセス手法として3つの手法を記載しました。デバイスを入手された以上、何をされても仕方がない、と白旗をあげてしまうアプリ提供者もいるかもしれませんが、モバイルデバイスにとって盗難・紛失は身近なリスクと言えます。デバイスを第三者に窃取・拾得されてしまった場合でも、可能な限りユーザのデータを保護できるよう実装しておくと良いでしょう。1つ目の手法に対する対策としては、アプリ起動時のサーバ側での再認証処理の実装、2つ目、3つ目の手法に対する対策としては、不要な重要情報はアプリのストレージ内に保存しない、もし保存の必要がある場合は、第三者からは復号できない方法で暗号化したうえで保存する、といった対策が有効であると考えられます。

6.ディープリンクを悪用した脅威

これは、ユーザがモバイルデバイス上でブラウザアプリ等のアプリを操作している際に、悪意をもって仕掛けられたリンクをタップしてしまい、それによって起動した対象アプリ内で何らかの不正な挙動が引き起こされることを想定した脅威です。モバイルアプリには他のアプリとの連携を行うための手法として、ディープリンクという仕組みが用意されています。この記事では、ディープリンクの詳細については割愛しますが、端的に言うと、ユーザーをアプリ内の特定のコンテンツに直接誘導することができるURLです。通常のリンクはタップするとブラウザアプリが起動し、特定のページが表示されますが、ディープリンクをタップした際は、特定のアプリの特定のコンテンツを表示することができます。


ディープリンクを悪用した攻撃イメージ

ディープリンクにはいくつかの種類があるため、ここではその一種であるカスタムURLスキームを例に説明すると、これは、あらかじめアプリ独自のスキーム(例."hoge://")をアプリ内に定義しておくことで、そのスキームを含むURLのリンク(例.hoge://host?param=value)を別のアプリ上でタップした際に、スキームを定義したアプリを起動し、そこに含まれるデータ(例.param=value)を送り込むことができるという仕組みです。言葉にすると難しく感じますが、モバイルデバイスのユーザは日常的にこの挙動を目にしているのではないでしょうか。例えば、ブラウザアプリ(ChromeやSafari等)上でX(旧Twitter)のリンクをタップすると、Xアプリが起動し、特定の投稿が表示される、といった具合です。

複数のアプリを利用するモバイルデバイスにおいて、ユーザがわざわざ手動でアプリを起動しなくても、自動的に対象のアプリを起動し、特定のコンテンツに遷移してくれるこの仕組みはとても便利なものです。しかし、ディープリンクには任意の文字列を含めることが可能であるため、悪意のある第三者が以下のような流れで対象のアプリに対して不正な文字列を送り込み、アプリ側で意図されていない処理を実行されるおそれがあります。

  1. 悪意のある第三者は、対象のアプリにおいてディープリンクを処理する実装個所を解析し、不正な挙動を引き起こすために送り込む文字列を把握する。
  2. 悪意のある第三者は、手順1で把握した文字列を含むディープリンクを、罠サイト等に設置する。
  3. 被害者となるユーザが、対象のアプリがインストールされているモバイルデバイス上で、罠サイト等に設置されたディープリンクをタップしてしまう。
  4. 対象アプリが起動し、ディープリンク内に含まれる文字列によって不正な処理が実行され、ユーザが何らかの被害を受ける。

このタイプの脅威によってユーザに生じる被害の例としては以下のようなものあります。

上記の攻撃が成功するためには、被害者となるユーザが不正なリンクをタップしてしまうことが前提となります。そのため、攻撃が成功するか否かはユーザ次第である、という面があります。ただ、不正なディープリンクを登録できるのは、怪しいサイトだけではありません。ユーザが任意の文字列を投稿できるタイプのサイト(口コミサイト等)にもディープリンクを設置できる場合があります。また、ディープリンクに含まれる文字列から対象アプリ内でどのような挙動が引き起こされるかは判別が困難であるため、ユーザにタップしないことを求めるのは無理があると思います。

このような悪用行為を防ぐため、外部から受け取ったディープリンクURLを無条件に信用するのではなく、想定していない文字列が含まれていた場合は無視する、あるいはエラーとするようアプリ側で検証を行う必要があります。

7.悪意あるユーザによる脅威

これは、正規の利用者が自身のモバイルデバイスを利用して対象アプリを操作し、何らかの不正操作を働くことを想定した脅威です。モバイルデバイスにインストールされたアプリは、実行ファイルとして圧縮された形式でデバイス内に配置されますが、そのファイルをデバイスから抜き出し、手元で解析することも容易です。悪意あるユーザは、アプリがサーバとの間で行う通信を解析しながらリクエスト・レスポンスの内容を操作したり、アプリの実行ファイルのリバースエンジニアリングを行うことで、本来は利用できないコンテンツの利用や、本来与えられた権限を超えた処理等を試みる恐れがあります。


悪意あるユーザによる攻撃イメージ

このタイプの脅威によって生じる被害例としては以下のようなものあります。

上記のような悪用行為からモバイルアプリを守るために、アプリのソースコードを難読化したり、モバイルデバイスがroot化・JailBreakされている状態ではアプリが動作しないように検知機能を実装するといったケースが年々増えています。これらのセキュリティ機能は、攻撃者のリバースエンジニアリングによる解析行為を妨げることにつながるため、一定の効果があると考えられます。セキュリティ機能を組み合わせて用いることで、攻撃側の気力を削ぐという効果もあるでしょう。

しかし、これらのセキュリティ機能はアプリの解析を困難にするだけであって、悪用にいたる原因を根本的に解消しているわけではない、という点は認識しておかなければなりません。
OWASP MASTG の以下の一文が示す通り、攻撃側に十分な時間とリソースさえあれば、それらのセキュリティ機能はいずれ解除され、アプリも解析されてしまうと考えておくべきです。

None of these measures can assure a 100% effectiveness, as the reverse engineer will always have full access to the device and will therefore always win (given enough time and resources)!

(参照：OWASP Mobile Application Security「Android Anti-Reversing Defenses」)

アプリ側に上記のセキュリティ機能を実装するだけでなく、そもそもの問題の根本となる脆弱性を解消しなければ悪用の種を摘んだことにはなりません。サーバ側でもユーザ操作の整合性を検証し、不正を検知できる体制を整えておくとよいでしょう。

まとめ

ここまで、モバイルアプリに対する脅威を種類ごとに説明してみましたが、いかがでしたでしょうか。Webアプリケーション(サーバサイド)に対する脅威とは異なる、モバイルアプリ特有の脅威がいくつかあるということを見て取れたかと思います。

本記事は、私の知る限りの情報を、可能な限り誤解を生まないよう慎重に記載しましたが、もしかしたら情報の抜け漏れや誤った理解が含まれているかもしれません。恐れ入りますが、そのような記載がありましたら、コメント等でお知らせ頂けますと幸いです。

最後に、長文となりましたが、本記事をお読みいただきありがとうございました。
本記事は、各脅威の表面部分をさらっと記載するのみでしたが、今後は記事中に出てきた技術や脆弱性等に関する情報を、より深堀りして解説するような記事を残していきたいと思います。

Discussion