se un server utilizza / dev / random per generare la chiave di sessione casuale con un client. Come puoi lanciare un attacco Denial-Of-Service (DOS) su un server del genere?
se un server utilizza / dev / random per generare la chiave di sessione casuale con un client. Come puoi lanciare un attacco Denial-Of-Service (DOS) su un server del genere?
Oltre a tutti i normali metodi di attacco DoS che potrebbero funzionare contro il sistema, è possibile che in determinate condizioni sia possibile eseguire il sistema DoS richiedendo un numero follemente grande di nuovi ID di sessione.
Tieni presente che "può verificarsi in determinate circostanze" qui per due motivi:
/dev/random
estenuante. Questo non funzionerà su alcuni sistemi UNIX, come OpenBSD, che fornirà felicemente numeri casuali sicuri da /dev/random
fino alla morte termica dell'universo senza blocco. Questo perché su OpenBSD /dev/random
è un collegamento simbolico a /dev/arandom
, che è un CSPRNG a esecuzione libera che riceve periodicamente più entropia iniettata .. /dev/random
per seminare il loro RNG interno e quindi usarlo per generare cose come le chiavi di sessione, il che significa che non hanno problemi oltre all'avvio o ri-seed con un pool di entropia vuoto. Quelli ancora più intelligenti utilizzano invece /dev/urandom
per il seeding, quindi non hanno letteralmente alcun problema con un pool di entropia vuoto. Anche supponendo che il resto del sistema non sia influenzato dalla mancanza di entropia, potresti non essere in grado di avere un impatto diretto su quel servizio stesso. A seconda del modo in cui è progettato, potresti avere un impatto esattamente pari alla tua connessione al servizio.
Potresti riferirti al problema che la lettura da /dev/random
bloccherà su alcuni sistemi se non c'è abbastanza entropia disponibile. Disegnare rapidamente entropia dal sistema creando molti id di sessione potrebbe quindi portare al blocco dell'applicazione durante la creazione di un altro ID di sessione, facendo in modo che almeno questa parte specifica dell'applicazione non risponda per qualche tempo: un attacco denial of service.
Come esattamente l'applicazione può creare nuovi ID di sessione dipende dall'applicazione, ma per le implementazioni tipiche potrebbe essere sufficiente inviare una singola richiesta HTTP che non ha ancora un cookie di sessione e l'invio di molte di tali richieste può essere facilmente automatizzato .
Leggi altre domande sui tag random cryptography