cPGuard の更新経路が乗っ取られた:更新したあと、鍵とパスワードも替える
開発元の請求・ライセンス管理サーバーから更新用の鍵が盗まれ、約 2,950 台に偽の更新が root で入った。修正版で既知のファイルは消えるが、持ち出された /etc/shadow のハッシュや root の SSH 鍵はそのまま使えるので、交換までやって初めて終わる。
いつ使うか
- Linux サーバーに OPSSHIELD の cPGuard を入れている、または入れていた
- 「セキュリティ製品の自動更新」そのものが侵害経路になったときの後始末の型として
何が起きたか
- 攻撃者は 11 月 1 日(UTC)に偽の身元で顧客登録し、請求ポータルへの細工リクエストで管理サーバー上のコマンド実行を得た(正確な侵入リクエストはログに残っていない)。
- 更新の公開に使う鍵を盗み、5.88.12〜5.88.19 として偽の更新を配った。顧客サーバーへの導入は 11 月 2 日 02:08〜03:20(UTC)。
- 偽の更新が集めたのは、
/etc/shadowのパスワードハッシュ、root の SSH 鍵とシェル履歴、MySQL の root パスワード、一部サーバーのクラウドストレージ鍵。 - 請求ポータルのアカウント約 7,900 件(氏名・住所・メール・bcrypt ハッシュ)も持ち出された。
対応の順番
- 上の時間帯に cPGuard が 5.88.12〜5.88.19 に上がっていたかを確認する(パッケージ履歴や cPGuard のログ)。
- 5.88.26 以降へ更新する(不正な root シェルを除去するのは 5.88.26。初期勧告では 5.88.25 以降)。更新後に
/etc/cron.d/などに見知らぬ項目が残っていないか確かめる。 - 「更新で消えた=終わり」にしない。全ユーザーのパスワード、root の SSH 鍵(
authorized_keysに入れている先も含めて差し替え)、MySQL の root、クラウドストレージのアクセスキーを交換する。 - 交換前に盗まれた鍵で入られていないか、当日以降の SSH ログイン記録とクラウドのアクセス記録を見る。
- 請求ポータルのパスワードを変え、2 要素認証を有効にする。
注意
- 自動更新を止めればよい、という話ではない。更新元が侵害されたときに「何が盗まれたか」を開発元の報告で特定し、その種類の秘密を全部替えるのが本筋。
- 同じ考え方: SaaS 側が侵害されたときの利用者の後始末:GitBook の全 API トークン無効化の例