Un Slackbot de test de sécurité construit avec un backend Kubernetes sur Google Cloud Platform
NOTE : Je ne maintiens plus activement ce projet. Je travaille sur la v2 de Kubebot avec quelques autres personnes, qui sera probablement présentée lors d'une prochaine conférence de sécurité.
1 - Une requête API (outil, cible, options) initiée depuis Slackbot est envoyée au serveur API, qui s'exécute en tant que conteneur Docker sur un cluster Kubernetes (K8s) et peut être mis à l'échelle.
2 - Le serveur API dépose la requête reçue sous forme de message dans un sujet PubSub Tool.
3 - Les messages sont publiés dans l'abonnement Tool.
4 - Un ou plusieurs abonnés Worker, s'exécutant en tant que conteneurs Docker sur le cluster K8s, consomment le message depuis l'abonnement. Le nombre de ces workers peut également être mis à l'échelle.
5 - Selon l'outil, la cible et les options reçus de l'utilisateur final, des Workers Tool appropriés sont lancés dans le même cluster K8s en tant que conteneurs Docker. Les résultats sont stockés temporairement dans un répertoire local de ce conteneur. Le répertoire Github de cet outil est cloné.
6 - Une vérification est effectuée pour voir si le fichier de résultats généré existait ou non. S'il n'existait pas, il est ajouté et les modifications sont poussées vers Github. S'il existe, les fichiers sont comparés, le nouveau fichier est poussé vers Github et seules les modifications sont transmises à l'étape suivante.
7 - Un webhook depuis les Workers Tool renvoie les modifications à Slack. Les workers Tool sont supprimés car ils ne sont plus nécessaires.
PS - Toutes les images Docker du serveur API, des abonnés Worker et des Workers Tool sont téléchargées depuis Google Container Registry de ce compte GCP avant d'être déployées sur le cluster K8s.
Liste des outils intégrés jusqu'à présent (Cette liste sera mise à jour au fur et à mesure que de nouveaux outils seront ajoutés. Il y a quelques outils supplémentaires dans le dossier tools mais ils sont encore en cours de développement.)
api - Contient tout le code du serveur API Kubebot.
config - Contient les fichiers de configuration pour déployer les composants Kubebot.
cronjobs - Contient un exemple de fichier de déploiement (.yaml) pour configurer des cronjobs exécutant un outil spécifique à un intervalle donné et renvoyant les résultats à Slack via un webhook.
Un conteneur utilitaire appelé checkfile est utilisé pour effectuer l'opération de diff sur les fichiers github afin d'identifier les changements entre l'exécution précédente d'un outil et la dernière exécution. Ce conteneur est exécuté après chaque conteneur d'outil.
Un utilitaire appelé converttobq est utilisé pour convertir les données des outils dans un format ingérable par BigQuery. Cet utilitaire est utilisé dans les workflows d'automatisation où les résultats de chaque outil sont stockés dans BQ pour pouvoir être consommés par d'autres outils.
Un utilitaire appelé wfuzzbasicauthbrute est utilisé pour forcer brutement le mécanisme d'authentification de base des points de terminaison stockés dans une table BQ avec tous les secrets stockés dans une autre table BQ.
.env.sample - Renommez ce fichier en .env et assurez-vous que les valeurs sont correctes lorsque vous souhaitez déployer Kubebot localement.
Makefile - Makefile pour construire votre environnement Kubebot.
Pour commencer
Prérequis - Veuillez vous assurer que tous ces prérequis sont remplis.
Exécution de Kubebot localement - C'est un bon point de départ pour se familiariser avec Kubebot avant de l'exécuter à distance.
Exécution de Kubebot à distance - Une fois que vous êtes sûr que Kubebot fonctionne comme prévu localement (en utilisant Minikube) et que vous souhaitez maintenant le déployer et l'utiliser pleinement dans le cloud, il peut être déployé sur un cluster Google Container Engine (GKE). Cependant, je ne peux pas encore fournir d'instructions pour le déploiement à distance. Cela dit, si cela vous intéresse, je serai ravi de vous aider. Et si vous souhaitez simplement utiliser Kubebot comme une application Slack sans vous soucier de l'infrastructure backend, cela peut également être arrangé pour un petit abonnement mensuel, car j'hébergerai le backend sur mon compte GCP personnel et vous seriez uniquement responsable des coûts normaux liés à l'hébergement d'un VPS chez un fournisseur cloud. N'hésitez pas à me contacter pour discuter de ces options.
Remarquez comment vous pouvez exécuter une commande slash avec le nom de l'outil, les options et la ou les cibles. Je dis "cible(s)" car vous pouvez exécuter une commande slash pour exécuter un outil avec un ensemble d'options contre plusieurs cibles. Par exemple, la commande gitrob ci-dessous est exécutée contre test et abc.
/runtool nmap|-Pn -p 1-1000|google.com
/runtool sublist3r|-t 50|test.com
/runtool gobuster|-m dns -w fierce_hostlist.txt -t 10 -fw|google.com
root@kitploit:~
PS - Liste de mots à choisir :
bitquark_20160227_subdomains_popular_1000000.txt
deepmagic.com_top500prefixes.txt
fierce_hostlist.txt
namelist.txt
names.txt
sorted_knock_dnsrecon_fierce_recon-ng.txt
subdomains-top1mil-110000.txt
/runtool enumall|-s shodan-api-key|test.com
/runtool subbrute|-s subfiles/names.txt -v|kubebot.io (Cette opération prend beaucoup de temps)
anshumanbh/kubebot
