tls-attacker/tls-scannerScanner 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
[](https://hydrogen.cloud.nds.rub.de/job/TLS-Scanner/)
TLS-Scanner è uno strumento per assistere i pentester e i ricercatori di sicurezza nella valutazione delle configurazioni di server e client TLS.
**Nota bene:** *TLS-Scanner è uno strumento di ricerca destinato a sviluppatori TLS, pentester, amministratori e ricercatori. Non è presente alcuna GUI. È alla prima versione e potrebbe contenere alcuni bug.*
# Compilazione
Per compilare e utilizzare TLS-Scanner, è necessario eseguire:
```bash
$ cd TLS-Scanner
$ git submodule update --init --recursive
$ mvn clean package
```
In alternativa, se si ha fretta, è possibile saltare i test utilizzando:
```bash
$ mvn clean package -DskipTests=true
```
Se si desidera utilizzare TLS-Scanner come libreria, è necessario installarlo con il seguente comando:
```bash
$ mvn clean install
```
# Esecuzione
Per eseguire TLS-Scanner è necessario avviare uno dei file jar nella cartella apps/.
Questi possono essere ottenuti compilando l'applicazione autonomamente oppure
[scaricando i file jar rilasciati da GitHub](https://github.com/tls-attacker/TLS-Scanner/releases).
```bash
$ java -jar apps/TLS-Server-Scanner.jar -connect localhost:4433
```
TLS-Scanner valuterà il server specificato (qui `localhost` sulla porta `4433`) e, al termine, stamperà un report.
Il report utilizza i colori per comunicare la gravità dei risultati:
- Verde: Un buon risultato.
- Giallo: Un avviso, che potrebbe essere un potenziale problema.
- Sfondo giallo: Risultati in cui lo scanner non è sicuro che il target sia vulnerabile.
- Rosso: Un problema grave, che dovrebbe essere risolto.
- Colore predefinito (a seconda del terminale, probabilmente nero o bianco): Un risultato neutro, che non è né buono né cattivo. Questo include i risultati informativi.
- Blu: Lo scanner non ha potuto scansionare il server per questo specifico test. Ciò è probabilmente dovuto al fatto che un prerequisito per questo test non è supportato.
- Viola: Lo scanner ha riscontrato un errore durante la scansione del server per questo specifico test. Ciò può essere il risultato di un bug nello scanner, ma anche del fatto che il server non supporta una funzionalità richiesta.
- Ciano: Utilizzato per strutturare il report (intestazioni, ...).
## Parametri importanti
È necessario specificare un host che si desidera scansionare con il parametro -connect.
Se si desidera migliorare le prestazioni della scansione, è possibile utilizzare il parametro `-threads` per aumentare il numero di thread utilizzati.
Un altro parametro importante per motivi di prestazioni è il parametro `-scanDetail`, che può essere utilizzato per configurare quanto dettagliata si desidera che sia la scansione. I valori possibili, dal più veloce al più dettagliato, sono: QUICK, NORMAL, DETAILED, ALL.
Il dettaglio dell'output può essere configurato con il parametro `-reportDetail`. Per visualizzare maggiori dettagli sulle Linee Guida, utilizzare `-reportDetail ALL`.
Per impostazione predefinita, i risultati vengono scritti solo sulla console. Se si desidera un output leggibile dalla macchina, è possibile utilizzare `-outputFile output.json` per scrivere automaticamente i risultati in un file JSON.
## Casi d'uso
I parametri più importanti da modificare sono `-scanDetail` e `-reportDetail`. Di seguito spieghiamo alcuni casi d'uso per questi parametri.
### Scansione predefinita
Nella maggior parte dei casi, le nostre impostazioni predefinite dei parametri sono sufficienti. Questa esegue una scansione con entrambi i livelli di dettaglio impostati su `NORMAL`.
### Scansione veloce
Se si desidera eseguire una scansione veloce e ottenere una rapida panoramica del proprio sistema, si consiglia di impostare entrambi i livelli di dettaglio su `QUICK`. Questo limita l'estensione di alcune sonde eseguite per ridurre il tempo di esecuzione e limita il dettaglio del report per non includere informazioni molto dettagliate e tecniche.
### Scansione dettagliata
Se si desidera valutare completamente il proprio sistema ed eseguire tutto ciò che abbiamo, si consiglia di impostare entrambi i livelli di dettaglio su `ALL`. Questo esegue completamente tutte le sonde esistenti e stampa informazioni molto dettagliate per ulteriori analisi e valutazioni.
## Profili di scansione
Invece di (o in aggiunta a) impostare parametri come `-scanDetail` individualmente, è possibile raggruppare
quali sonde eseguire e quali di questi parametri utilizzare in un profilo di scansione JSON riutilizzabile con
il parametro `-profile <path/to/profile.json>`. È disponibile sia su `TlsServerScanner` che su
`TlsClientScanner`.
Un profilo è un file JSON con:
- `inheritedFromProfiles`: percorsi ad altri profili da cui combinare le sonde, risolti relativamente alla
directory del file di profilo che li dichiara (un percorso assoluto viene utilizzato così com'è).
- `probes`: le sonde da eseguire, come mappa dal nome completo di una classe enum `ProbeType`
alla lista dei nomi delle sue costanti da eseguire. Questo raggruppa le sonde per tipo invece di ripetere il
tipo per ogni singola sonda, mentre un singolo profilo può comunque combinare liberamente sonde da
diverse implementazioni di `ProbeType`, ad esempio `TlsProbeType` e `QuicProbeType`. Ogni lista per tipo
accetta anche `"*"` (tutte le costanti di quel tipo) e `"!CONSTANT_NAME"` (rimuove una costante
precedentemente aggiunta per nome o tramite `"*"`), elaborati in ordine — vedere `Everything.json` e
`demo.json` in [`scan-profiles/`](https://github.com/tls-attacker/tls-scanner/blob/main/scan-profiles) per esempi.
- `settings` (opzionale): override per parametri come `-scanDetail`, `-reportDetail`,
`-postAnalysisDetail`, `-noColor`, `-outputFile`, `-probeTimeout`, `-parallelProbes` e
`-threads`. Qualsiasi campo omesso mantiene il suo valore predefinito normale (o qualunque valore sia stato passato sulla riga
di comando). **A differenza di `probes`, i `settings` non vengono ereditati** — si applicano solo le impostazioni dichiarate direttamente sul
profilo a cui si punta `-profile`, anche se questo eredita sonde da altri profili.
Vengono eseguite solo le sonde risolte dal profilo attivo (e da tutto ciò da cui eredita);
tutto il resto viene saltato.
Esempio, che combina le sonde di un profilo base con le proprie e regola il dettaglio della scansione:
`base.json`:
```json
{
"probes": {
"de.rub.nds.tlsscanner.core.constants.TlsProbeType": ["PROTOCOL_VERSION", "CIPHER_SUITE"]
}
}
```
`quic.json` (nella stessa directory di `base.json`):
```json
{
"inheritedFromProfiles": ["base.json"],
"settings": {
"scanDetail": "QUICK"
},
"probes": {
"de.rub.nds.tlsscanner.core.constants.QuicProbeType": ["SUPPORTED_VERSIONS"]
}
}
```
```bash
$ java -jar apps/TLS-Server-Scanner.jar -connect localhost:4433 -profile quic.json
```
Questo esegue `PROTOCOL_VERSION`, `CIPHER_SUITE` e `SUPPORTED_VERSIONS` con `-scanDetail QUICK`.
Per vedere tutte le sonde disponibili per uno scanner (senza connettersi a un target), utilizzare `-listProbes`.
Le stampa raggruppate per classe `ProbeType` nella sintassi JSON esatta che il campo `probes` di un profilo
si aspetta, così è possibile copiarle e incollarle direttamente in un profilo:
```bash
$ java -jar apps/TLS-Server-Scanner.jar -listProbes
{
"de.rub.nds.tlsscanner.core.constants.TlsProbeType" : [ "ALPN", "ESNI", "CERTIFICATE", ... ],
"de.rub.nds.tlsscanner.core.constants.QuicProbeType" : [ "SUPPORTED_VERSIONS", ... ]
}
```
## Tutti i parametri
Per ottenere informazioni dettagliate su tutti i parametri possibili, utilizzare il parametro `-help` o eseguire il jar senza alcun parametro impostato.
# Docker
Forniamo immagini Docker precompilate per un facile utilizzo del TLS-Server-Scanner.
```bash
$ docker run -it --network host ghcr.io/tls-attacker/tlsscanner -connect localhost:4433
```
L'immagine è pensata per essere utilizzata per la scansione dei server ma contiene anche gli altri file jar.
È possibile accedervi modificando l'entrypoint.
```bash
$ docker run -it --network host --entrypoint java ghcr.io/tls-attacker/tlsscanner -jar TLS-Client-Scanner.jar
```
Forniamo anche un Dockerfile, per costruire il container autonomamente:
```bash
$ docker build . -t tlsscanner
$ docker run -t tlsscanner
```
**Nota bene:** *Non ho assolutamente familiarità con le best practice di Docker. Se sai come migliorare il Dockerfile
sentiti libero di inviare una pull request*
# Sistema dei requisiti
Le sonde (TLS) a volte hanno prerequisiti necessari per eseguire questa specifica sonda. Il sistema dei requisiti consente di definire insiemi di tali requisiti che devono essere soddisfatti affinché la sonda venga eseguita.
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 utilizzando operazioni logiche ben note. Ogni requisito offre i metodi di istanza `and`, `or`, `not` e `xor`
per concatenare più requisiti. Le seguenti sonde sono attualmente implementate e possono essere utilizzate immediatamente:
- `FulfilledRequirement` - Valuta sempre `true`, utile per indicare nessun requisito.
- `UnfulfillableRequirement` - Valuta sempre `false`, impedisce l'esecuzione delle sonde.
- `ProbeRequirement` - Valuta `true` se la/le sonda/e specificata/e è stata eseguita.
- `PropertyRequirement` - Valuta `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 scorciatoia per `TestResults.TRUE` e `TestResults.FALSE`.
- `PropertyComparatorRequirement` - Valuta `true` se il risultato della collezione di una proprietà analizzata è minore, uguale o maggiore di un valore costante.
- `ProtocolRequirement` - Valuta `true` se determinate versioni di protocollo sono supportate.
- `ExtensionRequirement` - Valuta `true` se determinate estensioni sono supportate dal peer remoto.
- `OptionsRequirement` - Valuta `true` se sono impostati flag cli aggiuntivi. Attualmente utilizzato in alcune sonde client (ALPN, SNI, ripresa della sessione).
- `WorkingConfigRequirement` - Valuta `true` se è stata trovata una configurazione funzionante.
Oltre a questi requisiti predefiniti, si può anche estendere la classe `Requirement` in modo anonimo all'interno del metodo `getRequirements`. Se non è richiesto nulla, è possibile restituire un `FulfilledRequirement` che valuta sempre true.
Esempi su come utilizzare i requisiti si possono trovare nei pacchetti `probe` di `tls-client-scanner` e `tls-server-scanner`.
```java
@Override
public Requirement<ClientReport> getRequirements() {
return new ProbeRequirement<ClientReport>(TlsProbeType.CIPHER_SUITE)
.and(new PropertyTrueRequirement<>(TlsAnalyzedProperty.SUPPORTS_DHE));
}
```