Passa al contenuto principale

9.5.1. Risks of Weak or Null Message Authentication (Rischi di autenticazione messaggi debole o nulla)

9.5.1. Risks of Weak or Null Message Authentication (Rischi di autenticazione messaggi debole o nulla)

Durante un audit di sicurezza che considera l'uso di autenticazione debole o nulla, è importante tenere a mente i seguenti attacchi che sono possibili quando non viene utilizzato alcun algoritmo di autenticazione dei messaggi.

Un attaccante che non può prevedere il testo in chiaro è comunque sempre in grado di modificare il messaggio inviato tra il mittente e il ricevitore in modo che si decifri in un valore di testo in chiaro casuale, o di inviare un flusso di pacchetti falsi al ricevitore che si decifrerà in valori di testo in chiaro casuali. Questo attacco è essenzialmente un attacco denial of service, sebbene in assenza di autenticazione dei messaggi, l'applicazione RTP avrà input che sono correlati bit per bit con il valore vero. Alcuni codec multimediali e sistemi operativi comuni si bloccheranno quando tali dati vengono accettati come dati video validi. Questo attacco denial of service può essere una minaccia molto più grande di quella dovuta a un attaccante che elimina, ritarda o riordina i pacchetti.

Un attaccante che non può prevedere il testo in chiaro può comunque riprodurre un messaggio precedente con la certezza che il ricevitore lo accetterà. Le applicazioni con codec senza stato potrebbero essere robuste contro questo tipo di attacco, ma per altre applicazioni più complesse questi attacchi possono essere molto più gravi.

Un attaccante che può prevedere il testo in chiaro può modificare il testo cifrato in modo che si decifri in qualsiasi valore di sua scelta. Con un cifrario a flusso additivo, un attaccante sarà sempre in grado di cambiare bit individuali.

Un attaccante può essere in grado di sovvertire la riservatezza a causa della mancanza di autenticazione quando viene presa una decisione di inoltro dati o controllo degli accessi su testo in chiaro decifrato ma non autenticato. Questo perché il ricevitore può essere ingannato nell'inoltrare dati a un attaccante, portando a una violazione indiretta della riservatezza (vedere Sezione 3 di [B96]). Questo perché le decisioni di inoltro dati sono prese sul testo in chiaro decifrato; le informazioni nel testo in chiaro determineranno a quale sottorete (o processo) il testo in chiaro viene inoltrato in modalità tunnel ESP [RFC2401] (rispettivamente, modalità transport). Quando RTP sicuro viene utilizzato senza autenticazione dei messaggi, dovrebbe essere verificato che l'applicazione non prenda decisioni di inoltro dati o controllo degli accessi basate sul testo in chiaro decifrato.

Alcune modalità operative di cifratura che richiedono padding, ad esempio il concatenamento standard di blocchi di cifratura (CBC), sono molto sensibili agli attacchi alla riservatezza se vengono utilizzati determinati tipi di padding in assenza di integrità. L'attacco [V02] mostra che questo è effettivamente il caso per il padding RTP standard come discusso in riferimento alla Figura 1, quando utilizzato insieme alla modalità CBC. Le successive aggiunte di trasformazioni a SRTP DEVONO quindi considerare attentamente il rischio di utilizzare questo padding senza un'adeguata protezione dell'integrità.