Avvelenamento della cache DNS come lamina su SSL

No, questo attacco non è fattibile. Credimi, ci ho provato. Ora, quando dico che l'ho provato, non stavo scrivendo un virus o qualcosa per rubare le password, stavo scrivendo software in cui l'utente era pienamente consapevole che stavano usando un server DNS personalizzato che intenzionalmente mentiva (in base alle loro regole) in congiunzione con un proxy HTTP. Questo è esattamente ciò che descrivi, "avvelenare" il DNS in modo da mentire fondamentalmente al software che effettua la ricerca e puntarlo ovunque tu voglia veramente andare al traffico. Ci sono diversi problemi che sorgono una volta lanciato SSL nel mix.

1) Anche se si dispone di un server DNS personalizzato o di un software che monitora e modifica i pacchetti DNS, non vi è alcun modo all'interno di questo protocollo per stabilire se si ha a che fare con richieste HTTP / HTTPS o chissà cosa. Quindi, non puoi dire a quale protocollo è richiesta la richiesta. Anche se ispezioni il pacchetto e cerchi il nome host, verrà visualizzato come "mail.google.com", non come " link ", come un esempio.

2) Per bypassare gli avvisi del browser, hai bisogno di alcune cose. Innanzitutto, è necessario un certificato di radice attendibile per il proxy o il server dannoso. Non succederà. Anche se riesci a far sì che l'utente lo accetti e lo installi (le finestre in fondo fanno in modo che l'utente si accorga di accettare una busta con l'antrace se dicono di sì), la maggior parte dei browser ha il proprio certificato di autorità radice attendibile che memorizza quello controllano contro. Quindi ora devi fare in modo che l'utente faccia il possibile per installare il tuo certificato in qualsiasi formato del browser che stanno utilizzando.

3) Il secondo passo non è sufficiente. Ora, se sei arrivato così lontano, hai il tuo certificato dannoso per il tuo server malevolo. Ora è necessario emettere in modo dinamico certificati per ogni singolo host che viene effettuata una connessione HTTPS oppure indovinare cosa, gli allarmi continuano a funzionare. Questi avvisi del browser non sono come ai vecchi tempi. Google Chrome non ti consente nemmeno di procedere quando rileva che si sta verificando , indipendentemente da quanto l'utente desideri essere negligente con la propria sicurezza.

Inoltre, senza fare nulla di questo fallito trucchetto discusso in 2 e 3, si ottiene ancora meno. Tutto quello che puoi vedere a livello di socket è il socket aperto dall'app che richiede la ricerca, vedi la risoluzione dell'host che si verifica su DNS, quindi un nuovo socket TCP aperto che tenta di connettersi all'host che richiede una connessione sicura. L'intestazione del socket non contiene nulla tranne questa richiesta di base. Non appena viene stabilita la connessione con il server, viene effettuato un handshake e la connessione HTTP viene protetta, in tal modo si perde la speranza di rovinare i dati.

Il punto è che la probabilità che questo attacco abbia successo è praticamente inesistente. L'utente dovrebbe ignorare gli avvertimenti di stile di Doomsday di Windows sui certificati, passare la richiesta di Windows per le autorizzazioni di amministratore elevate (supponendo che si stia utilizzando software dannoso per avvelenare direttamente la cache DNS o dire al sistema di utilizzare un server DNS dannoso), quindi Dovrebbe ignorare il gigantesco schermo rosso, avviso di stile del giorno del giudizio nel browser (se il browser lo consente). Sarebbe eccezionalmente difficile da ottenere e avrebbe un successo minimo anche se fosse possibile.

Tutto questo ha detto, spero davvero che tu stia richiedendo queste informazioni per il bene del bene, e non di tentare effettivamente cose del genere. Armeggiare e imparare queste cose può essere divertente e può aiutare a proteggere gli utenti. Sì, sarebbe perfettamente giusto impostare la tua rete di test e modificarla per divertimento e istruzione, ma fare e imparare tutte queste cose per sfruttare le persone ti rende un criminale e un criminale e una disgrazia per l'apprendimento superiore. Non sto dicendo che tu sia così, sto dicendo alle persone che lo fanno. Spero che tu consideri e valuti queste domande morali e filosofiche nella tua avventura per ottenere conoscenza.

Vedi anche, per la prova della protezione del browser da questo problema.

Avviso Chrome SSL : "Non puoi procedere perché l'operatore del sito web ha richiesto maggiore sicurezza per questo dominio."

L'intero motivo per cui i server SSL utilizzano i certificati è proprio così che il tipo di attacco che stai descrivendo non funziona. E, più in generale, SSL non fa affidamento su qualsiasi funzione di sicurezza, o sua mancanza, del suo mezzo di trasporto. Ciò include la conversione dei nomi in indirizzi IP, ad esempio il DNS. Per tutti gli scopi pratici, SSL rimane sicuro anche se tutti i pacchetti di dati sono trasmessi dall'attentatore stesso in entrambe le direzioni.

Se preferisci, anche con il pieno controllo del traffico a basso livello in entrambe le direzioni, non sarai in grado di far fare ai client una connessione SSL con il tuo server falso; il client riceverà un avvertimento molto visibile su come il certificato apparente del server è errato (o non sarà in grado di convalidarlo, o il nome nel certificato non corrisponderà a quanto previsto, o entrambi). Se gli utenti umani "cliccano attraverso" l'avviso, allora sì, si collegherebbero al tuo server falso e cadranno sotto il tuo controllo; tuttavia, i browser moderni rendono sempre più difficile per il tipico utente umano non prestare attenzione agli avvisi relativi ai certificati.

A parte le altre risposte, questo attacco dal punto di vista di una chiamata API che usa curl con opzione -k (insicuro) implicherebbe che andrà avanti e si connetterà al server malevolo, considerando che molti sviluppatori amano usare -k per ignorare il certificato convalida spesso.