nccgroup/berserkoExtension Burp Suite pour effectuer l'authentification Kerberos
Publié en open source par NCC Group Plc - http://www.nccgroup.trust/
Développé par Richard Turnbull, richard [dot] turnbull [at] nccgroup [dot] com
http://www.github.com/nccgroup/Berserko
Publié sous licence AGPL, voir LICENSE pour plus d'informations
Le développement ultérieur de Berserko aura lieu à https://github.com/rteatea/Berserko
Berserko est une extension Burp qui ajoute la prise en charge de l'authentification Kerberos. Elle est utile pour les tests dans un domaine Windows lorsque l'authentification NTLM n'est pas prise en charge (Burp gère déjà NTLM). Berserko n'exige pas que la machine exécutant Burp soit jointe au domaine (ni même qu'elle exécute Windows).
La seule solution existante dont nous ayons actuellement connaissance pour tester des applications Kerberos avec Burp consiste à passer par Fiddler, avec une authentification configurée selon ces instructions. Mais Fiddler est exclusivement Windows, et le chaînage de proxys ajoute de la complexité et nuit aux performances, il est donc agréable de disposer de la fonctionnalité Kerberos directement dans Burp.
Téléchargez le dernier fichier jar de Berserko depuis l'onglet Releases, ou depuis le dossier berserko\releases
Allez dans l'onglet Extender de Burp, sélectionnez Add, assurez-vous que Java est sélectionné comme Extension type, puis pointez-le vers le fichier jar. Si tout se passe bien, l'onglet Berserko devrait être ajouté à l'interface de Burp.
Il y a divers contrôles sur l'onglet Berserko de Burp.
La case Do Kerberos authentication est un interrupteur principal. Tant qu'elle n'est pas activée, Berserko ne fait rien du tout.
Le bouton Restore defaults remet Berserko à la configuration par défaut (dans laquelle aucun détail de domaine ni identifiants utilisateur n'est présent).
Le bouton Clear Kerberos state efface tous les tickets Kerberos et autres états côté client. La seule raison pour laquelle vous pourriez avoir besoin de l'utiliser serait si des modifications avaient été apportées à la configuration Kerberos côté serveur et que vous souhaitiez repartir d'un état vierge.
Le bouton Write tickets to log écrit des informations sur vos tickets Kerberos actuels dans le flux de journalisation de Berserko - cela peut être utile pour le débogage / le dépannage. Pour voir les journaux, allez dans l'onglet Extender de Burp, sélectionnez Berserko et regardez l'onglet Output en dessous. Il peut être judicieux d'utiliser l'option Save to file ici, car les données de tickets peuvent facilement remplir le tampon de journalisation de l'interface graphique.
Certains contrôles disposent d'un bouton d'aide qui affiche plus d'informations.
Spécifiez le nom DNS du domaine et l'hôte KDC à l'aide des contrôles de cette section. Les zones de texte ne peuvent pas être modifiées directement ; vous devez utiliser le bouton 'Change' pour les modifier.
Le Domain DNS Name doit être le nom DNS du domaine contre lequel vous souhaitez vous authentifier (pour être précis, il s'agit en réalité du realm Kerberos). Cela devrait ressembler à mydomain.acme.local. Il ne doit pas s'agir du nom NETBIOS du domaine (qui serait quelque chose comme MYDOMAIN).
L'hôte KDC doit être le nom d'hôte (ou l'adresse IP) d'un KDC Kerberos (Key Distribution Center). Dans un domaine Windows, un KDC est simplement un contrôleur de domaine.
Après avoir fourni le Domain DNS Name, vous pouvez utiliser le bouton Auto pour essayer de localiser automatiquement un KDC. Il procède en envoyant une requête DNS SRV pour le service Kerberos. Si l'un de vos serveurs DNS est un contrôleur de domaine pour le bon domaine, cela devrait fonctionner. Si ce n'est pas le cas, cela ne fonctionnera pas. ❗**Cette fonctionnalité ne fonctionnera pas dans les versions récentes de Burp, car les bibliothèques DNS nécessaires ne sont pas fournies avec le JRE intégré. Vous pouvez contourner ce problème en lançant sous un JRE complet comme décrit en haut de ce README.}❗
Lorsque le Domain DNS Name et l'hôte KDC ont été saisis, utilisez le bouton Test domain settings pour tester la connectivité. Si tout se passe bien, vous obtiendrez une réponse Successfully contacted Kerberos service.
Voir ce fichier pour beaucoup plus d'informations sur l'obtention des bonnes valeurs pour ces paramètres de domaine.
Spécifiez le nom d'utilisateur et le mot de passe d'un compte de domaine à l'aide des contrôles de cette section. Les zones de texte ne peuvent pas être modifiées directement ; vous devez utiliser le bouton 'Change' pour les modifier.
Le Username doit être simplement le nom d'utilisateur. Cela devrait ressembler à bob. Il ne doit pas s'agir de MYDOMAIN\bob ni de [email protected] ou similaire.
Après avoir fourni les identifiants, vous pouvez utiliser le bouton Test credentials. Cela tentera d'acquérir un ticket d'octroi de ticket Kerberos pour l'utilisateur spécifié. En cas de succès, vous obtiendrez une réponse TGT successfully acquired. En cas d'échec, notez qu'il s'agit d'une tentative d'authentification au domaine, alors veillez à ne pas verrouiller votre compte.
Le mot de passe ne sera pas enregistré dans la configuration de Berserko pour la prochaine fois, sauf si la case Save password in Burp config? est cochée. Tous les autres paramètres seront toutefois enregistrés.
Certaines applications utilisent la délégation Kerberos côté serveur pour transmettre l'identité du client à d'autres serveurs (mais il n'existe pas de moyen simple de déterminer côté client si elle est utilisée).
Berserko prend bien en charge cela, mais il y a un piège. La délégation ne fonctionne que si l'utilisateur dispose d'un TGT forwardable (ticket d'octroi de ticket). L'implémentation Java de Kerberos ne fournit malheureusement aucun moyen de spécifier par programmation qu'un ticket forwardable doit être acquis. Cela ne peut être fait qu'en ajoutant une entrée appropriée au fichier de configuration krb5.conf.
Ainsi, pour que la délégation fonctionne, Berserko doit être pointé vers un fichier krb5.conf approprié, et deux approches sont possibles ici.
La chose la plus simple à faire, et l'approche recommandée, est d'utiliser le bouton Create krb5.conf file. Cela créera pour vous un fichier approprié à l'emplacement de votre choix. Vous pouvez le placer dans un répertoire temporaire, dans le répertoire de votre projet, ou n'importe où. Mais le même fichier peut être réutilisé indéfiniment, il peut donc être judicieux de le placer dans un endroit plus permanent. Le bouton Change vous permet de sélectionner un autre fichier à utiliser.
Si cela vous intéresse, le fichier krb5.conf créé est très simple et aura le contenu suivant :
[libdefaults]
forwardable = true
Alternativement, vous pouvez utiliser le bouton Change pour pointer vers un fichier krb5.conf existant sur le système. La seule raison pour laquelle vous pourriez vouloir faire cela serait s'il y avait d'autres paramètres Kerberos importants dans ce fichier que vous souhaiteriez que Berserko prenne en compte (ce qui devrait fonctionner correctement en théorie, mais n'a pas été testé en pratique). Notez que l'emplacement par défaut de ce fichier sous Linux est /etc/krb5.conf - les autres systèmes d'exploitation sont moins susceptibles d'en avoir un. Si vous pointez vers un fichier krb5.conf existant, assurez-vous de le modifier pour activer le transfert - ajoutez forwardable = true à la section [libdefaults] (ou individuellement pour chaque realm). Mais soyez prudent. Demander à Berserko de créer le fichier pour vous sera la meilleure option 99 % du temps.
Si vous voulez savoir si votre configuration de délégation est réussie, utilisez le bouton Check current config. Cela vous indiquera si le fichier krb5.conf a été localisé et si le paramètre forwardable est correct. Notez également que Berserko vous indiquera s'il a réussi ou non à acquérir un TGT forwardable lorsque vous utilisez le bouton Test credentials.
Il est conseillé de vous assurer que vous disposez d'un ticket forwardable avant de commencer à utiliser une application. Il semble qu'IIS puisse mettre en cache l'état d'authentification d'un utilisateur côté serveur d'une manière telle que le passage d'un ticket non forwardable à un ticket forwardable ne fonctionnera pas.
Les paramètres de cette section contrôlent si Berserko tente l'authentification Kerberos « réactive » (c'est-à-dire attendre une réponse 401 du serveur puis renvoyer la requête avec un en-tête d'authentification Kerberos ajouté) ou « proactive » (c'est-à-dire ajouter l'en-tête d'authentification Kerberos à la requête sortante).
L'avantage de l'authentification proactive est qu'elle ne nécessite qu'un seul aller-retour HTTP, tandis que l'authentification réactive en nécessite deux. L'inconvénient de l'authentification proactive est qu'il est possible que des en-têtes d'authentification Kerberos soient envoyés à des hôtes qui ne les attendent pas. Berserko est également plus à même de diagnostiquer les erreurs d'authentification lorsqu'il utilise la stratégie réactive.
L'option Proactive Kerberos authentication, only after initial 401 received est un hybride de ces deux approches, où Berserko s'authentifie de manière réactive à la première requête vers un hôte, mais devient ensuite proactif.
Dans cette section, vous pouvez définir quels hôtes sont considérés comme dans le périmètre de l'authentification Kerberos.
Par défaut, la case All hosts in this Kerberos domain in scope for Kerberos est cochée. Cela signifie que Berserko ne tentera l'authentification Kerberos qu'auprès des serveurs web dont le nom d'hôte se termine par le nom DNS du domaine. Dans de nombreuses situations, cela sera suffisant. Cependant, il est possible d'avoir des applications web compatibles Kerberos avec un nom d'hôte qui ne prend pas cette forme (en supposant que l'administrateur a configuré un Service Principal Name approprié). Pour en tenir compte, vous pouvez ajouter des hôtes supplémentaires à considérer dans le périmètre à l'aide de la liste à droite. Notez que les jokers peuvent être utilisés (* correspond à zéro ou plusieurs caractères, ? correspond à n'importe quel caractère sauf un point).
Alternativement, vous pouvez cocher la case All hosts in scope for Kerberos authentication. Cela présente évidemment l'avantage de ne pas avoir à spécifier manuellement le périmètre. L'inconvénient potentiel de cette configuration est qu'elle pourrait amener Berserko à envoyer des requêtes Kerberos au KDC pour acquérir des tickets de service pour des hôtes qui ne sont pas dans le domaine. Cela pourrait entraîner des problèmes de performances et des problèmes de confidentialité (si vous ne voulez pas que ces informations soient divulguées au KDC). Cela risque d'être un problème particulier avec la stratégie Proactive Kerberos authentication, auquel cas Berserko essaiera d'ajouter un en-tête d'authentification Kerberos à chaque requête passant par Burp. Cette combinaison d'options n'est pas recommandée, et Berserko vous avertira si elle est sélectionnée (mais sans réellement l'empêcher).
Si ni All hosts in this Kerberos domain in scope for Kerberos ni All hosts in scope for Kerberos authentication ne sont sélectionnés, les seuls hôtes dans le périmètre seront ceux ajoutés à la liste.
L'option Plain hostnames considered part of domain, si elle est sélectionnée, signifie que les « noms d'hôte simples » (c'est-à-dire les noms d'hôte composés d'un seul élément) seront considérés comme faisant partie du domaine (et donc automatiquement dans le périmètre si All hosts in this Kerberos domain in scope for Kerberos est sélectionné). La principale raison pour laquelle vous pourriez vouloir désactiver cette option serait si votre machine était jointe à un domaine différent de celui contre lequel vous vous authentifiez avec Berserko (dans ce cas, les noms d'hôte simples se réfèrent probablement à des hôtes du domaine auquel vous êtes joint).
Si elle est sélectionnée, l'option Do not perform Kerberos authentication to servers which support NTLM demandera à Berserko de ne pas tenter l'authentification Kerberos contre les hôtes qui prennent en charge NTLM en plus de Kerberos (c'est-à-dire les hôtes qui renvoient à la fois les en-têtes WWW-Authenticate: NTLM et WWW-Authenticate: Negotiate).
Le Alert Level et le Logging Level peuvent être configurés ici, sur NONE, NORMAL ou VERBOSE.
Alert Level contrôle la quantité d'informations envoyée à l'onglet Alerts de Burp.
Logging Level contrôle la quantité d'informations envoyée à la sortie standard de Berserko (cela peut être consulté dans l'onglet Extender). Notez que l'augmentation du Logging Level à VERBOSE fournira plus d'informations sur les erreurs ou exceptions qui pourraient survenir.
Si des approbations de domaine Kerberos sont utilisées dans votre environnement, vous pouvez trouver quelques conseils ici.
Par défaut, Berserko effectue toutes les interactions Kerberos avec le KDC en UDP (port 88). Si vous souhaitez utiliser TCP à la place, c'est possible. La raison la plus courante de procéder ainsi est probablement lorsqu'une redirection de port SSH pour le port TCP 88 est utilisée. Ajoutez simplement udp_preference_limit = 1 à votre fichier krb5.conf, pour qu'il ressemble à ceci :
[libdefaults]
forwardable = true
udp_preference_limit = 1
Il est possible de configurer le SPN qui sera utilisé pour un hôte particulier, en incluant une section [berserko_spn_hints] dans le fichier krb5.conf (voir ci-dessus). La syntaxe est indiquée ci-dessous.
[berserko_spn_hints]
[email protected]
server2.bar.org=app.domain2.local
Le serveur cible se trouve à gauche du signe égal, et le SPN à utiliser est à droite. Le realm du SPN peut éventuellement être spécifié (sinon, Berserko tentera de déterminer le realm correct comme d'habitude). N'incluez pas la partie HTTP/ du SPN ici.
Berserko n'est pas compatible avec Burp v2 antérieur à v2020.5.1. Il n'y a aucun problème avec Burp v1.
Cela est dû au fait que la version d'OpenJDK fournie avec les premières versions de Burp 2 n'inclut pas une partie de la fonctionnalité Kerberos utilisée par Berserko. Cela provoquera une erreur java.lang.ClassNotFoundException: com.sun.security.jgss.ExtendedGSSContext lors d'une tentative d'utilisation de Berserko.
La solution évidente est de passer à v2020.5.1 ou une version ultérieure. Alternativement, Berserko devrait fonctionner avec n'importe quelle version de Burp v2 si vous lancez avec une version complète de l'environnement d'exécution Java (c'est-à-dire pas celle fournie avec Burp).
En supposant que vous avez java dans votre PATH :
java -jar burpsuite_pro.jar
Voir la documentation Burp sur le lancement depuis la ligne de commande.