CollaboratorPlusPlus

CollaboratorPlusPlus

Publié en open source par NCC Group Plc - http://www.nccgroup.com/

Développé par Corey Arthur, [email protected]

http://www.github.com/nccgroup/CollaboratorPlusPlus

Ce projet est publié sous licence AGPL, voir LICENSE pour plus d'informations.

Téléchargez les versions ici.

Contexte

Cet outil vise à étendre les fonctionnalités Collaborator existantes fournies par Burp Suite, en apportant un certain nombre de fonctionnalités de confort, ainsi que la mise en œuvre d'un mécanisme d'authentification pour sécuriser les déploiements Collaborator privés, tout en restant compatible avec toutes les extensions existantes qui génèrent et interrogent les contextes Collaborator.

CollaboratorPlusPlus sert de proxy entre Burp et le serveur Collaborator configuré, permettant la capture des contextes Collaborator utilisés par le client. CollaboratorPlusPlus peut ensuite stocker et afficher les contextes observés et leurs interactions récupérées dans une interface centralisée. De plus, les anciens contextes peuvent être interrogés manuellement, ce qui permet de récupérer les interactions même après la fermeture de la fenêtre du client Collaborator.

Mécanisme d'authentification

En plus de l'extension Burp, le projet Collaborator++ comprend également un composant d'authentification optionnel côté serveur pour authentifier les requêtes d'interrogation entrantes avant de les transmettre au serveur Collaborator. Il peut être déployé par les propriétaires de serveurs Burp Collaborator privés afin de restreindre l'interrogation aux seules personnes connaissant le secret partagé.

Lorsque Burp demande la liste des interactions reçues par le serveur Collaborator, l'extension chiffre les requêtes d'interrogation avec le schéma de chiffrement AES256-CBC, en utilisant le secret partagé pour générer la clé de chiffrement. Si le secret partagé est correct, le serveur d'authentification peut déchiffrer la demande et la transmettre au serveur Collaborator pour récupérer les interactions de l'instance Collaborator concernée. La réponse est ensuite chiffrée avec le secret partagé avant d'être renvoyée au client Burp.

En utilisant le secret partagé pour chiffrer la transmission entre le client Burp et le serveur d'authentification, le secret partagé n'a pas besoin d'être transmis avec la demande, ce qui permet de conserver la confidentialité même dans les cas où une communication HTTP doit être utilisée entre le client et le serveur.

Collaborator++ - Client

Exécution du client

1. Ajoutez l'extension à Burp
   • Remarque : il s'agit du même JAR que celui du serveur.
2. Spécifiez l'adresse et le port sur lesquels le serveur Collaborator écoute dans la configuration de l'extension.
3. Facultatif : si vous utilisez un serveur Collaborator Auth, spécifiez le secret partagé et activez l'authentification dans la configuration de l'extension.
4. Démarrez le serveur local ; cela configurera également les paramètres Collaborator dans Burp pour vous.
5. Facultatif : exécutez le contrôle de santé Collaborator de Burp pour vous assurer que tout fonctionne.

Paramètres supplémentaires

Quelques paramètres supplémentaires ont été ajoutés à Collaborator Auth pour plus de commodité.

Utiliser SSL : Active ou désactive l'utilisation de SSL entre le client et le serveur. Assurez-vous que votre serveur est également configuré pour utiliser SSL sur le port cible.

Ignorer les erreurs de certificat : Désactive les vérifications de validité des certificats. Permet l'utilisation de certificats auto-signés / expirés.

Activer la vérification du nom d'hôte SSL : N'effectue pas de vérification que le nom d'hôte du certificat correspond au domaine cible.

Bloquer le serveur Collaborator public : Empêche l'utilisation accidentelle du serveur Collaborator public de Burp. Ajoute une entrée DNS pour "burpcollaborator.net" vers 127.0.0.1 dans la configuration de résolution de noms d'hôte de Burp.

Collaborator Auth - Serveur

Exécution du serveur

1. Exécutez java -jar CollaboratorPlusPlus.jar pour générer la configuration par défaut.
   • Remarque : il s'agit du même JAR que celui du client.
2. Modifiez le fichier généré pour pointer vers votre instance Collaborator privée et choisissez un secret approprié.
3. Exécutez à nouveau le serveur et spécifiez la configuration à utiliser : java -jar CollaboratorPlusPlus.jar YOURCONFIGFILE.properties

Remarque : pour autoriser les requêtes HTTP et HTTPS vers le serveur Collaborator++ Auth, créez deux copies du fichier de configuration, l'une pour HTTP et l'autre pour HTTPS, puis exécutez deux instances du serveur Collaborator++ Auth.

Configuration SSL

Pour activer l'utilisation de SSL, générez un certificat pour le serveur et utilisez l'une des méthodes ci-dessous pour configurer le serveur.

Pour les deux méthodes, assurez-vous que enable_ssl est défini sur true dans le fichier de configuration.

Recommandé : configuration simple

1. Générez une nouvelle clé privée et un nouveau certificat pour le serveur à l'aide de la commande suivante, ou utilisez un certificat existant.
   • openssl req -newkey rsa:2048 -nodes -keyout privatekey.pem -x509 -days 365 -out certificate.pem
2. Facultatif : faites signer le certificat par une autorité de certification de confiance.
3. Modifiez le fichier de configuration :
   • Définissez ssl_private_key_path sur le chemin de votre clé privée.
   • Définissez ssl_certificate_path sur le chemin de votre certificat.
   • Si votre chaîne de certificats nécessite un certificat intermédiaire :
     • Définissez ssl_intermediate_certificate_path sur le chemin de votre certificat intermédiaire.

Alternative : Java Keystore

Cette méthode a été ajoutée uniquement pour des raisons de compatibilité. Je recommande vivement d'utiliser la configuration simple, sauf s'il existe une raison de faire autrement.

1. Modifiez le fichier de configuration et définissez la serializedValue de ssl_private_key_path sur une chaîne vide "".
   • Cela activera l'utilisation du keystore pour la configuration.
2. Générez une nouvelle clé privée et un nouveau certificat pour le serveur à l'aide de la commande suivante.
   • openssl req -newkey rsa:2048 -nodes -keyout privatekey.pem -x509 -days 365 -out certificate.pem
3. Convertissez la clé et le certificat au format PKCS12.
   • openssl pkcs12 -export -in certificate.pem -inkey privatekey.pem -out polling.p12 -name polling
4. Saisissez un mot de passe pour chiffrer le fichier PKCS12. Il sera utilisé à l'étape suivante !
5. Importez le fichier PKCS12 dans un nouveau Java Keystore.
   • keytool -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 polling
6. Modifiez le fichier de configuration pour activer SSL, pointer le serveur vers le keystore et spécifier les mots de passe utilisés.
7. Exécutez à nouveau le serveur et spécifiez la configuration à utiliser :

Recommandé : sécuriser le serveur Collaborator réel

Pour empêcher l'interrogation du serveur Collaborator sans utiliser Collaborator Auth, l'emplacement d'interrogation de Burp Collaborator doit être restreint.

Cela peut être fait à l'aide de votre pare-feu, ou en modifiant l'interface d'écoute des événements d'interrogation.

Option 1 - Exiger toujours l'utilisation de Collaborator Auth.

Si vous souhaitez forcer les utilisateurs de votre instance Burp Collaborator à s'authentifier quel que soit leur réseau, Burp Collaborator peut être configuré pour écouter les événements d'interrogation uniquement sur la machine locale (c'est-à-dire depuis Collaborator Auth).

Pour ce faire, modifiez l'adresse d'écoute de Burp Collaborator pour les événements d'interrogation vers l'interface de bouclage (127.0.0.1), ou utilisez quelque chose comme iptables pour supprimer les requêtes entrantes.

Option 2 - Exiger l'utilisation de Collaborator Auth uniquement sur les réseaux externes.

Pour permettre à Burp Collaborator d'être utilisé normalement lorsqu'il se trouve sur le même réseau que le serveur, tout en exigeant Collaborator Auth lorsqu'il est utilisé sur un réseau externe, Burp Collaborator peut être configuré pour écouter les événements d'interrogation provenant d'adresses internes.

Pour ce faire, modifiez l'adresse d'écoute de Burp Collaborator pour les événements d'interrogation vers l'adresse interne du serveur (192.168.x.x, 10.x.x.x, etc.).

Pour garantir que les événements d'interrogation externes ne soient pas traités par Burp Collaborator, le port d'interrogation doit être bloqué sur le pare-feu tourné vers Internet. Vous pouvez également utiliser iptables pour supprimer le trafic entrant provenant de réseaux externes.