Brew Hijack: Homebrewのコアタップを通じたマルウェア配信

ほとんどの場合、ソフトウェアをインストールするときは深く考えません。ファイルはHTTPSでダウンロードされます。チェックサムが検証されます。すべてが安全です。少なくとも、それが前提です。

そのおかげで助かります。すべてのダウンロードが傍受されたり、すべてのバイナリが警告なく置き換えられたりすることができれば、インターネットは地雷原になるでしょう。

しかし、両方の保護がなかったらどうでしょう？ダウンロードがプレーンHTTPで配信され、インストーラーが事後検証さえされていなかったら？さあ。2026年ですよ！広く使われているパッケージマネージャーではまだそんなことは起こり得ません。でしょう？

ただし、それはHomebrewのコアキャスクシステム内で起こる可能性があります。Homebrewの公式タップに、平凡な中間者攻撃に対して脆弱な20のキャスクが見つかりました。エクスプロイトは必要なく、昇格されたアクセス許可も必要ありません。これらのパッケージは暗号化されていないHTTPでダウンロードされ、完全性検証がないため、ネットワークパス上の誰でもペイロードをマルウェアに置き換えることができます。

これらは単なる無名パッケージではありません。コアタップにあります。毎日数百万人の開発者にChrome、Spotify、その他数千のアプリを配信する同じ信頼できるソースです。

私たちはこれについて理論化しただけではありません。インストールを傍受し、悪意のある.dmgを交換し、Homebrewがそれを警告なく/Applicationsに直接落とすのを見ました。

これらの調査結果を公開する前に、Homebrewのメンテナーとの責任ある開示プロセスに従いました。この開示に基づいて、Homebrewチームは影響を受けたキャスクをレビューし、可能な場合はHTTPSを使用するようにそれらを更新するか、安全な転送が可能でない場合はそれらを完全に無効にしました。

背景: Homebrewキャスクの仕組み

この脆弱性の影響を完全に理解するには、まずHomebrewのキャスクシステムがどのように機能するかを理解する必要があります。

ほとんどの人は、HomebrewをmacOS上の開発者ツールをインストールするための定番のコマンドラインパッケージマネージャーと考えています（`brew install python`、`brew install git`など）。これは**コア**です。Homebrewの公式レシピは、パッケージは通常ソースからビルドされるか、バイナリとして配布されます。

しかし、実際のmacOSアプリケーション`.dmg`、`.pkg`、およびアプリバンドルをインストールしたい場合、Homebrewの**キャスク**側に切り替えます（`brew install –cask`）。このシステムはダウンロードとインストール、アイコンを/Applicationsにドラッグしたり、インストーラーをクリックするなどの面倒なものを、すべて自動的に処理します。

これらすべてを誰が保守しているのですか？

ここが興味深いところです。Homebrewは巨大ですが、根本的に**コミュニティ主導**です。

メインタップはhomebrew/homebrew-caskで、GitHubで保守されています。誰でもプルリクエストを作成して新しいキャスクを送信したり、既存のキャスクを更新したりできます。貢献者が変更を提案し、メンテナーがそれをレビューし、承認されると、その更新は世界中のすべてのHomebrewユーザーに対してライブになります。

その上、ユーザーはサードパーティタップを追加できます。独自のキャスクまたはレシピセットを持つ外部GitHubリポジトリです。これらのサードパーティタップは公式タップと同じレベルのオーバーサイトを受けません。これは注意しない場合、さらに危険な遊び場になります。悪意のあるまたは不十分に保守されたサードパーティタップが通り抜ければ、攻撃サーフェスの新しいセット全体があります。

しかし、公式の`homebrew/homebrew-cask`タップに**特に焦点を当てましょう。メインライン、信頼できるソース。ここでも、リスクは非常に現実的です。**

キャスクをインストールするとどうなりますか？

フローを分解しましょう。
実行するとき：

brew install --cask some-app

Homebrew:**‍**

** 1. キャスク公式レシピを解析**します。ダウンロードURL、バージョン、チェックサムなどのメタデータを取得します。**‍**

** 2. インストーラーをフェッチ**します。通常は.dmgまたは.pkg。キャスクで定義されたURLから直接取得します。**‍**

** 3. （おそらく）チェックサムを検証**します。しかし、ここが厳しいところです。

‍**なぜ`no_check`が存在するのですか？**

理論的には、Homebrewはダウンロードされたファイルのチェックサム（`sha256`）を検証して、改ざんされていないことを確認します。ただし、多くのキャスク、特に自動更新を行うか、動的でバージョン不要なURLを提供するものは、この検証をスキップするために`no_check`フラグを使用します。なぜですか？これらの場合、チェックサムが頻繁に変わるため、キャスク公式レシピで固定ハッシュを保持することは現実的ではなく、不可能な場合もあります。これは利便性やコーナーカッティングだけではありません。時々、Homebrewが急速に変化し、常に更新されるアプリをインストールするためには必要なトレードオフです。**‍**

‍**
実際、メインの公式キャスクタップ内だけで、`sha256 :no_check`を明示的に宣言する2,800以上のキャスクがあります。**しかし、その完全性チェックをスキップすることは、特に暗号化されていない接続と組み合わさった場合、信頼チェーンに大きな穴を開けます。

これはエコシステムのニッチな角ではありません。広く使われるアプリについて話しています。これは一味です：

• Google Chrome（`google-chrome`）→ 今年**260K以上のインストール**‍
• Spotify（`spotify`）→ 今年**90K以上のインストール**‍
• Steam（`steam`）→ 今年**35K以上のインストール**‍
• Google Drive（`google-drive`）→ 今年**25K以上のインストール**

さて、単独の`no_check`は必ずしも災害ではありません。一般的なアプリケーションの多く、私たちが先ほどリストアップした人気キャスクを含めて、安全なHTTPS接続でダウンロードを提供しています。これらの場合、チェックサムがなくても、暗号化された転送層がペイロードを転送中の改ざんから保護します。

真の問題は、`no_check`がHTTPと組み合わさったときに現れます。完全性検証なし、転送暗号化なし。ただ、リモートサーバーからあなたの/Applicationsフォルダへの直接的で保護されていないパイプです。ネットワークパス上に位置している誰でも（パブリックWiFi、危険にさらされたルーター、または悪意のあるISPを考えてください）ダウンロードを傍受し、望むものに置き換えることができます。

では、この組み合わせはどの程度一般的ですか？公式homebrew-caskタップを掘り下げ、プレーンHTTPでダウンロードを提供し、`no_check`が有効になっている20のキャスクを見つけました。これはコアタップの20の開かれたドアです。開発者が毎日依存している信頼できるソース。

何が安全だと私たちは仮定していますか？

Homebrewキャスクの背後にある**信頼モデル**は、いくつかの重要な仮定に依存しています：

✅ キャスク内のurlで定義されているアップストリームサーバーは正当で、侵害されていないこと。

✅ 転送層（理想的にはHTTPS）がダウンロードを改ざんから保護すること。

✅ Homebrewがダウンロードされたファイルの完全性を検証すること。

個別には、これらの各ギャップは生き残る可能性があります。しかし、**両方**を組み合わせると。ペイロードの改ざん（暗号化されていないダウンロードまたは侵害されたサーバー経由）**と**チェックサム検証が無効になっている場合、シームレスで検出不可能な攻撃のための完全な条件を作成します。そして、それはまさにこの脆弱性が存在する場所です。

概念実証（PoC）: Homebrewキャスクインストールのハイジャック

`no_check`とHTTPの組み合わせがどの程度危険であるかを実証するために、シンプルな概念実証を組み立てました。

私たちは`tau`キャスクをターゲットにしました。これはHTTP経由でインストーラーをフェッチし、チェックサム検証が無効になっています。表面上、それはただ別のパッケージインストールです。しかし、内部では、MITM傍受のための完璧な攻撃ベクトルになります。

ステップ0：攻撃の準備

攻撃を開始する前に、まず「**悪意のある**`.dmg`ファイル」を作成しました。この場合、「あなたはハッキングされています！」というメッセージをポップアップするシンプルなアプリケーションです。開かれたとき。これは純粋にデモンストレーション目的でしたが、ペイロードを完全に置き換えることができることを証明しています。

また、**中間者（MITM）**傍受を実行する位置をネットワークにセットアップしました。これにより、被害者のマシンとアップストリームサーバー間のHTTPトラフィックをキャッチして置き換えることができます。

ステップ1：インストールの実行

標準的なHomebrewインストールコマンドを実行：

ターミナル出力では、以下を明確に見ることができます：

• Homebrewはアップストリームソースに到達します：
  http://tau.uoregon.edu/tau_arm64.dmg
• SHA256チェックは行われていません（キャスク公式レシピで`no_check`が設定されています）。

転送層へのアクセスを使用して、アップストリームサーバーへのリクエストを傍受し、私たちが作成した「悪意のある」アプリケーションでその代わりに応答しました：

ステップ2：アプリをアプリケーションに入れる

ダウンロード後、Homebrewはアプリを`/Applications`に移動します：

ステップ3：悪意のあるペイロードのトリガー

インストール後、ユーザーがアプリを起動すると、MITM攻撃中に交換した**悪意のあるペイロード**を無意識のうちに実行しています。このPoC では、それは単純なポップアップメッセージをもたらしました：

これはラボのみの理論的なテストではありませんでした。以下の場合の実世界で繰り返可能なデモンストレーションでした：

✅ インストーラーは安全でないHTTP経由でフェッチされました。

✅ キャスク公式レシピは`no_check`を使用し、完全性検証をスキップしました。

✅ Homebrewがアプリをインストールして配置しました。それはそのように設計されています。

ネットワークパス上に座ることで、プロンプトなし、アラートなし、昇格されたアクセス許可なしで、**シームレスに悪意のあるアプリ**をユーザーのシステムに注入することができました。

責任ある開示

問題の影響を検証した後、影響を受けたキャスクのリストとともに、Homebrewのメンテナーに非公開で調査結果を開示しました。Homebrewチームが報告をレビューし、中央で行動を起こしました。安全に更新できるキャスクは、HTTPSを使用するように変更されました。安全な転送がオプションではなかったり、保証されなかった場合、その他は無効にされました。

このプロセスは、私たちが特定した特定のインスタンスを解決しましたが、キャスクエコシステムの重要な設計上の考慮事項も強調しています。Homebrewは、有効な実用的な理由のために、HTTPダウンロードURLと`no_check`の使用の両方をサポートし続けています。

うまくいけば、この開示によってもたらされた追加的な精査は、将来のレビューと保守の決定に情報を提供するのに役立つでしょう。可能な限り安全な転送と完全性管理の一貫した使用をお勧めします。

タップをきれいに保つ

Homebrewキャスクエコシステムは攻撃者のために構築されていません。便利さのために構築されています。しかし、便利層と同じように、仮定が無視されると亀裂が現れます。数千のアプリ、コミュニティが保守するキャスク、アップストリームソースから取得された公式レシピがあれば、すべての`brew install –cask`コマンドにどれだけの信頼が組み込まれているかを忘れるのは簡単です。

このProof of Conceptは、単なる誤った構成以上のものを明らかにしています。それは構造的な弱点を露出させています。静かに完全性チェックをバイパスすることを許可し、安全でない転送を滑らせるシステム。単独では、これらの要因は眉をひそめるかもしれません。組み合わせると、ユーザーのマシンに悪意のあるコードを直接配信するための監視されていないパスウェイを作成します。通常の防御をバイパスし、アクセス許可をサイドステップし、信頼できるインストールプロセスの下にマルウェアを埋め込みます。

発見時には、公式タップ内の複数のキャスクが`no_check`とHTTPを組み合わせていました。これらのケースはそれ以降、更新または削除を通じて解決されていますが、毎日のパッケージインストールに埋め込まれている信頼の大きさをどの程度思い出させるかに役立ちます。キャスクエコシステムが進化するにつれて、安全な転送と完全性チェックへの継続的な注意は、Homebrewを便利で安全に保つのに役立ちます。

これは正確には、Koiが捕捉するために構築されたブラインドスポットです。当社のプラットフォームは、ソフトウェア配信パイプライン（パッケージマネージャー、ブラウザ拡張機能、IDE拡張機能）を継続的に監視します。ペイロードがディスクに触れる前に、安全性チェックなしおよび安全でない転送などの危険な組み合わせにフラグを付け、ブロックします。チームがKoiを実行していた場合、これらの20個の脆弱なキャスクは、環境に表示された瞬間にフラグが付き、ブロックされていたでしょう。

ソフトウェアエコシステムがより動的で分散化するにつれて、これらの見落とされた信頼のギャップは増加するだけです。パッケージマネージャーに頼ってエンドポイントをきれいに保つ場合は、インストールコマンド全体で実際に流れているもの、より詳しく見えるようにすることが時間です。

環境を保護するのにどのようにお手伝いできるかについて、当社に相談してください。