TCP Sequence Bruteforcing è pericoloso al giorno d'oggi?

Naviga le tue risposte
3

Stavo leggendo sulla previsione della sequenza TCP che è descritta come quasi impossibile su tutto il sistema operativo aggiornato al giorno d'oggi. La quantità totale di possibili numeri di sequenza è 2^32-1 che, se proviamo a forzare la forza, verrà indovinata dopo una media di (2^32-1)/2 = 2 147 483 647.5 try.

Quindi ora, ciò che è necessario per un buon attacco di spoofing IP

SYN + ACK + almeno un PSH pacchetto per eseguire l'attacco. 20B + 20B + ~30B = 70B

Ci vuole approssimativamente (2^32-1)/2*70 ~= 150TB per eseguire un attacco di spoofing IP.

Abbiamo visto il più grande attacco DDOS, con oltre 1 TB / s qualche settimana fa ( fonte ). Quindi, se capisco, questa botnet della telecamera è in grado di eseguire un attacco di spoofing IP in 150 secondi.

Qual è il futuro della sequenza TCP Bruteforcing? Con il costante aumento della larghezza di banda e della potenza del computer, questo diventerà un vettore di attacco importante da affrontare? I protocolli TCP dovrebbero essere aggiornati per gestire la sequenza a 64 bit?

    
posta Xavier59 18.10.2016 - 18:47
fonte

1 risposta

5

What is the future of TCP sequence Bruteforcing?

Sosterrò che non è così buio come potrebbe sembrare all'inizio. Indovinare un numero a 32 bit non è fattibile, anche se si inviano molti di pacchetti con tentativi. Come ha detto @armani, l'uso di una larghezza di banda delle dimensioni DDoS è più probabile che faccia sì che la macchina non risponda piuttosto che accettare il pacchetto contraffatto.

Tuttavia, ci sono altri modi. Tutti si basano sul fatto che è possibile ridurre lo spazio di ricerca (32 bit) a un importo più modificabile.

  1. Anni fa Michal Zalewski eseguì una ricerca dove realizzò serie temporali di generatori di numeri pseudo casuali . Le serie temporali hanno permesso di indovinare il numero successivo basato su un paio di precedenti. Conoscere alcuni pacchetti ha permesso di fare un'ipotesi molto migliore contro i sistemi in cui il PRNG era in qualche modo prevedibile. E indovina un po ', la maggior parte dei sistemi ha un PRNG piuttosto prevedibile.

  2. Un anno dopo Zalewski ha verificato se i PRNG sono migliorati dopo aver segnalato i problemi. E il miglioramento non è stato così grande.

  3. Persino i tentativi di proteggere dall'indagine ISN sono falliti in passato. CVE 2016-5696 successo perché un RFC ( RFC 5961 ) non ha definito le cose correttamente e le implementazioni (in realtà l'unica implementazione nello stack TCP di Linux) sono diventate più vulnerabili. Sono diventati vulnerabili perché hanno fornito numeri di sequenza tramite pacchetti challenge ACK che potrebbero essere utilizzati per determinare la sequenza PRNG (in tecniche simili al punto 1.). Una volta raggiunto il numero di pacchetti challenge ACK consentiti, non solo è possibile provare a indovinare come di consueto, ma disporre di diversi pacchetti per basare l'analisi PRNG.

Noi (sviluppatori di sistemi operativi e analisti della sicurezza) continuiamo a commettere errori con ISN. E, anche se i sistemi popolari e aggiornati sono improbabili che siano vulnerabili (a Linux sono stati fissati quei CVE), non tutti i sistemi vengono aggiornati. Inoltre, come osservato nella ricerca di Zalewski, i sistemi operativi dei router non sono molto migliori per quanto riguarda la prevedibilità del PRNG. E i sistemi operativi del router spesso non vengono aggiornati.

C'è ancora futuro per l'ipotesi di sequenza, non necessariamente forzatura bruta. Ma la supposizione, implica ancora qualche forzante brutale. Puoi indovinare un paio di intervalli che possono essere generati da un PRNG, e da lì devi inviare diversi pacchetti con numeri di sequenza diversi ciascuno in base agli intervalli (utilizzando tutti i numeri nell'intervallo calcolato nel migliore dei casi).

Sta diventando sempre più difficile rendere possibili attacchi di spoofing su numeri di sequenza TCP. Ma non è impossibile.

Riferimenti

risposta data 18.10.2016 - 20:37
fonte

Leggi altre domande sui tag

Generazione di una chiave GPG con una data di scadenza Distruzione e Cyber Warfare reciprocamente certi [chiuso]