))%20%E3%83%8F%E3%83%83%E3%82%AF%20-%20%E5%86%8D%E7%99%BA%E3%82%92%E9%98%B2%E3%81%90%E3%81%AB%E3%81%AF%E3%81%A9%E3%81%86%E3%81%99%E3%82%8C%E3%81%B0%E3%82%88%E3%81%84%E3%81%A7%E3%81%97%E3%82%87%E3%81%86%E3%81%8B%3F.png)
最近、当社の Web サイトがハッキングされ、次のような PHP コードが index.php ファイルに挿入されました。
eval (gzinflate(base64_decode('s127ezsS/...bA236UA1')));
このコードにより、別の PHP ファイル (cnfg.php) がインクルードされ、医薬品関連のスパムが表示されるようになりました (ただし、Googlebot などにのみ表示されます)。これは、WordPress の医薬品ハックのようですが、このソフトウェアは実行していません。このコードはその後削除されましたが、今後はこのような事態が発生しないようにしたいと思います。
これはかなり広範囲にわたる問題であり、原因となり得るセキュリティホールは無数に存在する可能性があると認識していますが、過去に同様の問題を経験したことがある人がいるかもしれないので、ここに投稿しようと思いました。
これらの PHP ファイルのアップロードを可能にする潜在的なセキュリティ ホールにはどのようなものがありますか? また、今後このような事態が発生しないようにするにはどうすればよいでしょうか?
乾杯
答え1
それがどうやってそこにたどり着いたのか調べる必要があります。
- 攻撃者は sftp/scp 経由でファイルシステムにアクセスできましたか?
- このような事態が発生した場合は、リモートアクセス方法をロックダウンする必要があります。
- 攻撃者は、アップローダー スクリプトを使用したか、または既存のスクリプトのバグを利用してファイルを変更したのでしょうか?
- スクリプトを修正し、スクリプトと Web コンテンツの権限を変更して、Web サーバー プロセスがそれらを変更できないようにします。Web サーバーは、どこかのデータ ディレクトリ内のファイルの変更のみに制限する必要があります。通常、スクリプトとファイルは、Web サーバーによって所有または書き込み可能であってはなりません。
- スクリプトは、インストールした悪意のあるソフトウェアの一部として提供されましたか?
- 私は、WordPress テンプレートの一部としてそのようなものが含まれているのを見たことがあります。何も知らないユーザーが、ランダムなサイトからテンプレートをダウンロードしました。それらのテンプレートには、外部 Web サーバーからコードを実行する機能が含まれていました。これと不適切な権限設定が組み合わさって、攻撃者は他のものを変更することができました。
答え2
ただの警告です。
FTP クライアントとして FileZilla を使用している場合、Filezilla のプレーン テキスト ファイル (ひどすぎる!) から FTP 認証情報を取得し、その情報を使用してマルウェア コード ("gzinflate(base64_decode)" コマンドの周囲の #b58b6f# タイプのコードで示される) を挿入するマルウェアが存在します。これが、ファイルが攻撃/侵害される原因となります。
%APPDATA%/Roaming/Filezilla フォルダを見てください。そこにある XML ファイルの 1 つに、FTP Web サイトの資格情報 (ユーザー名/パスワードなど) がすべてプレーン テキストで含まれています。FileZilla の開発者は、この明らかなセキュリティ ホールを修正することを拒否しています。
私の推奨事項: コンピューターから FileZilla を削除します (APPDATA フォルダー内のフォルダーを手動で削除する必要があります)。
安全な FTP クライアントが必要な場合は、WinSCP (www.winscp.net) を使用してください。WinSCP ではマスター パスワードを設定でき、サイトの資格情報はすべて暗号化されます。
ただの警告です...リック...J
答え3
侵入経路にはさまざまな可能性があります。これを絞り込むのに役立つ情報の1つは、ホスティングの種類(共有、専用、仮想)とホストが誰であるかです。侵入経路として考えられるものには次のようなものがあります。
- 管理者アカウントの侵害
- 妥協のあなたのプロバイダーに ftp/ssh/Web コンソールなどのアカウントを設定してください。暗号化されていないプロトコル (FTP など) 経由でパスワードを送信する場合は、それをやめてください。
- 妥協のあなたのローカル開発マシンを所有する
- Apache やそのモジュールなど、サーバー上のサーバー ソフトウェアに脆弱性がある。
サイトの PHP におけるアプリケーション レベルの脆弱性:
- サードパーティのソフトウェアを使用していますか? 使用している場合、すべて最新ですか?
- サイトでかなりの量の独自のプログラミングを記述しましたか? そうであれば、穴をあける方法は 100 万通りあります。ユーザー入力からのデータ (REQUEST/GET/POST/COOKIES/FILES) に触れるメソッドをすべてチェックしてください。ファイルのアップロードを許可している場合、それらのファイルをフィルター処理せずに Web 表示可能なディレクトリに保存していますか? そうであれば、誰かが .php スクリプトをアップロードして、それを表示することができます。次のようなテンプレート ソリューションを使用している場合、include/require ステートメントは特にホット ターゲットになります。
<?php include $_GET['page'] . '.php'; ?>
再発を防ぐにはどうすればいいでしょうか?
- ホストのセキュリティを絶対に信頼できるかどうかを確認してください。ホストに電話して、セキュリティ ポリシーや、脆弱性が明らかになったときにサービスにパッチを適用する速度などについて質問してください。
- 安価な共有ホスティングはやめて、専用または仮想専用ホスティングにお金をかけましょう。サーバーを使用する人が減れば、攻撃されるベクトルも減ります。
- 独自のサードパーティ アプリケーション/ライブラリを最新の状態に維持します。メーリング リスト、RSS フィードなどに登録して、リリースの最新情報を入手します。
- 自分のコードを監査します。これに十分な経験がない場合は、報酬を支払ってくれる人を探してください。
- サイトを git や subversion などのバージョン管理下に置いてください。運用ディレクトリを作業コピーとして保持しておくと、コード ベースの変更を簡単に検出できます (ただし、.git や .svn ディレクトリなどのメタデータへのアクセスは必ずブロックしてください)。
答え4
試してみるといいかもしれませんhttp://www.hardened-php.net/suhosin/これにより、eval() が無効になる可能性があります。cnfg.php がリモートでホストされていた場合、cnfg.php が組み込まれるのを防ぐこともできます。
可能であれば、Web サーバーを実行しているユーザーに PHP ファイルへの書き込みアクセス権を付与しないでください。