Ho visto nel mio server Apache2 dei messaggi come
[ssl:error] [pid 28482] AH02032: Hostname xxx.yyy.zzz.www:443 provided via SNI and hostname xxx.yyy.zzz.www provided via HTTP are different
Uno di questi messaggi di errore è stato attivato da una richiesta da researchscan367.eecs.umich.edu , quindi presumo che stiano cercando una vulnerabilità nota. Quale tipo di vulnerabilità o attacco è stato prevenuto dall'errore?
What kind of vulnerability or attack vector is prevented by the error?
L'attacco si chiama "confusione dell'host virtuale" e nel 2014 molti CDN sono stati trovati vulnerabili contro di esso . L'idea principale è una mancata corrispondenza tra il nome di destinazione nell'handshake TLS ( "fornito tramite SNI" ) e il nome di destinazione nel protocollo HTTP ( "fornito via HTTP" ) può essere sfruttato. A seconda della configurazione del server potrebbe essere utilizzato per impersonare i siti HTTPS di proprietà di altri che possono anche essere utilizzati per rubare cookie di sessione, ecc.
Per maggiori informazioni leggere il documento "Attacchi di confusione all'origine basati sulla rete contro HTTPS Virtual Hosting ", leggi le informazioni su HackerOne , guarda un video di come questo attacco aiuta a "utilizza Akamai per aggirare la censura di Internet" o guarda il discorso al Blackhat 2014 dove questo e altri attacchi contro TLS sono stati dimostrati.
Server Name Indication (SNI) è un'estensione TLS che consente a un client TLS di indicare quale host sta tentando di raggiungere. Questo è importante per i server Web con host virtuali (cioè più domini ospitati da una casella) in modo che possano decidere quale certificato restituire. Normalmente l'host virtuale di destinazione viene rilevato tramite l'intestazione HTTP Host , ma non può essere inviato prima che venga creato un tunnel TLS. SNI consente al client TLS di indicare il nome in modo che possa essere offerto il certificato corretto, prima che venga effettuata la chiamata HTTP sottostante. Un'altra caratteristica della maggior parte dei server TLS è che SNI può essere utilizzato per scegliere tra diverse configurazioni TLS che sono state configurate per ciascun host virtuale.
Dato che ora hai due indicatori su quale host stavi tentando di raggiungere (intestazione SNI e Host) potrebbero esserci comportamenti strani se imposti loro di non corrispondere. Ora immagina una situazione in cui hai un sito che utilizza HTTPS, ma anche un sottodominio amministrativo e sono entrambi ospitati sullo stesso server. Il sottodominio amministrativo è bloccato a livello di configurazione SNI in modo che richieda un certificato client. Ciò significa che l'utilizzo regolare del sito esegue solo il normale HTTPS, ma è necessario un certificato client per connettersi al sottodominio di amministrazione.
Tuttavia, se si dovesse fare una richiesta in cui l'SNI punta al dominio principale, ma l'intestazione Host punta al sottodominio amministrativo, è possibile costruire il tunnel TLS senza il certificato client (poiché vengono utilizzate le regole del sito principale) ma il server web può pubblicare contenuti come se ci si stesse connettendo al sottodominio amministrativo. Ciò potrebbe consentire di ignorare la restrizione del certificato client.
Se hai una configurazione in cui un frontend leggero utilizza SNI per inviare richieste tra diversi server HTTPS, il controllo extra eseguito da Apache protegge da richieste non valide utilizzate per accedere a contenuti che altrimenti sarebbero inaccessibili.
Poiché il campo SNI si trova nel client TLS, il messaggio ciao viene inviato dal client prima che qualsiasi cosa sia stata inviata dal server, è possibile costruire un frontend leggero che non sappia nulla di HTTP e molto poco su TLS ma che sia ancora in grado di inviare Connessioni TLS a diversi backend in base al nome host.
Un front-end di questo tipo dovrebbe conoscere solo un numero sufficiente di TLS per analizzare il messaggio di benvenuto del client ed estrarre il nome host. Una volta che è in grado di passare tutti i dati non modificati per separare i back-end HTTPS. Solo i backend hanno bisogno della chiave del server necessaria per stabilire la connessione TLS.
In questa configurazione il frontend non sarà mai in grado di sapere quale nome host è stato mandato nell'intestazione dell'host HTTP perché non può decodificare il traffico. Quindi è impossibile per un front-end confrontare i due nomi host.
Questa configurazione consente a più domini di essere ospitati dietro un singolo indirizzo IP, anche se i server HTTPS non sanno nulla di SNI. Tuttavia se i server HTTPS non sanno nulla di SNI, è possibile che un client invii una richiesta corrotta in cui frontend e backend vedono due hostname diversi per la stessa richiesta HTTPS.
È possibile configurare il frontend e il backend in modo tale che un certo vhost sia raggiungibile solo dicendo i nomi host di frontend e backend diversi.
Se un vhost è irraggiungibile per ogni richiesta HTTPS valida, può ragionevolmente essere considerato una vulnerabilità se detto vhost può essere raggiunto inviando richieste HTTPS non valide. Se il backend è una versione di Apache con supporto SNI, il controllo che chiedi protegge la vulnerabilità.
Leggi altre domande sui tag apache attacks tls vulnerability