モバイルセキュリティ-攻撃ベクトル

定義上、 Attack Vector は、ハッカーが別のコンピューティングデバイスまたはネットワークにアクセスして、よく呼ばれる「不正なコード」を挿入するために使用する方法または手法です。 payload。このベクトルは、ハッカーがシステムの脆弱性を悪用するのに役立ちます。これらの攻撃ベクトルの多くは、このシステムの最も弱い点である人間の要素を利用しています。以下は、ハッカーが同時に使用する可能性のある攻撃ベクトルプロセスの概略図です。

モバイル攻撃ベクトルのいくつかは次のとおりです。

  • マルウェア

    • ウイルスとルートキット

    • アプリケーションの変更

    • OSの変更

  • データの漏えい

    • データが組織を離れる

    • 印刷画面

    • USBにコピーして損失をバックアップ

  • データの改ざん

    • 別のアプリケーションによる変更

    • 検出されない改ざんの試み

    • ジェイルブレイクされたデバイス

  • データロス

    • デバイスの損失

    • 不正なデバイスアクセス

    • アプリケーションの脆弱性

攻撃ベクトルの結果

攻撃ベクトルは説明されているようにハッキングプロセスであり、成功しています。以下はモバイルデバイスへの影響です。

  • Losing your data −モバイルデバイスがハッキングされた場合、またはウイルスが導入された場合、保存されているすべてのデータが失われ、攻撃者によって取得されます。

  • Bad use of your mobile resources−これは、ネットワークまたはモバイルデバイスが過負荷になり、本物のサービスにアクセスできなくなる可能性があることを意味します。最悪のシナリオでは、ハッカーが別のマシンまたはネットワークを接続するために使用します。

  • Reputation loss− Facebookアカウントまたはビジネス用メールアカウントがハッキングされた場合、ハッカーは友人、ビジネスパートナー、その他の連絡先に偽のメッセージを送信する可能性があります。これはあなたの評判を損なう可能性があります。

  • Identity theft −写真、名前、住所、クレジットカードなどの個人情報の盗難が発生する可能性があり、同じことが犯罪に使用される可能性があります。

モバイル攻撃の構造

以下は、モバイル攻撃の構造の概略図です。それは攻撃ベクトルを含む感染段階から始まります。

デバイスへの感染

デバイスへのモバイルスパイウェアの感染は、AndroidデバイスとiOSデバイスで異なる方法で実行されます。

Android−ユーザーは、一般的にソーシャルエンジニアリング攻撃を使用して、市場またはサードパーティのアプリケーションからアプリをダウンロードするようにだまされます。リモート感染は、Man-in-the-Middle(MitM)攻撃を介して実行することもできます。この攻撃では、アクティブな攻撃者がユーザーのモバイル通信を傍受してマルウェアを注入します。

iOS− iOS感染には、モバイルへの物理的なアクセスが必要です。デバイスへの感染は、JailbreakMEエクスプロイトなどのゼロデイ攻撃によるものでもあります。

バックドアのインストール

バックドアをインストールするには、Androidデバイスをroot化し、Appleデバイスを脱獄することによる管理者権限が必要です。デバイスメーカーがルート化/ジェイルブレイク検出メカニズムを配置しているにもかかわらず、モバイルスパイウェアはそれらを簡単にバイパスします-

Android −発根検出メカニズムは、意図的な発根には適用されません。

iOS −脱獄する「コミュニティ」は声高でやる気があります。

暗号化メカニズムをバイパスし、情報を盗み出す

スパイウェアは、暗号化された電子メールやメッセージなどのモバイルコンテンツをプレーンテキストで攻撃者のサーバーに送信します。スパイウェアは安全なコンテナを直接攻撃しません。ユーザーがデータを読み取るためにセキュアコンテナからデータをプルアップした時点でデータを取得します。その段階で、ユーザーが使用できるようにコンテンツが復号化されると、スパイウェアがコンテンツを制御して送信します。

ハッカーは、侵害に成功したモバイルからどのように利益を得ることができますか?

ほとんどの場合、私たちのほとんどは、携帯電話がハッキングされた場合に何を失う可能性があるかを考えています。答えは簡単です-私たちはプライバシーを失います。私たちのデバイスは、ハッカーが私たちを監視するための監視システムになります。ハッカーにとって利益となるその他の活動は、機密データの取得、支払い、次のような違法行為の実行です。DDoS attacks。以下は概略図です。

OWASPモバイルのトップ10リスク

モバイルセキュリティについて話すとき、脆弱性の種類は、4月21日に設立された米国の非営利慈善団体であるOWASPに基づいています。OWASPは国際的な組織であり、OWASPFoundationは世界中のOWASPの取り組みをサポートしています。

モバイルデバイスの場合、OWASPには 10 vulnerability classifications

M1-不適切なプラットフォームの使用

このカテゴリは、プラットフォーム機能の誤用またはプラットフォームセキュリティコントロールの使用の失敗を対象としています。これには、Androidインテント、プラットフォームのアクセス許可、TouchIDの誤用、キーチェーン、またはモバイルオペレーティングシステムの一部であるその他のセキュリティ制御が含まれる場合があります。モバイルアプリがこのリスクを経験する方法はいくつかあります。

M2-安全でないデータ

この新しいカテゴリは、モバイルトップテン2014のM2とM4の組み合わせです。これは、安全でないデータストレージと意図しないデータ漏洩を対象としています。

M3-安全でない通信

これには、不十分なハンドシェイク、誤ったSSLバージョン、弱いネゴシエーション、機密資産のクリアテキスト通信などが含まれます。

M4-安全でない認証

このカテゴリは、エンドユーザーの認証または不適切なセッション管理の概念をキャプチャします。これには以下が含まれます-

  • 必要なときにユーザーをまったく識別できない
  • 必要なときにユーザーのIDを維持できない
  • セッション管理の弱点

M5-不十分な暗号化

このコードは、機密情報資産に暗号化を適用します。ただし、暗号化は何らかの形で不十分です。TLSまたはSSLに関連するすべてのものがM3に含まれることに注意してください。また、アプリが暗号化を使用する必要があるときにまったく使用できない場合、それはおそらくM2に属します。このカテゴリは、暗号化が試行されたが、正しく実行されなかった問題用です。

M6-安全でない認証

これは、承認の失敗(クライアント側での承認の決定、強制ブラウジングなど)をキャプチャするためのカテゴリです。認証の問題(デバイスの登録、ユーザーIDなど)とは異なります。

アプリが必要な状況でユーザーをまったく認証しない場合(たとえば、認証および承認されたアクセスが必要な場合に、リソースまたはサービスへの匿名アクセスを許可する)、それは認証の失敗であり、承認の失敗ではありません。

M7-クライアントコードの品質

これは、あまり使用されていないカテゴリの1つである「信頼できない入力によるセキュリティの決定」でした。これは、モバイルクライアントでのコードレベルの実装の問題のキャッチオールになります。これは、サーバー側のコーディングミスとは異なります。これにより、バッファオーバーフロー、フォーマット文字列の脆弱性、その他のさまざまなコードレベルの間違いなどがキャプチャされ、モバイルデバイスで実行されているコードを書き直すことが解決策になります。

M8-コードの改ざん

このカテゴリには、バイナリパッチ、ローカルリソースの変更、メソッドのフック、メソッドのスウィズリング、および動的メモリの変更が含まれます。

アプリケーションがモバイルデバイスに配信されると、コードとデータリソースはそこに常駐します。攻撃者は、コードを直接変更するか、メモリの内容を動的に変更するか、アプリケーションが使用するシステムAPIを変更または置換するか、アプリケーションのデータとリソースを変更する可能性があります。これにより、攻撃者は、個人的または金銭的な利益のためにソフトウェアの使用目的を破壊する直接的な方法を提供できます。

M9-リバースエンジニアリング

このカテゴリには、ソースコード、ライブラリ、アルゴリズム、およびその他の資産を決定するための最終的なコアバイナリの分析が含まれます。IDA Pro、Hopper、otool、およびその他のバイナリ検査ツールなどのソフトウェアは、攻撃者にアプリケーションの内部動作に関する洞察を提供します。これは、アプリケーション内の他の初期の脆弱性を悪用したり、バックエンドサーバー、暗号定数と暗号、および知的財産に関する情報を明らかにしたりするために使用される可能性があります。

M10-外部機能

多くの場合、開発者は、実稼働環境にリリースされることを意図していない、隠されたバックドア機能またはその他の内部開発セキュリティ制御を含めます。たとえば、開発者が誤ってハイブリッドアプリのコメントとしてパスワードを含めてしまう可能性があります。別の例には、テスト中に2要素認証を無効にすることが含まれます。