GitLabのパスワード再設定バグにより5,300台超のサーバーが危険にさらされる

 (scmagazine.com)
1 ポイント 投稿者 GN⁺ 2024-01-29 | 1件のコメント | WhatsAppで共有

GitLab CVE-2023-7028脆弱性の未パッチサーバー

  • GitLabの重大な脆弱性CVE-2023-7028が火曜日時点で5,300台以上のサーバーに未適用のままとなっており、ソフトウェア開発者のアカウントがリモートで乗っ取られる可能性がある。
  • このバグは最大CVSSスコア10を受けており、GitLabが1月11日に初めて公開してパッチを提供した。
  • GitLabのログインシステムの脆弱性により、攻撃者は被害者の操作なしに、認証されていないメールアドレスへパスワード再設定リンクを送信できる。

パッチ情報および脆弱性テスト結果

  • GitLabバージョン16.5.6、16.6.4、16.7.2向けのセキュリティアップデートが公開され、16.1.6、16.2.9、16.3.7、16.4.5にもバックポートされた。
  • ある研究者はGitLab Community Editionバージョン16.6.1でこのバグをテストし、「非常に効果的で容易に悪用できる」とAttackerKBで結果を共有した。

脆弱なインスタンスの検出と減少傾向

  • パッチ適用が可能になってからほぼ2週間が経過した時点で、Shadowserver Foundationによって世界全体で5,379件の脆弱なGitLabインスタンスが検出された。
  • 米国とドイツがそれぞれ964件、730件で、最も多くの脆弱なインスタンスを保有している。
  • Shadowserverのダッシュボードツールは、1月24日に脆弱なインスタンスが4,652件まで減少したことを示した。
  • Shadowserverの広報担当者はSC Mediaへの確認で、脆弱なインスタンスの減少は前向きな進展ではあるものの、これが傾向なのか単なる変動なのかを判断するには、さらに時間が必要だと述べた。

GitLab CVE-2023-7028の侵害指標

  • GitLab Community EditionおよびGitLab Enterprise Editionのセルフマネージドインスタンスを利用しているGitLab顧客は、ログを確認してCVE-2023-7028が悪用されたかどうかを調べる必要がある。
  • gitlab-rails/production_json.logで/users/passwordパスへのHTTPリクエストを確認し、params.value.emailが複数のメールアドレスを含むJSON配列で構成されているかを確認する必要がある。
  • gitlabs-rails/audit_json.logでmeta.caller.idがPasswordsController#createであり、target_Detailsが複数のメールアドレスを含むJSON配列で構成された項目を確認する必要がある。
  • GitLab.comまたはGitLab Dedicatedインスタンスでは、このバグの悪用は検出されていない。
  • GitLabはまた、2要素認証（2FA）を有効にすることを推奨している。これによりCVE-2023-7028を通じたアカウント乗っ取りは防げるが、未パッチのインスタンス利用者には、攻撃者が脆弱性を悪用してパスワードを再設定し、アカウントから締め出されるリスクが依然として残る。

GN⁺の見解

  • この記事は、GitLabの重大なセキュリティ脆弱性に関する重要な情報を提供している。CVE-2023-7028はソフトウェア開発者のアカウントセキュリティに直接的な脅威となり得るため、適切な対応が必要だ。
  • パッチが提供されたにもかかわらず、世界中で多くのサーバーが依然として脆弱な状態に置かれており、セキュリティ意識と適時のアップデートの重要性を強調している。
  • 2要素認証（2FA）の重要性を浮き彫りにし、ユーザーに追加のセキュリティ手段の活用を勧めることで、セキュリティへの意識を高めるきっかけを与えている。

関連記事

1件のコメント

 
GN⁺ 2024-01-29
Hacker Newsの意見

  • 「アカウントベースのWebアプリにおける『メールアドレスとアカウントの紐付け』機能の危険性について触れたい。これはペンテスターが真っ先に試そうとするものの1つであり、2000年代初頭から脆弱性が見つかってきた。GitLabでもこの問題が再現された。GitLabには優れたセキュリティチームがあるが、この種のバグを避けるのは難しいようだ。この話に関心のある一般のHacker News読者なら、自分のパスワード再設定機能、とくにメール連携ロジックを確認してほしい。」

  • 「Railsコードベースでこの脆弱性を見つけたコミットへのリンクを共有する: GitLab commit link」

  • 「このバグの被害を受けた。攻撃にはユーザーのメールアドレスを知っている必要があるが、GitLabのユーザーID（1から増えていく数字）に紐付いた隠しメールアドレスがある。ID 1や2は管理者である可能性が高いので、格好の標的になる。メール形式は 1-user@mail.noreply.<gitlabhost> のようなものだ。自動化された攻撃のように見えたが、2FAに救われた。」

  • 「メール経由のパスワード再設定は、正しく実装されていたとしてもセキュリティ上の悪夢だ。ほとんどのサービスではこの機能を無効化できず、代替手段はたいていエンタープライズSSOしかない。SMSトークン用に電話番号を設定できるサービスもあるが、メールとSMSトークンの両方を要求するオプションは見たことがない。」

  • 「ログインフォームにパスワード配列を入力することでアカウントに総当たり攻撃を仕掛けられるバグを見つけたことがある。スパム対策アプライアンス向けの粗末なWebインターフェースで、意図されたものだったのか、PHP初心者がコードを書いたのかは分からない。当時、特殊文字入りのパスワードを使っていたユーザーがこれを発見した。」

  • 「GitLabのような社内向けサービスは、信頼できるユーザーだけがアクセスできるVPNの背後で運用するのがよいということを思い出させてくれる。」

  • 「GitLabのアップデート自動化は非常に簡単だ。Docker+ComposeでGitLabを使い、Watchtowerなどで毎日更新すればよい。7年以上この方法でGitLabサーバーを運用しているが問題はなかった。見回してみると古いバージョンのGitLabが多いが、管理者たちは何をしているのだろうか？」

  • 「どんな種類の内部サーバーであっても、公開インターネットにさらさないという原則を持っている。VPN経由でしかアクセスできないようにして、第2の防衛線を構築する。」

  • 「常にSSOを使い、2FAを使うことを忘れないように、というもう1つの注意喚起だ。」

  • 「Ruby/Railsが、安全であるべきソフトウェアに適した選択だという考えはもうやめよう。GitLabがこれに対処しなければならない事情は理解しているが、今後は知的で隠れた制御フローを優先する言語やフレームワークより、もっと単純なもののほうがよいと認めるべきだ。私は本番のRubyコードベースで働いているが、何層もの抽象化によってコードが非常に拡張可能になったと思い込んでいる誰かのせいで、同様の問題が発生しうることは十分に想像できる。」