世界を動かす技術を、日本語で。

Ghrc.ioは悪意のあるサイトのようです

2025年8月25日原文(bmitch.net)

概要

ghcr.ioghrc.io のタイポが重大なセキュリティリスクにつながる事例の解説。 ghrc.io は一見普通のnginxサーバーだが、 OCI API へのアクセス時に不審な挙動を見せる。 www-authenticateヘッダー を悪用し、 GitHub認証情報 を盗む可能性。 docker login 等で誤ってログインした場合、資格情報が漏洩する危険性。 対策としては パスワード変更PATの無効化 が推奨される。

ghcr.ioとghrc.ioの違いと危険性

  • ghcr.ioGitHub が運営する、 OCI準拠のコンテナイメージ/アーティファクトレジストリ
  • ghrc.ioタイポスクワッティング されたドメインで、見た目はnginxのデフォルトページ表示。
  • /v2/ パスにアクセスすると、 nginxデフォルト ではなく OCIレジストリ のような401レスポンスと www-authenticateヘッダー を返す挙動。
  • Dockerやcontainerd, podman, Kubernetes などのOCIクライアントは、このヘッダーに従い 認証情報をghrc.io/tokenに送信 する。
  • 正規のnginx には不要な設定であり、明らかに 認証情報窃取 を狙った攻撃。

どんな場合に情報漏洩が起こるか

  • docker login ghrc.io を実行した場合、入力した認証情報が ghrc.io に送信される。
  • GitHub Actionsuses: docker/login-actionregistry: ghrc.ioを指定した場合、 トークンやPAT が漏洩。
  • Kubernetes Secret でghrc.io向けのレジストリ資格情報を作成し、イメージプル時に送信した場合。
  • push/pullのみ (ログインなし)では 匿名トークン取得 が失敗するだけで、資格情報自体は漏れない。
  • ghrc.io 用に保存された認証情報がなければ、基本的に影響は限定的。

影響とリスク

  • GitHubアカウント乗っ取りghcr.ioリポジトリへの不正アクセス の危険性。
  • 漏洩した認証情報で 悪意のあるイメージのプッシュアカウント自体へのアクセス が可能に。
  • GitHub Personal Access Token(PAT) やパスワードが特に狙われやすい。

対策・対応方法

  • 誤ってghrc.ioにログインした場合 は、すぐに パスワード変更PATの無効化 を実施。
  • GitHubアカウントの不審なアクティビティ を確認。
  • レジストリURLの正確な入力 を徹底し、 タイポスクワッティング に注意。
  • CI/CDや自動化スクリプト でもURLをコピペでなく、公式ドキュメントを参照推奨。

まとめ

  • ghcr.ioghrc.io のタイポは 単なるミス では済まない 重大なセキュリティインシデント に発展。
  • www-authenticateヘッダー の悪用により OCIクライアントの認証情報送信 を誘発。
  • 誤操作時は速やかな対応今後の再発防止策 が重要。

Hackerたちの意見

cとrが入れ替わってるって指摘されるまで、問題に気づかなかったよ!

うん、これが俺が1日に多分10回はやらかすタイプミスだわ。

ここでの問題は、GitHubのひどいドメイン名だね。コンテナレジストリの名前も最悪。

かなり説得力のある攻撃ベクトルだね。ドメインの問題に気づくのに何度も読まないといけなかった。

あなたも、他の多くの人もそうだよ。何度もリトライしたり、マシンを再起動したりする人もいるし。* https://stackoverflow.com/a/66985424/340790 (回答者のアカウント名を見つけてみて!)* https://forums.docker.com/t/docker-unable-to-push-to-ghrc-io...

くそ、これCIジョブからタイプミスを拾って悪いことする可能性があるな。

このドメインを使ってるオープンソースプロジェクトがたくさんあるよ。 https://github.com/search?q=ghrc.io&type=code

GitHubは内部で一括作成するツールを持つべきだよ。それを修正として送信すればいいのに。

これはかなり大きなリストだね。

ここでの危険はトークンのリプレイかな?Bearerトークンを使ってるから、パスワードを送信してるわけじゃないよね。 「Bearerトークンの脅威」セクションを見てみて: https://datatracker.ietf.org/doc/html/rfc6750#section-5.2 OAuthはドメインを跨いでトークンを再利用するの? もしそうじゃないなら、これはghrc(「偽」ドメイン)のために認証トークンをリクエストしてるだけで、ghcr(本物のドメイン)の認証トークンにはアクセスできないってことになるの?

ここにブログの著者(OCIのメンテナー)がいるよ。ベアラートークンを取得するリクエストでは、パスワードやPATが基本認証ヘッダーを使って送信されるんだけど、base64エンコードされてるけど、内容はクリアテキストなんだ。それがwww-authenticateヘッダーをトリガーしてるリクエストだよ。トークンを受け取ったら、レジストリはそれを使ってアクセスを確認して、最終的には期限切れになる。でも、攻撃者はトークンを取得してるわけじゃなくて、ベアラ認証トークンを取得するために使う資格情報をリクエストしてるんだ。

https://github.com/search?q=ghrc.io&type=code

Hacker Newsで議論の続きを見る