Newsgroup: it.comp.reti.wireless
Titolo: buon KRAK a tutti :-P

Dopo questa notizia direi che è meglio criptare tutto il traffico via VPN (di un 
fornitore affidabile) e sperare che i produttori di dispositivi wi-fi e vari 
sistemi operativi aggiornino al più presto il protocollo WPA2:
https://www.krackattacks.com/
 
 
x-post e f/u
 
Gabriele


Su Windows e' gia' corretto, il problema restano gli altri, specie gli 
smart-phone.
 
-- 
I'm not anti-social;
I'm just not user friendly


In ufficio ho la Vodafone Station e spero che Vodafone faccia un 
aggiornamento...
 
Ha casa ho un TP-Link TD-W8970 V1 (anzi da ieri sono 2, il secondo o uso 
come access point, collegato con cavo, per coprire meglio la casa che 
anche se piccola ha molti muri :-\ ) e non viene più aggiornato dal 2014.
 
Forse potrei sperare in un aggiornamento DD-WRT... ma mi risulta che poi 
non funzionerebbe la parte "modem".
 
E poi che succede con Smartphone e Tablet? Devono essere aggiornati 
anche questi... e li sarà dura, salvo andare su Firmware alternativi.
 
 
 
-- 
Daniele Pinna
DAPINNA.COM
 
(leva oops per rispondere)
-----
Utente Skype: dapinna
DAPINNA.COM
        :  
http://www.dapinna.com
 
Il Docfa in Pillole:  
http://www.ildocfainpillole.it
 - Sito Aggiornato!!!
DAPINNA.COM
 su Facebook: 
https://www.facebook.com/dapinnadotcom
 
BLOG: 
http://storielaboratorioinformatica.wordpress.com
 



Dubito fortemente che l'uso di una VPN possa aiutare; se è l'AP ad
essere compromesso, hai voglia a metter su VPN o altre cose, quando uno
potrebbe reindirizzare le tue richieste; che c'entra, si può anche
fare, ma non credo sia una soluzione :P
 
 

 Su Windows e' gia' corretto
 
il che, lascia le cose come stanno, se il client è a posto ma l'AP (o
il repeater) sono vulnerabili, non hai risolto una mazza
 

ObiWan wrote on 17/10/17 15:06:

Reindirizzare se usi il DNS del router/AP, altrimenti non credo.
Altrimenti elabora che la discussione è interessante.
Certo se lo sviluppatore di BetterCap ci fa un modulino per KRACK sarà da 
ridere, o piangere a seconda...
 

 
 
Sarà una strada molto lunga.
 

 sarà da ridere, o piangere a seconda...
 
non solo il DNS, basta anche iniettare qualche pacchetto DHCP farlocco
per farti cambiare il gateway, considerando che l'attaccante è "sulla
tua rete" (WiFi) a quel punto sarà in grado di intercettare tutto il
tuo traffico
 
 
 
 

 il repeater) sono vulnerabili, non hai risolto una mazza
 
Si e no, il protocollo di per se non e' vulnerabile, il problema e' 
sull'autenticazione del client e se e' risolto su *tutti* i client 
allora non si pone.

 allora non si pone.
 
io ho sistemato il mio client sul portatile.
 
Visto che sono l' unico client del mio wifi potrei evitare di sistemare 
l' autenticazione sul router ?
 
a me sembra strano perchè se è bucabile sul router/ap io potrei essere 
connesso con il mio client sicuro ma un altro potrebbe autenticarsi ed 
entrare nella mia rete wifi
 

 entrare nella mia rete wifi
 
Il router non e' bucabile (almeno per ora <g>), la falla riguarda solo i 
client.
Con questo non voglio dire che il problema vada sottovalutato, perche' 
non dimentichiamoci che se anche un solo client e' vulnerabile, allora 
lo e' l'intera rete.
Resta il fatto che in assenza di client vulnerabili, l'attacco KRAK 
fallisce.



vero, ma devi considerare che nel caso dei repeater, questi *sono* dei
client il che significa che se hai un AP configurato come repeater,
sarà necessario applicare una patch (ammesso che esista) anche all'AP
 
 
 
 



tra l'altro... la cosa potrebbe funzionare *anche* solo con routers non
aggiornati, stavo rileggendo il paper pubblicato qui
 
https://papers.mathyvanhoef.com/ccs2017.pdf
 
 
e c'è scritto chiaramente che
 
"This attack technique requires us to wait until a rekey of the
session key occurs. Several APs do this every hour [ 66 ], some exam-
ples being [ 24 , 26 ]. In practice, clients can also request a rekey by
sendinganEAPOLframetotheAPwiththe Request and Pairwise
bits set. Coincidently, Broadcom routers do not verify the authentic-
ity (MIC) of this frame, meaning an adversary can force Broadcom
APs into starting a rekey handshake. All combined, we can assume
a rekey will eventually occur, meaning an adversary can carry out
the key reinstallation attack."
 
per cui, se ho capito bene (sono ancora mezzo addormentato, mi serve
altro caffè), se hai un AP vulnerabile, l'attacco riesce ugualmente
 
 

 sarà necessario applicare una patch (ammesso che esista) anche all'AP
 
Certo, in caso di repeater o bridge la cosa riguarda anche loro in 
quanto client.

 altro caffè), se hai un AP vulnerabile, l'attacco riesce ugualmente
 
Questo e' un aspetto ulteriore della faccenda che evidenzia come il 
crack possa essere piu' o meno agevole, una volta stabilito che ci sono 
client crakkabili. Ma in assenza di client crakkabili, non si applica.
 
Il ricercatore ha giustamente evidenziato anche questo aspetto perche' 
fornisce informazioni importanti riguardo agli AP, cioe' permette di 
capire come rendere piu' difficile l'operazione, ma non risolve il 
problema che resta lato client.



Si, corretto; come ti dicevo stamattina ero ancora mezzo "lesso" :)
 
A (s)proposito, ancora non ho trovato quel dannato PDF, ma non dispero
 
 
 
 

 Sarà una strada molto lunga.
 
Mi ha fatto venire in mente i pericoli prospettati in altri campi (in 
tutti i sensi) delle monocolture (grano, soia, tabacco, cacao, caffè, 
mele, etc): quando ti arriva il parassita, o altro problema, cui la 
cultivar di un unico tipo dominante è sensibile, rischi di perdere tutta 
la produzione. Si salvano solo le varianti, che provengono da selezioni 
diverse.
Ho l'impressione che anche in ambito software si stia andando un po troppo 
verso le monocolture, dopo averlo fatto in area HW (CPU, GPU, DSP,...).
 
-- 
Sans

 DSP,...).
 
si chiama economia di scala.
 
Ai tempi del 386 e 486 esistevano versioni con e senza coprocessore 
matematico ( senza era 386 sx e 486 sx).
 
Quelle senza erano
o cpu " venute male"
o cpu "venute bene" ma con coprocessore appositamente bruciato.
 
Conveniva/conviene  la monoproduzione
 
 

 o cpu "venute bene" ma con coprocessore appositamente bruciato.
Questo aspetto riguardava solo i 486, i 386 non avevano un coprocessore 
nello stesso chip, e' sempre rimasto esterno.
I 386sx erano delle versioni economiche compatibili a livello software 
col 386 ma con bus dati a 16 bit e con prestazioni piuttosto limitate.
Mentre i 486sx erano caratterizzati solo dall'assenza del coprocessore, 
ma a parita' di clock le prestazioni erano identiche.
