nccgroup/berserkoEstensione di Burp Suite per eseguire l'autenticazione Kerberos
Rilasciato come open source da NCC Group Plc - http://www.nccgroup.trust/
Sviluppato da Richard Turnbull, richard [dot] turnbull [at] nccgroup [dot] com
http://www.github.com/nccgroup/Berserko
Rilasciato sotto licenza AGPL, vedi LICENSE per maggiori informazioni
L'ulteriore sviluppo di Berserko avverrà su https://github.com/rteatea/Berserko
Berserko è un'estensione di Burp per aggiungere il supporto all'autenticazione Kerberos. È utile per i test in un dominio Windows quando l'autenticazione NTLM non è supportata (Burp gestisce già NTLM). Berserko non richiede che la macchina su cui gira Burp sia membro del dominio (o che esegua Windows).
L'unica soluzione esistente che conosciamo attualmente per testare applicazioni Kerberos usando Burp è quella di passare attraverso Fiddler, con l'autenticazione configurata secondo queste istruzioni. Ma Fiddler è disponibile solo per Windows, e concatenare i proxy aggiunge complessità e penalizza le prestazioni, quindi è bello avere la funzionalità Kerberos direttamente in Burp.
Scarica l'ultimo file jar di Berserko dalla scheda Releases o dalla cartella berserko\releases
Vai alla scheda Extender in Burp, seleziona Add, assicurati che Java sia selezionato come Extension type, e poi indica il file jar. Se tutto funziona, la scheda Berserko dovrebbe essere aggiunta all'interfaccia di Burp.
Ci sono vari controlli nella scheda Berserko in Burp.
La casella Do Kerberos authentication è un interruttore generale. Finchè non viene abilitata, Berserko non fa assolutamente nulla.
Il pulsante Restore defaults riporta Berserko alla configurazione predefinita (in cui non sono presenti dettagli del dominio o credenziali utente).
Il pulsante Clear Kerberos state cancella tutti i ticket Kerberos e altro stato sul client. L'unico motivo per cui potresti aver bisogno di usarlo è se sono state apportate modifiche alla configurazione Kerberos lato server e vuoi ripartire da uno stato pulito.
Il pulsante Write tickets to log scrive informazioni sui tuoi ticket Kerberos correnti nello stream di log di Berserko: può essere utile per il debug/risoluzione dei problemi. Per vedere i log, vai alla scheda Extender di Burp, seleziona Berserko e osserva la scheda Output qui sotto. Potrebbe avere senso usare l'opzione Save to file, perché i dati dei ticket possono facilmente riempire il buffer di log nella GUI.
Alcuni controlli hanno un pulsante di aiuto che mostra ulteriori informazioni.
Specifica il Domain DNS Name e il KDC Host usando i controlli di questa sezione. Le caselle di testo non possono essere modificate direttamente; devi usare il pulsante 'Change' per modificarle.
Il Domain DNS Name dovrebbe essere il nome DNS del dominio contro cui desideri autenticarti (per essere precisi, in realtà è il realm Kerberos). Dovrebbe essere qualcosa come mydomain.acme.local. Non dovrebbe essere il nome NETBIOS del dominio (che sarebbe qualcosa come MYDOMAIN).
Il KDC Host dovrebbe essere il nome host (o indirizzo IP) di un KDC Kerberos (Key Distribution Center). In un dominio Windows, un KDC è semplicemente un controllore di dominio.
Dopo aver fornito il Domain DNS Name, puoi usare il pulsante Auto per tentare di individuare automaticamente un KDC. Lo fa inviando una query DNS SRV per il servizio Kerberos. Se uno dei tuoi server DNS è un controllore di dominio per il dominio corretto, dovrebbe funzionare. In caso contrario, non funzionerà. ❗Questa funzionalità non funzionerà nelle versioni recenti di Burp, poiché le librerie DNS richieste non vengono distribuite con la JRE inclusa. Puoi aggirare il problema avviando con una JRE completa come descritto all'inizio di questo README.❗
Quando sono stati inseriti il Domain DNS Name e il KDC Host, usa il pulsante Test domain settings per verificare la connettività. Se tutto va bene, riceverai una risposta Successfully contacted Kerberos service.
Vedi questo file per molte altre informazioni su come ottenere i valori corretti per queste impostazioni di dominio.
Specifica l'Username e la Password per un account di dominio usando i controlli di questa sezione. Le caselle di testo non possono essere modificate direttamente; devi usare il pulsante 'Change' per modificarle.
L'Username dovrebbe essere solo il nome utente semplice. Dovrebbe essere qualcosa come bob. Non dovrebbe essere MYDOMAIN\bob o [email protected] o simili.
Dopo aver fornito le credenziali, puoi usare il pulsante Test credentials. Questo tenterà di acquisire un ticket-granting ticket Kerberos per l'utente specificato. In caso di successo, riceverai una risposta TGT successfully acquired. In caso di insuccesso, tieni presente che si tratta di un tentativo di autenticazione al dominio, quindi fai attenzione a non bloccare il tuo account.
La password non verrà salvata nella configurazione di Berserko per la volta successiva a meno che la casella Save password in Burp config? non sia spuntata. Tutte le altre impostazioni verranno comunque salvate.
Alcune applicazioni usano la delega Kerberos lato server per inoltrare l'identità del client ad altri server (ma non esiste un modo semplice per determinare dal lato client se questa funzionalità è in uso).
Berserko la supporta, ma c'è un problema. La delega funziona solo se l'utente ha un TGT (ticket-granting ticket) forwardable. Purtroppo l'implementazione Java di Kerberos non fornisce un modo per specificare a livello di programmazione che debba essere acquisito un ticket forwardable. Questo può essere fatto solo aggiungendo una voce appropriata al file di configurazione krb5.conf.
Quindi, perché la delega funzioni, Berserko deve essere puntato a un file krb5.conf adatto, e ci sono due possibili approcci.
La cosa più semplice, e l'approccio raccomandato, è usare il pulsante Create krb5.conf file. Questo creerà un file adatto per te in una posizione a tua scelta. Puoi metterlo in una directory temporanea, nella directory del tuo progetto, o dove preferisci. Ma lo stesso file può essere riutilizzato indefinitamente, quindi potrebbe avere senso metterlo in un posto più permanente. Il pulsante Change ti permette di selezionare un file diverso da usare.
Se sei interessato, il file krb5.conf che viene creato è molto semplice e avrà il seguente contenuto:
[libdefaults]
forwardable = true
In alternativa, puoi usare il pulsante Change per puntare a un file krb5.conf già esistente sul sistema. L'unico motivo per cui potresti volerlo fare è se nel file ci fossero altre importanti impostazioni Kerberos che vuoi che Berserko rilevi (che in teoria dovrebbe funzionare, ma non è stato testato nella pratica). Nota che la posizione predefinita di questo file su Linux è /etc/krb5.conf: altri sistemi operativi hanno meno probabilità di averne uno. Se stai puntando a un file krb5.conf esistente, assicurati di modificarlo per abilitare l'inoltro: aggiungi forwardable = true alla sezione [libdefaults] (o singolarmente per ogni realm). Ma fai attenzione. Chiedere a Berserko di creare il file per te sarà l'opzione migliore nel 99% dei casi.
Se vuoi sapere se la tua configurazione di delega ha avuto successo, usa il pulsante Check current config. Ti dirà se il file krb5.conf è stato individuato e se l'impostazione forwardable è corretta. Nota anche che Berserko ti dirà se è riuscito ad acquisire un TGT forwardable quando usi il pulsante Test credentials.
È una buona idea assicurarti di avere un ticket forwardable prima di iniziare a usare un'applicazione. Sembra che IIS possa memorizzare nella cache lo stato di autenticazione di un utente lato server in un modo tale che il passaggio da un ticket non forwardable a uno forwardable non funzioni.
Le impostazioni di questa sezione controllano se Berserko tenta l'autenticazione Kerberos in modo 'reattivo' (cioè attende una risposta 401 dal server e poi invia nuovamente la richiesta con un header di autenticazione Kerberos aggiunto) o 'proattivo' (cioè aggiunge l'header di autenticazione Kerberos alla richiesta in uscita).
Il vantaggio dell'autenticazione proattiva è che richiede un solo round trip HTTP, mentre l'autenticazione reattiva ne richiede due. Lo svantaggio dell'autenticazione proattiva è che è possibile che header di autenticazione Kerberos vengano inviati a host che non se li aspettano. Berserko è anche più in grado di diagnosticare errori di autenticazione quando usa la strategia reattiva.
L'opzione Proactive Kerberos authentication, only after initial 401 received è un ibrido di questi due approcci, in cui Berserko autentica in modo reattivo alla prima richiesta verso un host, ma successivamente in modo proattivo.
In questa sezione puoi definire quali host sono considerati nell'ambito dell'autenticazione Kerberos.
Per impostazione predefinita, la casella All hosts in this Kerberos domain in scope for Kerberos sarà spuntata. Questo significa che Berserko tenterà l'autenticazione Kerberos solo verso server web il cui nome host termina con il nome DNS del dominio. In molte situazioni questo è sufficiente. Tuttavia, è possibile avere applicazioni web abilitate a Kerberos con un nome host che non assume questa forma (supponendo che l'amministratore abbia configurato un Service Principal Name adatto). Per tenerne conto, puoi aggiungere host aggiuntivi da considerare nell'ambito usando la casella di riepilogo a destra. Nota che si possono usare caratteri jolly (* corrisponde a zero o più caratteri, ? corrisponde a qualsiasi carattere tranne un punto).
In alternativa, puoi spuntare la casella All hosts in scope for Kerberos authentication. Ovviamente questo ha il vantaggio di non doversi preoccupare di specificare manualmente l'ambito. Il potenziale svantaggio di questa configurazione è che potrebbe portare Berserko a inviare richieste Kerberos al KDC per acquisire ticket di servizio per host che non sono nel dominio. Questo potrebbe causare problemi di prestazioni e problemi di privacy (se non vuoi che queste informazioni vengano divulgate al KDC). Questo è probabilmente un problema particolare con la strategia Proactive Kerberos authentication, nel qual caso Berserko proverà ad aggiungere un header di autenticazione Kerberos a ogni richiesta che passa attraverso Burp. Questa combinazione di opzioni non è raccomandata, e Berserko ti avviserà se viene selezionata (ma non la impedirà).
Se non sono selezionate né All hosts in this Kerberos domain in scope for Kerberos né All hosts in scope for Kerberos authentication, gli unici host nell'ambito saranno quelli aggiunti alla casella di riepilogo.
L'opzione Plain hostnames considered part of domain, se selezionata, significa che i 'plain hostnames' (cioè nomi host composti da un solo componente) saranno considerati parte del dominio (e quindi automaticamente nell'ambito se All hosts in this Kerberos domain in scope for Kerberos è selezionata). Il motivo principale per cui potresti voler disabilitare questa opzione è se la tua macchina è unita a un dominio diverso da quello contro cui ti autentichi usando Berserko (in tal caso, i plain hostnames probabilmente si riferiscono a host nel dominio a cui sei unito).
Se selezionata, l'opzione Do not perform Kerberos authentication to servers which support NTLM ordinerà a Berserko di non tentare l'autenticazione Kerberos verso host che supportano NTLM oltre a Kerberos (cioè host che restituiscono sia header WWW-Authenticate: NTLM che WWW-Authenticate: Negotiate).
L'Alert Level e il Logging Level possono essere configurati qui, su NONE, NORMAL o VERBOSE.
L'Alert Level controlla la quantità di informazioni inviate alla scheda Alerts di Burp.
Il Logging Level controlla la quantità di informazioni inviate all'output standard di Berserko (che può essere visualizzato nella scheda Extender). Nota che aumentare il Logging Level a VERBOSE fornirà più informazioni su eventuali errori o eccezioni che potrebbero verificarsi.
Se nel tuo ambiente sono in uso trust di dominio Kerberos, puoi trovare alcune indicazioni qui.
Per impostazione predefinita, Berserko esegue tutte le interazioni Kerberos con il KDC su UDP (porta 88). Se vuoi usare TCP, è possibile. Il motivo più comune per farlo è probabilmente quando è in uso un forward SSH della porta TCP 88. Basta aggiungere udp_preference_limit = 1 al tuo file krb5.conf, in modo che appaia così:
[libdefaults]
forwardable = true
udp_preference_limit = 1
È possibile configurare l'SPN che verrà usato per un determinato host, includendo una sezione [berserko_spn_hints] nel file krb5.conf (vedi sopra). La sintassi è mostrata di seguito.
[berserko_spn_hints]
[email protected]
server2.bar.org=app.domain2.local
Il server di destinazione è sul lato sinistro del segno di uguale, e l'SPN da usare è sul lato destro. Il realm per l'SPN può essere specificato opzionalmente (se non lo è, Berserko tenterà di determinare il realm corretto come al solito). Non includere la parte HTTP/ dell'SPN qui.
Berserko non è compatibile con Burp v2 precedente alla v2020.5.1. Non ci sono problemi con Burp v1.
Questo è causato dal fatto che la versione di OpenJDK distribuita con le versioni precedenti di Burp 2 non include parte della funzionalità Kerberos usata da Berserko. Questo causerà un errore java.lang.ClassNotFoundException: com.sun.security.jgss.ExtendedGSSContext quando si tenta di usare Berserko.
La soluzione ovvia è aggiornare alla v2020.5.1 o successiva. In alternativa, Berserko dovrebbe funzionare con qualsiasi versione di Burp v2 se lo avvii usando una versione completa dell'ambiente di runtime Java (cioè non quella inclusa con Burp).
Supponendo che tu abbia java nel PATH:
java -jar burpsuite_pro.jar