1つのブラウザーゲームをハッキングした歴史。 戻り制御

良い一日。 Webアプリケーションのセキュリティ監査に従事しています。 Webサイトの簡単な侵入テスト。 私の実務には時々、そのような記事の形で説明したい興味深い有益なケースがありますが、めったに（私にとってこれは最初のケースです）クライアントがすべての問題と取られた行動の詳細な説明を伴うそのような資料の出版を許可する状況はめったにありません。 当然、ここでは特定の名前や顧客企業の名前などは見つかりません。そのようなデータについては、おそらく誰も許可しないでしょう。 親愛なる読者の皆さんにとって、この記事が興味深く有用であることを願っています。

まえがき

最初の状況は次のとおりでした。 比較的高いオンラインで1つのブラウザゲームを開発しました。 このプロジェクトは、実質的なお金のために仮想物を購入するプレーヤーによって収益化されました。 ある晴れた日、ハッカーがプレイヤーの中に現れ、ゲームエンジンにいくつかの脆弱性を発見した後、さまざまな方法でゲームのバランスを崩し始めました。 彼は家と他のプレイヤーの両方でお金を増やし、皆のためのゲーム体験を増やし、珍しいゲームアイテムを生み出しました。 当然、ユーザーからの支払いはほとんどすぐに無駄になりました。 何かを無料で提供しているのに、なぜ何かを支払うのですか？ 開発者はこれに対処しようとし、コードの「すべての脆弱性」を排除するために200ドルで引き受けた人を雇いましたが、結果はありませんでした。 攻撃者がデータベースダンプ+ゲームのすべてのソースコードをリークし、1つのパブリックフォーラムに投稿したとき、彼らの忍耐はついに破裂しました。 そして、ハッカーとの戦いの過程で以前にゲームが何らかの形で開発されていた場合、これを行うことは単に不可能でした-改善または新しいモジュールはすぐにネットワークに漏洩する可能性があります。

初期検査

ゲームは、ホストされた管理でDebianを実行するVPSに基づいていました。 後者からは、サーバー自体に加えて、コントロールパネルとPhpMyAdminもありました。

内部ソフトウェアの構成は、ハッキングに非常に役立ちました。 PHPのセットアップでは、外部ファイル（allow_url_fopen / include）のオープンと接続の両方が許可されていましたが、ゲームを動作させるためにどちらも必要ではありませんでした。 セーフモード（safe_mode）が無効になっています。open_basedirオプションは設定されていません。 system（）、exec（）など、システムコマンドの実行を保証する機能は、disable_functionsを使用して禁止されていませんでした。 エラー出力はオンになりましたが、ログに問題はありませんでした。

Webサーバー（Apache）に関しては、ゲームに関連するいくつかのサブドメイン（フォーラム、テストサイトなど）がその制御下で回転していました。 PHPを使用するWebサーバーはFastCGIモードで実行されていましたが、セキュリティの観点からの主な切り札（所有者の権利でスクリプトを実行する）は単純な要因によって無効にされました-同じユーザーがすべてのサブドメインのコンテンツの所有者でした。 この時点で、脆弱性はゲーム自体のエンジンにある必要はなく、周辺ドメインにも存在する可能性があることが明らかになりました。

MySQLでは、状況は似ていました。 各サブドメインには独自のデータベースがあり、スクリプトを使用した作業は同じユーザーを経由しました。

外部からサーバーへのアクセスは、SSHとFTPを介して行われました。 そして、最初のことについて何も悪いことを言えない場合、FTPの場合、状況は完全に異なっていました。 FTPにアクセスすると、ユーザーはすぐにすべてのサブドメインのコンテンツにアクセスできます。 さらに、ここでは、FTPのルートに、データベースバックアップのあるフォルダーがありました。 彼らはすべてユーザーパスワードまで持っていました。 FTPログを含むアーカイブもありました。 多くの人が推測しているように、これらすべての問題は、ログインとパスワードがSSH、FTP、MySQLで同じであったことです。

よく知った後、別の良い瞬間が浮上しました。 ゲームエンジンは、バージョン管理システムを使用せずに開発されました。 すべてが「ライブ」で修正され、ファイルのバックアップコピーを作成する必要がある場合は、script_name111111111.phpのようなFTP上で直接呼び出し、その後、新しいscript_name.phpをダウンロードしました。 エンジンでの作業はかなり前から行われており、そのような「ロールバック」ファイルは多数ありました。 それらの存在により、攻撃者がダウンロードできるWebシェルやその他のバックドアの検索が非常に複雑になりました。 また、ソースコードに脆弱性が存在するかどうかを分析することは不可能でした。 一般的に、状況を修正することが急務でした。

ナンバーワンを試みる

私がそう言うことができるなら、私たちのために働いた1つのハンディキャップに言及する必要があります。 開発者が私に目を向ける頃には、ゲームの開発は実質的に停止し、プレイヤーの数は減り、クラッカー自身はそれに座って退屈していました。 彼は1日1回入り、約1時間かけてあらゆる種類の通信を行い、去りました。 開発者が行動を始めたときだけ、彼は積極的に振る舞い始めました-いくつかのアドオンを導入したり、アカウントをブロックしたりしました。つまり、サーバーソフトウェアに目立った変更を加え始めるまでは安全でした。そしてゲームでは、クラッカー自身は動き始めません。

これに基づいて、保護に関する変更を認識した後、攻撃者がそれらに影響を与えないように行動する必要がありました。 したがって、まず第一に、その影響範囲の最大の削減を取り上げました。

まず、IPアドレスを介してすべての重要なサービス（VPS、PMA、SSH、FTP、MySQL）への外部アクセスを制限することが決定されました。 さらに、サブドメインごとにシステム内にユーザーが作成され、すべてのコンテンツが対応するホームディレクトリに移動されました。 データベースでも同じことを行いました。 攻撃者は1つのサイトを制御できずに、他のサイトに何らかの影響を与えることができなくなりました。

私はほとんど忘れていました。 私たちは、それらが存在するすべてのディレクトリから777の権利を削除しました。 サイトは互いに完全に分離されています。

次に、PHPの構成を修正しました。 OSコマンドを起動する機能、およびURLでファイルを接続して読み取る機能は禁止されています。 ファイル（error_log）にエントリを含めることにより、エラー出力が無効になりました。 残念ながら、エンジンの機能に関連する理由により、セーフモード（safe_mode）を有効にすること、または少なくともopen_basedirをインストールすることはすぐにはできませんでした。 したがって、私は彼らの助けなしにさらに仕事をしなければなりませんでした。

奇妙なことに、私たちのすべての行動は攻撃者の注意をまったく引きつけませんでした。

どうやら彼は最後にサーバーを登るのに飽きていたようで、ゲーム自体の他にどこにも行かなかったようです。 これにより、もう少し時間がかかりました。 この時点で、開発者はすべてのバックアップスクリプトを削除し、使用したWebアプリケーションの分析を開始できました。

非常に一般的な問題の1つがすぐに発見されました。ライブラリ、構成ファイルなどのアクセスがあるディレクトリの内容は外部から開かれていました。 もちろん、これは重大な欠陥ではありません（同じ構成ファイルはphpスクリプトであり、それらへの直接アクセスは何も提供しませんでした）が、そのコンテンツが外部からアクセス可能な場合、悪意のあるコードを格納するのに適した場所を表します。 そのようなフォルダへのアクセスが閉じられると、攻撃者からの「ギフト」を検索する場所の数が急激に減少します。 ゲームエンジンの場合、外部から同じディレクトリにスクリプトといくつかのJSファイル、スタイル、画像を使用してアクセスする可能性を残しました。 後者では、スクリプトは単に禁止されました。 したがって、外部ユーザーがPHPコードの実行を引き起こす可能性のあるフォルダーは1つだけでした。 原則として、攻撃者は内部スクリプトに危険な変更を加え、公開スクリプトから自分のコードにアクセスしようとする可能性があります。 しかし、すぐには解決しませんでしたが、この問題を解決しました（詳細は以下を参照）。

ゲーム自体のソースコードには、単純にブラインドSQLインジェクションが詰め込まれていました。 私たちの協力の全期間にわたって、それらの数十が発見されました。 それらを削除するために雇われた人は、記事の冒頭ですでに述べましたが、mysql_real_escape_string（）関数の使用はリクエストに該当する各変数に簡単に起因すると考えました。 しかし、何らかの理由で、開発者がこれらの変数に数値が存在することを期待しているという事実を考慮していなかったため、SQLクエリでは、それらが含まれる場所は引用符で囲まれていませんでした。 そのため、mysql_real_escape_string（）を使用したエスケープにもかかわらず、インジェクションを使用できますが、主なことは危険なクエリにスペシャルを含めることではありません。 文字。

興味深いことに、その時点ではどのドメインでも悪意のあるスクリプトは見つかりませんでしたが、少なくとも1つは予想されていました。 後に、すべてのハッカーがPMAを介して自分の行動を実行したことがわかりました。

最後の仕上げとして、auto_prepend_fileオプションを使用して、すべての着信要求に関する情報のロガー（シリアル化されたGET / POST / SERVER / COOKIE / SESSION配列の記録）をPHPに接続し、攻撃者に別の禁止を引き起こすことにしました。 ロガーにすぐに問題が発生しました。 その時までの平均的なオンラインはあまりよくありませんでしたが、プレーヤーは非常に多くのリクエストを行ったため、ロガーは日中ではなく時間単位でハードドライブのスペースを使い果たしていました。 解決策として、記録されたデータのgzip圧縮を使用しようとしました。 助けた。 ハードドライブの空き容量+ 1 GBの予備容量を考慮すると、ロガーは約17時間動作します。 この点で、1時間ごとにログを個別に書き込むことを決定し、1日中に利用可能なすべてのログファイルをローカルコンピューターにマージして、同時に元のファイルを消去しました。 禁止後の攻撃者は最大24時間後に行動を開始するので（毎日ゲームに登場しているため）、ログを2〜3回だけポンプアウトする必要があります。 そしてそれが起こった。

試行番号2

指定された時間に、ロガーをオンにし、データが正常に記録されているかどうかを確認し、古いパスワードをすべて変更し、攻撃者を禁止しました。 待つ時間です。 約12時間後、彼は自分を感じさせました。 驚いたことに、ハッカーは再び禁止を解除し、プレイを続けました。

その直後、私たちは逃したものを理解するために取られたすべての措置の議論を始めました。 そして、彼らはすぐに1つの間違いを発見しました。 それは単純で平凡なものでした-すべての管理サービスのパスワードは変更されましたが、管理パネルについては忘れていました。 そこで、パスワードは古いままでした。

その後、ゲーム自体のソースコードに再び注意を払うことにしました。 最近の攻撃の後、攻撃者がそこに何をダウンロードできたのか、あなたは決して知りません。 私はハードドライブで最後の作業オプションを選択しました。 FTPからエンジンをダウンロードし、ローカルでコピーを比較し始めました。 単一のファイルが変更されたわけではありませんが、1つの新しいスクリプトが表示されました（後で実行されたロガーレコードの分析により、そのファイルへのアクセスが示されました）。 それはWebシェルでした。 その作成日までに、私はすぐに何が起こっているのかを理解しました。 ソースコードを確認し、フォルダーごとに調べて、脆弱性を開発者に引き渡し、疑わしいスクリプトを探しました。 総ボリュームの約半分を調べたとき、攻撃者はWebシェルをディレクトリにアップロードしました。その内容は最初に確認しました。 したがって、誰もすぐにこれを発見しませんでした。 そして、攻撃者はそれを使用して禁止を解除することができました。 次に、エンジンのファイル構造の整​​合性を制御する問題を何らかの形で解決する必要があることが明らかになりました。 バージョン管理システムの使用はまだ開始されていなかったため（後で紹介されました）、10分ごとにクラウンが実行するbashスクリプトを使用して出て、新しい/削除されたファイルをチェックし、スクリプトのチェックサムを元の合計でチェックする必要がありました。 私の記事の1つであるanton-kuzmin.blogspot.com/2011/01/blog-post.htmlでプロトタイプを説明しました。

シェルが削除され、パスワードが再び変更され（今回はすべて）、bashスクリプトが実行されているので、次の禁止の時が来ました。

おわりに

講じられた対策は機能しています。 攻撃者はゲームに新しいキャラクターを登録しましたが、1日後（そして今まで）でも、彼のアカウントは他のプレイヤーと同じくらい簡単でした。 サーバーのファイル構造にこれ以上の変更はなく、ゲームのバランスはゆっくりと回復し始め、開発者は以前に準備したアップデートを大量に適用し始めましたが、ハッカーの問題が解決するまでサーバーにアップロードしたくありませんでした。

ところで、クラッカーはすぐに落ち着きませんでした。 彼はフォーラムに同じ日に投稿しました。そこでは通常、ゲームの内部、かなり新鮮な別のダンプ、最も新鮮なものを装ってレイアウトしました。 その後、何らかの理由で開発者の1人に連絡し、サーバーへのアクセスがまだ失われていないことを説得し始めました。 しかし、この確認の要求（たとえば、管理者の1人のパスワードを与えるため）に対して、彼はまったく答えなかったか、関連性のないデータを与えました。

PS

この記事の最後で、Webアプリケーションの開発者と管理者にとって重要ないくつかのルールを強調したいと思います。 ある人にとっては当たり前のように見えるかもしれませんが、きっと役に立つ人もいるでしょう。

1） PHPを最大に制限します。 OSコマンドの実行機能を無効にし、セーフモードを有効にし、使用しないモジュールを無効にします。 インタープリターエラーをログに記録し、運用サーバーでの出力を無効にします。

2）バックアップを作成するときは、ユーザーパスワード、秘密の質問への回答、データベースへの接続の詳細などの機密情報を削除します。

3）データをハッシュするときは、md5（）またはsha1（）への単一の呼び出しなどの非単純なスキームを使用します。 一般的なWebエンジンから取得したソリューションを使用しないでください。 ハッシュを処理するプログラムのほとんどは、すでに復号化を整理できます。 独自のスキームを使用すると、md5（）が7回連続して呼び出されたとしても、攻撃者はほとんど何も解読できません。 結局のところ、使用しているスキームが既知のプログラムにない場合、彼はあなたのケースに特化した別のモジュールを書くか、お金で注文する必要があります。 サイバー犯罪者の総数の何パーセントがこれを行うかを考えてください。 複雑なパスワードを忘れないでください。

4）アプリケーションでは、管理アカウントと単純アカウントを厳密に分離して使用してください。 つまり、管理者は、管理パネルの詳細を使用して、および離職のために同じゲームに参加できませんでした。

5）パスワードをアプリケーションコードに直接保存する場合は、自分でパスワードを保存するのではなく、ハッシュを保存します。

6）特権ユーザーのパスワードは、アプリケーションに固有でなければなりません。 たとえば、司会者がメインアプリケーションを入力してフォーラムにアクセスするために同じパスワードを持っている場合、非常に悪い結果が生じる可能性があります。

7） PEAR :: MDB2のような既製のライブラリを使用して、データベースを操作します。 それらでは、リクエストに該当するデータをシールドする機能が自動的に呼び出され、多くの問題を防ぎます。 状況はフレームワークでも同様です。 すでにコード内のSQLクエリにデータを直接挿入する必要がある場合（たとえば、mysql_query（）を使用）、クエリに配置された各値を引用符で囲み、mysql_real_escape_string（）を忘れないでください。

8） Webアプリケーションディレクトリで777権限を公開しないでください。 それはすべて状況に依存しますが。 時にはそれなしで。

9）外部からアクセス可能で、内部にスクリプトを持たないディレクトリ内のスクリプトの実行を禁止します。 これらは、JSファイル、CSSスタイル、フォント、画像などを含むフォルダーにすることができます。また、ユーザーがアクセスしてはいけないディレクトリ（およびそのコンテンツ）、通常はアクセスに近いフォルダーにできます。 可能であれば、Webディレクトリの外部に移動する必要があります。

10） Webサーバーに関連するすべての制限と設定を共通の構成ファイル（httpd.conf）に保存し、「オンサイト」設定を無効にする（.htaccessを使用）ことは非常に望ましいことです。 これにより、構成の集中ストレージが提供され、サイトにアクセスできるユーザーが特定のディレクトリに関連するものを変更することもできなくなります。 これが不可能で、たとえば.htaccessを使用する場合は、Webサーバーに代わってそこで変更を加えることができないように、そのような権利と所有者で設定してみてください。

11）重要なサービスおよびコントロールパネルへのアクセスをIPアドレスで制限します。

12）バージョン管理システムを使用します。

13）相互に影響を与えないように、それらに配置されたアプリケーションのドメインとデータベースを配置します。 そのため、あるサイトをハッキングした攻撃者がそのサイトを介して別のサイトに侵入することはできません。

14）すべての種類のハッカー対策スクリプトおよび同様のモジュールを、最初に徹底的にテストせずに配置しないでください。 このようなスクリプトを2〜3個まとめて作成する場合は、特に徹底的に検討してください。 ほとんどの場合、これは大きな問題につながります。

15）反射された攻撃の後、突然攻撃者があなたに連絡して、あなたの行動が役に立たないことをあなたに納得させ始めたら、彼があなたに言うすべてを注意深くチェックしてください。 たぶん彼はただブラフしています。

16）インシデントが発生した場合、Webサーバーのログで脆弱性を検出できない場合は、すべてのユーザーのすべてのアクセスデータをログに記録してください。 これは、独自のスクリプトと個々のWebサーバーモジュールを使用して実行できます。



また、オンラインゲームでのユーザーコントロールに関する2つの個別のルールがありますが、このケースに取り組む過程で私はこのルールに取り組みました。

1）ゲームの金額（受信、消費）と経験の計算を自動化し、毎日の統計を保持します。 1日1回、このデータを収集し、最終日と比較します。 したがって、1週間で、ゲームの通常のコースでの24時間の合計増加の平均割合を決定します。 たとえば、自分自身に巨額のゲーム通貨を請求することに成功した不正なプレーヤーが現れると、すぐにそのことを知ることができます。

2）ゲームに関するすべての操作を記録します。 怪物が殺され、物が移され、物が売られたときに物が作られました-すべてを書き留めてください。 前の段落と同様に、一定の時間間隔で、プレイヤーが履歴を持たない前の基本的なものから選択できます。 つまり、彼らはどこからともなく出現しました。 ところで、この同じメカニズムは、盗まれたアイテムを所有者に返すのに役立ち、不正なプレイヤーはすぐに捕まることができます。



この記事を読んでいる間、あなたが何か新しいことを学び、それがあなたにとって有益だったことを願っています。 ご質問にお答えできることを嬉しく思います。