お客様のクレジットカードデータを収集するためにハッキングされたと思われるサイトで作業していますが、確実ではありません。
私はしませんでした、私はいくつかの記事で示唆見てきた共通の場所で任意の不審なコードを見つけます。
私は疑わしい「壊れた」画像ファイルを見つけました：
/skin/adminhtml/default/default/images/db-tab-bottom-right-bg_bg.gif
ファイル拡張子を変更して彼女を開いたが、それは暗号化されたテキストの壁であり、JPEG-1.1散らばっている。
サイトが侵害されているかどうかを確認するにはどうすればよいですか？
パッチが適用されたことを確認しましたが、パッチの前にハッキングが発生した可能性があります。
編集：影響を受けるバージョンは1.7.0.2です
回答:
質問に対する具体的な回答については、https：//magento.stackexchange.com/a/72700/361を参照してください
第一に、特定のエクスプロイトはありません -現時点でラウンドを行っている一連の記事があり、ソース記事を誤読し誤解しています。
元の記事は、単に言った（と私は言い換えています）
ハッカーが Magentoファイルにアクセスできた場合、ハッカーは顧客から情報を取得できます。
重要な部分は、実際にサーバーにアクセスしてファイルを変更する必要があるハッカーです。
情報のキャプチャに関しては、Magentoに固有のウェブサイト/プラットフォームはありません。ハッカーがファイルにアクセスすると、効果的にゲームオーバーになります。ハッカーは必要な情報をすべてキャプチャできます。
できる最善のこと（そして最終的には最低限行うべきこと）は、支払い処理業界のPCIセキュリティ標準に準拠した適切なセキュリティポリシーを維持することです。リストはhttps://www.pcisecuritystandards.orgにあります。 /documents/Prioritized_Approach_for_PCI_DSS_v3_.pdf
ハッカーの表面攻撃エリアを大幅に削減するストアのファセットを実際にロックダウンすることができます。
ドキュメントルートの権限を制限して、重要なディレクトリ（/varおよび/media）への書き込みのみを許可できます。
これは、デフォルトでMageStackで行うことです。
echo -n "Fixing ownership"
chown -R $SSH_USER:$WEB_GROUP $INSTALL_PATH && echo " ... OK" || echo " ... ERROR"
INSTALL_PATH="/path/to/public_html"
chmod 750 $INSTALL_PATH
find $INSTALL_PATH -type d ! -perm 750 -exec chmod 750 {} \; && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing file permissions"
find $INSTALL_PATH -type f ! -perm 740 -exec chmod 740 {} \; && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing cron permissions"
find $INSTALL_PATH/*/cron.sh -type f ! -perm 750 -exec chmod 750 {} \; && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing media/var file permissions"
chmod -R 760 $INSTALL_PATH/*/media $INSTALL_PATH/*/var && echo " ... OK" || echo " ... ERROR"
echo -n "Fixing media/var directory permissions"
find $INSTALL_PATH/*/media $INSTALL_PATH/*/var -type d ! -perm 770 -exec chmod 770 {} \; && echo " ... OK" || echo " ... ERROR"合わせて調整INSTALL_PATH,SSH_USER,WEB_GROUPします。重要なのは、SSH_USERPHPがWebサーバープロセスに使用するユーザーと同じではないということです。そうでない場合は、基本的にWebサーバーへの完全な書き込みアクセスを提供することになります（利点は軽減されます）。
MageStackでは、これを次のように設定します。 ___general/x.conf
set $magestack_protect_admin true;
set $magestack_protect_downloader true;Nginxでは、これを使用できますが、
location ~* ^/(index.php/)?admin{
satisfy any;
allow x.x.x.x;
auth_basic "Login";
auth_basic_user_file /microcloud/data/domains/x/domains/x/___general/.htpasswd;
deny all;
location ~* \.(php) {
include fastcgi_params;
}
try_files $uri $uri/ /admin/index.php ;
}ここに.htpasswdファイルを準備する方法に関するドキュメントがもう少しあります
cron.shプロセスをラップするcron / admin専用のマシンを使用している他のホスティングプロバイダーに出くわしました。つまり、cron.shファイルを変更すると、cron / adminにアクセスすることなくリモートでコードを実行できるようになります。fakechrootで適切なユーザーでプロセスをラップすると、プロセスをさらにロックダウンすることができます。
投稿するにはあまりにも多くのコードがありますが、ここにはスクリプトがあります。MageStackに固有ですが、エレガントではないサーバー構成での使用に合わせて調整できます。
Linuxは、ログインとタップの点で素晴らしいため、サーバーが何をしているのかを完全に把握できます。
MageStackの素晴らしい機能は、あらゆる種類のアクセスとファイルの変更を毎日記録する監査ツールです。ここでログを見つけることができます、
/microcloud/logs_ro
|-dh[0-9]+
|---access-YYYY-MM-DD.log.gz
|---backup-YYYY-MM-DD.log.gz
|---magescan-YYYY-MM-DD.log.gz
|---php-differential-YYYY-MM-DD.log.gz
|-acc[0-9]+
|---access-YYYY-MM-DD.log.gzMageStackを使用していない場合は、これを簡単に独自のホスティングプロバイダーで複製できます。これrsyncは最も簡単なツールです。
例えば。バックアップがローカルで使用可能な場合は、次のことを実行できます。これにより、2つのディレクトリがドライランで比較され、差分パッチリストが作成されます。
rsync -na /path/to/public_html/ /path/to/backup/public_html/ > change.log
grep -E '\.php$' change.log | while read FILE; do
diff -wp /path/to/public_html/$FILE /path/to/backup/public_html/$FILE >> php-differential.log
donePHPの変更は非常にまれなので、これを毎日（または毎日複数回）実行するようにスケジュールし、PHPファイルの変更があった場合はメールで通知します。
顧客はすべての個人情報を引き渡す際に非常に多くの信頼を置いています。安全なビジネスを運営していないためにその信頼を裏切ると、顧客の習慣と将来のすべての習慣が失われます。
PCIフォレンジック調査は非常に費用がかかり、時間がかかり、最終的には再びカードの支払いを受けることができなくなる可能性があります。自分をそのような立場に置かないでください！
最近、Magentoからリリースされた一連のパッチがありました。これには、リモートコード実行を可能にするものを含む、穴を修正するものがありました。ここから取得できます、https：//www.magentocommerce.com/products/downloads/magento/
しかし、これらの新しい記事は新しいエクスプロイトについて言及しているのではなく、ハッカーがカード所有者情報を取得できるように歴史的なエクスプロイト（またはその他の攻撃ベクトル）をどのように活用しているのかを単に示しています。
ソース
私の他の回答が実際に質問に回答しなかったという理由だけで、別の回答を追加します。
最終的には、できません。際立った指標がある場合がありますが、
例えば。
しかし、コンテンツがプレーンテキストだけではない場合、バイナリファイルのコンテンツをダイジェストしてコンテンツを決定することは特に困難です。
最も一般的には、私が使用してファイルにプレーンテキストデータを書き込む伴わない見てきましたエクスプロイト.jpg|png|gif|etcの拡張、彼らは通常、（例えばデータを難読化するエンコード/暗号化のいくつかの種類を必要とするbase64かmcryptなど）。つまり、単純なgrepは機能しません。
あなたは（そしてこれは決して網羅的ではありません）...
異常に大きいファイルを見つける
find \
/path/to/public_html/skin \
/path/to/public_html/media \
-type f -size +20M 2>/dev/nullCC正規表現に一致するファイルを見つける
grep -lE '([0-9]+\-){3}[0-9]{4}|[0-9]{16}' \
/path/to/public_html/skin \
/path/to/public_html/media 2>/dev/null画像ファイルが有効かどうかを確認します
find \
/path/to/public_html/skin \
/path/to/public_html/media -type f \
-regextype posix-egrep -regex '.*\.(jpg|gif|png|jpeg)' |\
xargs identify 1>/dev/nullまたは
find \
/path/to/public_html/skin \
-name '*' -exec file {} \; | grep -v -o -P '^.+: \w+ image'インストールファイルを比較する最も簡単な方法は、コアをクリーンコピーと比較することです。これはテーマファイルを考慮しませんが、インストール中の数千のファイルをチェックするのに大いに役立ちます。
プロセスは本当に簡単です、
例えば。Magentoバージョン1.7.0.2の場合
wget sys.sonassi.com/mage-install.sh -O mage-install.sh
bash mage-install.sh -d -r 1.7.0.2
tar xvfz latest-magento.tar.gz
diff -w --brief -r magento-ce-*/app/code/core app/code/core
diff -w --brief -r magento-ce-*/lib lib古いMagentoリリースは（面倒なことに）パッチが適用されないため、コアdiffを実行すると変更が表示されることに注意してください。これを回避するには、新しくダウンロードしたクリーンソースにパッチを適用し、その後で再度差分します。
素晴らしい投稿ですが、残念ながらすべてのものが平等に作成されているわけではありません。
共有ホスティングが一般的になると、人々が同じサーバー上の他人のコンテンツを見ることが許可されないことがより重要であると考えられました。FreeBSDが投獄されるまで、これは次のことを意味していました。
これにより、アカウント所有者による（その後の）HTMLファイルの変更が可能になり、同時にWebサーバープロセスとアカウント所有者の両方が同じマシン上の他のユーザーにアクセスできなくなりました。
これはあまり変更されておらず、共有ホスティング向けのソフトウェアパッケージ（CPanel、DirectAdmin、Plex）はすべてこれらの原則を使用しています。これは、エントリのメインポイント（Webサーバーまたはスクリプトインタープリター）がアカウント内の任意のファイルに書き込むことができるため、ファイルのアクセス許可が役に立たないことを意味します。
CCデータが実際にサーバーに送信されるかどうか、また暗号化されていない場合は暗号化されていない場合は、CC支払いプロバイダーに通知してください。JavaScriptは最近非常に強力であり、顧客のJavScriptエンジンを使用してサーバーに送信する前に機密情報を暗号化する支払いサービスプロバイダーが存在します。この情報収集者はセッションキーと暗号化されたデータを取得することができます（したがって、暗号化を解除できます）が、収集されたデータが大きくなり、ボットのAIがはるかに複雑になるため、収集者にとってはあまり興味がありません。
15年以上のunixで、TripWireの生まれ変わりを見ると、懐かしい笑顔が私の顔に残っています。Gitはこれにも適したツールです。サイトのローカルな変更は初期インストールよりも頻繁に行われるため、追加を考慮せず、ここでも優れたツールをgitするため、既知の優れたバージョンと比較すると、やや劣ります。
何らかの形式のHTTP認証をインストールするのと同じくらい簡単に、ダウンローダーをドキュメントルートの外に移動できます。その後、使用するときにのみ元に戻します。それが実用的でない場合は、別のユーザー/パスワードレイヤー、特にパスワードをプレーンテキストで送信するレイヤーではなく、リモートアドレスに基づいてロックダウンすることを好みます。
Webアプリケーションファイアウォールは、すでに攻撃のスキャン段階にある多くの問題を防ぐことができます。残念ながら、これらは高価なブラックボックスですが、いくつかの選択肢があります。
私たちはたくさんのことをカバーしたと思いますが、私のpetpeeveで終わりましょう：
FTPの使用をやめる
そこ。言った。そしてここに行く：https : //wiki.filezilla-project.org/Howto