まず、2つの短いポイント：
- まず、明らかにされた脆弱性のほとんどはOS Xに関連しています。iOSでは、すべてがずっと穏やかです。
- 第二に、すべてが実際には非常に悲しいです。
そして今、脆弱性についての詳細：
1. URLスキームを介して送信されるデータの傍受。
iOS（およびOS X）では、アプリケーションはURLスキームを介して相互に通信できます。 それはどのように見えますか：
例として、お気に入りのBlaBlaPostモバイルメールクライアントでアドレスを含むメールを受信した場合を考えてみましょう。 メーラーは十分に賢く、このアドレスをクリックすることで、ユーザーをたとえばBlaBlaKartaナビゲーションアプリケーションにリダイレクトします。 iOSでこのような移行を実装する唯一の方法は、最初のアプリケーションでフォームのリンクを呼び出すことです。
blablamaps：// 55.678 + 32.432
システムはそのようなURLへの呼び出しをキャッチし、インストールされているアプリケーションのどれがそれを処理できるかを確認します。 そのようなアプリケーションが見つかった場合、遷移が発生し、開くプログラムがデータ（この場合は座標）の処理方法を既に決定しています。
すべての楽しみは、1つではなく、2つのアプリケーションがこの種のURLで動作することを宣言したときに始まります。 著者は、次のオペレーティングシステムの動作ルールを決定しました。
- OSXは、このスキームで動作することを最初に発表したアプリケーションにユーザーを転送します。
- iOSはユーザーをアプリケーションに転送します。これは、このスキームで動作することを最後に宣言しました。
興味深い点は、Androidとは異なり、ユーザーはどのアプリケーションを開くかを選択できないことです。 追加の認証メカニズムはなく、何もありません。
したがって、この脆弱性は次のように悪用されます。
アプリケーションでBlaBlaHijackを作成し、そのプロパティでblablamaps URLスキームを処理し、ユーザーに提供する機能を示します。 BlaBlaMapsとは異なり、悪意のあるプログラムはマップを開かず、単にこれらの座標をサーバーに送信します。
同じスキームは、アプリケーション間で転送されるすべてのデータで機能します。たとえば、FacebookまたはTwitterを介した認証中に受け取ったトークンです。
このようなスキームの弱点は、通常、悪意のあるプログラムを攻撃されたユーザーに転送する方法にあります。 特に注目すべきこと-AppleはURLスキームの一般的なディレクトリを保持していないため、このようなアプリケーションは穏やかにモデレートされ、ダウンロード可能になります。
2. OS Xでのキーチェーン許可の変更
iOSとは異なり、OS Xのキーチェーンに格納されている各プロパティには、追加のアクセス権（アクセス制御リスト）を設定できます。これにより、アクセスが許可されているアプリケーションがリストされます。 BlaBlaSoftwareファミリの次の代表者に、このメカニズムに関連する脆弱性を示します。
ユーザーは、Mac App Store、 BlaBlaBook-流行に敏感なソーシャルネットワークから非常に人気のあるアプリケーションをダウンロードします。 他の適切なアプリケーションと同様に、認証データを入力すると、キーチェーンに保存しようとします。 そして、ここで別のメカニズムが有効になります-新しいレコードを作成する前に、システムはキーチェーンにそのようなパラメーターを持つレコードが既にあるかどうかをチェックします。 これは、プログラムを更新するときにユーザーデータが飛び出さないようにするためです。 そのようなエントリが見つかった場合、その内容は上書きされ、見つからない場合は新しいエントリが作成されます。 2番目のケースでBlaBlaBookアプリケーションがACLを定義している場合、 最初のケースではACLは変更されません。
それでは、脆弱性に戻りましょう。 BlaBlaBookをインストールする前日、ユーザーはすでにBlaBlaHijackerに言及されている別のアプリケーションをダウンロードしました 。 このマルウェアは、必要な元のアプリケーションと同じパラメーターでキーチェーンにエントリを追加した最初の人物であり、ACLにすべての権限を追加しました。 したがって、ユーザーがパスワードを保存しようとすると、2つのアプリケーションがアクセスできます-BlaBlaBookとBlaBlaHijackerの両方。
興味深いことに、悪意のあるアプリケーションを最初にインストールする必要はありません-サードパーティのアプリケーションは、キーチェーンの特定のエントリを削除し、独自のエントリで上書きすることができます。
3.サンドボックスへのアクセス
OS Xのすべてのアプリケーションが独自のサンドボックス内で動作し、他のプログラムにアクセスできないことはよく知られています。 これらのサンドボックスは、ファイルシステム内でフォルダーによって表されます。フォルダーの名前は、アプリケーションの一意の識別子です。 Mac App Storeは、公開されているすべてのプログラムをチェックするときに、このIDの一意性をチェックするため、繰り返しはないようです。
困難さにより、元のアプリケーションに追加のルーチン（ヘルパー、フレームワーク、および独自のバンドルIDを持つその他のもの）を含めることができます。 これらの各ルーチンは、独自のサンドボックスで機能します。 脆弱性は、Appleがこれらのヘルパーの識別子の一意性をチェックしないことです。その結果、2つの異なるアプリケーションが同じサンドボックスで動作し、互いのデータへのフルアクセスを取得できます。
この脆弱性は、一般的なパスワードマネージャー1Passwordとその拡張機能1Password Miniの場合に最もよく実証されます 。
4. WebSocketを介した通信の脆弱性
要するに、WebSocketはサーバーがクライアントと通信できるプロトコルです。 HTML5標準の一部として統合されており、ブラウザのWebViewコンテンツは、特定のTCPポートを介してデータを転送することにより、システム内の他のアプリケーションにアクセスできます。 そして、もちろん、この場合認証はありません-誰でもこのポートを聞くことができます。 ブラウザの拡張機能は、具体的に通信する相手とは一切検証できません。
脆弱性を悪用する例は、前のケースのように1Passwordです。 ブラウザ拡張機能は、ユーザーがさまざまな形式で入力したパスワードとクレジットカード番号を収集し、ポート6263を介してアプリケーションに送信しました。 それ以降のアクションは簡単です。同じポートをリッスンし、受信したすべてのデータを記録し、適切なベースを収集するプログラムを作成します。 繰り返しますが、これらすべてはApp Storeのテストに静かに合格します。
Appleは、昨年の秋以来、言及されたすべての脆弱性を認識しており、レポートの情報によると、これらの脆弱性を修正するには少なくとも6か月かかります。
もう一度申し上げますが、iOSは考慮されている脆弱性の最初の脆弱性のみに関するものです。
便利なリンク：
- 元のレポート （真剣に読む必要があります）
- 1Passwordフォーラムに関する議論