web-dev-qa-db-ja.com

クリプトマイニングマルウェア-Ubuntu-Stratum TCP

私のLAMPサーバーは、ある種の暗号化マイニングマルウェアに見舞われました。 Crontabは明確で使用されていないため、Clamは何も検出できません。

これらのファイルは、一日のランダムな時間に/ tmpフォルダーに自動的に作成されるようです。

  • phpIij8W8.c
  • phpIij8W8_fkk2qr2rqjikiewz（削除後は常にランダムな名前になります）

このphpIij8W8_fkk2qr2rqjikiewzの内部：

threads = 1
mine = stratum+tcp://44XNuUyCFUgjG23yPfCHp(cut for content...etc):[email protected]:3333/xmr

それらはすべて「php」で始まるので、ある種のPHPスクリプトがこれらのファイルをtmpフォルダに自動的に作成して実行するサーバー上にあると想定しています。

INotifyを使用して、これらがどのように作成されたのかを特定しようとしましたが、私が判断できたのはこれだけです。

ファイルphpvlnebP_fkk2qr2rqjikiewzがMOVED_TOによって作成されました

これらのランダムファイルを作成しているスクリプトを絞り込むためのヒントを誰かに教えてもらえますか？または、ファイルが作成/アクセスされたときにiNotifyに詳細情報を提供する方法がある場合。または、一体、この問題を診断するためのより良いツールがある場合。

Ubuntu 16.04.3

malwarelinuxubuntu
6
Taurian

私も同じ問題を抱えていて、絞り込んだところ、ハッカーはアップグレードされていない古いワードプレスに侵入することができました。

おそらく誰があなたのUbuntu 16.04.3サーバーでどれだけの時間を消費しているかを確認するための最良かつ最も速い方法は、htopをインストールすることです

Sudo apt install htop

次にSudo htopと入力します

どのユーザー名がどのくらいのCP​​Uを消費しているかが表示されます enter image description here

CPUを多く消費しているプロセスを特定した場合は、lsof -p <pid>で確認できます。

lsofは、開いているファイルのリストを表します。コマンドの完全なセットを確認するには、man lsofと入力します。

しかし、それはすべて、あなたのPHPがどのように実行されているか、そしてハッカーがあなたのシステムに対して実際に何をしたかによって異なります。

Apacheが正確に行っていることを確認するもう1つの良い方法は、mod_statusを有効にすることです

通常、新しいubuntuでは次のようになります。

Sudo a2enmod status

その後、これを000-default.conf Webサイトに追加します。

<Location /server-status>
    SetHandler server-status
    Require ip 127.0.0.1
    Require ip ::1
    Require ip X.X.X.X
</Location>

Xを実際のIPに置き換えます...

または、たとえばサーバーのコンソールからlyncでそれにアクセスできます

lynx 127.0.0.1/server-status

出力は次のようになります。 enter image description here

私の他の投稿 https://security.stackexchange.com/questions/172396/some-bot-keeps-posting-this-to-my-server/172571 あなたはセキュリティを向上させる方法を見ることができますあなたのサーバーとそのような攻撃を防ぎます。

2
Aleksandar Pavić

明確にするために、ここでの最善の策は 軌道からそれをnuke することです。おそらく、どこかにアプリケーションのコピーと、データベースのコピーがあります。本当にそれを理解したい場合は、おそらく侵入ベクトルが1つまたは2つあるという観点から始める必要があります。

  1. あなたのウェブアプリケーション
  2. あなたのシステム

私は乱暴に推測していますが、PHP削除し続けるファイルは実際のマルウェアではなく、マルウェアの副産物であることに安全な賭けのようです。私は知っています。あなたはこれを知っていますが、明確にするために、あなたはマルウェアを取り除くために何もしていません、それの症状だけです。マルウェア自体の発見と除去は、それがあなたのウェブアプリケーションにあるか、あなたのシステムにあるかによって大きく異なります。 。削除し続けるファイルの所有者は誰ですか？それがWebサーバーを実行しているユーザーである場合、感染はおそらくWebアプリケーションにあります。そうであれば、役立つ可能性のある詳細を以下に示します。

Webアプリケーション侵入

  1. 一時ディレクトリにペイロードが作成されるタイミングがわかります。 HTTPログに、その期間に関連する疑わしい検索リクエストがないかどうかを確認します。侵入ベクトルがWebアプリケーションである場合、ペイロードの実行をトリガーしているC＆CサーバーからHTTPサーバーを介して着信する呼び出しが存在する可能性があります。
  2. サードパーティソフトウェア（ワードプレスなど）を展開していることを前提として、ソフトウェアアプリケーションをすぐに最新バージョンに更新します。
  3. Webユーザーは、Webアプリケーションが存在するフォルダーへの書き込みアクセス権を持っていますか？もしそうなら、あなたはSOLです。 Webアプリケーションを介して侵入した場合、これは、リモートコード実行の脆弱性を発見したことを意味します。アプリケーションディレクトリへの書き込みアクセス権があれば、アプリケーション内のどこにでもバックドアをインストールできます。古いバックアップがあり、コードベースに悪意のあるものが何も追加されていないことを確認できる場合を除き（これは大きな苦痛です）、最善の策はNUKE IT FROM ORBIT
  4. 逆に、パッチが適用されていないオープンな脆弱性があり、システム自体が変更されていない可能性があります（WebサーバーにWebアプリケーションへの書き込みアクセス権がない場合）。この場合、C＆Cサーバーがセキュリティの脆弱性を再利用し続けるため、ペイロードは戻り続けます。その意味で、セキュリティの問題にパッチを当てれば、問題はなくなるでしょう。 Webアプリケーションのすべての部分を確認してアップグレードします。これが自社開発のアプリケーションである場合は、SOLである可能性が非常に高くなります。自分の脆弱性を見つけて閉じることができない場合、軌道から外すと、元に戻せなくなる可能性があります。この場合は、サーバーログ。ログに最初の侵入の証拠が見つかれば、脆弱性を見つけてパッチを適用するのに役立ちます。

システム侵入

これはおそらくそれほど可能性は低いですが、システム自体が危険にさらされている可能性があります（安全でないサービス、クラッキング可能なSSHパスワードなど）。多くのログを掘り下げることなく、システム自体が弱点であったかどうかを確実に判断するのは難しい場合があります。おそらく、Webアプリケーションが問題であると判断する方がはるかに簡単です（私自身の経験から、とにかく原因となっているのはおそらくWebアプリケーションです）。どちらの方法でも、それがWebアプリケーションであるかどうかを確実に判断できない場合は、システムが唯一の原因です。

答え

いずれにせよ、問題はどこで問題が始まったのかを確実に判断することが非常に難しくなり、問題が解決したかどうかを判断することがさらに困難になることです。クリプトマイナーが自分自身を配置するのをやめても、より静かで悪意のあるプロセスが他の場所に隠れていないことは、どのように保証されますか？データベースをこすり落とし、リモートのC＆Cサーバーに送信するバックグラウンドプロセスは、週に1回ですか？これは、システムにログインしたユーザーの個人情報が漏洩するための優れた方法です。自分のパスワードとアカウントの資格情報に対する脅威は言うまでもありません。これが、侵入がどこで始まったかに関係なく、答えが1つしかない理由です。

  1. 軌道からそれを攻撃する
  2. すべてのベストプラクティス（最低限のサービス、適切なファイアウォール、すべてが完全にパッチされている）に従って新しいサーバーを起動する
  3. すべてのサービスにすべての新しいパスワードを使用します。
  4. クリーンであることがわかっているであるアプリケーションのコピーを見つけます。サードパーティのソフトウェアを使用している場合は、アップグレードしてパッチを適用してください。
  5. データベースの最新のコピーから復元します。管理者アクセス権を持つ余分な「ユーザー」がいないことを確認し、すべての管理者パスワードを変更します
  6. 新しいデータベースに、自分以外のトリガーや手順がないことを確認してください。
  7. このアプリケーションが自社開発のシステムである場合は、システムに障害がないことを確実に知らない限り、セキュリティトレーニングと書き換えに多額の投資をするときです。
1
Conor Mancone

私のサーバーの1つはどういうわけか1つのデータセンターでそれをキャッチできましたが、同じソフトウェアを実行している他の2つのサーバーはそれぞれ異なるプロバイダーでホストされていたため、感染しませんでした。最大限に。

答えを探した後、私はこのボードに出くわしましたNUKE IT OUT OF ORBITアプローチは好きですが、何時間も多くのアプローチを試した後、解決策を見つけたかもしれません。

概要は次のとおりです。

既存のプロセスが起動しないようにする場合は、実行可能ファイルを削除する必要があります。正確ではありません。感染に対処しているため、プロセスは数ミリ秒後に戻ってきました。実行可能ファイルを削除した後、それらは戻ってきました-C＆Cサーバーに送信されるSSH接続をなんとかキャッチし、実験用マシンにログオンすると、後でここに投稿されます。次のステップでは、起動しないようにしました。すべての実行可能ファイルを見つけて削除するのではなく、それらの権限をnobody：nobodyと444に設定しました（これよりも低く設定できるコンテンツを引き続き確認したいと思います）。これにより、悪意のあるプログラムが使用するファイルの名前が占有されるため、SSH接続でファイルの内容を置き換えることができず、ファイルを実行できなくなり、役に立たなくなります。これは、プロセスが自動的に開始されないように停止し、リモートコード実行を許可し、実行可能ファイルを効果的に隔離するために機能するようです。

これはパッチによる解決策であり、問​​題を修正するための対策ではないことに注意してください。コミットが（gitで）コードログを確認し、最初にペイロードがどのようにそこに入ったかがわかるまで、しばらくの間ログファイルを確認します。

CentOS7

手順：

install htop:
#: Sudo yum install htop

#: htop

CPU％で並べ替え、99％または100％を消費しているプロセスの名前をメモします。

実行可能ファイルを見つけます：

#: Sudo find / -type f -iname "[FILENAME]"

[FILENAME]をhtopから取得した名前に置き換えます

#: Sudo chown nobody:nobody /path/to/[FILENAME]
#: Sudo chmod 0444 /path/to/[FILENAME]

現在実行中の実行可能ファイルをシャットダウンします

#: Sudo htop

プロセスを見つけて選択し、「K」キーを押してプロセスを強制終了します。この時点では、戻らないはずです。新しいプロセスがポップアップした場合は、上記の手順を繰り返します。

多分誰かが自動的にそれをするshスクリプトを書く時間があるでしょう。

[更新：]ユーザーApacheのCRONジョブにも注意してください-ペイロードをダウンロードするために15分ごとに実行されます。

0
Shib