Proteggersi dallo spoof DNS

Rilevare l'uso di un certificato valido ma in qualche modo compromesso è difficile:

• Se il sito di destinazione ha rubato le chiavi private e non l'ha ancora realizzato, l'autore dell'attacco può falsificare perfettamente il sito, ovvero il cliente non si renderà conto della differenza rispetto al sito originale.
• Se il sito ha rubato la sua chiave privata e l'ha realizzato, dovrebbe revocare il certificato. In teoria il browser controllerà se il certificato è stato revocato e si rifiuta di connettersi in questo caso. Ma in pratica questo controllo non può realmente essere fatto affidamento se non in casi speciali (come certificati EV o siti ritenuti importanti dal fornitore del browser) poiché i browser non eseguono alcun controllo di revoca con OCSP o ignorano gli errori durante il controllo - dove tali errori potrebbero essere causati dall'hacker.
• Se un utente malintenzionato è riuscito a ottenere un certificato pubblicamente attendibile per il sito (ad esempio, rilevando i siti DNS abbastanza a lungo per ottenere tale certificato, vedere recente problema con Fox-IT ) è anche difficile per il client rilevarlo come un problema poiché l'utilizzo di un nuovo certificato potrebbe effettivamente essere valido. Progetti come Convergence potrebbero aiutare in questo caso perché consentono di rilevare se altri utenti vedono un certificato diverso per lo stesso posto. Inoltre, il blocco dei certificati (HPKP) utilizzato dal sito stesso potrebbe essere di aiuto.

Dal momento che rilevare l'utilizzo del certificato errato è impossibile in molti casi questo lascia solo rilevare lo spoofing del DNS:

• Il monitoraggio IP come suggerito potrebbe aiutare a rilevare se l'autore dell'attacco utilizza un IP di destinazione molto diverso da quello solitamente utilizzato dal sito originale. Nota che ciò non aiuta lo spoofing ARP nelle reti locali o in Internet reindirizzamenti BGP poiché l'IP di destinazione non viene necessariamente modificato in questo caso, ma solo reindirizzato.
• Se il sito supporta DNSSec, dovrebbe essere usato per verificare quale sia l'IP reale. Naturalmente questo aiuta solo contro lo spoofing locale e non se il server DNS primario per il dominio è stato violato.
• Se il target non utilizza DNSSec potrebbe essere utile chiedere a un server DNS che non sia influenzato dallo spoofing DNS (locale). Ad esempio si potrebbe usare DNS su HTTPS in modo che l'attaccante non sia in grado di spoof anche queste risposte DNS. Naturalmente, un utente malintenzionato potrebbe tentare di rendere questi siti non disponibili nella speranza di ricorrere al DNS spoofato localmente.

Ci sono vari progetti come DNSSEC e DNSCrypt che mirano a prevenire l'avvelenamento del DNS, ecc. L'adozione di questi tipi di tecnologie sta aumentando, ma non ancora del tutto.

Cerchiamo di distinguere tra il controllo del server DNS, il controllo del nome del dominio e il controllo del server web.

Se un utente malintenzionato ha il controllo di un server DNS, può inviarlo al suo server di attacco, ma non può falsificare un certificato attendibile. Questo è facile da vedere poiché otterrai "questo sito non è attendibile".

Tuttavia, se un utente malintenzionato dovesse ottenere le informazioni dell'account per il proprio registrar di dominio, potrebbe registrare il proprio IP con il proprio nome di dominio, che potrebbe quindi incanalare per ottenere un certificato attendibile per tale dominio.

Se un utente malintenzionato ha il controllo del server Web, potrebbe ottenere un certificato attendibile per tale dominio; questo è completamente indipendente dal DNS.

Per i due attacchi successivi, è molto difficile da rilevare. Il monitoraggio degli IP non è molto utile nella maggior parte dei casi, poiché molti siti Web utilizzano il cloud ospitato (Amazon, Azure, Google) dove il loro IP può cambiare giorno per giorno. È possibile monitorare i certificati, un nuovo certificato avrebbe un'impronta digitale diversa, che è possibile rilevare lato client (e potrebbe essere probabilmente automatizzato con un plug-in del browser). Tuttavia, i certificati cambiano legittimamente ogni pochi anni: i certificati scadono dopo un periodo prestabilito in base alla progettazione, quindi questo potrebbe produrre molti falsi positivi.

In breve, se un utente malintenzionato può rubare l'identità di un sito Web tramite il dirottamento del dominio tramite il registrar o semplicemente l'accesso al server Web esistente, è molto difficile per un client rilevarlo. Spetta agli amministratori del sito web assicurarsi di mantenere il controllo della propria identità.

Fino all'ultimo punto su zeroSSL / let's cripta / e quei tipi di fornitori di certificati automatici. Ci sono stati numerosi casi di alto profilo in cui questi sistemi automatici hanno generato certificati che non dovrebbero essere (certificati in cui il controllo del dominio non viene adeguatamente convalidato). In questo caso, l'errore si trova interamente nella CA (ZeroSSL / Let's Encrypt / etc.) E espone il problema inerente consentendo agli algoritmi di gestire la convalida. È veloce ed economico, ma gli algoritmi possono essere ingannati in modi che gli umani intuitivamente sanno essere trucchi.