Goインフラの悪用

 (reverse.put.as)
2 ポイント 投稿者 GN⁺ 2024-05-26 | 1件のコメント | WhatsAppで共有

問題点

  • 昨夜、Goのチェックサムデータベースの内容を調べていたところ、興味深い結果を見つけた。
  • sqlite> select path, count(path) from modules group by path order by count(path) desc; コマンドを実行した結果:
    • github.com/homebrew/homebrew-core|39438
    • github.com/Homebrew/homebrew-core|30896
    • github.com/concourse/concourse|25372
    • github.com/openshift/release|24065
    • github.com/cilium/cilium|22138
  • HomebrewはRubyを使うことで知られており、Goとのつながりが疑問だった。
  • GitHubの言語統計もそれを裏付けていた。
  • Goに関連するファイル（go.mod またはGoのソースファイル）を探すためにリポジトリをクローンしたが、何も見つからなかった。

調査

  • 新しい日が始まり、好奇心が答えを求めた。
  • GitリポジトリがGoコードと無関係なら、なぜGoのチェックサムデータベースに現れるのか疑問に思った。
  • proxy.golang.org がデフォルトのモジュールプロキシで、sum.golang.org がチェックサムデータベースであることを知った。
  • Goのドキュメントを読むと、モジュールのバージョンがまだログに記録されていない場合、チェックサムデータベースは元のサーバーからモジュールを取得しようとすることが分かった。
  • 新しいGoモジュールのリポジトリがチェックサムデータベースとプロキシに追加されるか確認するため、lookup エンドポイントを呼び出してみた。
  • 新しいGoモジュールを作成してGitHubアカウントにアップロードした後、lookup コマンドを2つの形式で試したが、どちらもエラーになった。
  • 正しい疑似バージョンを生成し、モジュールがダウンロードされたか確認するためにチェックサムデータベースへ再度クエリした。
  • プロキシにクエリしてモジュールの zip をダウンロードし、任意のデータをGoインフラに保存できることを証明した。

悪用の可能性

  • 開発者マシンやCI/CDサーバーでダウンロード制限を回避するために使われる可能性がある。
  • マルウェアがペイロードを保存し、必要なときにプロキシから取得できる可能性がある。
  • proxy.golang.org に対するサービス拒否（DoS）攻撃が可能かもしれない。
  • コマンド＆コントロール（C2）システムを容易に実装できる。

結論

  • チェックサムデータベースのプロセスがどのように動作するかを理解できた。
  • 現時点ではGoインフラにおける深刻な問題ではないが、悪用される可能性はある。
  • なぜ非Goプロジェクトがデータベースに存在するのかという追加の疑問が残っている。
  • この調査から多くのアイデアを得ており、さらに探求する予定だ。

GN⁺の意見

  1. セキュリティ脆弱性: この記事は、Goのチェックサムデータベースが任意のデータを保存できるというセキュリティ上の弱点を指摘している。これは、マルウェアが容易に配布されうる経路を提供しかねない。
  2. 改善の必要性: Goインフラのセキュリティと完全性を強化するために、チェックサムデータベースとプロキシサーバーのアクセス制御を改善する必要がある。
  3. 他言語との統合: 非GoプロジェクトがGoのチェックサムデータベースに含まれる理由を明確にし、これを防ぐための追加の検証手順が必要である。
  4. 開発者教育: 開発者がこのようなセキュリティ上の弱点を認識し、それを防ぐためのベストプラクティスを理解できるようにする教育が必要である。
  5. 代替ソリューション: 類似機能を提供する他言語のチェックサムデータベースやプロキシサーバーを比較し、Goインフラ改善の参考にできる。

関連記事

1件のコメント

 
GN⁺ 2024-05-26
Hacker Newsの意見

Hacker Newsコメントまとめ要約

  • オンラインサービスの悪用可能性

    • あらゆるオンラインサービスは、最終的にコマンド＆コントロール、著作権侵害、CSAMホスティングに悪用される可能性がある。Twitter、Telegram、PGPキーインフラなどでも、すでにこうした事例がある。

  • Googleのファイルホスティング問題

    • Googleは悪意あるファイルのホスティング問題を頻繁に扱っているため、GoチームがGCPやDriveと連携した可能性がある。これはGoogleがすでに許可している他のエンドポイントと大きくは変わらない。

  • GitHubとの比較

    • GitHubにファイルをアップロードするのと大きな違いはない、という意見。GitHubもアカウントさえあれば任意のデータを保存できる。

  • PyPIの非Pythonプロジェクト

    • PyPIには非Pythonプロジェクトもあり、ユーザーがライブラリコードをコンパイルできない場合に備えて、wheel（コンパイル済みバイナリ）を配布できる機能が必要である。CやGolangで書かれたコードも対象になりうる。

  • Golangプロキシとチェックサムログ

    • Golangプロキシとsumdbを使って、任意のURLのチェックサムを透過的に記録するアイデアを試してみた経験がある。

  • ドメイン探索

    • 特定のドメインを調べたところ、予想していた内容の大半が含まれていた。

  • 既知の問題

    • Golangの既知の問題に関するリンクが共有されている。

  • CUEのモジュールシステム

    • CUEのモジュールシステムはリリースが進行中で、GoのMVSは好まれている一方、OCIインフラを基盤に構築されている。依存関係管理システムに興味があるなら、関連リンクを参照できる。

  • Webキャッシュ問題

    • W3CがWeb上のあらゆるものをキャッシュ可能にしたのに、汎用プロキシキャッシュがほとんど存在しない理由が気になる。発行者が不必要に短い Cache-Control: max-age や Vary: Cookie を返しているのか、あるいはあまりに多くのISPがトランジットコストを支払っているのか、という疑問がある。

  • プロキシキャッシュ問題

    • プロキシが非Goリポジトリをキャッシュするのは無駄かもしれないが、Goリポジトリをキャッシュできるようにすると任意のデータを保存できてしまう。大きな問題ではないと考えている。