6 ms·
This is not an end-of-the-world type vulnerability. 1. Does not affect long-term credentials - certs, wifi passwords are still safe. Rather, confidentiality (s
by twitchyliquid64 9y ago
This is not an end-of-the-world type vulnerability.
1. Does not affect long-term credentials - certs, wifi passwords are still safe. Rather, confidentiality (secrecy) from client --> AP is affected, and in some cases packet forgery is possible (integrity).
2. Actually accomplishing this attack, for now, requires special and expensive hardware (med to high range SDR gear). Its also not that reliable outside of a lab environment.
3. Everything you care about _should_ be going over TLS, which mitigates all effects of this attack. If it isnt, fix it.
This is a great moment for you to fire up wireshark and audit the traffic going over your wireless link. If its not adequately protected and you care about it, fix it.
- cm2187 9y agoAlso doesn't it require the attacker to have access to your wifi already? If that's the case, it's a hazard for connecting in a Starbucks or on your mobile service wifi, but you would be safe on your home or corporate wifi (unless the attacker is a colleague or relative!).
- snerbles 9y agoTotally safe, until your local war-driver sniffs out your insecure device and comes back at two in the morning to upload illegal content via your ISP.
- macawfish 9y agoYou're freaking me out with that scenario
- ibmthrowaway218 9y agoExcept the attack doesn't get you access to their wireless network. It allows you to redirect someone from their wireless network to your own (spoofed) wireless network and then you can snoop the traffic.
- lightedman 9y agoIf it works in one way what reason is there to think it won't work the opposite direction? This flaw is in the protocol itself.
- danilocesar 9y ago> Also doesn't it require the attacker to have access to your wifi already? No it doesn't. Watch the video. It creates a clone of your network and tricks the victim's software stack to connect into it.
- makomk 9y agoNope. The man-in-the-middle attack it uses involves forwarding and replaying encrypted packets without decrypting the contents, so all it requires is that the attacker be within range of your wifi; they don't need any of your keys or passphrases.
- mikehollinger 9y agoSpecial gear isn't all that expensive. From a cursory view of the video and a skim of the paper, they're using hostapd, which means that they simply need a wifi adapter with a sufficiently-good driver. Anything with the RTL8188CUS seems to be pretty nice (that's what I'm using in a raspberry pi project, myself). So - I agree with you that there's a barrier to entry, but it's not that big of a barrier.
- bitexploder 9y agoAgreed. Not specialized equipment. Just something that lets you shoot raw frames and run as a WiFi AP. I have 2 such USB WiFi dongles in my bag for setting up such environments. Give: http://www.tp-link.com/us/products/details/cat-5520_TL-WN722N.html http://www.tp-link.com/us/products/details/cat-5520_TL-WN722... a shot. It will let you setup an AP in a VM easily, etc. It is our currently anointed dongle for VM hosted MiTM setups. I haven't tested it, but it should work fine if they are just using mods to hostapd.
- ktta 9y agoNote that there are two versions of that dongle. The version 1 has Atheros Chip[1] with the best wi-fi support but version 2 has a Realtek chip[2] with subpar support. AFAIK it isn't possible to get version 1 of the dongle today. My suggestion is Alfa AWUS036NHA (The last three letters are important!) which has AR9271 chip with great support with the ath9k driver. [1]: https://wikidevi.com/wiki/TP-LINK_TL-WN722N https://wikidevi.com/wiki/TP-LINK_TL-WN722N [2]: https://wikidevi.com/wiki/TP-LINK_TL-WN722N_v2 https://wikidevi.com/wiki/TP-LINK_TL-WN722N_v2 [3]:http://www.ebay.com/itm/ALFA-AWUS036NHA-802-11n-Wireless-N-Wi-Fi-USB-Adapter-High-Speed-Atheros-AR9271-/380458349886 http://www.ebay.com/itm/ALFA-AWUS036NHA-802-11n-Wireless-N-W...
- bitexploder 9y agoHmmn, I wasn't aware. I will have to check and see, but it is probably I have a v1, since I have had it for a while. It has always taken a bit of effort and hunting to find WiFi cards with good chipsets that support monitor mode and AP modes painlessly (for WiFi frame capture, etc.). Thanks for the info... I am a little disappointed, the ones we have been using are all very reliable and worked out of the box, so we must have the Atheros ones. It also seems impossible to order the older version specifically.
- reluctantnitro 9y agoWrong, my devices have already been attacked with a handheld device. The attacker managed to hack my phone through this attack, which means that there is a compromise to kernel available in all Android's from wifi. They changed multiple parameters and downloaded my banking information as well as account details. Unfortunately for them, I am financially very poor. NSA and FBI are worthless. They never warn and just leave everyone exposed and vulnerable just to make their career points. Good thing for independent researchers. Never tell the NSA or FBI about security vulnerabilities. They will just threaten you to shut up. They are extremely nasty, cruel people. Nothing is too low or out of bounds to them to get you to keep quiet. Go direct to company and public.
- danilocesar 9y agoWhere did you find the information that it needs SDR? I couldn't find it in the paper (but I didnt fully read it) or the website.
- bitexploder 9y agoSpeculating. I don't think SDR is needed. Logically, all you need is a WiFi card that lets you do fairly standard things with the WiFi frames.
- jim-greer 9y agoAs far as I can tell that’s dangerous misinformation.
- andoma 9y agotcpdump -nw - | strings -n 6 Credit to https://twitter.com/marcan42 https://twitter.com/marcan42
- cratermoon 9y agoWhat exactly should a person who uses this command be seeing or looking for that would indicate a problem or not?
- iKenshu 9y agoSo, even if I'm using the extension HTTPSEverywhere I'm safe?
- wskinner 9y agoHTTPSEverywhere will not magically upgrade a site that doesn't serve HTTPS to HTTPS. If you connect to a site that doesn't support HTTPS, you are vulnerable.
- iKenshu 9y agoOh I see, Thanks for the answer! For what is useful the extension then?
- thecrazyone 9y agoThe extension makes you use the HTTPS connection when the site you are connecting to is known to support HTTPS. Websites can automatically redirect to HTTPS if the client connects on http, but many websites don't redirect
- kzahel 9y agoIt has the option to block HTTP traffic, making sites that don't support HTTPS unusable. You could create a separate "secure" profile and feel safe that all traffic is secured, while still being able to browse HTTP in another profile, for instance.
- spsful 9y agoTheoretically. The extension can refuse to load sites that aren’t using HTTPS, but the real flaw is sites that use SSL instead of TLS. Attackers can reject SSL but they can’t do anything about TLS, so the security of your browsing would be affected by the website’s HTTPS configuration, and whether they use SSL, TLS, or both (the only 100% safe method is TLS only). I know for most people disabling SSL and going TLS-only isn’t high on their list of priorities so I expect this attack to be very successful on the internet as it is right now.
- collinmanderson 9y agoDon't forget about HSTS. The author demonstrates in the video that you can sometimes bypass TLS if HSTS is not set up.
- mrb 9y agoNo, you do not need expensive hardware such as SDR to carry the KRACK attacks. Most plain standard WLAN adapters support AP mode, which is all you need to simulate the rogue network, as demonstrated in the video.
- SadWebDeveloper 9y agoYou still need proximity to the client, a powerful SDR will definitely improve reliability on real-life environments.
- twitchyliquid64 9y agoI stand corrected. Rogue AP / MiTM only needs a AP with the ability to send raw packets, gotcha.
- firewall-bad 9y agoI do think it's an end-of-the-world type vulnerability, at least as far as Wi-Fi goes. 1) The paper claims confidentiality compromise allows the attacker to hijack a tcp connection: "allow an adversary to decrypt a TCP packet, learn the sequence number, and hijack the TCP stream to inject arbitrary data", this on all cases, even in the cases where it doesn't allow forgery (CCMP) 2) There's no such claim on the paper and according to the researcher, exploiting this on Android and Linux is trivial. Apparently also macOS. Did you see the video on their website? 3) There's no way for you to control this (apps, https stripping, for instance). Most importantly, there's no way for the average user to control this, short than using a VPN. Again, as far as Wi-Fi security goes, seems pretty end-of-the-world to me. I don't think the huge attention this is getting is unwarranted.
- SadWebDeveloper 9y agoYou have two school of thought here... optimist vs pessimist. Remember that the attack affects mostly client implementations therefore still needs proximity to victim(s), this makes most of the end-of-the-world type scenarios impractical (they even state these on their QA) and leaves exploitation to direct/APT-groups alone.
- firewall-bad 9y agoWell I did mention it's "an end-of-the-world type vulnerability, at least as far as Wi-Fi goes". I don't think it's a lot of consolation saying something along the lines of "Wi-Fi security is broken, but it's not so bad because it's Wi-Fi"
- SadWebDeveloper 9y agoYou should read "Silence on the Wire: A Field Guide to Passive Reconnaissance and Indirect Attacks" by Michal Zalewski to expand your universe on things you should be afraid pal. Interesting book that can really burst your bubble on how bad things are and yet we are still here.
- 9y ago
- cryptonector 9y agoMost IoT devices never get patched. With this vulnerability you can just drive around and spy on webcams. I mean, that's pretty bad. It's enough to make me want to build rpi wifi-wired bridges/gateways for every IoT I own (which, thankfully, isn't all that many, but enough to annoy me).
- panarky 9y ago> 3. Everything you care about _should_ be going over TLS, which mitigates all effects of this attack. This is probably the biggest misconception. Many, many websites and APIs don't have HSTS enabled to force all connections to use TLS. The author demonstrates using sslstrip to downgrade the connection of match.com to steal credentials. How many people watch the green "secure" indicator in the URL bar to ensure it doesn't change mid-session? How many thousands of apps don't even have such an indicator to observe? How many millions of phones and APs will never get patched? This is a severe vulnerability.
- mercer 9y ago> How many thousands of apps don't even have such an indicator to observe? I honestly never considered that one...
- twitchyliquid64 9y ago> Many, many websites and APIs don't have HSTS enabled to force all connections to use TLS. True. Yet another reason for us to push for it. I have a chrome extension that sets the background-color of all form fields to red if the site it was served on or the ACTION attr are not https. That said, pretty much every website in my day except for casual reading is pinned to TLS. APIs are the notable exception you pointed out, but otherwise HSTS is quite widely used, and especially effective with preload lists. > How many thousands of apps dont have this indicator to observe? Sure there will be some, but your standard Java apache client (along with 99% of the libraries used in Apps) dont have this kind of downgrade behaviour. If they expect validated https, they will fail without it. > This is a severe vulnerability. Yepp :D Not the end of the world. I think the main fallacy here is the implicit assumption that the link layer is secure. That has never really been the case and a broken wifi model is merely one more testament to this fact.