ハクソク

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

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

274日前原文(bmitch.net)

概要

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

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

  • ghcr.io は GitHub が運営する、 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 Actions でuses: docker/login-actionとregistry: 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.io と ghrc.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

GitHubのコンテナレジストリは、細かいトークンをサポートしてないし、代わりにクラシックなトークンを使ってるから、これがさらに危険だよ。[1] https://docs.github.com/en/packages/working-with-a-github-pa... 編集: 一番関連性のある問題は？ https://github.com/orgs/community/discussions/38467 https://github.com/github/roadmap/issues/558

└

近くにいる優しい人が、間違ったドメイン名を全部買い取ってMicrosoftに渡してほしいな。Microsoftにはレジストリの名前を変えてもらいたい。ほんとにひどい名前だよ。前に間違えて打ったことあるし。

└

これに対して他にどんな対策をしてる人がいるのかな？この問題があるから、クラシックPATを完全にオフにできないんだ。短い有効期限での再認証を企業のSSOにするのが一番いいみたいだけど、実際に必要なクラシックPATが一つだけだから不便なんだよね。

以前のHacker Newsで見たやつだよ。https://news.ycombinator.com/item?id=44974240

おかしなTLDを使わないようにリマインドしておくよ。可愛さよりもセキュリティの方が大事だからね。悪意のあるドメインを取り下げるプロセスが.comのようにスムーズになる保証はないし、アメリカのVeriSignとやり取りする方が、イギリスのインド洋地域やコロンビア、アンギラとやり取りするよりはマシだよ。

└

.ioのTLDはアメリカの企業Afiliasが管理してるよ。

Whoisによると、これはDynadotが登録してるみたいだから、彼らのアビューズメール（abuse@dynadot.com）に連絡してみる価値はありそうだね。