higuchi.com blog

The means justifies the ends

告白 [サーバーを Spam メール送信の踏み台にされました]

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

今回のインシデントのポイントは、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 かもしれません)や、メールの文面らしきファイルや、メールアドレスのリストになっている巨大なテキストファイルが置かれていないか、確認してくださいませ。

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

コメント

石橋秀仁さんのコメント:

そうか、rootじゃなくてもスパム送信の踏み台にされる手口があるのですね、なるほど。

きちんと対処されたうえで情報公開なさるとは素晴らしいと思います。むしろ侵入されつつ気付かない会社のほうが多いのでしょうし。

いわゆる専用レンタルサーバやVPSなどの「root権限付与型(=自己管理型)ホスティングサービス」はネットワーク管理者が必要なわけですが、実際には放置されてそうですね。

対策として、レンタルサーバ業者さんが、ホスティングしてるサーバに対して脆弱性チェック(抜き打ちSaint)をかければいいことですよね。利用規約をそういう風に改定すればいいと思います。

Outbound Port25 Blocking、有害サイトフィルタリングは実現されているわけですし。

(脆弱性検査に留まらず、そのまま侵入して勝手に脆弱性を修正するCode Blueというワームもあったわけですが、あれはやり過ぎでしたね)

樋口 理さんのコメント:

そうなんです。root を取られたのかと思ったのですが、実は nobody だけでスパム送信ぐらいはできちゃうというところがなかなか巧妙。ただの Web ホスティングも油断できません。
気づかずにやられてるケースが結構あるんじゃないかと思います。
2008/10/16 00:51

なべさんのコメント:

久々に見にきたらコメントできそうな記事が・・・。

元ホスティング事業者として、内部告発すると、ほとんどのホスティング事業でWebサーバのOSと周辺アプリに脆弱性が出た場合、対応が難しい状況のはずです。
例えば、ApacheやPHPなどで脆弱性が発見されても、それをアップデートするのにどのくらい労力が必要か・・・。
下手に、勝手にアップデートすると、動かなくなるCGIとか出て来そうなので、やるとすると、周知徹底し、コンテンツに不具合が出てきてもホスティング業者としては一切責任を負わない点を約款でうたっておくか(そんなサービス約款見たことない)、今回のアップデートを承認しますボタンを押させる?

大体、Webサーバの運用を請け負っている案件でも、サーバ管理とコンテンツ屋が別々だと、上記と同じ理由でアップデートなんかできないし、リソースを使う運用予算が割り当てられない場合は、構築したままほおって置かれているサーバがほとんどのはずです。

運用予算が潤沢にあるか、個人で何でも責任取れる規模の両極端じゃないと運用はちょっと危険な状態? サーバがたくさんあるホスティング事業者がアップデートとどうやってやっているのか?気になるところですよね。
2008/11/2 21:41
Host: w133084.ppp.asahi-net.or.jp - 121.1.133.84

レンタルサーバーJPさんのコメント:

最近、自分のメールアドレスから送信してきた迷惑メールが増えています。やり方はサッパリ分かりませんが、何か撃退する方法があるのでしょうか。
2009/1/30 15:13
Host: p185170.doubleroute.jp - 219.119.185.170

コメントを書く

関連するかもしれない記事

みなさん、どうですか? [Gmail Mobileが先週末から使えない件について]

先週末ぐらいから、Gmail MobileのサーバーにアクセスするとInternal Server Errorらしきエラーが出て、...

この記事を読む »

ただより高いモノ [Gmail にプライバシーを期待しちゃいけないよ]

Google 様もそうおっしゃっております。CNETの“グーグル、「Gmail」にプライバシーを期待すべ...

この記事を読む »

くせもの [ビジネス FOMA M1000]

携帯電話を替えました。発表時から気になっていたビジネス FOMA M1000です。 出先でちょっとブラウザ...

この記事を読む »

ルールから確率へ [スパム除けベイジアンフィルター]

私のメールアドレスは、昔からWeb上などに掲示していたため、今では1日200通ぐらいのスパムが送られてき...

この記事を読む »

汎用テキスト分類フィルタの威力 [CRM114 活用事例]

先月導入したベイジアンフィルター式スパムフィルターのCRM114ですが、着々と手になじんで来ました。 ...

この記事を読む »

MacBook Air

軽薄バンザイ [MacBook Air ファーストインプレッション]

手元に届いたみなさんの喜びの声があちこちで聞かれはじめた MacBook Air ですが、私のところにも届いて...

この記事を読む »

How I Leaned to Stop Worrying and Love the Spam [CRM114のインストール]

さて、驚異のスパム分別精度99.98%を誇る、新型ベイジアン=マルコフモデル搭載(笑)スパムフィルターT...

この記事を読む »

私は如何にして心配するのをやめてスパムを愛するようになったか [CRM114の日本語対応]

さて、先日のインストール編に続いて、CRM114の日本語対応改造です。 CRM114のFAQには“BUT if you us...

この記事を読む »

そのメールは本物ですか? [電子メールの偽造]

永田町界隈で、誰かの電子メールのプリントアウトが本物かどうかで大騒ぎをしているようです。そのせい...

この記事を読む »