web-dev-qa-db-ja.com

ハッキングされました。方法を理解したい

誰かが、私が実行を支援するサイトに2回目のJavaScriptのチャンクを追加しました。このjavascriptはGoogle AdSenseを乗っ取り、独自のアカウント番号を挿入し、広告をくまなく貼り付けます。

コードは常に1つの特定のディレクトリ(サードパーティの広告プログラムで使用されるディレクトリ)に常に追加され、この1つの広告ディレクトリ(20程度)内のいくつかのディレクトリにあるファイルの数に影響し、ほぼ同じ夜間に挿入されます時間。 AdSenseアカウントは、中国のウェブサイトに属しています(来月中国に行く予定の場所から1時間ほど離れていない町にあります。たぶん、私はバストヘッドに行く必要があります...冗談です)ところで...ここに情報がありますサイト: http://serversiders.com/fhr.com.cn

では、どうすればこれらのファイルにテキストを追加できますか?ファイルに設定されている権限(755から644の範囲)に関連していますか? Webサーバーユーザーに対して(MediaTempleにあるので、安全である必要がありますか?)?つまり、アクセス許可が777に設定されているファイルがある場合でも、コードを自由に追加することはできません。

ここにあなたの閲覧の喜びのための実際のコードのサンプルがあります(そしてあなたが見ることができるように...それにそれほど多くはありません。本当のトリックはそこにどうやってそれを入れたかです):

<script type="text/javascript"><!--
google_ad_client = "pub-5465156513898836";
/* 728x90_as */
google_ad_slot = "4840387765";
google_ad_width = 728;
google_ad_height = 90;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>

多くの人々がそれを言及しているので、これは私がチェックしたものです(そしてチェックすることで、私は奇妙さのためにファイルが変更されたときに見回し、POSTステートメントのためにファイルをgreppedしましたとディレクトリトラバーサル:

  • access_log(通常の(つまり過度の)msnボットトラフィック以外は何もありません)
  • error_log(何もありませんが、通常のファイルには無害に見えるファイルのエラーは存在しません)
  • ssl_log(通常のもののみ)
  • messages_log(私以外のFTPアクセスはここにはありません)

*更新:** OK、解決しました。中国からのハッカーは私たちのサイトに物理的にファイルを置いていて、あらゆる方法で管理を行うことができました(データベースへのアクセス、ファイルとディレクトリの削除と作成、名前を付けて、アクセス権がありました)。彼らがもっと破壊的なことをしなかったのは幸運だった。通常のApacheログファイルには何もありませんでしたが、Webサーバーのログアナライザーで別のログファイルセットが見つかり、そこに証拠がありました。彼らは自分の管理者ユーザー名とパスワードでこのファイルにアクセスし、サーバー上で必要なものを編集していました。それらのファイルには「Apache」がユーザーとして設定されていますが、サイト上の他のすべてのファイルには別のユーザー名があります。次に、私は彼らがどのようにこのファイルを私たちのシステムに物理的に取得したのかを理解する必要があります。私がこれを非難するのは、実際にはFTPログインがなければ、最終的にはWebホスト(メディアテンプル)にあると思われます。ただし、このファイルはおそらくしばらく存在しているため、どのように判断するかわかりません。

41

まず第一にchmod 744はあなたが望むものではありません。 chmodの目的は、システム上の他のアカウントへのアクセスを取り消すことです。 Chmod 700は、chmod 744よりもはるかに安全です。ただし、Apacheは、phpアプリケーションを実行するために実行ビットのみを必要とします。

chmod 500 -R /your/webroot/

chown www-data:www-data -R /your/webroot/

www-dataは通常、phpの実行に使用されるApacheのアカウントとして使用されます。次のコマンドを実行して、ユーザーアカウントを表示することもできます。

`<?php
print system("whoami");
?>`

FTPは恐ろしく安全ではないので、この方法でハッキングされた可能性が非常に高いです。 FTPを使用すると、ファイルを書き込み可能にして、再度感染させることができます。 FTPアクセスが可能なすべてのマシンで anti-virus を実行していることを確認してください。 FTPのユーザー名とパスワードのローカルトラフィックを盗聴し、ログインしてファイルに感染するウイルスがあります。セキュリティを重視する場合は、すべてを暗号化するSFTPを使用します。クリアテキストでネットワーク経由でソースコードとパスワードを送信することは完全に狂気です。

別の可能性は、古いライブラリまたはアプリケーションを使用していることです。ソフトウェアベンダーのサイトにアクセスして、最新バージョンを実行していることを確認してください。

9
Rook

私のMedia Temple Grid Serverアカウントは、このように何度も「ハッキング」されています。彼らのセキュリティは非常に貧弱です...PLAIN TEXT PASSWORDSで始まり、今日まで続きます(techサポートと彼らは「あなたのパスワードは何ですか?」と言います)。彼らが私のすべてのアカウントパスワードをどのように変更したかについてのメールを毎月受け取り、彼らがハッキングされるたびに実際にアクセスしてデータベースパスワードを変更しているので、私は知っています。その会社は表面上は地獄のように光沢がありますが、グリッドサーバーは混乱しています。 すぐに切り替えることをお勧めします。

この昨年の投稿元の大失敗 (警告、それはあなたを怒らせます)について参照してください。そこから下り坂になった。昨年、家族から離れて感謝祭を送り、私のWebサイトからポルノリンクを削除しました。美しい。

彼らの楽しみを追跡してください ステータスページ :最新のエクスプロイトについてすべてを教えてくれます(もちろん、実際に「エクスプロイトの可能性」があります)。

9
typeoneerror

アクセスログなどのアクティビティの欠如とほぼ同時に発生している事実に基づいて、サーバーを危険にさらし、追加を実行するために何らかのシェルスクリプトが実行されているようです。

Crontabに異常がないか確認しましたか?

ディレクトリとその参照の名前を変更しようとしましたか(シェルスクリプトが壊れる可能性があります)?

2
abarax

適切なアクセス権(およびカーネルサポート)がある場合は、 inotify または dnotify に基づいて監視デーモンを起動して、ファイルへの変更を監視し、(すばやく) "lsof"を使用して、書き込みアクセスでファイルを開いているプロセスを確認します。 strace を使用して監視することもできます。これにより、どの実行可能ファイルが悪用されているかについての手掛かりが得られます。

1
outis

FTP検査ログは、最初に開始する場所です。ログには、すべてではないにしてもほとんどのアクティビティがタイムスタンプとともに含まれている必要があるため、ファイルが変更された時刻がわかっている場合は、FTPアカウントが侵害されているかどうかを判断できます。

次に、そのコードを挿入しているWebサーバー上のスクリプトである可能性があります。共有ホスティングのシナリオでは、cat /web/malicious.com/script.js >> /web/innocent.com/index.php。これは、httpdユーザーが実行しているコマンドやindex.phpファイルもそのユーザーが所有/書き込み可能であるなど、特定の条件下で機能する場合があります。その場合は、スクリプトの挿入に使用されているアカウントを追跡するホスティングプロバイダーが必要です。

1
Salman A

ほとんどのサイトファイルは、Webサーバーで読み取り可能である必要があります。読み取り専用サイトでは、ログのみがWebサーバーによって書き込み可能である必要があります。所有者を、Webサーバーが使用するユーザー以外のユーザーに設定します。スクリプトを除くすべてのファイルに保護640を設定します。スクリプトとディレクトリを設定します。750。Webサーバーが書き込む必要のあるファイルまたはディレクトリの場合、所有者をWebサーバーに変更するか、関連するファイルまたはディレクトリをchmod g + 2に設定できます。

1
BillThor

はい、それは間違いなくファイルのアクセス許可に関連している可能性があります。 Webプロセスによって書き込み可能なファイルを用意することで、実行中のWebアプリケーションにセキュリティの脆弱性が生じます。すべてをロックして、Webプロセスが必要以上に何かを読み書きできないようにします。

他のコンポーネントは、ファイルをどのように変更しているかを正確に追跡します。最初に、Webサーバーのアクセスログを確認することをお勧めします。さまざまなユーザーの最終ログイン時刻を確認します。また、ファイルの変更を監視して通知するスクリプトを設定して、赤い手で犯罪者を捕まえようとすることもできます。

1
Chris AtLee

これは、最近多くのNetwork Solutionsサイトにヒットした Wordpress hacks に非常に馴染み深いようです。 Media Templeを使用しているため、マシンを共有している他のユーザーに一部のファイルが表示されたままになっている可能性があります。 POSTまたはeery Apacheログトレースがないことを説明します。その場合、コマンドラインにコードを挿入するのは非常に簡単です。

1
editor

コードは常に1つの特定のディレクトリに常に追加されます

ファイルに設定されている権限(755から644の範囲)に関連していますか?ウェブサーバーユーザーへ

共有サーバーにいますか?その場合(またはそうでない場合でも)、誰かがFTPパスワードをブルートフォースで強制し、手に入る可能性のあるファイルを追加するスクリプトをアップロードした可能性があります。

サードパーティの広告プログラムで使用されるもの

または、おそらくこのプログラムにはエクスプロイトがあります。

1
webbiedave

サイトをクラックする方法は無数にあります。スクリプトの脆弱性を利用したり、パスワードを盗んだり、共同ホストされたサイトの脆弱性を利用したり(安価なホストにいる場合)、サーバーマシン上のWeb以外のサービスの脆弱性を利用した可能性があります。 。

最初のステップとして、ファイルの変更日を確認し、その時点での疑わしいアクティビティがないか、アクセス、エラー、およびFTPログを確認します。

0
Tgr

しばらく前に同じことが起こりました。 Wordpressは、私の知る限り、このようなことを引き起こしていた唯一のソフトウェアでした。

0
Joe Phillips