Possiamo prevenire attacchi basati su DNS con SSL / TLS? [duplicare]

Question

Possiamo prevenire attacchi basati su DNS con SSL / TLS? [duplicare]

#1 da (1 voti)
#2 da (0 voti)

0

Considera lo scenario seguente dando un attacco ipotetico:

Crypto.com vende cryptostock e accetta pagamenti tramite PayEasy.com. Le pagine del sito complete (di crypto.com) sono servite tramite HTTPS.
Mentre viaggia in un paese straniero, Bob visita crypto.com sul suo laptop dalla sua rete di hotel e fa clic sul pulsante "acquista ora" per 10 cryptostock. Viene inoltrato a PayEasy.com utilizzando un link <a href='https://PayEasy.com/pay?amt=100&id=bob'/>
Un utente malintenzionato (come l'ISP) riesce a reindirizzare tutto il traffico destinato a PayEasy.com dal computer di Bob a un sito fittizio che ha impostato chiamato PayEazy.com . Quando Bob effettua una query DNS per PayEasy.com, l'utente malintenzionato restituisce l'indirizzo IP di PayEazy.com.Questo sito ha anche una connessione HTTPS utilizzando un vero SSL ottenuto da una CA che utilizza "domain-validation ". Il certificato conferma che il sito è servito da payeazy.com. Un utente malintenzionato deve eseguire questa operazione, poiché altrimenti il browser di Bob darà un avviso e potrebbe non riuscire nell'attacco. Pertanto, Bob fa effettivamente clic su un link equivalente a <a href='https://PayEazy.com/pay?amt=100&id=bob'/>
Bob non sospetta mai nulla perché vede la barra verde e non si è nemmeno preso la briga di leggere sul sito di crypto.com che utilizza PayEasy.com. Anche se Bob sapeva che PayEasy.com è il processore di pagamento di crypto.com, non nota la leggera differenza in PayEazy.com. Bob effettua il pagamento di $ 100 per 10 cryptostock e aspetta ma non arrivano mai.
Bob ritiene che Crypto.com sia un truffatore e li fa causa. A seconda del caso, gli avvocati di Crypto.com chiedono a Bob di dimostrare che Crypto.com lo ha inviato al link anziché a link . Bob non può dimostrarlo e perde. Il caso potrebbe essere andato in entrambi i modi, poiché anche Crypto.com non avrebbe potuto provare di aver effettivamente inviato Bob a link e non a link

In primo luogo, questo attacco è realistico. In secondo luogo, come prevenirlo? (Questo è simile all'esempio riportato nell'articolo Schneier's PalmPilot )

Come esempio di questo attacco: link è un link sicuro a google.com . Supponendo che questo sito ( security.stackexchange.com ) sia pubblicato su HTTPS. Ora modifica il tuo hosts.file 'in modo che l'indirizzo IP di google.com punti a yahoo.com e fai clic sul link sopra.

dns tls

posta Jus12 15.01.2016 - 17:18

fonte

2 risposte

0

In realtà nel caso in cui hai descritto (elaborazione dei pagamenti) c'è una cosa che ti sei perso: vendor (Crypto.com) < - > interazione payment_processor (PayEasy.com). Ho implementato tali legami, ed è così che funziona:

effettua una richiamata al processore: "dammi un ID transazione per i dettagli completi della transazione". I loro sig sono controllati tra di loro da i certificati che hanno scambiato in precedenza
riceve l'id e reindirizza Bob a link ... No "id = bob", "importo = 100 "- tutte queste informazioni e molte altre informazioni sono state passate GIÀ nel passaggio 1
Bob vede TUTTI i dati nel suo browser e solo dopo approva il pagamento.

Puoi anche registrare link come fornitore, ma per quanto riguarda il lato di Mario sarà nome del commerciante diverso in pagamento conferma, e questa pagina di conferma sarà firmata HTTPS dal certificato SSL PayEasy. Questo è tutto

risposta data 15.01.2016 - 18:34

fonte

Leggi altre domande sui tag dns tls

Autenticazione di base HTTP - password mancante AWS S3 Crittografia lato server - Chiavi fornite dal cliente PHP

score 1 · Accepted Answer

No. Questo è esattamente il motivo per cui abbiamo PKI - per prevenire questo tipo di attacco di avvelenamento DNS che stai descrivendo.

Ecco cosa succederebbe nel caso che tu stia descrivendo (compresi i commenti), dopo che Bob ha cliccato sul link link . Innanzitutto, il browser di Bob eseguirà una ricerca DNS per PayEasy.com.

Supponiamo che l'autore dell'attacco (l'ISP di Bob o il suo provider WiFi) sia riuscito a restituire un indirizzo IP falso per PayEasy.com e restituisca un indirizzo IP a un server Web controllato dall'hacker.

OK, quindi ora il browser di Bob si collega al server web dell'attaccante. Ma - qui sta il problema - il server web dell'attaccante serve un certificato per PayEazy.com. A questo punto, il browser di Bob sa che qualcosa è finito, perché il browser ha richiesto PayEasy.com, non PayEazy.com! Il browser di Bob gli mostrava un avviso di mancata corrispondenza del certificato e Bob sarebbe saggio a interrompere la connessione con il sito.