I potenziali attacchi temporali sono sempre presenti in un contesto o nell'altro, ma non credo di aver mai letto casi in cui qualcuno abbia effettivamente eseguito un simile attacco su Internet.
I potenziali attacchi temporali sono sempre presenti in un contesto o nell'altro, ma non credo di aver mai letto casi in cui qualcuno abbia effettivamente eseguito un simile attacco su Internet.
Potrebbe essere allettante supporre che la latenza della rete (jitter) renda questi attacchi poco pratici. Questo non è il caso perché timestamp TCP sono spesso usati dalle macchine vulnerabili, dove il tempo preciso in cui il pacchetto è stato generato è codificato nel Intestazione TCP Non importa quanto tempo impiega il traffico per arrivare, l'ora esatta in cui è stata creata è ancora presente. Anche nei sistemi con data e ora disabilitati, è possibile ottenere un'idea precisa della temporizzazione dei pacchetti ripetendo il test più volte e calcolando la media del risultato per tenere conto del jitter di rete. Quindi, con questo in mente ...
Sì, gli attacchi temporali possono essere fatti su una rete. L'esempio più importante è stata una vulnerabilità a lungo termine in OpenSSH che consentito enumerazione utente banale . Il problema era causato dal fatto che un utente non valido avrebbe attivato il confronto delle password utilizzando Blowfish, il valore predefinito. Quando veniva utilizzato un utente valido, veniva invece utilizzato SHA-2. Mentre normalmente la differenza di temporizzazione è minima, l'invio di una password di grandi dimensioni (diversi kilobyte) farebbe apparire la differenza.
dal bug originale divulgazione :
When SSHD tries to authenticate a non-existing user, it will pick up a fake password structure hardcoded in the SSHD source code. On this hard coded password structure the password hash is based on BLOWFISH ($2) algorithm. If real users passwords are hashed using SHA256/SHA512, then sending large passwords (10KB) will result in shorter response time from the server for non-existing users.
Gli attacchi contro questi tipi di bug spesso sfruttano il fatto che viene utilizzato un percorso di codice diverso a seconda dell'input fornito, causando una differenza di temporizzazione significativamente maggiore rispetto a quella tipica degli attacchi di temporizzazione architetturale di basso livello in cui le differenze sono misurate in nanosecondi e provengono da istruzioni non eseguite in tempo costante (flush + flush, ecc.)
Poiché la discussione su questa domanda su una minaccia di enumerazione degli utenti basata su un attacco di temporizzazione illustra ... tempistiche le vulnerabilità possono sorgere ogni volta che è necessaria una quantità diversa di lavoro per restituire un risultato, anche se la pagina sottoposta a rendering non è progettata per rivelare le informazioni utilizzate nell'elaborazione della richiesta.
La domanda collegata fa riferimento specificamente a una vulnerabilità di enumerazione degli utenti, ma potrebbero verificarsi differenze temporali simili in qualsiasi schema di autorizzazione che richiede il recupero di una risorsa e il controllo delle autorizzazioni prima che possa essere determinato se l'utente autenticato dispone dell'autorizzazione. Potrebbe essere possibile discernere, per esempio, se un utente ha una determinata funzione abilitata sul suo account, perché la logica di autorizzazione è più complessa e richiede più tempo per essere eseguita.
La gravità di tale vulnerabilità dipende interamente dalla sensibilità delle informazioni che sarebbero rivelate dall'attacco.
Sì, certo, perché uno di questi attacchi è Spectre ! L'attacco contro il timing della cache della CPU è noto per il suo potenziale di essere eseguito con Javascript , che rivela i dati degli utenti critici, memorizzati in un browser, in un sito Web arbitrario.
(A proposito, questo illustra l'idea: gli attacchi a distanza potrebbero a volte essere visti come qualcosa di quasi innocuo, ma potrebbero svolgere un ruolo di terreno solido per attacchi più sofisticati, costruire su altre vulnerabilità e troppo difficile da rintracciare, ad esempio se a un certo punto ci sarà anche una vulnerabilità clientide apparentemente innocua, un attacco di temporizzazione potrebbe facilmente evolvere in un grave problema.)
La ragione per cui gli attacchi a tempo erano sempre ritenuti non fattibili su Internet era, in pratica, il tempo di andata e ritorno che aggiunge un considerevole margine di errore, che a sua volta si presume sia in grado di rendere i problemi di temporizzazione molto oscuri per una parte remota. Tuttavia, in generale, RTT è qualcosa che, nella maggior parte dei casi, data una buona connettività sia dal lato della vittima che dal lato dell'attaccante (che è qualcosa di troppo facile da ottenere), statisticamente, è abbastanza stabile. Anche i problemi di tempistica sono stabili.
Se un utente malintenzionato è in grado di eseguire molti tentativi di raccolta di dati sufficienti per effettuare misurazioni statistiche, può generalmente effettuare un aggiustamento per RTT, rimuovendo efficacemente questa vaga offuscazione delle misure del tempo di esecuzione. Ecco un altro esempio pratico di come può essere fatto.
I problemi relativi ai tempi non sono da sottovalutare.
Leggi altre domande sui tag timing-attack