Può JavaScript sconfiggere la randomizzazione della porta sorgente?

3

È possibile che JavaScript dannoso sconfigga la casualizzazione della porta sorgente nei browser?

Sto leggendo un documento di ricerca che sembra sostenere che la risposta è sì:

many browsers seem to always assign a random local port number for different web pages which makes [source] port prediction very difficult. To overcome the challenge, we design a simple strategy to intentionally occupy as many local ports as possible so that the next port used is selected from a much smaller pool.

Specifically, the malicious website can instruct the client to open many connections to the malicious site (or any other server) to consume a large number of local ports. In addition, the occupied port numbers tend to be contiguous according to our experiment likely due to the origination from the same JavaScript. One challenge is that the OS may limit the total number of ports that an application can occupy, thus preventing the attacker from opening too many concurrent connections. Nevertheless, we found such limit can be bypassed if the established connections are immediately closed (which no longer counts towards the limit). The local port numbers are still not released since the closed connections enter the TCP TIME WAIT state for a duration of 1–2 minutes. If an attacker can manage to open enough connections, he can easily use brute force [to guess the source port of the next request].

Concettualmente, l'attacco sembra andare così. Supponiamo che la vittima visita una pagina Web dannosa, evil.com, controllata dall'attaccante. evil.com fornisce alcuni JavaScript che aprono molte connessioni a evil.com, nel tentativo di esaurire il pool di porte di origine locali. Quindi, JavaScript reindirizza il browser a www.amazon.com (o apre un iframe su www.amazon.com). L'affermazione è che il loro metodo consente loro di prevedere il numero di porta di origine TCP che verrà utilizzato in quella connessione a www.amazon.com.

È giusto? Questo attacco funziona?

Se l'attacco funziona, ho alcune domande su come / perché l'attacco funziona:

  • I browser gestiscono autonomamente un pool di porte locali o chiedono al sistema operativo di allocare una porta locale per loro? Che pool si sta esaurendo qui?

  • Se il sistema operativo sta allocando la porta di origine, la porta di origine non è specifica per il server di destinazione? (Posso aprire molte connessioni a evil.com e scaricare tutte le porte locali disponibili su evil.com, ma mi aspetterei che una nuova connessione a www.amazon.com possa utilizzare qualsiasi porta sorgente, anche una che è attualmente in uso con www.evil.com o è stato usato di recente con www.evil.com. Ho frainteso qualcosa?)

  • O il browser in qualche modo gestisce manualmente un pool di porte locali che è pronto per utilizzare per le connessioni? Se sì, quale strategia usa? Dipende dal browser?

  • In che modo l'utente malintenzionato prevede quale sarà il numero della porta di origine utilizzato per la connessione a www.amazon.com?

Speravo che qualcuno potesse aiutarmi a capire cosa sta succedendo qui e inserire i dettagli mancanti.

    
posta D.W. 27.09.2012 - 22:19
fonte

1 risposta

2

Per quanto ne so, il kernel assegnerà una nuova porta locale per ogni connessione in uscita (a meno che l'applicazione non applichi uno specifico valore di porta con bind() - questo può essere fatto anche per un client TCP) e non permetterà due connessioni in uscita per utilizzare la stessa porta locale contemporaneamente. Infatti, se provi a forzare due connessioni client a utilizzare lo stesso numero di porta locale, con chiamate di bind() esplicite, il secondo bind() non dovrebbe riuscire.

Un Linux allocherà porte locali nell'intervallo 32768-61000 (vedi questa pagina ). Questo è a livello di sistema.

Dubito che i browser Web selezionino porte locali specifiche. Non vedo cosa li comprerebbe e, inoltre, questo andrà perso quando si attraversa un router che esegue alcuni NAT - una cosa molto comune, sia per gli utenti domestici che per le imprese.

Indovinare la porta locale in anticipo non dà un vantaggio di per sé all'attaccante - può essere parte di un attacco più grande che indovina anche i numeri di sequenza TCP (che sembra più difficile).

Modifica: in realtà Linux permetterà a una porta di essere riutilizzata per un'altra connessione mentre la prima è ancora attiva, ma ciò non accade spesso. Linux randomizza le porte effimere (vedi RFC 6056 ) così, generalmente, verrà usata una nuova porta. Quando l'applicazione esegue una pre-connessione esplicita bind() , una nuova porta viene necessariamente allocata, poiché in quel momento il kernel non conosce ancora l'indirizzo di destinazione. Per un connect() senza binding, viene utilizzato un altro algoritmo, che tende a preferire l'utilizzo di una nuova porta ma può riutilizzare un vecchio. Vedi questo post del blog per un'analisi.

    
risposta data 27.09.2012 - 22:51
fonte

Leggi altre domande sui tag