M5: 安全でない通信 (Insecure Communication)

脅威エージェント

アプリケーション依存

最近のモバイルアプリケーションのほとんどは一つ以上のリモートサーバーとデータをやり取りします。データ伝送が行われる際、一般的にモバイルデバイスのキャリアネットワークとインターネットを経由しますが、平文や非推奨の暗号プロトコルを使用して送信した場合、回線上で盗聴する脅威エージェントがそのデータを傍受して変更する可能性があります。脅威エージェントは機密情報の窃取、諜報行為、なりすましなどのさまざまな動機を持っているかもしれません。以下のような脅威エージェントが存在します。

  • ローカルネットワーク (侵害された Wi-Fi や監視された Wi-Fi) を共有する敵対者

  • 不正な通信業者やネットワークデバイス (ルーター、携帯電話基地局、プロキシなど)

  • モバイルデバイス上のマルウェア

攻撃手法

悪用難易度 容易

最近のアプリケーションは SSL/TLS などの暗号プロトコルで応答しますが、その実装には以下のような欠陥が時折みられます。

  • 非推奨なプロトコルや不適切なコンフィグレーション設定の使用

  • 不適切な SSL 証明書 (自己署名、失効、期限切れ、正しくないホストなど) の受け入れ

  • 非一貫性 (認証などの特定のワークフローでのみの SSL/TLS の使用)

セキュリティ上の弱点

普及度 普通

検出難易度 普通

最近のモバイルアプリケーションはネットワークトラフィックの保護を目的としていますが、その実装には一貫性がないことがよくあります。このような非一貫性はデータやセッション ID を傍受にさらす脆弱性につながる可能性があります。アプリがトランスポートセキュリティプロトコルを使用しているからといって、それが正しく実装されているとは限りません。基本的な欠陥を特定するには、携帯電話のネットワークトラフィックを観察します。しかし、より微細な欠陥を検出するには、アプリケーションの設計と構成を詳しく調べる必要があります。

技術的影響

影響度 深刻

この欠陥によりユーザーデータがさらされ、アカウント乗っ取り、ユーザーなりすまし、個人情報データ漏洩などにつながる可能性があります。たとえば、攻撃者はユーザー認証情報、セッション、二要素認証トークンを傍受して、より手の込んだ攻撃の扉を開く可能性があります。

ビジネスへの影響

影響度 中

少なくとも、通信チャネルを介した機密データの傍受はプライバシーの侵害につながります。

ユーザーの機密性を侵害すると以下のような結果を招く可能性があります。

  • なりすまし

  • 詐欺

  • 風評被害

「安全でない通信」の脆弱性があるか？

このリスクはポイント A からポイント B へのデータ転送のあらゆる側面をカバーしますが、それを安全に行うことはありません。これにはモバイル間通信、アプリからサーバーへの通信、モバイルから他のものへの通信が含まれます。このリスクにはモバイルデバイスが使用する可能性のあるすべての通信テクノロジ (TCP/IP, Wi-Fi, Bluetooth/Bluetooth-LE, NFC, オーディオ, 赤外線, GSM, 3G, SMS など) が含まれます。

TLS 通信の問題はすべてここにあります。NFC, Bluetooth, Wi-Fi に関する問題はすべてここにあります。

顕著な特徴としては、ある種の機密データをパッケージ化してデバイスの内外に送信することが挙げられます。機密データの例としては、暗号鍵、パスワード、個人ユーザー情報、アカウント情報、セッショントークン、ドキュメント、メタデータ、バイナリなどがあります。機密データはサーバーからデバイスに送信されることや、アプリからサーバーに送信されることや、デバイスと他のローカルなもの (NFC 端末や NFC カードなど) の間で送信されることがあります。このリスクを定義付ける特徴は二つのデバイスが存在し、その間を何らかのデータがやり取りされることです。

データがデバイス自体のローカルに保存される場合、それは #Insecure Data です。セッション情報が安全に (強力な TLS 接続を介するなどで) 通信されているが、セッション識別子自体が不適切 (予測可能であったり、エントロピーが低いなど) である場合、それは #Insecure Authentication の問題であり、通信の問題ではありません。

安全でない通信の通常のリスクはデータ完全性、データ機密性、オリジン完全性に関するものです。転送中に (中間者攻撃を介するなどで) データが変更される可能性があり、その変更が検出できない場合、それがこのリスクの良い例です。通信の様子を観察 (すなわち盗聴) したり、会話の様子を記録し後から攻撃 (オフライン攻撃) することによって、機密データが開示、学習、導出される可能性がある場合、それも安全でない通信の問題です。TLS 接続の適切な設定とバリデートの失敗 (証明書チェック、弱い暗号、その他の TLS 構成の問題など) もすべてこの安全でない通信となります。

「安全でない通信」を防ぐには？

一般的なベストプラクティス

  • ネットワーク層は安全ではなく盗聴されやすいと想定します。

  • モバイルアプリがバックエンド API やウェブサービスにデータを転送するために使用する使用するトランスポートチャネルに SSL/TLS を適用します。

  • アプリケーションがブラウザや WebKit を介してルーチンを実行する際に、サードパーティ分析会社、ソーシャルネットワークなどの外部エンティティを考慮して、それらの SSL バージョンを使用します。ユーザーのセッション ID が公開される可能性があるため、混合 SSL セッションは避けます。

  • 強力な業界標準の暗号スイートを適切な鍵長で使用します。

  • 信頼できる CA プロバイダによって署名された証明書を使用します。

  • 不適切な証明書 (自己署名、期限切れ、信頼できないルート、失効、正しくないホストなど) を決して許可してはいけません。

  • 証明書ピン留めを検討します。

  • SSL チェーン検証を常に要求します。

  • キーチェーンの信頼できる証明書を使用してエンドポイントサーバーの身元を検証した後にのみ、安全な接続を確立します。

  • モバイルアプリが無効な証明書を検出した場合、UI を通じてユーザーに警告します。

  • 代替チャネル (SMS, MMS, 通知など) を介して機密データを送信してはいけません。

  • 可能であれば、機密データを SSL チャネルに渡す前に、そのデータに別の暗号層を適用します。将来、その SSL 実装に脆弱性が発見された場合、暗号化されたデータは機密性侵害に対する二次的な防御となります。

  • 開発サイクルの中では、SSL 検証メソッドを上書きして信頼できない証明書を許可することは避け、代わりに自己署名証明書やローカル開発認証局 (CA) を使用してみます。

  • セキュリティ評価の際には、アプリケーショントラフィックを分析して、トラフィックが平文チャネルを経由していないかどうかを確認することをお勧めします。

iOS 固有のベストプラクティス

iOS の最新バージョンのデフォルトクラスは SSL 暗号強度のネゴシエーションを適切に処理します。開発上のハードルに対応するために、開発者がこれらのデフォルトをバイパスするコードを一時的に追加した際に問題が発生します。上記の一般的なプラクティスに加えて、以下を行います。

  • 証明書が有効であり、フェイルクローズされていないことを確認します。

  • CFNetwork を使用する際には、信頼できるクライアント証明書を指定するために Secure Transport API を使用することを検討します。ほとんどすべての状況で、より高い標準暗号強度を得るには NSStreamSocketSecurityLevelTLSv1 を使用すべきです。

  • 開発後、すべての NSURL 呼び出し (または NSURL のラッパー) が NSURL クラスメソッド setAllowsAnyHTTPSCertificate などの自己署名証明書や無効な証明書を許可していないことを確認します。

  • 次を実行して証明書ピン留めを使用することを検討します。証明書をエクスポートし、アプリバンドルに含め、信頼オブジェクトにアンカーします。NSURL メソッド connection:willSendRequestForAuthenticationChallenge を使用すると証明書を受け入れます。

Android 固有のベストプラクティス

  • org.apache.http.conn.ssl.AllowAllHostnameVerifier や SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER などの、アプリケーションがすべての証明書を受け入れるコードを、開発サイクルの後にすべて削除します。これらはすべての証明書を信頼することと同じです。

  • SSLSocketFactory を継承したクラスを使用する際、checkServerTrusted メソッドが適切に実装され、サーバー証明書が正しくチェックされていることを確認します。

  • onReceivedSslError をオーバーライドして無効な SSL 証明書を許可することは避けます。

攻撃シナリオの例

モバイルアプリの通信セキュリティを検査する際、ペネトレーションテスト担当者がよく発見する一般的なシナリオがいくつかあります。

証明書検査の欠如

モバイルアプリとエンドポイントは正常に接続し、TLS ハンドシェイクを実行して安全なチャネルを確立します。しかし、モバイルアプリはサーバーから提供された証明書の検査に失敗し、モバイルアプリはサーバーから提供された証明書を無条件に受け入れます。これはモバイルアプリとエンドポイント間の相互認証機能を破壊します。モバイルアプリは TLS プロキシを介した中間者攻撃の影響を受けやすくなります。

弱いハンドシェイクネゴシエーション

モバイルアプリとエンドポイントは正常に接続し、接続ハンドシェイクの一環として暗号スイートをネゴシエートします。クライアントは弱い暗号スイートを使用してサーバーと正常にネゴシエートし、その結果、敵対者が簡単に復号できる弱い暗号につながります。これはモバイルアプリとエンドポイント間のチャネルの機密性を脅かします。

個人情報漏洩

モバイルアプリは個人を識別できる情報を SSL/TLS 経由ではなく安全でないチャネル経由でエンドポイントに転送します。これはモバイルアプリとエンドポイント間のプライバシー関連データの機密性を脅かします。

認証情報漏洩

モバイルアプリはユーザー認証情報を SSL/TLS 経由ではなく安全でないチャネル経由でエンドポイントに転送します。これにより敵対者がこれらの認証情報を平文で傍受できます。

二要素認証バイパス

モバイルアプリはセッション識別子を SSL/TLS 経由ではなく安全でないチャネル経由でエンドポイントから受け取ります。これにより敵対者は傍受したセッション識別子を使用して二要素認証をバイパスできます。

参考資料

PreviousM4: 不十分な入出力バリデーション (Insufficient Input/Output Validation)NextM6: 不適切なプライバシーコントロール (Inadequate Privacy Controls)

Last updated