WiFi Krack (key reinstallation attacks) - all WiFi vulnerable

[QuoVadis]

Paper - https://papers.mathyvanhoef.com/ccs2017.pdf

 

 "Every wi-fi device is vulnerable to some variants of our attacks. Our attack is exceptionally devastating against Android 6.0: it forces the client into using a predictable all-zero encryption key."

[Nytro]

In sfarsit ceva interesant.  

[QuoVadis]

2 minutes ago, Nytro said:

In sfarsit ceva interesant.  

 

Si in media...

 

http://www.independent.co.uk/life-style/gadgets-and-tech/news/krack-wifi-wpa-2-free-network-internet-device-android-ios-iphone-phone-safety-privacy-security-a8002731.html 

https://www.theregister.co.uk/2017/10/16/wpa2_krack_attack_security_wifi_wireless/ 

https://www.theguardian.com/technology/2017/oct/16/wpa2-wifi-security-vulnerable-hacking-us-government-warns 

https://www.forbes.com/sites/thomasbrewster/2017/10/16/krack-attack-breaks-wifi-encryption/ 

http://www.zdnet.com/article/wpa2-security-flaw-lets-hackers-attack-almost-any-wifi-device/ 

https://mspoweruser.com/krack-attack-makes-trivial-intercept-manipulate-traffic-sent-linux-android-devices/ 

http://www.bbc.co.uk/news/technology-41635516 

https://arstechnica.com/information-technology/2017/10/severe-flaw-in-wpa2-protocol-leaves-wi-fi-traffic-open-to-eavesdropping/ 

[Fi8sVrs]

 

[gutui]

Vulnerability Note VU#228519 Wi-Fi Protected Access II (WPA2) handshake traffic can be manipulated to induce nonce and session key reuse.

Vendor Information for VU#228519 Wi-Fi Protected Access II (WPA2) handshake traffic can be manipulated to induce nonce and session key reuse.
 

 

[robertutzu]

https://www.krackattacks.com/

[TheTime]

Ok guys, deci s-a dus pe p*la si WPA2-ul.

 

Ce solutii mai sunt ca sa avem o conexiune wifi sigura?

 

Ceva de genul:

1. update firmware pe router
2. panou de administrare cu parola strong
3. setari din router pentru a nu permite clientilor sa comunice intre ei
4. VPN intre clienti si un server extern sau VPN intre clienti si router
5. Setari statice pe clienti pentru IP si DNS.
6. HTTPS peste tot, inclusiv pentru site-urile din reteaua interna; asta ar trebui sa faca oricum, indiferent de vulnerabilitatea asta

Ce e mai sus ar mitiga o parte din atacuri. Un atacator tot ar putea trimite catre clienti pachete ce ar parea ca vin de la router (DNS / DHCP renew), dar ar trebui sa fie ignorate de catre clienti pentru ca au IP static. Imi mai scapa ceva?

 

Probabil problema e ca nicio retea nu mai e vazuta ca fiind privata. Odata ce un atacator patrunde in retea, o gramada de atacuri la nivel de retea devin fair game.

 

 

Oricum, probabil vor fi update-uri in curand. 

[Matasareanu]

6 minutes ago, TheTime said:

7 minutes ago, TheTime said:

Ceva de genul:

1. update firmware pe router
2. panou de administrare cu parola strong
3. setari din router pentru a nu permite clientilor sa comunice intre ei
4. VPN intre clienti si un server extern sau VPN intre clienti si router
5. Setari statice pe clienti pentru IP si DNS.
6. HTTPS peste tot, inclusiv pentru site-urile din reteaua interna; asta ar trebui sa faca oricum, indiferent de vulnerabilitatea asta

1. Updateuri e posibil sa nu vedem prea curand. Avand in vedere ca sunt routere vechi peste tot care nu au mai primit de secole updateuri sau nu o sa stea nimeni sa faca updateuri.

2. Nu cred ca ajuta. E in protocol vulnerabilitatea.

3. WiFi-ul in sine ca si canal de comunicatie face broadcast in aer. Nu este single channel ca prin cablu

4. cred ca momentan este cam singura solutie.

5. doar mitigheaza riscul de MiTM cu astea.

6. asta cred ca este cel mai important.

In concluzie cred ca doar sa ai un server de vpn in LAN ar mitiga problema. Chiar daca esti interceptat o sa fie gibberish.

Alta problema: Toate IoT devices need to be burned. Majoritatea nu or sa primeasca updateuri la wpa_supplicant. Toate deviceurile cu XP care mai exista nu or sa primeasca update, deci or sa fie easy targets.

[Nytro]

Patch-urile sunt disponibile de ani de zile...

 

[Matasareanu]

Just now, Nytro said:

Patch-urile sunt disponibile de ani de zile...

 

Si ce te faci cand ai doar asa ceva in casa:
https://goo.gl/images/LCN4rK ?

[gogusan]

7 minutes ago, Matasareanu said:

Si ce te faci cand ai doar asa ceva in casa:
https://goo.gl/images/LCN4rK ?

ai adaptoare pt OTG si Thunderbolt OBVIOUSLY

[TheTime]

35 minutes ago, gogusan said:

ai adaptoare pt OTG si Thunderbolt OBVIOUSLY

Stii cumva unde bag adaptorul ala in frigiderul WiFi? In congelator?

 

Pe partea de IoT sunt o gramada de device-uri care nu sunt concepute pentru wired use.

[gutui]

[...]

So unless your Wi-Fi password looks something like a cat's hairball (e.g. ":SNEIufeli7rc" -- which is not guessable with a few million tries by a computer), a local attacker had the capability to determine the password, decrypt all the traffic, and join the network before KRACK.

KRACK is, however, relevant for enterprise Wi-Fi networks: networks where you needed to accept a cryptographic certificate to join initially and have to provide both a username and password. KRACK represents a new vulnerability for these networks. Depending on some esoteric details, the attacker can decrypt encrypted traffic and, in some cases, inject traffic onto the network.

But in none of these cases can the attacker join the network completely. And the most significant of these attacks affects Linux devices and Android phones, they don't affect Macs, iPhones, or Windows systems. Even when feasible, these attacks require physical proximity: An attacker on the other side of the planet can't exploit KRACK, only an attacker in the parking lot can.

[...]

Nicholas Weaver

[...]

One of the problems with IEEE is that the standards are highly complex and get made via a closed-door process of private meetings. More importantly, even after the fact, they're hard for ordinary security researchers to access. Go ahead and google for the IETF TLS or IPSec specifications -- you'll find detailed protocol documentation at the top of your Google results. Now go try to Google for the 802.11i standards. I wish you luck.

The IEEE has been making a few small steps to ease this problem, but they're hyper-timid incrementalist bullshit. There's an IEEE program called GET that allows researchers to access certain standards (including 802.11) for free, but only after they've been public for six months -- coincidentally, about the same time it takes for vendors to bake them irrevocably into their hardware and software.

This whole process is dumb and -- in this specific case -- probably just cost industry tens of millions of dollars. It should stop.

[...]

Matthew Green

[gogusan]

1 hour ago, TheTime said:

Stii cumva unde bag adaptorul ala in frigiderul WiFi? In congelator?

 

Pe partea de IoT sunt o gramada de device-uri care nu sunt concepute pentru wired use.

omul a pus poza cu tableta nu cu frigider

[Matasareanu]

 

[Nytro]

https://pastebin.com/aZyyS16w

[john.doe]

Hi,

 

If you pay attention to the attack is based on a Rogue AP which disconnects your device (mainly Android/Linux) from the AP and then reconnects to the Rogue AP which in turn acts as a MiTM. It then performs some sort of SSL strip which again only works on some sites (mainly poor configured sites). It has to do with some drawbacks of IEEE 802.11 standard. Anyway, from the beginning wireless has been a compromise solution between an actual need and a proper way of fulfillment this need. 

 

There are solutions to the problem (depending on existing Wi-Fi setup):

1. WPA2-Enterprise with TLS + extra magic

2. Detect Rogue AP inside your Wi-Fi network area

3. Enforce security settings for Wi-Fi (MAC based rules, IP firewalling, AP isolation, etc)

4. Always keep in up-to-date system (IOS/Android/Linux/Windows) 

 

Not all devices are subject to a cracker`s interest. Yet again not all Wi-Fi networks are an easy target. For instance, on a corporate business network this kind of attack may be very hard to develop as IT may have ways of not only controlling but also detecting unknown devices (although I have seen big corporations falling at security seriously). 

 

But there is a point in this particular attack. It is obvious that nowadays we need to be able to address these kind of attacks and vulnerabilities even if we do not have the support  of a system or classical method of prevention.

 

Stay safe!

 

[QuoVadis]

1 hour ago, john.doe said:

Hi,

 

If you pay attention to the attack, it is based on a Rogue AP which disconnects your device (mainly Android/Linux) from the AP and then reconnects it to the Rogue AP which in turn acts as a MiTM. It then performs some sort of SSL strip, which again, only works on some sites (mainly poor configured sites). It has to do with some drawbacks of the IEEE 802.11 standard. Anyway, from the beginning, wireless has been a compromise solution between an actual need and a proper way of fulfillmenting this need. 

 

There are solutions to the problem (depending on existing Wi-Fi setup):

1. WPA2-Enterprise with TLS + extra magic

2. Detect Rogue AP inside your Wi-Fi network area

3. Enforce security settings for Wi-Fi (MAC based rules, IP firewalling, AP isolation, etc)

4. Always keep in up-to-date system (IOS/Android/Linux/Windows) 

 

Not all devices are subject to a cracker`s interest. Yet again, not all Wi-Fi networks are an easy target. For instance, on a corporate business network, this kind of attack may be very hard to develop as IT may have ways of not only controlling but also detecting unknown devices (although I have seen big corporations falling at security seriously seriously failing at security). 

 

But there is a point into this particular attack. It is obvious that nowadays we need to be able to address these kind of attacks and vulnerabilities even if we do not have the support  of a system or classical method of prevention.

 

Stay safe!

 

 

OFF: Daca tot o dai in limbi straine, macar scrie corect, fara greseli gramaticale si de punctuatie.

ON: Ceva detalii la "solutia" 1? Referitor la #3, poate ca e ok doar pentru o retea mica (home/small business), nu si in alt context. Cat despre #4, ai auzit de 0day-uri?

 

[yoyois]

Inca mi-e necalr:

KRACKs iti permite sa resetezi Nonce si practic sa decriptezi frameuri.

Poti dupa sa extragi Parola AP-ului (psk)? Nu am vazut niciun exemplu de PSK retrive dar nici nu inteleg de ce nu ar fi posibil.

[gutui]

la o cautare dupa  "WPA2" in baza de date a patentelor, gasim  US9491621B2

punctul 13, Claims, pag.8/8

[...]

13. A method for communicating data in a wireless communications network, comprising:
transmitting a beacon to a station, the beacon comprising a Wi-Fi Protected Access II pre-shared key (WPA2-PSK) authentication type;
receiving an authentication request from the station, the authentication request comprising the WPA2-PSK authentication type, a first secure attribute exchange (SAE) information element, and a station nonce;

transmitting an authentication response to the station, the authentication response comprising the WPA2-PSK authentication type, the first SAE information element, and an access point nonce;
generating a pairwise master key (PMK) identifier based on the first SAE information element;
receiving an association request from the station after generation of the PMK identifier, the association request comprising a key confirmation derived from the PMK identifier and a second SAE information element;

and transmitting an association response to the station in response to receiving the association request, the association response comprising the key confirmation and the second SAE information element.

[...]

 

vulnerabilitatea Krack pare a fi rezultatul specificatiilor cit si a implementarii.

 

@yoyois

protocolul “four-way handshake” folosit, functioneaza cam asa :

1. (AP catre client) stabilim o cheie doar pentru aceasta sesiune. iti trimit un set de date unic, pe sesiune, pe care sa-l folosesti tu.
2. (client catre AP) OK, ia de aici un set de date unic, pe sesiune, pachet de date  generate de mine, pe care sa le folosesti tu.

in acest moment, ambele parti isi "amesteca" impreuna parolele de retea  Wi-Fi  ( Pre-Shared Key sau PSK) si cele doua pachete de date transmise genereaza o cheie unica pe sesiune.

astfel, se evita utilizarea directa  a PSK in datele tansmise criptat in reteaua Wi-Fi, si se asigura cheia unica pe sesiune.

3. (AP catre client) confirma acordul asupra setului de date ca fiind suficient pentru a se construi cheia unica.
4. (Client catre  AP) confirma si el acordul sau.

nu vad cum ar putea fi extras Pre-Shared Key-ul.

Edited October 18, 2017 by gutui

[Matasareanu]

Cea mai ok explicatie de pana acum pe care am gasit-o:

 

[john.doe]

@QuoVadis

 

OFF: Thanks for correction. Is good to receive feedback, this way you can update your skills. I chose English for writing (although I am a Romanian) and I am not going to change this. I won`t spend time explaining way.

 

ON: If you want to be smart try to give solutions to the actual problem. 

#1 - WPA2 Enterprise with EAP-TLS. 

EAP-TLS info

When you implement WPA2-Enterprise you are basically using the IEEE802.1X for device authentication. EAP-TLS is used by the IEEE802.1X to enforce certificate exchange between the AP and the mobile device prior to use the network. Although I do not know any vulnerabilities of EAP-TLS, I cannot say is bulletproof. EAP-TLS allows your Wi-Fi network to be used only be authenticated devices. The next step is to authorize the use of the mobile device and log its activity.

 

#3 - You are right, SMBs should use these security features. Hence, you increase the level of security, but an experienced attacker will find no difficulties in bypassing all these security features. They are mandatory but not enough to stop all attacks.

 

#4 - Zero-day attacks exist and will always exist. What`s important is how you address them. Surely an unpatched system is worse then an up-to-date with zero-day vulnerabilities.

For instance, Apple patched this vuln on their Beta program for IOS some time ago (this attack is not "fresh", it was discovered 3 weeks ago if I am not mistaken).

 

I see things differently: A device is just a tool, what you do with the device is another thing. We should address security concerns by using a solution focused not on the device itself, but on what the device can do to my network.

 

Update: 

http://resources.infosecinstitute.com/krack-attack-earthquake-wi-fi-security/

http://blog.erratasec.com/2017/10/some-notes-on-krack-attack.html#.WemWtPlS3mE

https://www.linux.com/blog/2017/10/tips-secure-your-network-wake-krack

 

Latest info

The attack can make a device reuse old encryption keys so the attacker can decrypt the traffic. Even worse, the attacker can force your device to not use encryption at all. It depends on the device implementation of the standard. For bad implementations, the only solution to the problem is to change the firmware/upgrade OS.

WPA2-Enterprise with EAP-TLS may or may not protect you. It depends on the manufacturer`s implementation. Basically, by using EAP-TLS you form a key out of the certificate and encrypt all traffic between the AP and the mobile device with that key. This key is changed on at regular time intervals. When the re-initialization process of the key takes place, the attacker can force the mobile device to ignore encryption or to use old keys. 

 

In my opinion the only viable solutions are:

- patch firmware/OS

- use HTTPS sites whenever possible

- ensure there are no rogue AP on premise of Wi-Fi network

- always be cautious. Do not put your trust on the device (use your judgment instead)

Edited October 23, 2017 by john.doe
update

[john.doe]

Interesting article about the subject

 

http://securityaffairs.co/wordpress/64601/hacking/krack-attack-nsa.html

[Nytro]

La cate lucruri s-au aflat la acel moment, faptul ca ar avea acces la acest "krack" e unul dintre lucrurile minore.

[gutui]

2 hours ago, Nytro said:

La cate lucruri s-au aflat la acel moment, faptul ca ar avea acces la acest "krack" e unul dintre lucrurile minore.

da! ... defective by design si acum update-uri care aduc in "legalitate" vulnerabilitatea,  fara insa a oferi solutia "backdoor free" datorita specificatiilor tehnice ale patentului...

"[...] in order for the government to legislate a mechanism that would no longer meet the definition of a backdoor, they must disclose to the owner that the government can install functionality through auto-update (the third prong), or disclose that functionality that can introduce code deemed objectionable by the owner (the second prong). If the user chooses to still update their software, then this is not a backdoor because it’s been disclosed, and either its intent or its origins have been fully stated. It is, in fact, much worse than a backdoor at this point; it is a surveillance tool and should be treated as such in law. [...]

In today’s legal landscape, secret court orders are a possibility. In such scenarios, we are no longer discussing disclosed actors or intent, but rather secret orders such as those going through a FISA court, such as section 702 orders or secret orders under the All Writs Act. In these cases, our hypothetical software update service could unwittingly become a backdoor if the government chose to quietly control it without any disclosure to the user.

In the same way, for the manufacturer to be ordered to keep such capabilities a secret would be to turn the manufacturer into an arm of government for the express intent of creating a backdoor, and the manufacturer could be considered partially liable for the consequences of doing so. Those that control the mechanism dictate the intent, and so if the government is partially in control of the mechanism, then their intentions must become part of the overall test. In such a case, the functionality of the software would likely subvert the intent disclosed to the user. Consent would similarly become invalidated, resulting in a software update mechanism that qualifies as a backdoor by definition.

"

citatele sint de aici , facute intr-un context diferit, insa aplicabile topivului de fata.