先日に、Joomlaを利用する顧客サイトにスパム系クラッカーがマルウェアを撒いたためその駆除を行ったことを書きました。非常によく読まれています。これほど世の中にスパムが溢れている訳で、多くの無用心なサイトにその手のマルウェアは埋め込まれている訳です。が、そういう事柄を情報共有のため公表している業者はまだ少ない様子…。
 
tankかような有害事象が起こった際に、システム管理者としていくつか取るべき戦術がありますが、もっとも典型的な、Linuxシステム横断的な作業をここにメモとしてまとめておきます。事実、私の作業の半分はこれでした。下記にまとめてみました。
 
1) 直近メールログからスクリプト経由での送信メール数をチェック
 
 単純に以下のコマンドでチェックをかけましょう。弊社サーバーはメーラーにeximを使っていますので、リアルタイムのログファイルは「exim_mainlog」になりますね。「/home」以下に顧客の皆さんのディレクトリが連なっております。
 
cat /var/log/exim_mainlog | grep cwd=\/home\/ | cut -d' ' -f3 | sort -n | uniq -c
 
すいません、単純で。私はUnixハッカーではないのでこのレベルのコマンドです(笑)。
 
すると、戻ってくるのがこういうアウトプット:
 
2 cwd=/home/顧客a/public_html
1 cwd=/home/顧客b/public_html/cgi-bin
3 cwd=/home/顧客c/public_html
3288 cwd=/home/顧客c/public_html/tmp/install_4ee1a0cd1f7a8/modules/
 
上記ディレクトリをチェックすれば、条件確率的に言えば、「スクリプト経由 | 異常な本数のメール」がどのディレクトリから起動しているかが分かります。例えば、顧客bは「cgi-bin」から1本送信している。たいてい、こういうのは単純なメールフォームの起動によるもの。念のため、cgiに穴がないか確認を。

で、顧客cが変なディレクトリから…3288本の送信メール!?たった1日でこれか!確実にスパム送信に利用されたマルウェアの仕業です、これは。発信ディレクトリを見ると、Joomlaの中の/tmpの中の/installだなんて、いかにも通常はそんなところから発信されないという場所から送信されている。これで、場所が発見されました。

そのディレクトリに出向いて、当該ファイルを削除すればOK。…でしょうか?否!クラッキングされた後に、少数のマルウェアだけが仕込まれるというのは最近では稀です。必ず、他の場所にも散乱して埋め込まれているはず。故に、次の作業が必須となります。
 
2) 最近変更を加えた/新しく作成されたファイルを抽出する

コマンドは単純にこれでいきます。Unix系は、find、grep、cat,それに|(パイプ)の組合せで何でもできますよね、本当に。

find `pwd` -type f -mtime -2 | grep -v cache

こいつを、上記1)で発見されたユーザー顧客cのウェブディレクトリで発動させます。特にシステム横断でかける必要はないでしょう。rootkitではないですから、あくまでもpublic_htmlからこっちの話です。顧客cと顧客fが数千もの送信メールをしていれば、その2ディレクトリ直下でかけましょう。

結果はこんな感じで出ます:

/home/顧客c/public_html/tmp/install_4ee1a0cd1f7a8/modules/mod_popular/index.php
/home/顧客c/public_html/templates/bluestork/css/blog.php

引っかかったphpファイルをエディターで開いてみて下さい。いかにもBase 64でエンコードされた書式が出ます。ついでに言うと、そこで見つかるphpファイルのいくつかは、無害なHTMLファイルのできそこない。が、それはフェイクの可能性もありますし、他のphpマルウェアと組合わせてスパムが発動する場合も。油断できないため、全部削除です。
 
3) Joomlaのphpファイルを読むときのポイント

まずもって、下記の2行が入っていないJoomlaディレクトリ内のphpファイルは怪しい:

// no direct access
defined('_JEXEC') or die;

基本的に全てのphpファイルたちは、Joomlaからコールされることを前提としたものなので、外部から読まれると「自分からdieせよ」という約束事を守らされている。これがないということは、Joomlaとは無関係の外部から、例えばクラッカーが呼び出すことが可能ということですね。

例外として、「css」の情報のみで埋まっているタイプのphpファイルはOK。これらのファイルは、ファイル名がいかにもキャッシュで吐き出したような長い数字の羅列できているし、中身を見ればすぐに分かるので。

それと、前の前のブログ(サーバーとOSは堅牢…でもJoomlaサイトがクラッキング?)に書いた「cb6f82f3e40」のBase64で始まるマルウェアの細かい内容分析を見つけましたので、英語ですが、ここに。http://forums.whirlpool.net.au/archive/2072084
 
4) 抽出された数百のファイルを削除する

恐らく100個前後ぐらいが抽出されるのではないでしょうか。それをエディタである程度確認して、後に「rm」コマンドで削除する訳ですが、100個全部をいちいちマニュアルで…なんて狂気の沙汰は不必要ですね。上記の出力結果をそのまま(安全な最近更新ファイルはむろん除く)コピペして、例えば「file_list.txt」というテキストファイルを作り、そのファイルを入力として受けてrmする単純なスクリプトを書きます。

こんな感じの:

#!/bin/sh

while IFS= read -r file
do
rm -- "$file"
done < file_list.txt

上記は、どこかのUnix系質問サイトで見つけたものなんですが、すいません、ソースを忘れてしまいました…。プログラマーさん多謝です。こいつを「rm-list」とでも名づけましょう。実行権限を与えて起動します:

rm-list file_list.txt

これで、一気に数百のマルウェアが滅びます。
 
5) 事後処理~予防的措置
 
- これは前回(Joomlaサイトにおけるセキュリティチェック)・前々回(サーバーとOSは堅牢…でもJoomlaサイトがクラッキング?)のブログ記事にも書いたが、全てのソフトウェアを最新に(特にコンポーネントなどのエクステンションは最新に!)

- Joomlaのadmin、cPanelなどの管理パネルを利用していればそちらも変更する(上記のようなクラッキングは全自動で行われることがほとんどだが、念のためやはり)

- Joomlaサイトをクラッキングからプロテクトするエクステンションを導入する(…主にSQLインジェクションLFI/ローカル・ファイル・インクルージョン方面を防御するものを)

- error_logを頻繁にチェックする

Apacheは「public_html」直下にこの名前のログファイルを形成し、php関連エラーも全てここに書き出されます。まぁ、よほど暇でないと、頻繁にこのファイルを開けて観察することはないでしょう。が、ちょっとおかしいな、と思ったときにそのエビデンスを求めるのはやはりログファイルなので、チェック。

ちなみに、サーバー管理者(ホスティング会社)がどのようにPHPの行動を制御しているのかも、このログファイルを読めば分かりますね。例えば、「Warning: ini_set() has been disabled for security reason」というものでみっちり埋まったファイルはすぐに容量がぱんぱん。きついめのセキュリティを好む管理者は、この関数を嫌います。なんてことも判明。

こんなところでしょうか。さらに堅牢なサーバー管理を目指しましょう!
 
ブログトップへ
「security audits」と言います。

よく使われる0-1024までのportは無論のこと、そこに脆弱性の多い1500以上のportをチェック。
それだけならただの「free port scan」なので、PC向け。

で、「standard」テストの場合、実に32,169の脆弱性についてテストしてくれます。
実際、わずか直近の30日間の間に709 new tests in the last 30 days

加えて嬉しいのが、DOS(Denial of Service)テストまで付加すること。これは、ご存知のようにサーバーに高負荷をかけるため、外すことも。

無料なのだが、ポイントは「サーフできるportからし
/span

 blog update calendar

August 2018
MoTuWeThFrSaSu
303112345
6789101112
13141516171819
20212223242526
272829303112