[PR] 本ブログの商品紹介リンクには広告が含まれています

実にお恥ずかしい。自分で管理しているサーバーをスパム送信の踏み台にされてしまいました。みだりに公開するようなことではないというご意見の方もいらっしゃるかもしれませんが、以て他山の石、同じ轍を踏む人が少しでも減るように、また、踏んでしまった人の問題解決の糸口になるように、でもお子供たちが安易にいたずらで真似できないように気をつけながら差し障りのない範囲で恥をさらします。

今回のインシデントのポイントは、Web サーバーに普通に置いていたオープンソースの PHP スクリプトの脆弱性をついて、サーバーをスパム送信につかわれてしまったという点。「自分は Web サーバーを借りているだけでメールサーバーは管理していないから関係ないや」と思っている人も、同じ手口でやられるかもしれないというところがミソ。

発覚のきっかけは、ある日突然 “Return to sender” なエラーメールが頻繁に送られてきたことでした。FROM フィールドを偽装して、私のアドレスから送られたように見えるスパムを送信されると、未達などのエラーメールだけが偽装された FROM のアドレス宛に返ってくる、いわゆるバックスキャッター現象が起こるのはよくあるので今回もそれかと思ったのです。念のためエラーメールの中身を覗いてみると、エラーになっているのは案の定どこかのスパマーがブラジルのドメイン宛に一斉送信していると思われるポルトガル語のスパム。ところが、ばらまかれているスパムの FROM は私のメールアドレスにはなっていない様子。返送された元メールのヘッダが記述されているエラーメールをよく見ると、スパムは私がメールサーバーに使っているサーバーの IP アドレスから発信されているように見えます。

さあ、大変。
まず tail -f /var/log/maillog で sendmail のログを確認。まだものすごい勢いでスパムを送信中のようです。
sendmail の設定をなにかのはずみで間違えてしまって、外のスパム送信サーバーからリレーされているのかと思ったのですが、ログには inbound のセッションがない。入ってきているのはエラーメールの戻りだけ。netstat を見てもスパムを送り込む内向きの SMTP のセッションはないように思えます。不正リレーじゃないようです。
エラーメールになった元のメールのヘッダをよく見ると、このサーバーの nobody ユーザーが sendmail を直接動かしているようです。top と ps -Unobody で見ると、なにやら怪しげな perl のプロセスががんがん動いているので、それを kill するとメールの送信が止まりました。ここで一息。宛先不明や Deferred でキューにたまっている送信待ちのメールを /var/spool/mqueue から削除して、誰がどうやって勝手に nobody さんにスパムを送信させていたのかを探った結果、わかったこと。

このメールサーバーは、私のブログなどの Web サーバーとは別のサーバーを借りているのですが、そこに友人などの別ドメインの小さな Web サーバーを又貸しで同居させて使ってもらっています。
その Web サーバーのうちの一つに Nucleus がインストールされていたのですが、それが古くて、組み込まれている XML-RPC for PHP のライブラリが脆弱性のあるバージョンだったのです（Aさん、ごめん。root 権限使って無断でディレクトリの中と Apeche のログをチェックさせてもらいました。緊急だったし、使ってないサイトのようだったから、許しなさい）。
このブラジルのスパマー（IPアドレスがブラジルのものでした）は、XML-RPCの脆弱性をついて、ブログの画像などを保存するために Web サーバーから書き込み可能になっているディレクトリに、“c99 shell” と言われているスクリプトを書き込んだようです。このスクリプトはリモートから nobody 権限でシェル操作できるバックドア（裏口）。そのシェルを使って /tmp に perl で書かれた “Data Cha0s Connect Back Backdoor” という名前の別のバックドアのスクリプトをほかのクラックされたサーバーからダウンロード。ダウンロードしたものを nohup で実行。そのバックドアを使ってこれまた /tmp に、 perl で書かれたメール一斉送信のスクリプトと、スパムの文面と、ブラジルのメールアドレスが大量に詰まった送信先リストをダウンロードしてから、メール一斉送信スクリプトを実行したものと思われます。

侵入の途中でメールのキューが大きくなりすぎてディスクのクォータを超えたために、バックドアがファイル書き込みエラーを起こし、シェルの吐いたエラーのかけらが Apache のエラーログに残っていました。おかげでスクリプトなどをダウンロードした形跡の一部が手に取るようにわかりました。相当数のほかのサイトがバックドアスクリプトやスパム送信リストのファイル置き場にされているようです。侵入からファイル送信までの手順は手慣れていて、その手順の間の HTTP のセッションは User-Agent が libperl-www になっているところを見ると、その手続きも perl で自動化して動かしている模様。たぶん、穴のありそうなサイトを手当たり次第に機械的につついているんでしょう。

というわけで、Nucleus に限らず XML-RPC を使ったプログラムを動かしている Web サーバーの管理者のみなさん。もしまだ脆弱性のある古いバージョンを使っているのなら、すぐにバージョンアップを。

また、まだ古いバージョンを使っている場合はすでに踏み台にされている可能性もあります。Nucleus サイトを攻撃する場合は media ディレクトリに最初のとっかかりのスクリプトをダウンロードする手口を自動化してこなしているようです。media ディレクトリに不審なスクリプトファイルがないかどうかをチェック。もしあった場合は /tmp など、ほかのディレクトリに不審なスクリプト（拡張子は txt かもしれません）や、メールの文面らしきファイルや、メールアドレスのリストになっている巨大なテキストファイルが置かれていないか、確認してくださいませ。

いやはや。ご迷惑をおかけしました。お恥ずかしい。