Macのアプリをアップデートすると中間者攻撃を受ける可能性がある

安全でない「http」ウェブ接続を避けるべきだという声が、ますます高まっています。数日前、ある研究者がOS X YosemiteおよびEl Capitanのアップデートフレームワーク「Sparkle」に潜む脆弱性を公開しました。Sparkleは暗号化されていないウェブ接続経由でのアプリのアップデートを可能にするため、中間者攻撃によって悪意のあるアップデートが送信される可能性が非常に高いのです。しかし、この攻撃が成功するのは、OS Xに3つの別々の問題、すなわち、フォーマットされたテキストを表示するWebKitビューでJavaScriptを実行すること、デスクトップにFTPサーバーをマウントすること、そしてGatekeeperがダウンロードファイルの特定のパスと種類をチェックしないことが原因です。（この研究者の1月下旬の投稿については、Ars Technicaが最初に報じました。）

Sparkleプロジェクトのコーディネーターは、OS Xでは依然としてベクターが存在します。ただし、Sparkleが経路を提供しなければ、ベクターを利用することははるかに困難です。Sparkle接続にhttpを使用しているアプリ開発者は、ソフトウェアをアップデートし、https対応の新バージョンを直ちにリリースし、最終的には（そしてできるだけ早く）、最新のSparkleリリースを組み込む必要があります。

この無料のオープンソース コード モジュールは、当初は 2006 年に 1 人の開発者によって作成されました (現在はチームに引き継がれています)。アプリ ストアのような手軽さでソフトウェアをアプリ内でアップデートできるようにする方法として、Sparkle が開発しました。アップデートを確認したり、アップデートに関するメーリング リストに登録したり、Web サイトから新しいリリースをダウンロードしてインストーラーを実行したりする代わりに、Sparkle ではこれらすべてをプログラム内で自動化しました。アプリ側で設定を提供して、定期的にアップデートを自動的に確認するように設定することもできます (手動で [アップデートを確認] オプションを選択することもできます)。Sparkle フレームワークは、アプリ開発者のサイトでホストされている XML ベースのアップデート フィードを確認し、リリース番号が現在のバージョンよりも大きい場合は、リリース ノートでユーザーに通知し、ダウンロード、アプリの終了、アップデートのインストール、再起動をワンクリックで実行できるようにします。

研究者のラドスワフ・カルポヴィッチ氏（通称ラデック）は、2つの脆弱性を発見しました。1つ目は、開発者がSparkleをhttpsではなくhttpで使用している場合、中間者（MitM）攻撃を許してしまうことです。この攻撃により、悪意のある第三者はhttpsとは異なり、検知されることなくリクエストをリダイレクトできます。これは、公衆Wi-Fiネットワーク、適切な内部統制が欠如している企業ネットワーク、そして悪意のある第三者がアクセスしたり、政府による要求や管理下にある上位レベルのインターネットハブで発生する可能性があります。暗号化されていない接続におけるMitM攻撃には、トラフィックを検査して置換できる場所さえあれば十分です。

Karpowicz氏は、攻撃者がSparkleのチェックに対する応答として、別のXMLアップデートファイルを提供する可能性があると指摘しています。この偽装されたレスポンスは、偽情報を表示してマルウェアのインストールを誘導するだけでなく、OS XのWebKitに存在する2つ目の脆弱性を悪用する可能性もあります。SparkleはWebKitを利用して、アプリのポップアップウィンドウにフォーマットされたアップデート情報を表示しています。XMLファイルのアップデートペイロードには、WebKitウィンドウで直接実行されるJavaScriptが含まれる可能性があり、ブラウザが開き、ゼロデイマルウェア（まだパッチが適用されていないエクスプロイト）を含むウェブページを開く可能性のあるコードが実行されます。

しかし、より悪質な攻撃は、JavaScriptをFTP（ファイル転送プロトコル）サーバーに接続させることです。Mac OS XはFTPサーバーをデスクトップにボリュームとしてマウントします。JavaScriptはターミナルスクリプトを実行し、コマンドライン関数を実行することができます（MacでFirefoxを起動したことがある場合、この方法は無効になっているようです）。

これは、ユーザーが存在せず、何もクリックしなくても発生する可能性があります。必要なのは、SparkleとHTTPを使用するOS Xアプリのフィードが乗っ取られ、次回の自動アップデートチェック時にフィードデータがダウンロードされ、アップデートメッセージが表示されるようにすることです。これがJavaScript実行を引き起こします。ダウンロードされたファイルは、開発者署名がチェックされるダウンロード済みアプリのテスト基準を満たしていないため、Gatekeeperは起動しません。Karpowicz氏は、OS Xをクラッシュさせたり、その他の問題を引き起こしたりする可能性のある、他にもいくつかの悪意のあるアクティビティについて報告しています。

Ars Technicaは、この脆弱性を悪用する自動化された手法が既にいくつか登場していると指摘しています。これは非常に深刻なエクスプロイトであり、Sparkle以外にも影響を及ぼす可能性がありますが、少なくとも開発者によって容易かつ迅速にパッチが当てられています。また、攻撃者が脆弱なままとなっている特定のアプリまたはアプリバージョンを標的にし、大規模に攻撃を行うには、特権ネットワークへのアクセス権限が必要です。これは、物理的に近接したローカルWi-Fiネットワーク上に設置する必要がある、わずかなアクセスポイントではなく、より広範囲に及ぶアクセス権限を持つ必要があります。

開発者が直接配布するアプリの多くはSparkleを使用しており、どのアプリがhttpsにアップデートされておらず、最新のSparkleコードが適用されていないかを簡単に確認することはできません。そのため、すべてのソフトウェアで自動アップデートを無効にし、信頼できる自宅や職場のネットワークでのみ手動でアップデートを確認することをお勧めします。また、Sequel ProやVLCなどの影響を受けた2つのアプリ（現在は最新版）のように、ウェブサイトに直接アクセスしてパッチ適用済みのコードを含むアップデートを探すこともできます。

Apple は、Karpowicz 氏らが発見した広範な脆弱性の悪用を防ぐために OS X にいくつかの小さな変更を加える必要があるが、これらの Sparkle 修正によって、最も可能性の高い悪用の手段が遮断された。

この状況は、Google のような大規模で普及している企業から個人のセキュリティ研究者に至るまで、長年にわたり警告されてきた、私が数週間前や最近など、何度か書いてきたことを再強調するものです。つまり、http は簡単にハイジャックされ、本来であればブロックまたは最小限に抑えられるような他の攻撃を許してしまう可能性があるため、いかなる目的にも使用すべきではないということです。