ワーミーリンゴ[JailBreakなし]

ルートキットテクノロジーや、新しいARTランタイム環境に合わせた新しいコンセプトを除いて、今日のAndroid向けのマルウェアストーリーに誰も驚かないでしょう。 iOSマルウェアでは、逆のことが言えます 。誰かがそれを聞いた場合、原則として、 ジェイルブレイクのコンテキストでのみです。 2014年には、このようなプログラム（AdThief、Unflod、Mekie、AppBuyer、Xsser）に一般的なブームがありました。 しかし、この記事では、脱獄せずにiOS用のマルウェアとその機能について説明します...

Appleデバイスに関する初期条件にすぐに同意しましょう。

• ボード上のIOSデバイス。
• IOS最新バージョン;
• ジェイルブレイクのないデバイス。

そのような厳しい初期条件は、特別に設定されています（そのため、人生は蜂蜜のようには見えません）。 デバイスに既にジェイルブレイクがあるか、攻撃者がパブリックソースから簡単にインストールできる場合、これは面白くなく、すぐにゲームオーバーになります。ユーザー自身は邪悪なピノキオです。 オペレーティングシステムのセキュリティモデルは完全に侵害されており、そのようなAppleデバイス向けの悪意のあるコードの記述は、Android、Windows、またはMac向けの悪意のあるコードの記述と一般に変わりません。

Appleデバイスで悪意のあるコードが大量に取得されない（ lにヒットしない）主な保護対策：

• AppStoreへの入場時の厳格なアプリケーション検証。
• 外部ソースからコードを動的にロードする機能の欠如。
• Appleによって署名されたコードのみがデバイスで実行できます。

しかし、すべてについて順番に話しましょう。 最初に、ジェイルブレイクされていないデバイスで実行できるコードの種類を把握します。
まず、AppStoreからアプリケーションをインストールできます。それらは配布証明書によって署名され、無制限の数のデバイスで実行できますが、徹底的なチェックの後はAppStoreを介してのみ配布できます。
次に、アプリケーションのベータ版をテストするためのTestFlightアプリケーション（AppStoreから）を使用します。 このバージョンのアプリケーションは、ベータ版の資格を持つ配布証明書で署名され、1000人のユーザーが利用でき（Apple IDによってバインドされるため、より多くのデバイスが存在します）、ベータ版のアプリレビューに合格します（時間がかかりませんので、AppStoreのように徹底的です）それは明確ではありません...）。
第三に、もちろん、実際のデバイス（アドホック配布）でテストするために、特定のデバイス（事前に決定された100個以下のデバイス-UUIDの知識が必要）に対してApple開発者によって発行された開発者証明書で署名されたコードをデバイスで実行できます。 HockeyApp、Ubertesters、Fabric（Crashlytics）のサービスは同じルールでプレイします。 同時に、ご理解のとおり、Appleのコードチェックが欠落しています;）
第4に、エンタープライズ証明書で署名されたアプリケーション。 このようなアプリケーションはどこからでも配布でき（社内配布）、無制限の数のデバイスで実行できます（ProvisionsAllDevices = true）。 また、Appleのコードチェックも欠落しています！

どこからでもアプリケーションを配布することはどういう意味ですか？ つまり、アプリケーションをWebポータル（内部またはインターネット）に配置でき、アクセスするときにデバイスに簡単にインストールできます。 ユーザーの写真では、アプリケーションのインストールは次のようになります。



このようなアプリケーションは、キーワードでインターネット上で見つけることができます。

itms-services://?action=downloadmanifest 

-あなたを助けるインターネットクローラー。

私が思うに、問題の本質は開発者または企業の証明書で署名されたアプリケーションの完全な信頼であるとすでに推測しました。 一般的に、Appleのセキュリティモデル全体は、証明書の信頼に基づいています...
攻撃者が何らかの方法でこれらの証明書を取得できることは明らかです。偽の会社や1日の会社を作成するか、証明書を盗むだけです。これはすでに技術的な問題であり、攻撃に備える必要があります。 Appleには（OSCPを使用して）エンタープライズおよび開発者の証明書を取り消す機能がありますが、このプロセスに対抗するいくつかのトリックがあります。 そして、開発者の証明書では、これは一般的にAppleにとって簡単な作業ではありません。

現在、攻撃者の前でどの攻撃ベクトルが開かれているか（認識-保護されていることを意味します）を見てみましょう。
1）悪意のある贈り物。 安全なメッセンジャーから写真編集者まで、「有用な」プログラムの事前定義されたセット（才能のある馬は見ていません）を備えたデバイスをユーザーに与えるだけです。 このため、原則として、AppStoreから既知のプログラムが取得され、解凍され、復号化され、追加機能が導入され、適切な証明書によって署名され、デバイスにインストールされます。 同時に、ご理解のとおり、アプリケーションは引き続き正常に機能し、元の機能を実行します。 この方法がどれほどばかげていて原始的であっても、このような装置がロシアの特定の人々に与えられた事例をすでに知っています。
2）感染したコンピューター経由。 デバイスは、信頼されている（ペアリングがインストールされている）感染したコンピューターに接続し、システム上の悪意のあるコードがモバイルデバイスに悪意のあるアプリケーションをインストールします（たとえば、 libimobiledeviceライブラリを使用）。
3）間違った手で数秒。 攻撃者/敵/ je深い女の子に電話を数秒間貸すだけでも、電話にマルウェアをインストールするのに十分です。 攻撃者は自分のアプリケーションを事前にインターネット上のどこかに配置し、電話を手に持っている間にパスワードを知らずにSafariを介してリンクをクリックしてインストールします。
4）ピノキオ自身。 たとえば、AppStoreでゲームを購入する手間を省くために、サードパーティのソースからアプリケーションをインストールできます。 私が知っている限りでは、例えば、中国（Tongbu）では、ゲームを購入し、ゲームを中断し、証明書で再署名して無料（または安価）で配布するのが好きです。
5）ハッキングされた開発者。 悪意のあるコードはプロジェクトに侵入し、同じHockeyApp、Ubertesters、Fabric（Crashlytics）を使用してデバイスに簡単に拡散する可能性があります（もちろん使用されている場合）。 さて、または攻撃者は単に開発者から必要な証明書を盗みます。
6）インサイダー。 この項目は、エンタープライズアプリケーションの内部開発および配布を行う企業自体にのみ関連します。 問題は、この状況の開発者がAppleが許可した機能だけでなく、後でさらに自由に使用できることです。
7）アプリケーションの脆弱性を介して。 最も美しく、最も複雑な攻撃ベクトルであると同時に、最小限の疑いがあります。 さらに、アプリケーションはAppStoreを介して配布することもできます。 同様の概念は、iOSのJekyllですでに説明されています：良性のアプリが悪になるとき 。
8）iOSの脆弱性が原因です。 これは、たとえば、研究者のチャーリーミラーによって以前に発見されており、彼がデバイス上の署名されていないコードを動的にロードして実行することを可能にしました。

iOSのセキュリティメカニズムに精通している読者は、アプリケーションがiOSデバイスにヒットした後、すべてのアプリケーションから限定された独自のサンドボックスで動作することに注意するかもしれません...
原則として、実際にはそうですが、攻撃者によってダウンロードされた悪意のあるファイルがAppleポリシーによってチェックされることはなく、実際にはAppStoreのどのアプリケーションよりも多くの機能を使用できることを考慮する価値があります。 そして、すべてプライベートAPIに感謝します！ Apple自体は、このような機能を備えたプログラムを見逃すことはありませんが、誰もそれを求めません。
そのため、セキュリティの観点から、AppStoreからインストールされなかったアプリケーションには、次の違いがあります。

• プライベートAPIを使用できます-追加機能。
• 周囲のサービス（マッハポートなど）と通信できます。
• デバイスでジェイルブレイクを行うための攻撃対象領域を増やします。

では、攻撃者にとってプライベートAPIはどのように役立つのでしょうか？ すぐに：

挑戦する	説明
[[CTMessageCenter sharedMessageCenter] incomingMessageWithId: result]	着信SMSメッセージのテキストを取得する
CTTelephonyCenterAddObserver()	着信SMSメッセージおよび呼び出しのハンドラーを登録する
MobileInstallationLookup()	インストールされたアプリケーションに関するplist情報を取得します
CFUserNotificationCreate()	すべての画面の上部にあるポップアップダイアログボックス
CFUserNotificationReceiveResponse()	ダイアログボックスからユーザー入力を取得する
allApplications()	インストールされたアプリケーションのバンドルIDのリストを取得します
SBSCopyLocalizedApplicationNameForDisplayIdentifier()	バンドルIDでプログラム名を取得する

サンドボックスからでも、アプリケーションがプライベートAPIのおかげで多くの悪いことを行えることはすぐにわかります。 そして、これは攻撃者にとって有用な方法の完全なリストではありません。 これらのうち、どれだけ不明なのか...同時に、プライベートAPIに特化したiOS開発者はまもなく（すでに需要があります）登場するか、すでにiOS開発者がいると思います。
iOSの通常の開発者に隠され、許可されていない量の一般的な理解については、 iOS-Runtime-Headersプロジェクトを参照してください。これは、ランタイムで生成されるiOSのヘッダーファイルです。 または、原則として、このようなヘッダーファイルを生成するために使用されますが、呼び出しをすぐに操作できるRuntimeBrowserプロジェクト。 プライベートフレームワークとパブリックフレームワークの両方にプライベートAPIがあることに注意してください。 また、専用のObjective-Cクラスとメソッドに加えて、RuntimeBrowserが見つけられない非常に興味深いC関数もあります。

非常に示唆的な写真：




攻撃者はこれを何らかの方法で使用できます 。 ただし、NSBundleおよびdlopen（）を介してコードを動的にロードするためのさまざまな手法を自由に適用することもできます。

上記のすべてが単なるアイデアと概念であると思う場合、私はあなたを怒らせることを急いでいます...これは戦闘環境ですでに起こりました-たとえば、特にMasque Attackと呼ばれるWirelurker マルウェア 。 Masque Attack（CVE-2014-4493およびCVE-2014-4494 ）の意味は、悪意のあるアプリケーションが元のアプリケーション（メッセンジャー、メール、銀行クライアントなど、プリインストールされたiOSアプリケーションを除く）の上に置かれ、彼のデータ。

セキュリティに関する推奨事項：

• サードパーティのソースからアプリケーションをインストールしないでください。
• OSを更新します。
• デバイスの制御プロファイル（設定->一般->プロファイル）;
• 証明書を安全に保ちます（開発者向け）。
• 社内配布用に作成するコードを制御します（顧客向け）。

PS iOS用のマルウェアサンプルに興味がある人は、このリソースcontagiominidump.blogspot.ru/search?q=iOSを使用することをお勧めします。

トピックに関する有用な資料：

• プライベートAPI
• 承認済みのサードパーティアプリケーションを使用したiOSでの一般的な攻撃の開始
• シェルのないApple-標的型攻撃下のiOS
• Enpublic Apps：iOS Enterpriseおよび開発者証明書を使用したセキュリティの脅威