New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
WPA2 Eavesdropping Flaw?
An air of unease set into the security circles on Sunday as they prepared for the disclosure of high-severity vulnerabilities in the Wi-Fi Protected Access II protocol that make it possible for attackers to eavesdrop Wi-Fi traffic passing between computers and access points.
Thanked by 1ehab
Comments
https://github.com/vanhoefm/krackattacks/blob/gh-pages/index.html
rendered page https://www.krackattacks.com
formally verified love ain't enough
Skids will cruise their neighborhood wandering for a huge variety of clients that we all know will remain unpatched
welcome back, old friend
What I don't understand is that these flaws were discovered and published last year, why weren't they fixed or covered by news outlets then?
Also Ubiquiti released a firmware update last week to address these vulnerabilities. If you're using Ubiquiti APs go grab the latest beta firmware from their website.
They just told how it works but havent released the actual scripts yet.
Everything in my apartment is already wired except for phones and tablets. What's the best way to solve this for things that can't be wired?
VPN I guess? And not doing important stuff wirelessly. Hmm, wonder if connecting to a VPN within the LAN will be enough (the server being on the wired network ofc). Still unsure if this vuln. allows the attacker to actually "join" the network.
Soldering iron.
>
It's a MITM attack followed with a replay attack, so the attacker needs to spoof the network first before replaying the handshake.
The WPA2-AES-CCMP encryption is still solid, from what I understand, and passive collection of wifi packets isn't a factor.
VPN while on wireless should work to spoil any packet capturing.
>
Bleeping Computer has a list tracking the status of patches for various projects and equipment.
https://www.bleepingcomputer.com/news/security/list-of-firmware-and-driver-updates-for-krack-wpa2-vulnerability/
A bit late, but my iPhone received a beta/dev update that apparently patches the published vulnerabilities.
That's OK because I use my SSID as my password to make it easy to remember!
There was some WPA update in my Linux Mint today, I'm guessing it's a patch for this
Well, yes and no. A formal proof is specific; that's its nature. So, the statement "has been formally proven correct" may or may not relate to a certain property of a mechanism. (For the sake of comparison: For a given security entrance, say, of a data center, one might say that its security was formally proven, actually meaning, that the doors, the locking mechanisms, and the locks material, construction, etc. have been thoroughly checked against all well known lock breaking attacks. But still, some bad guy might, for instance, use a bomb or some chemical or just kidnap an authorized person).
Moreover, one actually needs to formally verify two (or more) different things, usually the crypto algorithm (and its implementation) and the protocol. To do that quite different approaches and tools are used. Obviously in the given case a limited set of properties (as opposed to mDY) has been checked/verified.
In the given case one major point is a known starting state and the fact that the handshake mechanism can be forced into that state (which is not surprising btw. given the nature of such systems (often even public)). More precisely the starting state uses a nonce of zero.
It's not that zero is somehow a worse number than any other (except, of course, for 42 g) it's that zero is the smallest possible state space, namely a single number (which, to make it funny has quite uncommon mathematical properties).
To understand state space better consider this: We say that rsa512 is utterly insecure but that rsa 2048 is still OK. The difference? state space (or in math lingo, the domain). The reason btw. is not just that factorizing 2048 numbers is computationally so much harder than 512 bit numbers but that there are vastly more primes (and non primes).
So, state space is very important. Prof. Bernstein and others are absolutely right to push people to use nonces (a number used only once).
Plus: those security researchers have found by far more grave problems, namely in the library of a very widely used crypto chip (e.g. with yubikey) which happens to also be used in some countries "smart" citizen cards, ids, etc.
Oh and, because the current case seems to suggest that most crypto and security related protocols are formally verified. NO they are not. In the luckier cases some algorithm is verified but most implementations are not.
This vulnerability is not in the WPA2 protocol at all. What is vulnerable is the linux client implementation in wpa_supplicant. Vulnerable are only systems that use the linux implementation (i.e. Linux, MacOS, FreeBSD, Android, IOS). Windows for instance is not vulnerable - it does not use the buggy linux wpa_supplicant implementation.
Once you have upgraded your wpa_supplicant you have nothing to worry about.
Even with the buggy wpa_supplicant, making use of this theoretical vulnerability is pretty hard. Probably only of academic value.
So don't worry, your passwords for your favourite porn sites are safe.
MacOS, FreeBSD, iOS are not "linux" no matter how hard you try to stretch the meaning of "linux" and Windows is vulnerable to this as well. See:
and Windows is affected as well . On top of it, Windows is not used on domestic routers and similar hardware. And I wouldn't rush to praise Microsoft secops.
Sadly we couldn't formally verify each implementation. Nice and well written insight nevertheless
that's debated lately, factorizing 2048 does not seem that much harder anymore (at least, for a state-level adversary). This may or may not weaken the "domain" of rsa 2048, but for sure doesn't really make it look so "secure", not to mention that implementations will always be running wild
Of course FreeBSD is not Linux, they simply "borrowed" the same open source wpa_supplicant implementation. Or Linux borrowed it from FreeBSD, or from something else - i don't know where it was implemented first.
wpa_supplicant is a cross platform supplicant implementation, for Windows too. It's free software released under the BSD license. This doesn't make it a "Linux" or "FreeBSD" solution engineered in the "Linux" or "FreeBSD" HQ.
Ok, so everything that uses the buggy wpa_supplicant implementation has this problem. Update wpa_supplicant and that's it. The WPA2 protocol itself is fine. There was some software bug in wpa_supplicant and it is fixed in the latest version.
That's again not what is written in the advisory; an unpatched wpa_supplicant is allegedly "especially catastrophic" but it's not a vulnerability concerning wpa_supplicant only, and that's not what Microsoft patched.
No.While theoretically one could say that wpa2 per se is OK but that doesn't make sense as wpa2 without the crypto is meaningless.
Moreover, even if windows were OK (which I bet it's not) that wouldn't change much as all the funny plastik wlan boxen don't use it. Keep in mind that we're talking about something with 2 sides, 1 of which not being OK is enough to fuck the whole thing.
That can indeed be debated. In fact, rsa per se can be debated. My statement, however, was based on the criterion "known to be crackable in low time" (as in "hours" or max a few days). Along that criterion even rsa 1k isn't utterly insecure and rsa 2k is secure. Or, more precisely, it's secure as far as state space is concerned. One might, however, reasonably doubt rsa per se, in particular wrt implementations.
Sidenote: I do not advise clients to use rsa anymore and I'm also not too sure how long ecc will hold firm; I prefer it for one major reason, namely that there are implementations of far better quality.
In the medium to long run, however, we'll have to design, implement and use something far better. Unfortunately the candidates, typically under the "post-quantum" label, don't have all the properties to make us happy and are moreover often not yet well enough researched (e.g. sidh).
I personally bet more on new symmetric schemes. They are well understood, there are good implementations (which are usually easier to get right, too), they are usually easy to extend in terms of state space (although 256 bit seems damn good enough for quite some decades) and they are by far more lightweight than public key crypto (which i.a. means that they don't lend themselves well to DOS attacks). I expect a future with considerably more secure (beyond NP towards NE) but also more expensive PK to exchange large keymat "reservoirs" for SK that is used much less frequently that todays PK. Which, to be frank, is used idiotically and wastefully anyway and at the same time often doesn't work properly and reliably and doesn't deliver what it promises, much of which, frankly, isn't needed anyway. But granted, I don't know many who share that view; most believe zealously in PK, particularly in ssl/tls (but then, most hardly have even a clue what they are praising...)
It is a client side bug, not an AP side bug. The plastic boxes (APs) don't need to be updated / fixed. Unless they can be used as clients to connect to other wireless networks, then they need to be patched too. But if they act just as APs, they should be OK.
VPN, clear. But wouldn't be important stuff use https anyway? mails do something like TLS.
So I wonder what is actually left to snoop?
That's again something not aligned with the security advisory. See:
Once packets are captured, it's just a matter of time before they are decrypted. VPNs, preferrably IPSec, provide defense in depth. VPNs, should, use heavier crypto, and if the packets are captured, it will take longer for attackers to break through the layers.
Check out SSLstrip (https://moxie.org/software/sslstrip/).
>
DNS and traffic flow. TLS isn't going to help when DNS gets hijacked, and the attackers can still see what site is being accessed.
Windows was partially affected, and only partially because MS didn't implement the standard correctly. wpa_supplicant is affect much more because it implemented the standard correctly.
Wasn't a problem found in ecc recently? I can't find the source, or I would post it.
Now, if that isn't funny!
You are right; ecc isn't perfect either but it's considerably better than rsa (note: opinions on that vary). I guess you mean the problems related to many Weierstrass curves.
25519, however, shouldn't have any problems.
As I already said, while ecc is (not only imo) better than rsa, still they both are in a complexity range where "NP" is quite relative and might change frighteningly. So, when I talk about ecc I mean a) good curves (not general weierstrass but e.g. Edwards), b) good implementations (like djb's) and c) that's said in the context of PK today.
For really sensitive scenarios I personally use a ratchet mechanism with a modified KEX where the "key" isn't used as key but as one ingredient that together with a preshared part gets hashed with the resulting hash serving as prng seed and a second factor (2fa) is the step count.
Obviously that is not something that I would advise for common everyday usem say to surf to web sites. It is, however, a pretty solid basis for infrequent (sym) keymat updates.