
Scanner automatizzato della configurazione TLS di server e client per penetration tester e ricercatori. Valuta suite di cifratura, versioni di protocollo e linee guida di sicurezza con profondità di scansione personalizzabile e output leggibile dalla macchina.
TLS-Scanner è uno strumento per assistere pentester e ricercatori di sicurezza nella valutazione delle configurazioni TLS di server e client.
Nota bene: TLS-Scanner è uno strumento di ricerca destinato a sviluppatori TLS, pentester, amministratori e ricercatori. Non ha interfaccia grafica. È alla prima versione e potrebbe contenere alcuni bug.
Per compilare e utilizzare TLS-Scanner, devi eseguire:
$ cd TLS-Scanner
$ git submodule update --init --recursive
$ mvn clean package
In alternativa, se hai fretta, puoi saltare i test usando:
$ mvn clean package -DskipTests=true
Se vuoi usare TLS-Scanner come libreria, devi installarlo con il seguente comando:
$ mvn clean install
Per eseguire TLS-Scanner devi eseguire uno dei file jar nella cartella apps/. Puoi ottenerli compilando l'app da solo o scaricando i file jar rilasciati da GitHub.
$ java -jar apps/TLS-Server-Scanner.jar -connect localhost:4433
Devi specificare un host da scansionare con il parametro -connect.
Se vuoi migliorare le prestazioni della scansione, puoi usare il parametro -threads per aumentare il numero di thread utilizzati.
Un altro parametro importante per le prestazioni è il parametro -scanDetail, che può essere usato per configurare quanto dettagliata vuoi che sia la scansione. I possibili valori, da veloce a molto dettagliato, sono: QUICK, NORMAL, DETAILED, ALL.
Il dettaglio dell'output può essere configurato con il parametro -reportDetail. Per vedere più dettagli sulle Linee Guida, usa -reportDetail ALL.
Per impostazione predefinita, i risultati vengono scritti solo sulla console. Se vuoi un output leggibile da una macchina, puoi usare -outputFile output.json per scrivere automaticamente i risultati in un file JSON.
I parametri più importanti da modificare sono -scanDetail e -reportDetail. Di seguito spieghiamo alcuni casi d'uso per questi parametri.
Per la maggior parte dei casi, le impostazioni predefinite dei parametri sono sufficienti. Questo esegue una scansione con entrambi i livelli di dettaglio impostati su NORMAL.
Se vuoi eseguire una scansione rapida e ottenere una panoramica veloce del tuo sistema, ti consigliamo di impostare entrambi i livelli di dettaglio su QUICK. Questo limita l'estensione di alcuni probe eseguiti per ridurre il tempo di esecuzione e limita il dettaglio del report per non includere informazioni molto dettagliate e tecniche.
Se vuoi valutare completamente il tuo sistema ed eseguire tutto ciò che abbiamo, ti consigliamo di impostare entrambi i livelli di dettaglio su ALL. Questo esegue completamente tutti i probe esistenti e stampa informazioni molto dettagliate per ulteriori analisi e valutazioni.
Per ottenere informazioni dettagliate su tutti i parametri possibili, usa il parametro -help o esegui il jar senza impostare alcun parametro.
Forniamo immagini docker precompilate per un facile utilizzo del TLS-Server-Scanner.
$ docker run -it --network host ghcr.io/tls-attacker/tlsscanner -connect localhost:4433
L'immagine è fatta per essere usata per la scansione di server ma contiene anche gli altri file jar. È possibile accedervi modificando l'entrypoint.
$ docker run -it --network host --entrypoint java ghcr.io/tls-attacker/tlsscanner -jar TLS-Client-Scanner.jar
Forniamo anche un Dockerfile per costruire il contenitore da soli:
$ docker build . -t tlsscanner
$ docker run -t tlsscanner
Nota bene: Non ho alcuna familiarità con le best practice Docker. Se sai come migliorare il Dockerfile, sentiti libero di aprire una pull request
I probe (TLS) a volte hanno prerequisiti necessari per eseguire uno specifico probe. Il sistema di requisiti ti permette di definire insiemi di tali requisiti che devono essere soddisfatti affinché il probe venga eseguito.
Ogni requisito offre una funzione evaluate che restituisce un valore booleano che indica se il requisito è stato soddisfatto.
I requisiti possono essere concatenati in diversi modi usando operazioni logiche ben note. Ogni requisito offre metodi di istanza and, or, not e xor per concatenare più requisiti. I seguenti probe sono attualmente implementati e possono essere usati così come sono:
FulfilledRequirement - Valuta sempre a true, utile per indicare nessun requisito.UnfulfillableRequirement - Valuta sempre a false, impedisce l'esecuzione dei probe.ProbeRequirement - Valuta a true se il/i probe specificato/i è stato eseguito.PropertyRequirement - Valuta a true se le proprietà analizzate specificate hanno un valore predefinito. Il valore può essere fornito come parametro del costruttore oppure si possono usare PropertyTrueRequirement e PropertyFalseRequirement come abbreviazione per TestResults.TRUE e TestResults.FALSE.PropertyComparatorRequirement - Valuta a se il risultato della raccolta di una proprietà analizzata è minore, uguale o maggiore di un valore costante.Oltre a questi requisiti predefiniti, è anche possibile estendere la classe Requirement anonimamente all'interno del metodo getRequirements. Se non è richiesto nulla, puoi restituire un FulfilledRequirement che valuta sempre a true.
Esempi su come usare i requisiti si trovano nei pacchetti probe di tls-client-scanner e tls-server-scanner.
@Override
public Requirement<ClientReport> getRequirements() {
return new ProbeRequirement<ClientReport>(TlsProbeType.CIPHER_SUITE)
.and(new PropertyTrueRequirement<>(TlsAnalyzedProperty.SUPPORTS_DHE));
}
trueProtocolRequirement - Valuta a true se determinate versioni di protocollo sono supportate.ExtensionRequirement - Valuta a true se determinate estensioni sono supportate dal peer remoto.OptionsRequirement - Valuta a true se sono impostati flag aggiuntivi della CLI. Attualmente usato in alcuni probe client (ALPN, SNI, ripresa della sessione).WorkingConfigRequirement - Valuta a true se è stata trovata una configurazione funzionante.