配布システムの侵害により、攻撃者は偽のcPGuardアップデートを数千台のLinuxサーバーに配信しました。アップデートはroot権限で実行されました。
ソフトウェアサプライチェーンの弱点が、またも露呈しました。今回の標的は、OpsShieldのアップデートプロセスです。
今週、攻撃者は侵害した認証情報を使い、cPGuardの顧客に悪意あるアップデートを配信しました。さらに、ベンダーのサーバーや課金ポータルのアカウントに保存されていたデータにアクセスし、OpsShieldのクラウドサーバー少なくとも3台のコピーを作成しています。
同社はセキュリティ勧告の中で、「把握している限りのすべてのシステムから攻撃者を排除し、完全には信頼できないシステムを再構築している」と説明しています。また、更新版もすでに公開しており、顧客に対して、cPGuardを最新版へ更新し、パスワードを変更し、新しいSSH鍵を生成するよう呼びかけています。
今回の不正アクセスが広範囲に及んだことは、ソフトウェアサプライチェーンの脆弱性が依然として解消されていないこと、そしてセキュリティツール自体も脆弱になり得ることを改めて示しています。
Infotechのテクニカルカウンセラー、Erik Avakian氏は次のように指摘します。「本当に危険なのは、攻撃者が信頼されたセキュリティ更新の仕組みを、サーバーへの侵入経路に変えられた点です。サーバーを守るはずのソフトウェアが、そのサーバーを侵害する発信源になってしまいました」
攻撃の全容
OpsShieldは、サーバー保護とWebセキュリティのソフトウェアを専門とする企業です。主力製品のcPGuardは、Linux型Webホスティングサーバー向けに設計されたセキュリティスイートで、マルウェアスキャナーとファイアウォールを備えています。
同社の発表によると、攻撃者は11月1日から2日にかけてOpsShieldのアップデート配布基盤に不正アクセスし、約70分間にわたって悪意あるアップデートを配信しました。
攻撃者はまずOpsShieldの課金ポータルを探り、偽の身元で顧客アカウントを登録して、cPGuardの無料トライアルを注文しました。続いて細工したリクエストを送信し、サーバー上でコマンドを実行できる状態を確保してデータを収集しました。盗んだアクセスキーを使って、root(最高位の管理者権限)で動作する偽アップデートを公開したほか、機密ファイルをコピーし、OpsShieldのクラウドサーバー3台の複製も作成しています。
OpsShieldによると、約2,950台の顧客サーバーが偽アップデートを実行し、パスワードハッシュ、root用SSH鍵、MySQLのrootパスワード、シェル履歴が流出する恐れがあります。さらに攻撃者は、顧客の氏名、住所、メールアドレス、ハッシュ化されたパスワードを含む約7,900件の課金ポータルアカウントにもアクセスしました。
OpsShieldによると、侵入の起点となった正確なリクエストについては現在も調査中です。侵入口になり得る2か所はすでに修正し、関連するベンダー製コンポーネントも「1行ずつ」検証しました。また、攻撃者のアカウントを閉鎖し、盗まれたアップデート保管用キーのほか、「アカウント上のすべてのクラウドAPIトークンとアクセスキー」を失効させています。
このほか、同社は次の対応を実施しました。攻撃者が設置したSSH(セキュアシェル)の経路を削除し、攻撃者が作成したサーバーの複製とスナップショットをすべて削除しました。ログイン保護を強化したうえで、SSH鍵とパスワードをすべて入れ替えています。課金ポータルのログインセッションはすべてリセットし、全キーをローテーションしました。課金、ライセンス、社内管理の各サーバーについては、PHPとファイアウォールの設定を厳格化したうえで再構築を始めています。
修正版のアップデートも公開済みです。v5.88.26は隠されたrootシェルを除去し、続報のアップデートは攻撃者が残したスケジュールタスクを削除します。さらに、攻撃者がアクセスしたコピーを無効にするため、cPGuardのライセンス用秘密鍵と公開鍵をすべて再発行する作業にも着手しました。
同社は管理者に対し、次の対応を求めています。
- cPGuardを最新版に更新し、/etc/cron.d/i93677、/var/tmp/.i93677/、/var/tmp/.cpg91511_shが存在しないことを確認する。残っていれば削除する
- rootパスワードと、サーバー上のすべてのローカルユーザーのパスワードを変更する
- 新しいroot用SSH鍵を生成し、その鍵を信頼していたすべてのサーバーから古い鍵を削除する。鍵を変更するまでは、サーバーが侵害されたものとして扱う
- MySQLのrootパスワードとデータベースのパスワードを変更し、rootのシェル履歴に残るパスワード、APIキー、トークンをローテーションする
- OpsShield課金ポータルのパスワードをリセットし、二要素認証を有効にする
- 最後に、同社は「攻撃者が手動でサーバーにログインしたとお伝えした場合は、11月1日より前に取得したクリーンなバックアップからサーバーを再構築してください」としています
OpsShieldは透明性を確保、それでも影響は深刻
Dickson ResearchのFrank Dickson氏は、「正直なところ、これほど率直に侵害を公表するベンダーはほとんどありません。OpsShieldはその点で大いに評価に値します」と述べています。
ただし同氏は、最悪の侵害とはセキュリティツールが運んでくるものだと指摘します。更新チャネルは意図的に開放されており、セキュリティツールはすべてを監視する必要があるためroot権限で動作します。そのため「偽のアップデートもrootで実行された」というわけです。
ホスティング事業者の場合、1台のサーバーに数百の顧客Webサイトとデータベースが載っていることもあります。MySQLのrootパスワードがあればそのすべてを開けられ、root用SSH鍵があれば、その鍵を信頼する他のサーバーにも入れます。シェル履歴にも、入力したパスワードやトークンが残っていることが少なくありません。
Dickson氏は、下流の顧客は最も大きな被害を受けかねないのに、最も状況を把握できていないと指摘します。Webサイトの所有者の大半は、ホスティング事業者がどのセキュリティエージェントを使っているか知らないからです。自動更新を行うサーバーはすべて、ベンダーの配信パイプラインを信頼しています。
OpsShieldは自社を、小規模な事業者向けに低価格で製品を販売する小さなチームだと説明しています。Dickson氏によれば、これこそがサプライチェーンの不都合な真実です。「自社のリスクを決めるのは、サーバーでroot権限を持つ最大のベンダーではなく、最小のベンダーです」
Avakian氏も、企業のソフトウェアサプライチェーンの安全性は、その背後にあるシステム、ID、プロセスの安全性を超えられないと同意します。「自社のインフラを守るためにできることをすべて行っても、信頼しているサードパーティのサプライヤー経由で侵害される可能性があります」
同氏によれば、特に懸念されるのは、攻撃者が数千の顧客を1社ずつ狙う必要がなかった点です。単一の配布の仕組みを侵害するだけで、ベンダー自身の信頼されたインフラを顧客に向けて武器にできました。
同氏は、サードパーティはリスクを拡大させるものであり、企業はその事実をいまだに過小評価していると言います。「企業は、サードパーティとサプライチェーンのリスク管理にもっと注意を払う必要があります」
ゼロトラストは必須
Avakian氏はさらに、盗まれた認証情報が新たな攻撃に使われかねないため、下流の顧客への影響は初期の侵害をはるかに超える可能性があると指摘します。企業は、ソフトウェアサプライヤーと、そのアップデートも対象に含めたゼロトラストのアプローチを採るべきだといいます。
「アップデートが信頼できる提供元から届いたからといって、安全だと決めつけてはいけません」と同氏は話します。企業はベンダーリスクをより厳しく精査し、特権認証情報を保護し、ソフトウェアの完全性を検証する必要があります。さらに、アップデート後の想定外の挙動を継続的に監視し、問題が起きた場合にはすぐにシステムを隔離できるよう備えるべきです。
「信頼できるサプライヤーでさえ侵害され得ると想定して、計画を立てる必要があります」と同氏は強調します。「そうしたシナリオは、定期的な机上演習プログラムの一環として訓練しておくべきです」
Dickson氏は、まず棚卸しから始め、rootまたは管理者権限で動作するベンダーのエージェントをすべて把握するよう勧めています。エージェントはどれも更新チャネルになるからです。顧客はベンダーに対し、アップデートの公開鍵がどこに保管され、顧客向けシステムとどう分離されているかを尋ねるべきだといいます。このほか、サーバーからの外向き通信を監視し、シークレットをシェル履歴に残さず、SSH鍵には有効期限のある認証情報として扱うことも求めています。下流の顧客は、利用中のホスティング事業者がcPGuardを使っているかどうかを直接確認し、自分のパスワードを変更してください。
「サーバー上で最も危険なソフトウェアは、自動更新を任せている信頼済みのソフトウェアかもしれません」と同氏は話します。「そうしたベンダーは、root権限を握っているものとして選んでください。実際に握っているのですから」
この記事はもともとNetworkWorldに掲載されたものです。