Che danno può fare un MITM al traffico crittografato e cosa si può fare al riguardo?

2

Assumi un server e un client che sono ciascuno su reti fisicamente sicure e senza compromessi. Tuttavia, tra ogni rete è un utente malintenzionato in grado di visualizzare il traffico. Ad esempio, due reti di reparto collegate a una rete aziendale più grande il cui router è compromesso o due dispositivi remoti in cui un IXP interveniente è stato compromesso da un avversario di livello nazionale.

L'avversario si rivolge in modo specifico a questi due dispositivi.

Il traffico tra i due dispositivi è crittografato con AES a 256 bit utilizzando una chiave condivisa da un canale laterale fisico (pen drive). I firewall di due dispositivi sono impostati per eliminare tutto il traffico non l'uno dall'altro indirizzo IP.

Quale scempio può scatenare quell'attaccante? Da quello che posso vedere, potrebbero reindirizzare il traffico in modo che non raggiunga il target previsto, oppure potrebbero falsificare l'indirizzo IP di un dispositivo per effettuare un attacco DOS contro l'altro dispositivo. Mi sto perdendo qualcosa?

    
posta TBridges42 05.08.2017 - 00:03
fonte

4 risposte

4

Supponendo che la crittografia sia implementata correttamente e che la chiave non sia compromessa, tutto ciò che un aggressore MITM può ottenere modificando i dati lo trasforma in una spazzatura imprevedibile. Quando A e B eseguono qualsiasi verifica di plausibilità sui dati, dovrebbero notarlo.

Quindi cosa può fare l'attaccante?

  1. Elimina completamente la comunicazione semplicemente filtrando tutto
  2. Trasforma la comunicazione in assurdità apportando alcune modifiche casuali (contromisura: aggiungi un hash a ciascun messaggio per rilevare e scartare i messaggi danneggiati)
  3. Inserisci ancora più sciocchezze nella comunicazione sperando di esaurire le risorse (attacco DOS)
  4. Reinvia messaggio precedentemente osservato ("replay attack"). Anche se non riescono a capire un messaggio, se hanno osservato che l'invio di un messaggio specifico ha causato qualcosa, l'invio dello stesso messaggio potrebbe causare nuovamente la stessa cosa (contromisura: aggiungere un timestamp a ciascun messaggio e scartare i messaggi che sono troppo vecchi. Il timestamp dovrebbe essere incluso nel calcolo dell'hash).
  5. Crea una copia del testo cifrato nel caso in cui in qualche modo riesca a ottenere la chiave di crittografia in futuro.
risposta data 05.08.2017 - 01:46
fonte
2

Aggiungere alcune possibili minacce a ciò che @Philipp ha detto. Non si specifica quale modalità di cifratura è in uso.

In caso di modalità ECB (assolutamente scoraggiato), poiché i blocchi crittografati non sono randomizzati, un attaccante sarà in grado di distinguere blocchi identici. Con una certa conoscenza del messaggio inviato, un utente malintenzionato può decodificare l'intera comunicazione

Nel caso in cui sia in uso una modalità malleabile come CBC, un utente malintenzionato che conosce parte del testo in chiaro potrebbe riuscire a manomettere il messaggio.

Alcune modalità che usano nonce, come CTR, hanno un limite su quanti blocchi puoi cifrare senza perdere la sicurezza. Se la quantità di blocchi crittografati supera tale limite, un utente malintenzionato potrebbe recuperare anche il testo in chiaro

Inoltre, anche se non è ancora pratico con l'hardware corrente, l'acquisizione di traffico sufficiente consentirà all'utente malintenzionato di eseguire un attacco di compleanno

    
risposta data 05.08.2017 - 18:24
fonte
1

L'utente malintenzionato può modificare i dati in modo malevolo per tentare di sfruttare potenziali vulnerabilità nel codice di decrittografia. Ad esempio, se utilizzi TLS, esiste la possibilità che tu stia utilizzando OpenSSL per questo, in modo che l'attaccante possa provare a creare pacchetti per sfruttare i bug OpenSSL, possibilmente ottenendo l'esecuzione di codice in modalità remota per divulgare la tua chiave e decifrare l'intera comunicazione, o compromettere la macchina per un accesso successivo.

    
risposta data 06.08.2017 - 01:30
fonte
-1

Assume a server and a client that are each on physically secure, uncompromised networks. However, between each network is an attacker that is capable of viewing traffic.

Questo in pratica significa: "Assumi A, il lancio A dalla finestra, e smetti di assumerlo."

The traffic between the two devices is encrypted with 256-bit AES using a key shared by a physical side channel (thumb drive).

Ciò rende irrilevante il resto della configurazione.

The two device's firewalls are set to drop all traffic not from each other's IP address.

Questo è inutile e non aggiunge molto in termini di sicurezza. È banale riscrivere l'intestazione TCP e falsificare la fonte.

Sembra che tu stia dicendo: "Il punto A e il punto B usano la crittografia end-to-end con una chiave simmetrica nota come A e B, e mai trasmessa in banda. Se un attaccante compromette [qualsiasi parte] della rete tra A e B, cosa può fare l'attaccante fare contro cosa possono conoscere ? "

Supponendo che tu stia usando AES256 per codificare i tuoi dati prima di lasciare il punto A, e il punto B decrittalo, quindi l'intermediario non può fare molto.

Cosa possono sapere - che le transazioni e le conversazioni di dati avvengono tra i due punti insieme ad altri metadati.

Cosa possono fare - bloccare, reindirizzare, memorizzare nella cache e manomettere in altro modo il traffico.

Poiché la tua configurazione non menziona l'autenticazione, solo la crittografia, quindi un attacco MiTM potrebbe (in questa configurazione) decrittografare i tuoi dati, memorizzarli nella cache, quindi ricrittografarli e inviarli. Né il punto A né B ne sono a conoscenza.

"Come decifrano i miei dati ???" - se questo è un attore di livello statale con risorse, possiamo supporre che abbiano le risorse per l'ingegnere sociale stesse una copia della chiave, o il malware ne ha rilevato una copia quando si trovava nell'unità USB di un computer, ecc.).

Il tuo problema principale è che stai usando la crittografia senza autenticazione. Ora, se si utilizza la crittografia con firma e autenticazione dei messaggi, se il MiTM sta manomettendo del tutto il traffico, entrambi gli endpoint lo sapranno. (Beh ... potrebbe sapere a seconda dell'implementazione).

    
risposta data 05.08.2017 - 00:58
fonte

Leggi altre domande sui tag