Kerberos: cosa può ottenere un attaccante da un attacco di replay?

Question

Kerberos: cosa può ottenere un attaccante da un attacco di replay?

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

7

Nell'ultimo passaggio di Kerberos, il client invia al server di destinazione un ticket e un autenticatore . Una delle parti dell'autenticatore è un timestamp. Si dice che il timestamp prevenga gli attacchi di replay, dal momento che il server può verificare che un messaggio sia fresco e che sia stato inviato una sola volta (usando una cache). Questo è tutto chiaro In primo luogo, ciò che non ottengo è lo scopo di un attacco di replay. Certo, senza il timestamp, l'attaccante può ritrasmettere i messaggi di autenticazione legittimi. Ma senza la chiave di sessione , non c'è modo di comunicare ulteriormente con il server in ogni caso, è lì ?

Quindi, supponendo che gli attacchi di riproduzione siano possibili e un utente malintenzionato può ingannare il server per pensare che sia un utente legittimo. Come può l'attaccante operare all'interno della sessione creata, dato che non ha mai ottenuto la chiave di sessione?

kerberos

posta 27.12.2011 - 15:14

fonte

2 risposte

Leggi altre domande sui tag kerberos

Yahoo! Attacco per iniezione di messaggeri Il servizio di aggiornamento NVidia crea un account locale sul sistema. Qualcuno conosce la password degli utenti?

score 2 · Answer 1

Potresti leggere questo PDF , che fornisce un esempio di tale attacco di replay. In effetti, non è tanto un attacco di replay quanto un attacco man-in-the-middle. Detto questo, parte del motivo per cui il timestamp e il cache sono di rendere più difficile per un utente malintenzionato eseguire un simile attacco di replay, e invece devono effettivamente eseguire un MITM, che è più difficile. Devono attivamente bloccare la richiesta per poter utilizzare l'autenticatore.

Per quanto riguarda la chiave di sessione, per quanto ho capito, e potrei sbagliarmi, non è in realtà necessaria una volta ottenuto il token che consente di accedere alla risorsa. Ancora una volta, non sono sicuro che sia meglio leggerlo in modo più dettagliato.

score 0 · Answer 2

Penso di aver capito da dove viene la domanda. Ho avuto la stessa domanda oggi.

Probabilmente stavi pensando di utilizzare la chiave di sessione, condivisa tra il client e il server, per garantire riservatezza e integrità per ulteriori comunicazioni tra le parti. E l'attacco di replay è davvero inutile sotto questo aspetto: senza la chiave di sessione l'attaccante non può neanche scendere a compromessi.

Ma immagina un caso d'uso, in cui duplicare il server per autenticare un utente malintenzionato ripetendo un messaggio contenente un ticket (e autenticatore) apre un canale di comunicazione in chiaro. Questo è quando gli attacchi di riproduzione dovrebbero essere prevenuti!

C'è un altro problema con gli attacchi di replay: possono essere usati come un meccanismo per montare attacchi denial-of-service, costringendo essenzialmente il server a decifrare il ticket e l'autenticatore ripetutamente. È significativo quando si ha a che fare con la crittografia a chiave pubblica, ma non penso che importi in questo caso, perché la crittografia simmetrica non è così costosa da causare la negazione della cpu.