※ 発覚からデーモン復帰までの一連の対処は「スパムメール大量送信事件その1」を参照してください。
問題となるスクリプトもmvして、スパムメールが送信されることはなくなりました。
事象自体は収束しましたが、そもそもsender.phpが送り込まれたタイミングや方法、HelloDollyが書き換えられた原因を探って再発を予防する必要があります。
いざ、調査開始です。
1. 事の発端(多分)
実は、HelloDollyプラグインの更新日あたりで、該当サーバーはフィッシングページがアップロードされているという警告を受けていました。関係者が調べましたが、そういったものがアップロードされるような不正アクセスのログを見つけることが出来ませんでした。
ただ、Apacheのエラーログにはフィッシングページの圧縮ファイルを展開したログだけが残っており、どうやって展開したんだろう…という疑問はあったんですが、展開方法は見つけられず。
これといった発生源を見つけられないため、apacheの脆弱性バッチを当てたりSSLやSSHのバージョンをあげたり…出来る対応として、ミドルウェアやモジュールのバージョンアップしたようです。
それはそれでやらなきゃいけないことなので、結果としてよかったと思います。
が、一番の疑問はどうやってそのファイルをサーバーに置いたか です。
FTPdは立てていないサーバーですし、ポートは必要最低限のみ、ログの改ざんの可能性はなきにしもあらずとは言えSSH(sFTPも)経由の怪しいログもない…Apacheのエラーログに残っているとなれば、Apache経由だろうと結論付けるしかありませんでした。
Apache経由でファイルのアップロードが出来、展開が可能な方法として、私が思ったのは、EC-CUBEの管理画面からログインしてファイル管理を利用したのではないかということでした。(今思えばなぜそこまで考えてWordPressの存在を思い出せなかったか悔やまれます。)
該当サイトのEC-CUBEの管理画面へのID/Passwordはかなり安易なものだったため、すぐに強固なものに変更するよう運営者に通達。
その時点では、フィッシングページは削除し、ID/Passwordも無事変更。
アップロードした箇所というのは分からないままでしたが、これが関係技術者の調査の限界でした。
(サーバーまるごとdiff取れればよかったんですけど。)
何も起こらず平和が戻った…と思いきや、スパムメールの送信となったわけです。
2. 今回の件のログを見る
今回、スパム発生前後のログを見たところバッチリ残っていたのが、こういうログです。
[Thu Mar 19 22:02:50 2015] [error] [client 46.108.39.193] PHP Notice: Undefined variable: out in /(略)/wp-content/plugins/hello.php on line 1053, referer: http://(略)/wp-content/plugins/hello.php
[Thu Mar 19 22:02:50 2015] [error] [client 46.108.39.193] PHP Stack trace:, referer: http://(略)/wp-content/plugins/hello.php
[Thu Mar 19 22:02:50 2015] [error] [client 46.108.39.193] PHP 1. {main}() /(略)wp-content/plugins/hello.php:0, referer: http://(略)/wp-content/plugins/hello.php
このエラーログの時刻と、sender.phpのタイムスタンプが一致しています。
hello.phpの1053行目には、「ファイルをアップロードした後に通る処理」がありました。
これがなければhello.phpの存在には気づかなかったかもしれません…。
アクセスログの方も見てみると、ありました。
#grep “hello\.php” /var/log/httpd/*
みたいな感じで検索するとポツポツポツポツ。
POSTが何度もされている形跡もありました。震えるしかないですね。
エラーログと、アクセスログから見てもhello.phpを利用してファイルがアップロードされたということになります。
hello.phpのタイムスタンプは、件のフィッシングページが生成された数日前でした。おそらく、フィッシングページもこのページを利用してアップロード、展開されたのだと思います。
正直、ほぉー！と感心してしまったんですが、フィッシングページのタイムスタンプとhello.phpのタイムスタンプの開きはログローテートのデフォルトの保存日数以上をあけて実施していたためフィッシングページのタイムスタンプを基準にログを探しても何も見つからなかったんです。結果、hello.phpの存在に気づくことが出来ませんでした。
気づくことができない理由はいくつかありましたが、クライアント独自のルールや関係技術者のロール・関係性による部分以外は、単純に経験不足・技術不足としか言えなかったです。大反省です。
では、どうやってHelloDollyが書き換えられたんでしょうか。
3. HelloDollyプラグインが書き換えられた原因
蓋をあけてみれば、WordPressのHelloDollyプラグインの書き換えから始まったこの事件。
どうやって書き換えたのか、は、当時のログはすでに残っておらずWordPressのログイン履歴等もプラグインを入れていなかったようなので分からないままです。が、恐らくWordPressの管理画面へのログインIDとPasswordを突き止め、管理画面から悠々と書き換えられたと考えています。
WordPressの管理画面では、パーミッション次第でプラグインの編集ができてしまいます。
WordPressでは、管理画面からのプラグインアップデートを実施するため、「ひとまず全部777」とする方が多いようで、それもまた悪い方に転んだ原因に思います。プラグインアップデートには楽なのですが、一方で管理画面からの編集が容易になるという怖い面もあったわけです。
編集が出来る状態なのは百歩譲っていいとして、なぜ簡単に管理画面にログインされたのか。
今回の件ではWordPressはクライアントさんの管轄下にありました。関連技術者たちは、「きっちり運用されている」と運用者を信じてしまっていたのですが、大間違いでした。聞いてみると安易なIDとPasswordが設定されており、自分でも悪意をもって試せば30回もあればスルーできたと思います。
この時、もっと疑っていれば…と悔しくて仕方ないです。
みなさんのログインIDとPasswordは大丈夫ですか？
オープンソースというのは、誰でもその作りを把握できます。
ログイン画面のURLはデフォルトで、WordPressは/wp-admin/、EC-CUBEなら/admin/なんていうのは一回でも触ったことがある人なら知っているようなことで、自分たちだけの秘密ではないです。そのログイン画面にはアクセスされて当然だと思っておくべきです。(勿論ログイン画面のURL変更をしてあるならひとまず回避はできますね。)
アクセスされて当然のそのログイン画面からその先に進めないように、ユーザーの管理や脆弱性を排除するためのアップデートやメンテナンスといった「ちゃんと運用する」というのが大事だと思います。
IDとPasswordを強固なものにするという簡単で最低限のことも怠った理由はなんでしょうか？
次は「WEB担当者やSEが持つべき最低限のリテラシー」を考えます。