今日は、ホスティングセキュリティと、この分野でのすべての問題についてお話したいと思います。 2014年半ば、当時の最新の流行の記事を読んでサイトをウイルスから保護し、ホスティングの安全性と、サイトを大量にハッキングするために脆弱性を使用できるかどうかを考えました。 要するに、すべてが私が予想したよりもはるかに悪く、この話は3年間続いた。
ほとんどのホスティングは次のようになります
2014年に戻って、私はその時に使用していたホスティングを確認することから始め、すぐにアカウント情報を変更するCSRFを見つけました。 CSRFについて話すことができるだけ単純な場合、この脆弱性により、ユーザーに代わってリクエストを偽造できます。 あるドメインから別のドメインにHTMLフォームを送信すると、ブラウザーはリクエストにターゲットドメインに設定されたCookieを自動的に追加します。 これにより、攻撃者は、Cookieにアクセスすることなく、Cookieを使用してユーザーに代わってターゲットドメインにリクエストを送信できます。 この攻撃から保護するために、CSRFトークン、リファラーヘッダーの確認、または重要な要求を確認するためのパスワードの入力が使用されます（これは非常に奇妙で安全でないソリューションです）。 詳細については、 Wikipediaをご覧ください 。
私は10個の大規模なホスティングサイトをすばやく確認しましたが、半数以上がこのような脆弱性を発見しました。 実際、許可されたユーザーが自分のメールアドレスに変更したページに切り替えた後、特別なページを作成し、パスワードをメールで復元し、アカウントとすべてのファイルにアクセスできました。 怖いですが、致命的ではありません。 攻撃を成功させるには、ユーザーを見つけて特別なページに誘導し、ユーザーがホスティングコントロールパネルにログインする必要があります。 これにより、大量のハッキングが成功する可能性が大幅に減少します。
ただし、ほとんどのホスティング会社は既製のコントロールパネルを使用しています。 同時に、管理者は多くの追加権限を持つ同じユーザーアカウントです。多くの場合、管理者はサーバー上のすべてのアカウントにアクセスできます。 攻撃を成功させるには、管理者のメールを変更するリクエストを自動的に送信するページ、追加の権限を持つ新しいアカウントを作成するページ、またはコントロールパネルで可能な他のアクションを実行するページを作成するだけで十分です。 必要に応じて、そのようなページの拡張子を.jpgに変更し、そのページにスクリーンショットを配置して、実際に何が起こっているかを隠すことができます。 その後、「ヘルプ、サイトがダウンしています。エラーのスクリーンショットがあります」というチケットを作成し、ページにリンクを適用できます。 管理者がこのページをクリックすると、攻撃者はすべてのホスティングユーザーアカウントにアクセスできます。
ホスティングを選択するために、いくつかの評価のデータを組み合わせた後、CSRF脆弱性の存在の目標を確認しました。 通常、ホスティングには多くの時間はかからないため、CSRFの存在のみを確認しましたが、偶然別のものを見つけた場合は、これらの脆弱性も報告しました。
結果と技術的詳細
上で書いたように、10の大きなホスティングサイトのうち、半分以上が脆弱でした。 2014年に検証された合計100のホスティングサイトのうち、63が脆弱でした。 通常、これらは単純なCSRFでしたが、いくつかの驚くべき脆弱性がありました。これについては後で説明します。
samopisnyパネルの場合、通常、メールの変更にCSRFを使用し、すでにパスワードを使用してパスワードを回復することができます。 脆弱なパネルの中で最も人気があったのは、ISPmanager、DirectAdmin、WHMCS、およびRootPanelです。 私は自分自身をコントロールパネルのホスティングの専門家と呼ぶことはできないので、バージョンやその他の微妙な点を間違える可能性があります。
これは非常に人気のあるパネルですが、現在のバージョンにはCSRFが含まれていません。 ただし、非常に古くて漏れやすい古いバージョンのパネルがよく使用されます。
このパネルを使用して、さまざまなホスティング会社でCSRFを見つけた後、パネル開発者にこのことについて書きました。 しかし、彼らは長い間、リファラーヘッダーをチェックするという形でCSRFに対する保護があると言っていましたが、ほとんどのホストでは無効にされていました。
同様の問題がWHMCSにありました。 なんらかの驚くべき理由で、CSRFトークンは多くのホスティングサイトでチェックされず、リクエストの改ざんに対する保護はありませんでした。 誰かが何かを誤って設定した可能性があります。
このパネルでは、CSRFが最初に存在していましたが、私が彼に手紙を書いた後、開発者によって脆弱性が修正されました。
ホスティングレスポンス
おそらく最も正しいのは、2014年にこの情報を公開し、大規模なハッキングとハッカーに対する苦情を観察することです。 しかし、その後、ホスティングに脆弱性を報告する方が良いと判断し、それを開始しました。 63人の脆弱なホスティングに問題について通知し、52人のみが回答しましたが、しばらくして48人のホスティングが脆弱性を修正しましたが、残りは何もしませんでした。
最も興味深いことは後で始まりました。 しばらくしてから、これらのホスティングサイトを再度確認しましたが、それらのいくつかでは脆弱性が魔法のように再び現れました。 2015年と2016年に、私は別の20〜30のホスティングを選択し、それらをチェックし、脆弱性について企業に手紙を送りました。 状況は似ています。ホスティングサイトの半分以上が脆弱であり、いくつかの脆弱性を修正してしばらくしてから再び現れます。
ある時点で、すべてがサーカスに似始めました。情報を送信すると、脆弱性は消えます。 多くの場合、特にsamopisnyパネルの場合、6か月後、脆弱性は同じまたは類似の形式で戻ります。
一部の企業は、使用済みのコントロールパネルに更新プログラムをインストールするだけで脆弱性を修正する準備ができていました（「最新バージョンのパネルを使用しています。これは開発者の問題です」）。 さらに、彼らが使用するパネル生成は長い間更新されていません。
ある時点で、このサーカスを終了し、既存の問題に関する情報を公開することにしました。
問題規模
これらの脆弱性を使用して侵害される可能性のあるサイトの数を計算するのはかなり困難です。 脆弱なホスティングの数（約90〜100）と各ホスティングの最小ホストサイト数1000に基づいて（実際の数ははるかに大きいと確信しています）、これは100,000以上のサイトです。 ただし、間接的な兆候（システム内のアカウントとサイトのID、独自のホスティングステートメント、および評価からの情報）は、数百万を超えるサイトが危険にさらされていることを示唆しています。 ほとんどのサイトは月に数人が訪れることは明らかですが、それでも状況は恐ろしいものです。
今日の簡単な結果とステータス
2014年と2015年の状況は恐ろしいものでした。当時の最大規模のものを含むホスティングの半数以上が、ユーザーデータへのアクセスを許可する単純な脆弱性を抱えていました。 最悪の場合、すぐにすべてのアカウントに。 徐々に、状況は改善し始めました。脆弱性を閉じることを計画していた人々がそれらを修正し、新しいホスティングプロバイダーがついに新しいコントロールパネルを使用し始めました。
ただし、軟膏にはハエがあります。現在でも、最も人気のある上位10〜20に含まれる多数の大規模なホスティングサービスには、ユーザーアカウントにアクセスできる単純なCSRFが含まれています。 同様の方法で管理者に代わってリクエストを実行することも可能だという疑いがありますが、これは別の問題です（コントロールパネルを使用しているため、管理者のリクエストの形式はわかりません）。 小規模なホスティング会社の中には、何らかの理由で脆弱性を修正していない人がまだかなりいます。 さらに、関連する脆弱性が多くあり、ホスティングセクターのセキュリティレベルは驚くほど低いです。
いくつかのメモと面白い状況
* 報酬 。 通常、彼らは無料のホスティングを提供し、条件は非常に異なっていました：本当に十分な10,000-20,000千から個人アカウント、120ルーブルの1か月の割引まで、私はこの寛大さに感銘を受けました。 お金の報酬ははるかに少ない頻度で提供され、通常は象徴的な1000-2000ルーブルでしたが、2つのはるかに楽しいケースがありました。 しかし、これらは孤立した状況であり、ほとんどは何も提供しませんでした。
* 適切 。 失礼や脅迫に遭遇したことはありません。 最も不快なことは、メッセージまたは「これを脆弱性とは見なしません」という回答を無視することです。
* セキュリティ問題に対する独創的なソリューション 。 いくつかの企業は、CSRFの脅威に奇妙な方法で対処することを決定しました。「管理者はユーザーからのリンクをたどらない」、ユーザーは「自分で対処する」必要があります。
* その他の脆弱性 。 CSRFのみを探しましたが、他の脆弱性が存在することもありました。 最も一般的なのは、不正なHTTPS構成です。完全に欠落している場合もあり、XSSが大量に存在し、奇妙なデータリークが発生しました。 最も安全なシステム（信頼性の高いシステム、アクセス制御、24時間監視）として位置付けられているホスティングでは、識別子を並べ替えるだけで任意のアカウントにアクセスできます。 どうやら、広報の費用は安全なサービスを作るには高すぎる。
* 会社名の公開 。 長い間、すべての会社名と脆弱性の詳細な説明を含むチェックの完全な結果を公開するかどうかを決定できませんでした。 ただし、CSRFのみのチェック、その選択性、依然として脆弱なホスティング、および報酬を受け取るためのいくつかの条件を考慮して、私はこの情報を公開しませんでした。
記事を読んだ後、何かをしたい場合は、違法な行動をとったり、ホスティングを中断したりしないようにお願いします。
来週、たとえばTelegramの未解決の脆弱性など、何か他の興味深いことをお伝えしたいと思います。
UPD ：コメントでは、証拠を提供するよう要求されました。 ネタバレの下には、いくつかのホスティング回答のスクリーンショット（スクリーンショットでは、会社を一意に識別できるすべてのデータを非表示にしようとしました）とDirectAdmin開発者の回答があります。
スクリーンショット
1） 
2）
3）
4）
5）
6）
2）
3）
4）
5）
6）