MacOS XとiOSのXARA脆弱性について

今日（６月１８日）午後、GigaZineで「iOSとOS XでiCloud・メール・ブラウザ保存のパスワードが盗まれる脆弱性が発覚、Appleは半年以上も黙殺」¹というセンセーショナルな記事が出ました。まぁ、Webメディアだからしょうがないかという感じではありますが、記事を読んだだけでは何のことやらさっぱりなので、読みましたよ、元の論文。

その論文は、これです。

• Xing, Bai, Li, Wang, Chen, Liao: “Unauthorized Cross-App Resource Access on MAC OS X and iOS” ²

まずは、著者たちに拍手をしましょう。

その上で：

著者たちが、初めて発見したと主張するゼロデイ攻撃は以下の４つ、細かくは５つに分類されます。

1. Password Stealing (Keychainのアクセス・コントロール脆弱性)[MacOS X]
2. Container Cracking (Apple App Storeの、BundleID確認の手違い) [MacOS X]
3. IPC Interception (3.a WebSocket non-authentication, and 3.b local OAuth redirect) [MacOS X]
4. Scheme Hijacking [MacOS X, iOS]

このうち、少なくとも3.b と4は実は私たちは少なくとも2013年11月から知っていたもので、現在規格策定の最終段階に入っているOAuth PKCE³が解決しようとしている問題そのものです。また、「対処方法は無い」と書かれていますが、正確に言うと、エンドユーザとしてすぐに出来る対処方法は無い、ですね。開発者として自分のアプリが脆弱性を持たないようにする方法はあります。これも以下で紹介します。

1. Password Stealing (Keychainのアクセス・コントロール脆弱性)

４つの脆弱性の中で、私が一番おもしろかった（不謹慎か…）のがこれです。Keychainのアクセス制御モデルの２つのバグの組合せから生じる脆弱性です。

MacOS Xのキーチェーンは、図１のような形を取っています。

それぞれのキーチェンのアイテムは、複数の属性(Attributes)とクレデンシャルおよびアクセス制御リスト(ACL)を持っています。ACLには、このアイテムにアクセスを許す複数のアプリケーションとそれぞれのアプリケーションに許される操作（読み出し、書き込み、等）を入れておくことができます。そして、このアイテムにアクセスできるのは、ここに指定されているアプリケーションのみになります。逆に言うと、ここに指定されているアプリケーションは、このアイテムの情報を読み出したり書き込んだりすることができます。

このACLを指定できるのは、最初にこのアイテムを作ったアプリです。

攻撃のシナリオは次のようです。

1. 正規のアプリがキーチェンのアイテムを作る前に、悪意のあるアプリがこのアイテムを作り、ACLに正規のアプリも登録しておく。
2. ユーザが正規のアプリをインストールして、使い出すことにより、正規のアプリがクレデンシャルをそのアイテムに書き込む。
3. 書き込まれた値を攻撃アプリで読み出す。

これだけだと、正規のアプリが、正規のキーチェンアイテムを作る前にまず攻撃アプリが仕込まれなければならなず、攻撃が成功する確率は低く思えるかもしれません。たとえば、iCloudだと、OSインストール直後に作られてしまうので、iCloudのクレデンシャルを盗むのは不可能に思えます。しかし、状況を一変させるもう一つのバグがあったのです。それは、

「当該アイテムを消すだけならどのアプリからでも消せる。」

というバグです。そのため、次のような攻撃パターンを取ることによって、キーチェーンに書き込まれる任意のものを盗み出すことができるようになります。

1. 攻撃アプリで正規のアプリのキーチェーン・アイテムを削除する。
2. 同アプリで、キーチェーン・アイテムを作り、ACLに正規のアプリも登録しておく。
3. ユーザが正規のアプリを使って、クレデンシャルを書き込む。
4. 書き込まれた値を攻撃アプリで読み出す。

【対処方法】

これを回避するには、正規アプリがキーチェーンに何か書き込む前に、ACLを読みだして、不正なアプリが紛れ込んでいないかをチェックしなければなりません。逆に言えば、そうすることで回避できます。

なお、iOSにはこの脆弱性はありません。そもそも、ACLというものが無く、自分が作ったキーチェーン・アイテムにしかアクセスできないからです。

2. Container Cracking (Apple App Storeの、BundleID確認の手違い) [MacOS X]

MacOS XのApp Storeのアプリは、ユニークなBundle IDというものを持ち、そのネームスペースを持ったサンドボックス内に閉じ込められています。そのエリアは、同じBundleIDを持ったアプリでないと読み出せません。AppleのApp Storeは、このBundleIDに重複がないかをチェックして、重複がある場合はStoreへの登録を許さないようにしています…。いや、しているはずだった、でしょうか。

実際、アプリケーションのBundleIDはチェックしているのですが、そのアプリがサブ・アプリケーションを持っている場合、そのBundleIDのことはチェックしていなかったのです。そのため、サブアプリケーションは、任意のBundleIDを持つことができました。したがって、攻撃対象のアプリのBundleIDを付けたサブ・アプリケーションを作ってインストールさせることに成功すれば、対象アプリの秘密の情報まで読み出せることになります。

【対処方法】

対処策は、App Storeでちゃんとチェックする、ですかね。まずは。他にも色々やりようがありますが、ちょっと時間がかかりそうですな。

3. a WebSocket non-authentication

プロセス間通信に使える手段にはいろいろあります。たとえばUnix Socketなどがそうですが、ここで問題になっているのは、ローカルのWebSocket通信です。WebSocketはネットワーク越しで使われることが多い規格で、その場合は、先方のTLS証明書を確認してから接続するなどします。しかし、ローカルのサーバのポートを指定された場合、このTLSのチェックが効きません。その結果、当該ポートでスパイアプリを立ち上げておけば、ユーザが入力したパスワードなどを盗み出すことができます。

1passwordにはこの脆弱性があるとのことです。1passwordはポート6263でブラウザにインストールしたブラウザ拡張からの通信を待ち受けており、1passwordブラウザ拡張は、ユーザがWebブラウザに入力したパスワードなどの値を、このポート6263に送っているのですね。そのため、1passwordより前に攻撃アプリが立ち上がってポート6263を抑えておけば、これらの秘密情報を抜くことができます。

【対処方法】

1passwordによると、対処策はムズカシイということですが、何でですかね。私だったら、インストール時に1passwordアプリにキーペアを生成させて、公開鍵をブラウザ拡張に持たせて、ブラウザ拡張からポート6263への通信を全てその公開鍵で暗号化してしまうんですけどね。そうすれば、たとえ攻撃アプリがその情報を取得しても、復号できませんから攻撃は失敗します。

3. b Local OAuth Redirect

これは、WebSocketの代わりに、ローカルで走るWebサーバにリダイレクトするというものです。例として挙げられているのがPushbulletというアプリで、このアプリはGoogle SIngle Sign Onでユーザを認証して、ポート20807にリダイレクトに入ってくるアクセス・トークンを使います。

攻撃は、Pushbulletよりも前に攻撃アプリがポート20807を押さえるところから始まります。そうすることによって、帰ってきたアクセス・トークンを横取りします。横取りした後、ポート20807を開放して、正規アプリがトークンを取れるようにします。

【対処方法】

この攻撃に対する解決策は、Implicit flowを使うのをやめてCode Flow とOAuth PKCEを使うことです。

4. Scheme Hijacking [MacOS X, iOS]

1. http://gigazine.net/news/20150618-ios-os-x-password-killer/
2. https://sites.google.com/site/xaraflaws/
3. Sakimura, N., Bradley, J, and N. Agaawal:”Proof Key for Code Exchange by OAuth Public Clients”, RFC7636, IETF, (2015)