nccgroup/collaboratorplusplusBurp SuiteのCollaboratorに、コンテキストキャプチャ、ポーリング履歴、およびプライベートサーバー展開向けのオプションのAES暗号化認証を追加する拡張機能。
NCC Group Plc によってオープンソースとして公開 - http://www.nccgroup.com/
開発者: Corey Arthur, [email protected]
http://www.github.com/nccgroup/CollaboratorPlusPlus
このプロジェクトはAGPLのもとで公開されています。詳細はLICENSEを参照してください
リリースはこちらからダウンロードできます。
このツールは、Burp Suiteが提供する既存のCollaborator機能を拡張することを目的としており、利便性を高める多数の機能と、プライベートなCollaboratorデプロイメントを保護するための認証メカニズムの実装を提供します。既存のCollaboratorコンテキストを生成・ポーリングするすべての拡張機能との互換性も維持されています。
CollaboratorPlusPlusは、Burpと設定済みのCollaboratorサーバー間のプロキシとして動作し、クライアントが使用しているCollaboratorコンテキストを取得できるようにします。CollaboratorPlusPlusは、観測されたコンテキストとその取得済みインタラクションを中央インターフェースに保存・表示できます。さらに、古いコンテキストを手動でポーリングできるため、Collaboratorクライアントウィンドウを閉じた後でもインタラクションを取得できます。
Collaborator++プロジェクトには、Burp拡張機能に加えて、オプションのサーバーサイド認証コンポーネントも含まれており、Collaboratorサーバーに渡す前に受信したポーリングリクエストを認証します。これは、プライベートなBurp Collaboratorサーバーの所有者が、共有シークレットを知っている者のみにポーリングを制限するためにデプロイできます。
BurpがCollaboratorサーバーで受信したインタラクションのリストを要求すると、拡張機能は共有シークレットを使用して暗号化キーを生成し、AES256-CBC暗号化スキームでポーリングリクエストを暗号化します。共有シークレットが正しければ、認証サーバーはリクエストを復号化し、Collaboratorサーバーに転送して、指定されたCollaboratorインスタンスのインタラクションを取得できます。レスポンスは、Burpクライアントに返送される前に共有シークレットで暗号化されます。
共有シークレットを使用してBurpクライアントと認証サーバー間の通信を暗号化することで、共有シークレットをリクエストと一緒に送信する必要がなくなり、クライアントとサーバー間でHTTP通信を使用しなければならない場合でも機密性を維持できます。
利便性のため、Collaborator Authにはいくつかの追加設定が追加されています。
SSLを使用: クライアントとサーバー間のSSL使用を切り替えます。 サーバーも対象ポートでSSLを使用するように設定されていることを確認してください。
証明書エラーを無視: 証明書の有効性チェックを無効にします。 自己署名証明書や期限切れ証明書の使用を許可します。
SSLホスト名検証を有効にする: 証明書のホスト名が対象ドメインと一致するかどうかをチェックしません。
パブリックCollaboratorサーバーをブロック: パブリックなBurp Collaboratorサーバーの誤使用を防ぎます。Burpのホスト名解決設定に "burpcollaborator.net" のDNSエントリを 127.0.0.1 に追加します。
java -jar CollaboratorPlusPlus.jar を実行してデフォルト設定を生成します。
java -jar CollaboratorPlusPlus.jar YOURCONFIGFILE.properties注: Collaborator++ AuthサーバーへのHTTPおよびHTTPSリクエストを許可するには、設定ファイルのコピーを2つ作成し、1つをHTTP用、もう1つをHTTPS用に設定して、Collaborator++ Authサーバーのインスタンスを2つ実行してください。
SSLの使用を有効にするには、サーバー用の証明書を生成し、以下のいずれかの方法でサーバーを設定します。
どちらの方法でも、設定ファイルの enable_ssl が true であることを確認してください。
openssl req -newkey rsa:2048 -nodes -keyout privatekey.pem -x509 -days 365 -out certificate.pemssl_private_key_path を秘密鍵のパスに設定します。ssl_certificate_path を証明書のパスに設定します。ssl_intermediate_certificate_path を中間証明書のパスに設定します。この方法は純粋に互換性の理由で追加されました。特別な理由がない限り、シンプルな設定を使用することを強くお勧めします。
ssl_private_key_path のserializedValueを空文字列 "" に設定します。
openssl req -newkey rsa:2048 -nodes -keyout privatekey.pem -x509 -days 365 -out certificate.pemopenssl pkcs12 -export -in certificate.pem -inkey privatekey.pem -out polling.p12 -name pollingkeytool -importkeystore -deststorepass NEW_PASSWORD_FOR_KEYSTORE -destkeypass NEW_PASSWORD_FOR_PRIVATE_KEY \
-destkeystore polling.jks -srckeystore polling.p12 -srcstoretype PKCS12 \
-srcstorepass PASS_FROM_PREVIOUS_STEP -alias pollingjava -jar CollaboratorAuth-SERVER.jar CollaboratorServer.propertiesCollaborator Authを使用せずにCollaboratorサーバーがポーリングされるのを防ぐには、Burp Collaboratorのポーリング場所を制限する必要があります。
これはファイアウォールを使用するか、ポーリングイベントのリッスンインターフェースを変更することで行えます。
オプション1 - 常にCollaborator Authの使用を要求する。
ネットワークに関係なくBurp Collaboratorインスタンスのユーザーに認証を強制したい場合は、Burp Collaboratorをローカルマシン上（つまりCollaborator Authからのみ）のポーリングイベントのみをリッスンするように設定できます。
これは、Burp Collaboratorのポーリングイベントのリッスンアドレスをループバックインターフェース（127.0.0.1）に変更するか、iptablesなどを使用して受信リクエストをドロップすることで行えます。
オプション2 - 外部ネットワークでのみCollaborator Authの使用を要求する。
サーバーと同じネットワーク上ではBurp Collaboratorを通常どおり使用できるようにしつつ、外部ネットワークからはCollaborator Authの使用を要求するには、Burp Collaboratorを内部アドレスからのポーリングイベントをリッスンするように設定できます。
これは、Burp Collaboratorのポーリングイベントのリッスンアドレスをサーバーの内部アドレス（192.168.x.x、10.x.x.xなど）に変更することで行えます。
外部からのポーリングイベントがBurp Collaboratorによって処理されないようにするには、インターネットに面したファイアウォールでポーリングポートをブロックする必要があります。あるいは、iptablesを使用して外部ネットワークからの受信トラフィックをドロップします。