本番サーバーでosCommerceを使用して構築されたハッキングされたサイトを修正するように依頼されました。
このサイトは常にリモートホスト上に存在していました。オフラインのクリーンバージョンはありません。これがどれほど愚かであるかを少しの間忘れて、それが何であるかを扱いましょう。
これは何度もハッキングされており、別の人がWebシェルファイル/アップロードスクリプトを削除して修正しました。
それは継続的に頻繁にハッキングされます。
私に何ができる?
本番サーバーでosCommerceを使用して構築されたハッキングされたサイトを修正するように依頼されました。
このサイトは常にリモートホスト上に存在していました。オフラインのクリーンバージョンはありません。これがどれほど愚かであるかを少しの間忘れて、それが何であるかを扱いましょう。
これは何度もハッキングされており、別の人がWebシェルファイル/アップロードスクリプトを削除して修正しました。
それは継続的に頻繁にハッキングされます。
私に何ができる?
Web ホストでは何も信頼できないため (ルートキットがインストールされている可能性があります)、最も安全な方法は、新しい Web サーバーを最初から再構築することです。オンラインにする前に、すべての外部向けソフトウェアを更新することを忘れないでください。厳格なファイアウォールのハッピー サイドですべての更新を行います。
システムを再構築するときは、適切な構成に特に注意してください。Web サーバーのユーザー ID とは異なる Unix ユーザーが Web コンテンツを所有しており、ファイルのアクセス許可が書き込みを禁止するように設定されている場合、Web サーバーはプログラム ファイルを変更できません。
Web サーバーの Unix ユーザー アカウントを構成して、ログ ファイルとデータベース ソケット (ファイル システムにある場合) のみに書き込みアクセスできるようにします。ハッキングされた Web サーバーは引き続きハッキングされたページをクライアントに提供できますが、再起動すると「ライブ ハック」が「元に戻されます」。もちろん、あなたのデータベースの内容がヤクザに送られたり、あなたのデータにユニコーンの写真が含まれているべきだと考える人々によって破壊されたりする可能性があります. 最小特権の原則は良いガイドラインになります。Web サーバーがその仕事をするために、正確には何にアクセスする必要があるのでしょうか。それだけを与えてください。
また、 AppArmor、SELinux、TOMOYO、SMACKなどの強制アクセス制御システムの導入も検討してください。これらのシステムはいずれも、適切に構成されていれば、システムがハッキングされたときに損傷または漏洩する可能性のある範囲を制御できます。(私は AppArmor に 10 年間取り組んできましたが、ほとんどのシステム管理者は、1 日か 2 日でシステムに実行可能なセキュリティ ポリシーを展開する方法を習得できると確信しています。すべての状況に適用できるツールはありません。すべての選択について読むことができます。)
2 回目は、 puppet、chefなどのツールを使用して、または少なくともリビジョン管理システムで構成を管理してください。
アップデート
他に、オンラインに戻ることとは少し関係ありませんが、潜在的に教育的なことです。侵害されたシステムからハード ドライブを保存し、それをマウントして、別のシステムからその内容を検査できるようにします。侵害されたデータに対してフォレンジックを行うことで、何かを知ることができるかもしれません。侵害が数か月前に発生し、パスワードやssh
キーが盗まれていたことに気付くかもしれません。ルートキットやさらなるエクスプロイト ツールが見つかる可能性があります。攻撃の原因を示す情報が見つかるかもしれません。おそらく、そのサイトの管理者は、サイトがハッキングされたことにまだ気づいていません。
ハッキングされたデータを調べるときは注意.jpg
してください。最初にシステムをクラックしたエクスプロイトである可能性が非常に高く、「既知の正常な」システムで表示するとクラックされる可能性があることを認識していません。完了したらフォーマットできるハード ドライブを使用して作業を行います。(仮想化または必須のアクセス制御システムは、「受動的な」データベース ハッキングを制限するのに十分かもしれませんが、安心のために使い捨てシステムに勝るものはありません。)
サイトが構築された osCommerce バージョンの新しいコピーを取得し、新しい新しい osCommerce とハッキングされたサイトとの差分を作成します。また、サーバーには存在するが osCommerce パッケージには存在しないファイルも確認してください。
違いを手動で比較することにより、ハッキングによってスクリプトが作成または変更された可能性のあるすべての場所を追跡できます。
このソリューションを提供するのが少し遅れていることは承知していますが、osCommerce 開発による公式の修正はこちらです: http://library.oscommerce.com/confluence/display/OSCOM23/(A)+(SEC)+Administration +ツール+ログイン+更新
これらのコードの変更が適用されると、実際の作業のほとんどは Web サイトのクリーンアップになります。管理者ログイン バイパス エクスプロイトは、攻撃者がファイル マネージャーを介して (通常は) 書き込み可能なディレクトリ (多くの場合はイメージ ディレクトリ) にファイルをアップロードできるようにする原因となります。
悪意のあるコードが追加されている可能性のある書き込み可能なファイルが他にもあります。cookie_usage.php と includes/languages/english/cookie_usage.php は影響を受ける通常のファイルですが、一部のサーバー構成では、すべてのサイト ファイルが影響を受ける可能性があります。
公式の osCommerce 修正は上記にリンクされていますが、この変更も行うことをお勧めします: 上のページで、「Update PHP_SELF Value」というリンクが表示されるまで下にスクロールします。それらの変更も行います。
これにより、$PHP_SELF の報告方法が修正され、攻撃者が不正な形式の URL を使用して管理者ログインをバイパスしようとするのを防ぐことができます。
また、admin ディレクトリに htaccess 基本認証ログインを追加することをお勧めします。
また、私が作成した osC_Sec というアドオンもチェックしてください。これはオールインワンのセキュリティ フィックスです。これは、ほとんどの PHP に基づく Web システムで動作しますが、osCommerce の古いバージョンに存在する問題に対処するように特別に設計されています。 http://addons.oscommerce.com/info/8283