
今日のAndroidモバイルオペレーティングシステム用の新しいマルウェアに関するニュースと研究は、誰も驚かないでしょう。 しかし、Googleはプラットフォームのセキュリティを改善するために特定の措置を講じています(ところで、採用されているOSセキュリティモデルとOSバージョンの大きな断片化により、これは非常に困難です)。 そして、これにより、ウイルス作成者は子孫を広めるために新しい措置を講じるようになります。
この記事では、Android OS用の既存および現在使用されているマルウェア配布ベクトルについて検討します。 興味があれば、猫をお願いします。
エントリー
最初、Android向けの悪意のあるプログラムは、利用可能な機能を単純に悪用しました。一意のデバイス識別子、地理位置座標、最優先のSMSメッセージなどを受信し、それをすべて作成者に送信しました。
しかし、今日の最新のイノベーションはRATシステム全体(リモート管理ツール)であり、それらの一部はすでにブートキットテクノロジーを隠すために使用されています 。 これらのプログラムは、Androidセキュリティモデルのフレームワーク内には存在しなくなり、さまざまな脆弱性を介してシステム内の特権を引き上げます。 その後、デバイス上の他のアプリケーションのデータとシステムファイルの両方を自由に読み取ったり、変更したりできます。これは、PCの対応するものと同じです。 進化はまったく同じルートをたどると言うことができます。
自然なステップは、アプリケーション配布ストアでのアンチウイルスソフトウェアの出現です。 このステップのロジックは明確です-ユーザーがマルウェアをダウンロードするのを防ぎます。 そのため、2012年にGoogle Anti-Virus BouncerがGoogle Playに登場しましたが、たとえばYandex.Storeには独自のがあります。 Android OSの別の問題は、単に盗まれたアプリケーションと埋め込まれた悪意のある機能の両方を配布できるさまざまなアプリケーションストアが豊富にあることです。 誰もがアプリケーションの事前調整に独自のアプローチを採用しており、悪意のある機能のために自動スキャンツールを使用するストアは2つだけです。 ただし、ご存じのとおり、必要に応じて費用がかかります。
モバイルアンチウイルスについて
モバイルウイルス対策は、Androidセキュリティモデルの一部としてデバイスでも動作することを理解する必要があります-それらは個々の特権を受け取りません。 サンドボックスで動作し、他のアプリケーションとシステムで実行できるのは、システムによって提供され、最初の起動時に許可されたものだけです。 このような状況では、マルウェアに対抗することは困難ですが、ウイルス対策は伝染病の予防に役立ちます。
アプリを確認する
「 アプリの確認 」という新しい機能がAndroid 4.2に登場しました。 主に、Google Playからインストールされていないアプリケーションに役立ちます。 そのため、このオプションをオンにすると、システムがインストール前であっても、アプリケーションに悪意のある機能がある場合に警告が表示されます(おそらく、Googleが購入したVirusTotalサービスを隠しています)。

ポータル
それでは、マルウェアの配布ベクトルに移りましょう。 私はこれが現在の出来事の絵に対する私の個人的な見解であるとすぐに言わなければなりません。 ここに追加するものがある場合は、コメントを記入してください。

1)ストアから。
セキュリティの観点から、各Androidストアは次の2つの基準に従って検討できます。
•ストア内にビルトインアンチウイルスが存在する。
oただし、ウイルス対策を万能薬として服用しないでください。
•デバイスの「信頼できる」ソースですか?
oファームウェアでストアが信頼できるものとして提供されている場合、ファームウェアの他のストアは「信頼できない」ソースになり、設定に特別なチェックマークをインストールする必要があります。 原則として、誰もがデバイス上の唯一のアプリストアになりたいと考えています。
1.1)ウイルス作成者がマルウェアをストアに投稿し、ユーザーがインストールしました。
最も一般的なシナリオ。 攻撃者は、悪意のある機能を使用してアプリケーションをアップロードするか、他の誰かにそれを埋め込み、アップロードします。もちろん、難読化、時間遅延などを使用して以前に自分の悪い機能を隠していました。 ゲームオーバー
1.2)ウイルス作成者はアプリケーションをアップロードし、その後、悪意のあるコードをダウンロードします。
悪意のない優れたアプリケーションをストアに入れて視聴者を獲得し、いつかアップデートをロールアップして、ユーザーをボットの群れに変えることさえできます。 ゲームオーバー
この方向で、私は研究者ダニエル・ディブリチェーンの最後の発見が本当に好きでした。 彼は、アプリケーションが3つの権限しか持たないことを発見しました。
•android.permission.INTERNET-アプリケーションがネットワークソケットを開くことを許可します。
•android.permission.GET_ACCOUNTS-アカウントサービスのアカウントのリストにアクセスできます。
•android.permission.USE_CREDENTIALS-アプリケーションがAccountManagerから認証トークンを要求できるようにします-
アカウントに関連付けられているすべてのデバイスに、ユーザーの知らないうちに、許可なしで(すべて直接アクセスできます)アプリケーションをインストールできます。 ゲームオーバー
1.3)ウイルス作成者は、すでに数百万台のデバイスにコストがかかる優れたアプリケーションを購入/ハッキングし、アップデートで悪意のある機能を追加しました。
これは狂人の幻想ではなく、悲しい現実です。 時間が経つにつれて、このベクターはより一般的になると思います。 これに関連して、開発者アカウントのハッキング/盗難の数が増加します。 ゲームオーバー
2)未知のソースから。
Android OSの不明なソースからアプリケーションをインストールするには、ユーザーは設定メニューに1つのチェックを入れるだけです。

2.1)ユーザー自身がどこかからアプリケーションをインストールしました。
ユーザーがこれを行うのはなぜですか? 1000と1つの理由があるかもしれません、そして、それらをすべて考慮するのは愚かです。 攻撃者自身は、多くの場合ソーシャルエンジニアリングの助けを借りて、リモートバンキングでの安全な作業やカフェなどでのインターネットへの無料アクセスのためにアプリケーションを配置することを余儀なくされています。 ゲームオーバー
2.2)デバイスにモバイルマルウェアを配置するウイルスに感染したコンピューター。
このベクトルも実在し、非常に独創的です。 確かに、これにはいくつかの条件があります。信頼できないソースからインストールする許可と、ADBを介してデバッグする許可です。 しかし同時に、すべてが被害者に対して透過的に発生します。 ゲームオーバー
3)脆弱性を介して。
どんなに驚くかもしれませんが、Androidは実行可能なコードを外部からアプリケーションに取り込み、そこで実行する可能性を残しています
iOS(ジェイルブレイクなし)でApple署名のコードのみを実行できる場合(アドホックアプリケーションは別の話です)、Androidでは、サーバーからコードを取得し、アプリケーションのコンテキストで実行できますが、既定のコード署名はありません。
そして、これはよく使われます:
•さまざまな広告ネットワーク。
•アプリケーションを更新するとき(たとえば、ゲームに新しいレベルを追加するとき)。
•アプリケーションのテスト中。
3.1)コードの読み込み。
このシナリオを実装するには、攻撃者はRCEの脆弱性とMiTM攻撃を実行する能力が必要です。
MiTMですべてが明確で十分なものである場合(オープンフォームでのデータ転送またはSSLでの誤った動作)、AndroidのRCEに専念しましょう。 これは、たとえば次の方法で実現できます。
•JavaScriptインターフェイス:
o私たちはすでにこのことについてここで詳細に話しました 。
•クラスローダー:
o攻撃者のコードはDexClassLoader()に入ります。
•パッケージコンテキスト:
o脆弱なアプリケーションは、別のアプリケーション(攻撃者が所有)からコードをダウンロードして実行する可能性があります。 このシナリオでは、MiTMは不要です。主なことは、アプリケーションが既に被害者のデバイス上にある必要があることです。これにより、権限なしで脆弱なコンテキストに移行できます。
たとえば、 PayPalのこの種の脆弱性(この記事の執筆時点)。
問題の本質と範囲をより深く理解するために、「 これを実行してください!Androidアプリケーションでの安全でない悪意のある動的コードの読み込みの分析 」の調査を参照することをお勧めします。 ゲームオーバー
3.2)別のアプリケーションの脆弱性を介して。
AndroidにはIPC用の非常に広範なメカニズムセットがあり、非常に興味深い脆弱性につながる可能性があることを忘れないでください。 Android OS自体には脆弱性があり、たとえば、サイバー犯罪者が怪物の動物園をひそかに広めるために使用する可能性があります。
4)バックドア。
悲しいことですが、本当です。デバイスを購入すると、そのような「プレゼント」がすでにあるかもしれません。 彼がどのように(意図的/偶然)そこにたどり着いたか、誰によって、何のために組み込みアプリケーション、またはOS、またはファームウェアのレベルで使用されるかは別の話です。
サムスンの最新の印象的な例。 ゲームオーバー
ご清聴ありがとうございました!
PS:モバイルマルウェアを研究したい人のために、これらのアーカイブに注意することをお勧めします: 1、2 。