約2,950台。Linux サーバー 向けのセキュリティ ソフト「cPGuard」の偽の更新を、11月2日に動かしたサーバーの数です。入っているサーバーは版を上げるだけでは足りず、rootのパスワード やSSH の鍵、データベースのパスワードまで替える必要があります。開発元のOPSSHIELDは11月3日、更新の配信に使う基盤に不正アクセスを受け、偽の更新が顧客のサーバーに配られたと公表しました。
発表から6日がたち、11月8日には更新の配信の仕組みを改めた5.89.00が出ました。ただ、事故についての2本の発表は、どちらも3日の日付のままです。
自分で入れた覚えがなくても、借りているサーバーに入っていることがあります。cPGuardは、VPSや共有サーバーを貸すホスティング会社向けにも売られている製品だからです。発表は英語で、日本での提供の状況には触れていません。
探り始めから偽の更新まで、約10時間
事故の発表にある経過を日本時間に直すと、攻撃者が探り始めたのは11月2日の0時38分でした。相手は請求と契約のポータル「manage.opsshield.com」です。1時34分には偽の身元で顧客として登録し、無料の試用を申し込みました。
6時17分、攻撃者は試用版を自分のサーバーに入れ、エージェントがライセンスのシステムとどうやりとりするかを調べます。6時40分から51分には、cPGuard自身が攻撃者を2回締め出しました。それでも7時50分にポータルのコールバックのページへ細工したリクエストを送り、7時58分には請求とライセンスのサーバーでコマンドを実行できるようになります。
11時4分から9分には、盗んだアクセスキーで偽の更新が保管場所に置かれました。顧客のサーバーのエージェントは11時8分から12時20分にこれを入れ、rootで動いて機密のファイルを攻撃者のもとへ送ったといいます。
どのリクエストで入られたかはログに残っておらず、同社は入口の候補を2か所ふさいだと説明します。
2本の発表で、見分け方の物差しが違う
OPSSHIELDは11月3日に、先にアドバイザリ、あとに事故の発表を出しました。アドバイザリの冒頭は、自らを先の時点の記録とし、最新の内容は事故の発表を見るよう案内していますが、影響を受けたサーバーの見分け方は2本で違います。
アドバイザリは版で線を引きました。5.88.12から5.88.19の更新を入れた記録があれば、今が新しい版でも侵害されたおそれがあるものとして扱うよう求めます。
事故の発表は時間で線を引きました。2日の11時8分から12時20分にcPGuardを入れてオンラインだったサーバーは、rootの権限で読める秘密を攻撃者が知っているものとみなすよう求めます。その時間にオンラインでなければ、偽の更新は届いていないという立場です。
OPSSHIELDの事故の発表（11月3日）。対象の時間と、件数 出典: OPSSHIELD「Security Incident Disclosure: manage.opsshield.com」 (引用) それでも、事故の発表は版で見分ける手順を取り消していません。アドバイザリは、対象の版の公開から「12時間以内」に攻撃を見つけたとし、更新の確認は間隔を置いて走るとも説明します。載せた記録の例でも、対象の版への更新が「02:46」から「12:46」まで、2〜4時間おきに5回並びました。事故の発表の約70分より長い間に、対象の版が入りうると読めます。
どちらか一方で「対象外」と決めるのは危ういでしょう。時間と版の両方を調べ、どちらかに当たれば対象と考えるのが安全です。アドバイザリも、記録が見つからないことや欠けていることだけでは、影響がなかったとは言えないとしています。
修正版の呼び方も、そろっていません。アドバイザリは5.88.25以降を、事故の発表は5.88.26を、きれいな版として挙げました。
今から上げるなら、11月8日に出た最新の5.89.00でそろえるのが分かりやすいはずです。なお、変更履歴では10月22日の5.88.11の次が11月2日の5.88.25で、対象の5.88.12から5.88.19は1つも載っていません。
cPGuardの変更履歴。11月8日の5.89.00と、2日の5.88.26と5.88.25 出典: OPSSHIELD「cPGuard software release notes / changelog」 (引用) 読まれたのは、ほかのサーバーへの合鍵でもある
偽の更新が読んだファイルは、次のとおりです。
/etc/shadowと/etc/passwd
/root/.sshにあるSSHの秘密鍵、authorized_keys、known_hosts
MySQLのrootのパスワードを書いた/root/.my.cnf
rootのシェルの履歴
クラウドストレージのキーを書いた/root/.s3cfg（一部のサーバー）
しかも、被害はそのサーバーで終わりません。rootのSSHの秘密鍵で入れるほかのサーバーも、鍵を替えるまでは危ないものとして扱うよう、同社は求めました。シェルの履歴には打ち込んだパスワードやトークンがよく残る、とも指摘しています。
偽の更新は、隠したシェルも置いていきました。事故の発表が挙げた侵害の痕跡によると、実行すればrootになれるsetuidのシェルです。共有サーバーなら、ほかの利用者のアカウントや乗っ取られたサイトからも、修正版が当たるまで使えたおそれがあります。
攻撃者は請求のポータルからも、約7,900件のアカウントの名前、会社名、住所、メールアドレス、bcryptのハッシュにしたパスワードを写し取りました。cPGuardの契約者の名簿とも言えるものです。OPSSHIELDやホスティング会社を名乗る「更新のお願い」が、これから届くかもしれません。
うちの会社に関係あるかは、サーバーの持ち方で分かれる
自社でLinuxのサーバーを管理し、cPGuardを入れている会社は、全台を調べる側です。cPanelやPlesk、DirectAdmin、Webminなどの管理画面と組み合わせるほか、管理画面のないサーバーにも入れられます。
共有サーバーやマネージドのVPSを借りている会社は、ホスティング会社が入れたかどうかで決まります。OPSSHIELDの説明では、利用者向けのプラグインがあり、cPanelとWebuzoなら「Security」、DirectAdminなら「Extra Features」の欄にcPGuardが出ます。日本語の画面では、欄の名前が訳されていることもあるでしょう。そこにあれば、借りているサーバーにcPGuardが入っているということです。
見当たらなくても、入っていないとは言い切れません。プラグインを出さずに使うホスティング会社もありうるからです。借りている側で替えられるものは、自分のアカウントとデータベースのパスワード、サイトに置いたキーくらいでしょう。rootの秘密を替える役目は、ホスティング会社にあります。
一方、cPGuardが入っていないサーバーは、今回の偽の更新とは関係がありません。ただし、試用だけでもmanage.opsshield.comにアカウントを作ったことがあれば、パスワードの再設定は要ります。
サーバーで確認すること、ホスティング会社に聞くこと
自社で管理しているサーバーなら、2本の発表にあるコマンドとファイルの名前で、次の順に進めます。
cpgcli --version で版を見て、5.89.00でなければ cpgcli update --start で上げます。grep 'Successfully updated' /opt/cpguard/logs/install_log で、5.88.12から5.88.19を入れた記録を探します。11月2日の11時8分から12時20分にサーバーが動いていたかも、last -x reboot か監視の記録で、あわせて見ます。/var/tmp/.cpg91511_sh、/var/tmp/.cpg91511/、/var/tmp/.i93677/、/etc/cron.d/i93677が残っていないかを調べます。2本の発表で挙げた名前が少しずつ違うので、全部を見ます。残っていれば、そのサーバーは偽の更新を動かしたものとして4に進み、ファイルは消します。見つからなくても、動かなかったとは言い切れません。
2か3で当たったサーバーは、rootとほかのローカルのアカウントのパスワード、/root/.sshの鍵、MySQLのパスワード、履歴と/root/.s3cfgにあるキーを替えます。古い公開鍵は、それを信頼していた全てのサーバーから外します。
manage.opsshield.comのパスワードを再設定し、二要素認証を有効にします。
借りているサーバーなら、ホスティング会社に聞くことは3つです。5.88.12から5.88.19を入れたか。rootの秘密とSSHの鍵を替えたか。利用者が替えるべきパスワードはあるか。返事を待つあいだに、自社のアカウントとデータベースのパスワードは先に替えておいてかまいません。
作り直すかどうかの線引き
10月には、WordPressのSEOプラグイン「Rank Math PRO 」の配布にも不正なコードが入りました。Rank Mathは、協定世界時の10月15日20時2分から16日7時12分までに、3.0.123を入れて有効にしたサイトを、侵害されたものとみなします。そのうえで、事故の前のバックアップからの復元を勧めました。
OPSSHIELDは逆に、サーバーの作り直しを決まりの対応としては勧めていません。更新とパスワードやキーの入れ替えで足りるという見立てで、暫定だとも断りました。作り直しを求める先は、攻撃者が手でログインしたと同社が連絡したサーバーです。その場合は、11月1日より前のきれいなバックアップから作り直すよう求めます。
同社も、ほかの侵害の跡が見つかったときや、サーバーが無事だと確かめられないときは、作り直しが適切な場合があるとしています。setuidのシェルが一時は置かれていたことを考えると、見覚えのないユーザーやSSHの鍵、外への通信が見つかった時点で、作り直す側へ倒すのが妥当でしょう。
5.89.00の変更履歴には、更新の配信を署名し、ほかと切り離した基盤から配る形に改めたことと、社内の監査で見つかったセキュリティの問題の修正が並びます。どの鍵でどう署名を確かめるのか、監査で何が見つかったのかまでは、まだ説明がありません。
サーバーを守るための製品ほど、rootで動き、自動で更新します。今回の件は、その更新の通り道が、数千台のサーバーへの入口にもなりうることを示しました。署名の仕組みを改めた5.89.00が、その入口をどこまで狭めたのか。同社の次の説明で、いちばん確かめたいのはそこです。
