Nginx、PHP5-FPM、MariaDBを実行するDebian 7 VPSがあります。このサーバーは、いくつかのWordPressインストール、phpMyAdminおよびRoundcube Webmailを実行します。 1つはWP 3.9.1を実行している私の個人ブログで、もう1つは開発目的で最新のWPトランクバージョン4.0-beta1を実行しています。
SSHアクセスとwp-adminアクセスを持っているのは私だけです。 SSH経由のrootログインは無効になっているため、パスワードを使用してログインしています。
今日、_/tmp
_内に次のファイルが見つかりました。
_# ls -l /tmp
total 8
-rw------- 1 www-data www-data 1551 Jul 9 03:22 php9Lg8Js
-rw------- 1 www-data www-data 1551 Jul 9 03:23 phpQNsW36
_
ファイルのstat
出力
_# stat /tmp/phpQNsW36
File: `/tmp/phpQNsW36'
Size: 1551 Blocks: 8 IO Block: 4096 regular file
Device: ca01h/51713d Inode: 337356 Links: 1
Access: (0600/-rw-------) Uid: ( 33/www-data) Gid: ( 33/www-data)
Access: 2014-07-09 03:23:03.000000000 +0530
Modify: 2014-07-09 03:23:03.000000000 +0530
Change: 2014-07-09 03:23:03.000000000 +0530
Birth: -
# stat /tmp/php9Lg8Js
File: `/tmp/php9Lg8Js'
Size: 1551 Blocks: 8 IO Block: 4096 regular file
Device: ca01h/51713d Inode: 337355 Links: 1
Access: (0600/-rw-------) Uid: ( 33/www-data) Gid: ( 33/www-data)
Access: 2014-07-09 03:22:27.000000000 +0530
Modify: 2014-07-09 03:22:27.000000000 +0530
Change: 2014-07-09 03:22:27.000000000 +0530
Birth: -
_
これらのファイルには両方とも、同じbase64エンコードされたPHPコードが含まれています。私はeval()
をprint()
に置き換えて、PHPシェルコードが2つのGmailアドレスに_HTTP_Host
_と_REQUEST_URI
_を電子メールで送信するものであることを見つけましたまた、攻撃者がシェルコマンドを実行してファイルをアップロードするための入力ボックスを印刷します。
分析に必要で、許可されている場合は、ここにこのコードを投稿できます。
タイムスタンプに基づいてNginxアクセスログを検索すると、次のPOSTリクエストしか見つかりませんでした。
_121.97.137.10 - - [09/Jul/2014:03:22:27 +0530] "POST /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form&cid=20&6bc427c8a7981f4fe1f5ac65c1246b5f=cf6dd3cf1923c950586d0dd595c8e20b HTTP/1.1" 499 0 "-" "BOT/0.1 (BOT for JCE)"
121.97.137.10 - - [09/Jul/2014:03:23:03 +0530] "POST /index.php?option=com_jce&task=plugin&plugin=imgmanager&file=imgmanager&method=form&cid=20&6bc427c8a7981f4fe1f5ac65c1246b5f=cf6dd3cf1923c950586d0dd595c8e20b HTTP/1.1" 499 0 "-" "BOT/0.1 (BOT for JCE)"
_
このサーバーはJoomlaを実行しません
私の理解では、BOTはJCEのエクスプロイトを使用してJoomlaインストールのWebをランダムにスキャンしていました。一部のファイルコンテンツをPOSTして要求を閉じました(Nginxステータス499-クライアントが要求を閉じました)。要求が完了しなかったため、このPOSTされたコンテンツは_tmp_name
_ディレクトリに_/tmp
_で終了しました。
これは正しいです?
これが失敗した試みかそれ以上のものかどうかを確認するために他に何をチェックする必要がありますか?
さらに情報が必要な場合はお知らせください。
あなたの評価は正しいようです。もちろん、サーバーが危険にさらされていないと言うことは不可能ですが、デフォルトではPHPはスクリプトを実行する前にすべてのデータを受信するため、ファイルのアップロードを/ tmpに書き込み、それを提供します実行中のスクリプトのファイル名。
/tmp
がatime
を有効にしてマウントされている場合、atime
== mtime
は安心です。攻撃者がアップロード後にこれらのスクリプトを実行する方法を見つけた場合(LFIの脆弱性など)、atime
が変更されるため、更新されていないという事実は、それらが実行されなかったことを示します(ここでも、 atime
サポートが/tmp
で有効になっている場合)。
PhpMyAdminの実行について何か言いましたか?そのディレクトリは標準であるか、公開されていますか? (パスワードを誰も持っていないとしても)。
phpMyAdminは通常、Webサーバーおよびデータベースサーバーに対する攻撃経路であり、その存在は自動クローラーで広く検索されています。
サーバーは危険にさらされていますか? Davidが言ったように、それがそうであったかどうかはわかりませんが、適切な構成では、nginxを実行しているユーザーは本当に必要以上のアクセス権を持っているべきではありません( 最小特権の原則 ) 、およびそれに応じて権限が設定されている必要があります。これには、サーバーが任意のPHPコードを実行した場合の損害がほとんど含まれます。
おそらく、設定ファイルに設定されたパスワードを危険にさらしたと見なしたいと思うでしょう。
タイムスタンプは簡単に変更できます。それらはおそらく良い指標ですが、あまり頼りにしないでください。常に完全にログを検索してください。