テック技報最新号へ →
セキュリティ

cPGuard の更新経路が乗っ取られた:更新したあと、鍵とパスワードも替える

開発元の請求・ライセンス管理サーバーから更新用の鍵が盗まれ、約 2,950 台に偽の更新が root で入った。修正版で既知のファイルは消えるが、持ち出された /etc/shadow のハッシュや root の SSH 鍵はそのまま使えるので、交換までやって初めて終わる。

@MalwareBibleJP · 2026-11-08

いつ使うか

  • Linux サーバーに OPSSHIELD の cPGuard を入れている、または入れていた
  • 「セキュリティ製品の自動更新」そのものが侵害経路になったときの後始末の型として

何が起きたか

  1. 攻撃者は 11 月 1 日(UTC)に偽の身元で顧客登録し、請求ポータルへの細工リクエストで管理サーバー上のコマンド実行を得た(正確な侵入リクエストはログに残っていない)。
  2. 更新の公開に使う鍵を盗み、5.88.12〜5.88.19 として偽の更新を配った。顧客サーバーへの導入は 11 月 2 日 02:08〜03:20(UTC)。
  3. 偽の更新が集めたのは、/etc/shadow のパスワードハッシュ、root の SSH 鍵とシェル履歴、MySQL の root パスワード、一部サーバーのクラウドストレージ鍵。
  4. 請求ポータルのアカウント約 7,900 件(氏名・住所・メール・bcrypt ハッシュ)も持ち出された。

対応の順番

  1. 上の時間帯に cPGuard が 5.88.12〜5.88.19 に上がっていたかを確認する(パッケージ履歴や cPGuard のログ)。
  2. 5.88.26 以降へ更新する(不正な root シェルを除去するのは 5.88.26。初期勧告では 5.88.25 以降)。更新後に /etc/cron.d/ などに見知らぬ項目が残っていないか確かめる。
  3. 「更新で消えた=終わり」にしない。全ユーザーのパスワード、root の SSH 鍵(authorized_keys に入れている先も含めて差し替え)、MySQL の root、クラウドストレージのアクセスキーを交換する。
  4. 交換前に盗まれた鍵で入られていないか、当日以降の SSH ログイン記録とクラウドのアクセス記録を見る。
  5. 請求ポータルのパスワードを変え、2 要素認証を有効にする。

注意

出典

X の元の投稿を開く