Un Slackbot per test di sicurezza basato su un backend Kubernetes su Google Cloud Platform
NOTA: Non sto più mantenendo attivamente questo progetto. Sto lavorando alla v2 di Kubebot insieme ad altre persone, che verrà probabilmente presentata a una delle prossime conferenze di sicurezza.
1 - Richiesta API (strumento, target, opzioni) avviata da Slackbot, inviata al server API, che gira come container Docker su un cluster Kubernetes (K8s) e può essere scalato.
2 - Il server API inserisce la richiesta ricevuta come messaggio in un Topic PubSub per gli strumenti.
3 - I messaggi vengono pubblicati nella Sottoscrizione dello strumento.
4 - Uno o più Subscription Worker, in esecuzione come container Docker sul cluster K8s, consumano il messaggio dalla sottoscrizione. Anche questi worker possono essere scalati.
5 - A seconda dello strumento, del target e delle opzioni ricevute dall'utente finale, vengono avviati gli appropriati Tool Worker nello stesso cluster K8s come container Docker. I risultati vengono memorizzati temporaneamente in una directory locale di quel container. Viene clonata la directory Github di quello strumento.
6 - Viene verificato se il file dei risultati generati esisteva già. Se non esisteva, viene aggiunto e le modifiche vengono inviate a Github. Se esiste, i file vengono confrontati, il nuovo file viene inviato a Github e solo le modifiche vengono passate al passaggio successivo.
7 - Un webhook dai Tool Worker invia le modifiche a Slack. I tool worker vengono eliminati perché non più necessari.
PS - Tutte le immagini Docker del server API, dei Subscription Worker e dei Tool Worker vengono scaricate dal Google Container Registry di quell'account GCP prima di essere distribuite sul cluster K8s.
Elenco degli strumenti integrati finora (Questo elenco verrà aggiornato man mano che verranno aggiunti altri strumenti. Ci sono alcuni strumenti aggiuntivi nella cartella tools, ma sono ancora in fase di sviluppo.)
api - Contiene tutto il codice per il server API di Kubebot.
config - Contiene i file di configurazione per distribuire i componenti di Kubebot.
cronjobs - Contiene un file di distribuzione di esempio (.yaml) per impostare cronjob che eseguono uno strumento specifico a un intervallo specifico e inviano i risultati a Slack tramite un Webhook.
Un contenitore utility chiamato checkfile viene utilizzato per eseguire l'operazione di diff sui file di github per identificare eventuali cambiamenti rispetto all'esecuzione precedente di uno strumento con l'esecuzione più recente. Questo contenitore viene eseguito dopo ogni contenitore dello strumento.
Un'utility chiamata converttobq viene utilizzata per convertire i dati degli strumenti in un formato ingeribile da BigQuery. Questa utility viene eseguita nei flussi di lavoro automatizzati in cui i risultati di ogni strumento vengono memorizzati in BQ per poter essere consumati da altri strumenti.
Un'utility chiamata wfuzzbasicauthbrute viene utilizzata per forzare la bruteforce del meccanismo di autenticazione di base degli endpoint memorizzati in una tabella BQ con tutti i segreti memorizzati in un'altra tabella BQ
.env.sample - Rinomina questo file in .env e assicurati che i valori siano corretti quando desideri distribuire Kubebot localmente.
Makefile - makefile per costruire il tuo ambiente Kubebot.
Per iniziare
Prerequisiti - Assicurati che tutti questi prerequisiti siano soddisfatti.
Esecuzione locale di Kubebot - Questo è un buon punto di partenza per familiarizzare con Kubebot prima di eseguirlo in remoto.
Esecuzione remota di Kubebot - Una volta che sei sicuro che Kubebot funzioni come previsto in locale (usando Minikube) e ora desideri scatenarlo e usarlo al massimo delle sue potenzialità nel cloud, può essere distribuito su un cluster Google Container Engine (GKE). Tuttavia, non posso ancora fornire istruzioni per la distribuzione remota. Detto questo, se c'è interesse, sarò felice di aiutare. E, se desideri semplicemente usare Kubebot come app Slack senza preoccuparti dell'infrastruttura backend, anche questo può essere organizzato con un piccolo abbonamento mensile, dato che ospiterò il backend nel mio account GCP personale e tu saresti responsabile solo dei normali costi di hosting di un VPS su un provider cloud. Sentiti libero di contattarmi per discutere queste opzioni.
Nota come puoi eseguire un comando slash con il nome dello strumento, le opzioni e il/i target. Dico target perché puoi eseguire un comando slash per eseguire uno strumento con un set di opzioni contro più target. Ad esempio, il comando gitrob qui sotto viene eseguito contro test e 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 - Wordlist tra cui scegliere:
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 (Ci vuole molto tempo)
anshumanbh/kubebot
