はじめに
この実験では、Gobuster が TLS 証明書エラーに遭遇した場合の対処法を学びます。特に自己署名証明書や無効な証明書を扱う場合です。デフォルトでは、Gobuster は多くのツールと同様に、厳格な TLS 証明書検証を実行し、安全な通信を確保します。しかし、特定のテストシナリオでは、この検証をバイパスする必要がある場合があります。この実験では、そのようなターゲットを特定し、デフォルトのエラーを観察し、次に -k フラグを使用して証明書検証を無効にし、スキャンを進める方法を説明します。最後に、TLS 検証を無効にすることのセキュリティへの影響について説明します。
自己署名または無効な TLS 証明書を使用したターゲットの特定
このステップでは、自己署名またはその他の無効な TLS 証明書を使用するターゲット URL を特定します。この実験の目的のために、Gobuster がフラグを立てる証明書の問題があることが知られている、一般公開されているテストサイトを使用します。これにより、問題をその解決策を確実に実証できます。
ターミナルを開き、curl を使用してターゲット URL にアクセスしてみてください。証明書エラーが表示され、証明書がシステムによって信頼されていないことを示しているはずです。これは、Gobuster も問題を抱えることになるシナリオです。
次のコマンドを実行します。
curl https://self-signed.badssl.com/
証明書の問題を示す、以下のような出力が表示されるはずです。
curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about such a situation and
how to fix it, please consult the relevant articles in the links above.
この出力は、ターゲット https://self-signed.badssl.com/ がデフォルトで信頼されていない証明書を提示していることを確認しており、これはまさにこの実験に必要なものです。
スキャンを試行し、証明書エラーを観察する
このステップでは、TLS 証明書検証を無効にせずに、特定したターゲットに対して Gobuster を実行します。予想通り、Gobuster は自己署名証明書に遭遇し、curl が示したものと同様のエラーで終了します。これは、厳格な証明書検証を強制する Gobuster のデフォルトの動作を示しています。
次の Gobuster コマンドを実行します。
gobuster dir -u https://self-signed.badssl.com/ -w /usr/share/wordlists/dirb/common.txt -q
dir: ディレクトリ/ファイル総当たりスキャンを実行することを指定します。-u https://self-signed.badssl.com/: ターゲット URL を設定します。-w /usr/share/wordlists/dirb/common.txt: 総当たりに使用する単語リストを指定します。-q: バナーやその他の不要な出力を抑制し、エラーをより明確にします。
TLS ハンドシェイクエラーを示す、以下のような出力が表示されるはずです。
[!] GoBuster is unable to connect to the target: Get "https://self-signed.badssl.com/": x509: certificate signed by unknown authority
このエラーメッセージは、信頼されていない証明書のために Gobuster が接続を確立できなかったことを確認しており、スキャンを進めることができません。
-k フラグを使用してスキャンを再実行する
このステップでは、Gobuster スキャンを再実行しますが、今回は -k フラグを含めます。-k フラグ（--no-tls-validation の短縮形）は、Gobuster に TLS 証明書検証をスキップするように指示します。これは、制御された環境や、証明書の警告にもかかわらずターゲットを明示的に信頼している自己署名証明書を持つターゲットに対するテストに役立ちます。
-k フラグを追加して、次の Gobuster コマンドを実行します。
gobuster dir -u https://self-signed.badssl.com/ -w /usr/share/wordlists/dirb/common.txt -k -q
-k: TLS 証明書検証を無効にする重要なフラグです。
今回は、Gobuster は証明書エラーで直ちに終了しないはずです。代わりに、ディレクトリ総当たりプロセスを開始します。単語リストが大きく、ディレクトリがすぐに見つからない場合、即時の出力は表示されないかもしれませんが、以前のエラーがないことは成功を示しています。
スキャンが現在進行していることを確認する
このステップでは、-k フラグのおかげで Gobuster スキャンが現在アクティブに実行され、単語リストを処理していることを確認します。-q フラグを使用してほとんどの出力を抑制したため、ディレクトリが見つからない限り、多くの活動は表示されない可能性があります。進捗をより分かりやすくするために、-q フラグを削除し、Gobuster を短時間実行させます。
進捗を確認できるように、今回は -q フラグなしでコマンドを再度実行します。
gobuster dir -u https://self-signed.badssl.com/ -w /usr/share/wordlists/dirb/common.txt -k
これで、Gobuster の通常の出力が表示され、ターゲットをアクティブにスキャンしていることが示されるはずです。出力には、進捗状況と検出されたディレクトリまたはファイルが表示されます。例：
===============================================================
Gobuster vX.X.X -- by OJ <@_odejim> & @Neohapsis
===============================================================
[+] Url: https://self-signed.badssl.com/
[+] Threads: 10
[+] Wordlist: /usr/share/wordlists/dirb/common.txt
[+] Status codes: 200,204,301,302,307,401,403,405
[+] User Agent: gobuster/X.X.X
[+] Timeout: 10s
[+] Allow redirects: false
[+] Follow new location: false
[+] No TLS validation: true
===============================================================
2023/10/27 10:30:00 Starting gobuster in directory enumeration mode
/admin (Status: 301)
/login (Status: 301)
...
実行されていることを確認したら、Ctrl+C を押してスキャンを停止できます。重要な点は、以前の証明書エラーなしでスキャンが正常に開始されたことです。
検証を無効にすることのセキュリティ上の影響を理解する
この最終ステップでは、TLS 証明書検証を無効にすることのセキュリティ上の影響について説明します。-k フラグは特定のテストシナリオに役立ちますが、なぜ注意して、必要な場合にのみ使用する必要があるのかを理解することが重要です。
TLS 証明書検証を無効にすると、本質的に Gobuster（または他のツール）に対し、証明書が有効であるか、期限切れであるか、自己署名であるか、信頼されていない機関によって発行されたかに関わらず、サーバーによって提示された証明書を信頼するように指示することになります。これにより、いくつかのセキュリティリスクが生じます。
- 中間者攻撃 (MitM Attacks): 攻撃者は、正規のサーバーへの接続を傍受し、独自の偽造証明書を提示する可能性があります。検証が無効になっている場合、ツールは意図せずに攻撃者のサーバーに接続し、通信を盗聴または操作できるようになります。
- なりすまし： 意図したターゲットになりすました悪意のあるサーバーに誤って接続する可能性があります。証明書検証がない場合、正規のサーバーと通信しているという暗号学的な保証はありません。
- データの整合性と機密性の侵害： 攻撃者が MitM 攻撃を成功させることができた場合、通信内のデータを読み取ったり、変更したり、挿入したりする可能性があり、機密性と整合性の両方が侵害されます。
-k を使用することが許容されるのはいつか？
- 制御されたテスト環境： ラボ環境でアプリケーションまたはサーバーをテストしており、サーバーを明示的に制御し、自己署名または無効な証明書を認識している場合。
- 内部ネットワーク： すべてのエンドポイントを完全に制御し、リスクを理解している信頼されたネットワーク内で通信する内部ツールの場合。
- デバッグ： デバッグ目的で一時的に使用する場合。ただし、本番環境または機密性の高い操作では、常に検証を再度有効にしてください。
ベストプラクティス: 常に強力な TLS 証明書検証を優先してください。無効にするのは、絶対に必要であり、関連するリスクを完全に理解している場合に限ってください。本番システムでは、常に有効で信頼された証明書が使用されていることを確認してください。
これで、Gobuster で TLS 証明書検証を無効にすることに関する実験は終了です。証明書の問題があるターゲットを特定する方法、Gobuster のデフォルトの動作を観察する方法、そして -k フラグを使用して検証をバイパスする方法を学びました。同時に、重要なセキュリティ上の影響についても理解しました。
まとめ
この実験では、Gobuster で TLS 証明書検証を管理する方法を学びました。まず、curl を使用して自己署名証明書を持つターゲットを特定し、典型的な証明書エラーを実証しました。次に、Gobuster がデフォルトで厳格な TLS 検証のためにそのようなターゲットのスキャンに失敗する方法を観察しました。実験の核心は、Gobuster で -k フラグを使用して証明書検証をバイパスし、スキャンを進めることでした。最後に、TLS 検証を無効にすることの重大なセキュリティ上の影響を理解し、制御された、または特定のテストシナリオでのみ慎重に使用することを強調しました。この知識は、Web スキャンツールの効果的かつ安全な使用にとって不可欠です。