Cloud

クラウド環境の監視

このプロジェクトの使命は、主要なクラウドサービスプロバイダーごとに、常に最新で自由にアクセス可能なクラウド環境のマップを提供することです。

私たちは、セキュリティ研究者にとっての価値を考慮し、まずはAWS EC2とGCPマシンのSSL証明書データを収集することから始めることにしました。ただし、近い将来、より多くのデータとプロバイダーを含むようにプロジェクトを拡大する予定です。皆様のご意見やご提案は非常に貴重ですので、Twitter または Discord までお気軽にお知らせください。次に優先すべき分野について教えてください。

SSL証明書データはどのように役立つのか？

SSLデータ はCSVファイルに整理され、発見された各証明書について以下のプロパティが収集されています：

• IP Address
• Common Name
• Organization
• Country
• Locality
• Province
• Subject Alternative DNS Name
• Subject Alternative IP address
• Self-signed (boolean)

では、このデータで何ができるのか？

ターゲットドメインのサブドメインを列挙する

ターゲットのドメイン名（例：example.com）を検索し、収集された証明書の Common Name および Subject Alternative Name フィールドでヒットを見つけます。すべてのIP範囲は毎日スキャンされ、データセットはそれに応じて更新されるため、一時的なホストが削除される前に発見できる可能性が非常に高くなります。

ターゲット企業のドメインを列挙する

ターゲットの会社名（例：Example, Inc.）を検索し、Organization フィールドでヒットを見つけ、関連する Common Name および Subject Alternative Name フィールドを調べます。結果には、おなじみのドメインのサブドメインが含まれる可能性が高く、運が良ければ新しいルートドメインを見つけてスコープを拡大できるかもしれません。

サブサブドメイン列挙の可能性のあるターゲットを列挙する

証明書がワイルドカード（例：*.foo.example.com）に対して発行されている場合、そこをブルートフォースすることで他のサブドメインが見つかる可能性が高いです。そして、このテクニックがどれほど効果的かは ご存知 でしょう。そのための wordlists をいくつか用意しています！

💡 注意：新しいアセットが出現するたびに通知を受け取るために、データセットの毎日の更新を監視することを忘れないでください。

IPルックアップを実行する

IPアドレス（例：3.122.37.147）を検索して関連するホスト名を見つけ、Common Name、Subject Alternative Name、Organization フィールドを調べることで、そのアドレスに関する詳細情報を得ることができます。

プロキシサービスをバイパスするためにオリジンIPアドレスを発見する

WebサイトがCloudflare、Akamai、Incapsulaなどのセキュリティプロキシサービスの背後に隠されている場合、データセット内でホスト名（例：example.com）を検索することが可能です。この検索により、オリジンIPアドレスが明らかになり、プロキシをバイパスできる可能性があります。同様のテクニックについては、こちらのブログ で説明しています。

稼働中のWebサーバーの最新データセットを入手する

データセット内の各IPアドレスは、ポート443で動作するHTTPSサーバーに対応しています。このデータを自分で収集する時間をかけることなく、大規模な研究に使用できます。

その他、思いつくことすべて

このデータをクールなプロジェクトや研究に使用した場合は、ぜひお聞かせください！

さらに、以下ではデータ収集プロセスの詳細な説明と、独自のIP範囲から情報を収集するために同じ手法を実装する方法を説明します。

仕組み

TB; DZ（大きすぎてズームできなかった）

1. ワークフローは、IP範囲を取得する2つのシンプルなbashスクリプトから始まります：
   • AWSのIP範囲 はJQクエリを使用してフィルタリングされます。.prefixes[] | select(.service=="EC2") | .ip_prefix でフィルタリングしてEC2マシンのIP範囲を抽出します。他のサービスはカスタムSSL証明書をサポートしていないため、このワークフローから除外され、データセットには関連しません。
   • GCPのIP範囲 は別のJQクエリ .prefixes[].ipv4Prefix を使用して抽出されます。
2. 次に、mapcidr を使用して、ステップ1で取得したIP範囲を、それぞれ最大10万台のホストを含む小さな範囲に分割します（ProjectDiscovery チームに感謝！）。このステップは、次の並列スキャンプロセスを実行する際に便利です。
3. 執筆時点で、クラウドのIP範囲には7500万以上のIPアドレスが含まれているため、単一のマシンですべてをスキャンすることは非現実的です。そこで、file-splitter ノードが登場します。このノードは mapcidr からの入力を反復処理し、各範囲に対して個別のジョブをトリガーします。このワークフローを複数のマシン（たとえば30台）で実行すると、これらのジョブを並行して処理するため、全体的な実行時間が大幅に短縮されます。この効率性により、ワークフローを毎日実行し、データを常に最新の状態に保つことができます。
4. 次に、並列マシンが zgrab2 インスタンスを起動してSSL証明書を収集します。さまざまなツールや手法を試した結果、zgrab2 のtlsモジュールが最速で最も信頼性の高いオプションとして浮上しました。The ZMap Project チームに感謝します！
5. 各zgrab2インスタンスは、データをbashスクリプトに渡し、そのスクリプトが関連データを抽出してCSVファイルに出力します。
6. 最後に、すべてのCSVファイルを収集し、管理しやすい450KBのチャンクに分割して、GitHubが CSVファイルをレンダリング できるようにします。これらのチャンクはその後、このリポジトリにプッシュされます。

貢献

すべての貢献/アイデア/提案を歓迎します！ GitHub issues で新しいチケットを作成するか、@trick3st にツイートするか、Discord で会話に参加してください。

独自のワークフローを構築する

私たちは、試行錯誤の価値を信じています。画一的な解決策はめったに通用しません。Trickest のデモにサインアップして、このワークフローをユースケースに合わせてカスタマイズしたり、さらに多くのワークフローにアクセスしたり、ゼロから独自のワークフローを構築してください！