/ dev / random genera la chiave di sessione

0

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?

    
posta John hopkins 03.10.2018 - 01:02
fonte

2 risposte

0

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:

  • L'attacco si basa sull'estensione di /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 ..
  • I servizi sane usano solo /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.

    
risposta data 03.10.2018 - 16:55
fonte
1

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 .

    
risposta data 03.10.2018 - 04:29
fonte

Leggi altre domande sui tag