最近、さまざまなサービスの動作にエラーや脆弱性がないかどうかを確認する提案を受け取り始めました。 そして、そのような提案では、結果に取り組み、プロセスから最大限の喜びを得ようとしています。 しかし、最後の「プロジェクト」の結果は、控えめに言ってもショックを受けました。
ホスティングプロバイダーのテストを依頼されました。
名前は公開しません。 そして、私の話では、Hosterという名前を使用します。 サイト自体では、ホスティングサービスはすべて標準でした。 VDS、ドメイン、SSL証明書の購入を申し出ます。
まず、ユーザーの個人アカウントがどのように実装されているかに驚いた。 登録中のメールアドレスの所有権の証明は必要ありませんでした。 つまり、メールアドレスsteve.jobs@apple.comで登録できます。 それとも、support @ hoster.com。
しかし、幸いなことに、 この話との類推により、サービスサポートデスクの機密情報の開示は行われませんでした。
ただし、テストサポートリクエストを作成し、すぐに他のサポートリクエストの近隣IDの可用性を確認したときにも発生しました。 驚いたことに、それらは利用可能でした。 そして、誰が何をホスト者に登録しているかを観察することができました。 また、ユーザーはどのような問題に直面していますか？ 一般的に、標準のIDOR脆弱性は、今では誰も驚かないでしょう。 もちろん、彼女は即座に修正されました。
Stored XSSにはいくつかの場所もありました。 また、サービス管理者のCookieを返すBlind XSSもありました。 このXSSのおかげで、管理者インターフェイスがどこにあるかを知ることができ、一般に、多くの興味深い情報が明らかになりました。
- アクティブユーザーの数。
- 制御しているドメインの数。
- 展開されているVDSの数。
その他多数...
CSRFトークンにはさまざまなエラーがあり、ユーザーに代わってアカウントで多くの危険なことを行うことができました。 そして、CSRFトークンが転送された場所がある場合、それらは単に転送されました。 バックエンドでそれらをチェックする予定はありませんでした。 私の発見の結果、機能の一部が完全に無効になりました。 たとえば、2FA認証は実装で行われなかったため、一時的に削除されることが決定されました。
作業の過程で、セキュリティの問題だけでなく、実装エラーや一部の機能の動作の問題にも注意を払いました。 私はQAがこのように通り過ぎることができなかったのが好きです。 その結果、私の問題追跡ツールは22という数字に達しました。私が見つけて修正した集合体には非常に多くの問題があります（例外的に注目に値する）。
結果は説得力を超えています。 そして、私はすでにこのプロジェクトを完了する予定でした。 しかし、何らかの理由で、登録時にメールアドレスの所有者が確認されないという問題を思い出しました。 そして彼は、これがホスティングとその所有者に最大の問題を引き起こす可能性がある状況を思いつき始めました。 ある時点で、このホスティングサービスの所有者と、私が知っている同じ会社の他のプロジェクトとの関係について考え始めました。 数分後、同じ会社の別のプロジェクトのメールアドレスでアカウントを登録しました（support@example.comにします）。 次に、作成したアカウントsuppot@example.comにドメインexample.comをバインドしました。 しかし、バインドされたドメインのコンテンツを制御できませんでした。
しかし、彼はサービスexample.comに代わってメールで完全に釣り上げることができました。
応答文字がどこに来たかは明らかではありません。 私はそのようなテストレターに自分自身に答えたからです。 しかし、私は答えそのものを受け取りませんでした。 電子メールアカウントsupport@example.comの実際の所有者への応答でおそらく消滅しました。
そして、この記事を書くことにした何かが起こった。
忘れてしまったサブドメインを解決できました。 従来のサブドメイン乗っ取りの脆弱性。 詳細については、 こちらをご覧ください 。
理由はわかりませんが、存在しないドメインにバインドを追加しようとしました。 そして、私はそれをやった。
サブドメインが正常に追加され、このサブドメインのコンテンツを制御できました。 そして、コンテンツが表示されました。
しかし、これは同じにはできません！ どうして？ 結局のところ、古典的なサブドメイン乗っ取りの脆弱性は、既存のサブドメインでのみ機能します。
この状況は絶対に私の頭に収まりませんでした。 つまり、大丈夫、私はexample.comに対する態度の検証レベルをバイパスすることができました。これは決して私のものではありません（おそらく、アカウント名のexample .comのおかげです）。 しかし、サブドメインを追加して、A、TXT、CNAMEレコードのコンポーネントをチェックせずにそれらを制御するにはどうすればよいですか？
通常、私はこれを見ます-私たちはあなたにサブドメインを追加します、あなただけがそれを行うことができることを証明します。 移動して、このハッシュololopyshpyshpyshbdysh123をTXTに追加します。
しかし、そのようなことはありませんでした。 admin.example.comサブドメインが必要ですか？ 問題ありません！
サブドメインテイクオーバーV2の脆弱性のように。
テストしたホスティングサービスの所有者と迅速に通信できるため、このボックスはPandoraによって開かれました。
次のことが判明しました。 ホスティングはCloudFlareを介して機能しました。 そして彼は非常にcなやり方で働いた。
簡単な言葉で説明しようと思います。
大まかに言って、私に言って、私のところに来て、私はあなたをホストします。 あなたのドメインを私に委任してください。
そして、私はすべての着信コールをCloudFlareに無差別に送信します。
そして、私がvasya.ruドメインを委任され、隣人が来てtest.vasya.ruでサイトを猿aggedけし、ホスティングのために私にそれを与えた場合、CloudFlareにアクセスし、すでにvasya.ruに対する権限を持っている私のサーバーは、問題なく第3レベルを追加しました隣人とすべてのルールのためのドメイン、迅速かつ疑いなく。 すべてのDNSについて、CloudFlareから正しい情報が到着しました。 CloudFlareは私を信頼しています。
通常、当然、ホスティングプロバイダーはDNSサービスを構成します。 しかし、ここでは、彼らがだまして、1人のユーザーからすべてをCloudFlareに転送していることがわかります。
したがって、サブドメインの引き継ぎgod_modeがあります。 確かに、これはホスティングが既に制御しているアドレスでのみ機能しました。 しかし、以前に発見された管理サービスと併せて-これは、ホスティングサービスのホスティング事業者とクライアントの両方でトリックを演じることができます。
現時点では、ほぼすべての重大な脆弱性とエラーが修正されています。 そして、私はこの物語を読んだ後に誰もそのような建築の喜びを決定しないことを願っています。
PS：記事に関するコメントと提案を歓迎します。 技術的なアドバイスをしてくれたPatriot2kに感謝します！ また、何か面白いものをテストするための提案も受け付けています。