Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
HTTPS doesn't save you here.
[doublepost=1508167554][/doublepost]

Yes.

Https saves half of you here: all major websites have https implemented correctly, and https means that this exploit can’t see the data coming from the server with which you’re communicating.
 
  • Like
Reactions: grayskies
This is only tangentially related to Apple because they made and still sell routers so why bring that troll line up even in sarcasm? The flaw is in the Wi-Fi standard itself.

No, the WiFi *standard* is still secure. This (massively overblown) exploit exists because most client-side libraries that implement WPS are doing it incorrectly.
 
No, the WiFi *standard* is still secure. This (massively overblown) exploit exists because most client-side libraries that implement WPS are doing it incorrectly.

From the Krackattacks.com web site (site of the two who discovered the vulnerability -- so if you have a beef with what I wrote about the Wi-Fi standard take it up with them since you are apparently more knowledgeable than they on the subject.)

Will the Wi-Fi standard be updated to address this?
There seems to be an agreement that the Wi-Fi standard should be updated to explicitly prevent our attacks. These updates likely will be backwards-compatible with older implementations of WPA2. Time will tell whether and how the standard will be updated.
 
This can't be overstated. How many hotels, Starbucks, etc. even know what "firmware" is or how to access their WiFi settings? And just think of all the cheap Chinese routers out there that will never see updates from the manufacturer.

Except for extremely rare edge cases, this exploit has nothing to do with wireless routers. Client devices that connect to access points (phones, computers, etc), MAY be succeptible to having some (mostly outgoing) data intercepted, IF the attacker has physical proximity to you... in which case there are far better attacks than this one.
 
No, the WiFi *standard* is still secure. This (massively overblown) exploit exists because most client-side libraries that implement WPS are doing it incorrectly.

from the article "This vulnerability appears to be caused by a remark in the Wi-Fi standard that suggests to clear the encryption key from memory once it has been installed for the first time. When the client now receives a retransmitted message 3 of the 4-way handshake, it will reinstall the now-cleared encryption key, effectively installing an all-zero key."
 
From the Krackattacks.com web site (site of the two who discovered the vulnerability -- so if you have a beef with what I wrote about the Wi-Fi standard take it up with them since you are apparently more knowledgeable than they on the subject.)
Well, I’m a CISSP at the tip of the spear, so I know as much as he does, anyway...
From the Krackattacks.com web site (site of the two who discovered the vulnerability -- so if you have a beef with what I wrote about the Wi-Fi standard take it up with them since you are apparently more knowledgeable than they on the subject.)

The quote you referenced doesn’t say that the standard’s insecure, just that they could update the standard in the future (to prevent the potential issues caused by incorrectly implementing the standard on the client side). Basically, ‘We wrote an airtight wireless standard, but since everyone’s too dumb to implement it correctly, we might put in controls to explicitly block their bad practices.’
 
Then why did Vanhoef (one of the researchers) say, "a patched client can still communicate with an unpatched access point"? Sounds like both need to be patched for it to be fully fixed, though it's not clear to me what an unpatched AP would do besides not participate in helping an unpatched client fall victim to this problem (though I assume this could be used by someone who knows what they're doing to gain access to an otherwise password-protected network).

The long explanation: When your computer or phone connects to a WiFi router, there is a negotiation that takes four steps. The attacker listens in. After step 3, the hacker's hardware shouts very loudly "hey, something went wrong here". At the same time, it manages to convince one of the two devices to throw an important key away. Because both devices think that something went wrong, they repeat step 3, and because that key was thrown away, a key of all zeroes is used, and with that the attacker can crack the encryption (simple because a key of all zeroes was used).

The fix is very simple: If one of the devices refuses to re-negotiate from step 3, but insists on starting all over, then the problem goes away. _Either_ side can do that. It takes a bit longer repeating step 1 and step 2, but in reality this happens so rare that it doesn't matter. So now if the attacker tries the same trick, one of the devices says "sorry, not re-negotating from step 3, we have to start all over again." And the attack doesn't work anymore.

Obviously you _should_ fix all devices, but if either your Mac / iPhone _or_ your router are fixed, you are fine.
 
from the article "This vulnerability appears to be caused by a remark in the Wi-Fi standard that suggests to clear the encryption key from memory once it has been installed for the first time. When the client now receives a retransmitted message 3 of the 4-way handshake, it will reinstall the now-cleared encryption key, effectively installing an all-zero key."

That quote’s referring to why a WPA-implementation library (wpa_supplicant) would set an encryption key to all zeros: i.e. the ‘client-side implementation library error’ was seemingly caused by that comment. Again, the underlying WiFi standard’s fine (as far as we know!).
 
No, the WiFi *standard* is still secure. This (massively overblown) exploit exists because most client-side libraries that implement WPS are doing it incorrectly.
How is this massively overblown?

It will be patched on many primary systems (phones, computers, routers) over time.

However, there is a sea of secondary computing infrastructure that will likely never be patched. Or will require such high effort to patch that most people just never will. Not only the IoT type stuff, but common things like printers.

I can access 20-30 secure wifi networks from where I'm sitting right now. The first line of defense those networks had is presently compromised. That seems quite major to me.
 
Https saves half of you here: all major websites have https implemented correctly, and https means that this exploit can’t see the data coming from the server with which you’re communicating.

You're incorrectly assuming that the only data sent over wifi is web browsing. There's a LOT of other things people will have access to if they can intercept your wifi connection. I can browse your computer files and even potentially read your HTTPS sessions by grabbing the encrypted session data.

DMSJYtOU8AAOZj1.jpg
 
HTTPS doesn't save you here.
[doublepost=1508167554][/doublepost]

So your saying any https certificate is invalid, with domain match and the nice green lock? If you get
the, this certificate does not match the domain, then yes. Thought that's everything about https.

What am I missing? Thx
 
So your saying any https certificate is invalid, with domain match and the nice green lock? If you get
the, this certificate does not match the domain, then yes. Thought that's everything about https.

What am I missing? Thx

If I can capture all your traffic, I can capture your initial secure session start with HTTPS and possibly have access to that session going forward. Essentially you're setting a password with the secure site when you first visit it. If I can get that password when it's first sent, I can decrypt all the rest of what happens during that session.
 
If I can capture all your traffic, I can capture your initial secure session start with HTTPS and possibly have access to that session going forward. Essentially you're setting a password with the secure site when you first visit it. If I can get that password when it's first sent, I can decrypt all the rest of what happens during that session.

Thx, I gathered that from your post above mine. I did not see, just replied to your comment way above.

"if", that is really a understanding using WiFi imo.
 



Mathy Vanhoef, a postdoctoral researcher at Belgian university KU Leuven, has discovered and disclosed major vulnerabilities in the WPA2 protocol that secures all modern protected Wi-Fi networks.

wi-fi-mac-800x288.jpg

Vanhoef said an attacker within range of a victim can exploit these weaknesses using so-called KRACKs, or key reinstallation attacks, which can result in any data or information that the victim transmits being decrypted. Attackers can eavesdrop on network traffic on both private and public networks.

As explained by Ars Technica, the primary attack exploits a four-way handshake that is used to establish a key for encrypting traffic. During the third step, the key can be resent multiple times. When it's resent in certain ways, a cryptographic nonce can be reused in a way that completely undermines the encryption.

As a result, attackers can potentially intercept sensitive information, such as credit card numbers, passwords, emails, and photos. Depending on the network configuration, it is also possible to inject and manipulate data. For example, an attacker might be able to inject ransomware or other malware into websites.

Note that the attacks do not recover the password of any Wi-Fi network, according to Vanhoef. They also do not recover any parts of the fresh encryption key that is negotiated during the four-way handshake.

Websites properly configured with HTTPS have an additional layer of protection, but an improperly configured site can be exploited to drop this encryption, so Vanhoef warned that it is not reliable protection.

Since the vulnerabilities exist in the Wi-Fi standard itself, nearly any router and device that supports Wi-Fi is likely affected, including Macs and iOS devices. Android and Linux devices are particularly vulnerable since they can be tricked into installing an all-zero encryption key instead of reinstalling the real key.As a proof-of-concept, Vanhoef executed a key reinstallation attack against an Android smartphone. In the video demonstration below, the attacker is able to decrypt all data that the victim transmits.


iOS devices are vulnerable to attacks against the group key handshake, but they are not vulnerable to the key reinstallation attack.

Fortunately, the vulnerabilities can be patched, and in a backwards-compatible manner. In other words, a patched client like a smartphone can still communicate with an un-patched access point like a router.

Vanhoef said he began disclosing the vulnerabilities to vendors in July. US-CERT, short for the United States Computer Emergency Readiness Team, sent out a broad notification to vendors in late August. It is now up to device and router manufacturers to release any necessary security or firmware updates.

Despite the vulnerabilities, Vanhoef says the public should still use WPA2 while waiting for patches. In the meantime, steps users can take to mitigate their threat level in the meantime include using a VPN, using a wired Ethernet connection where possible, and avoiding public Wi-Fi networks.

Vanhoef is presenting his research behind the attack at both the Black Hat Europe and Computer and Communications Security conferences in early November. His detailed research paper (PDF) is available today.

Article Link: Major Wi-Fi Vulnerabilities Uncovered Put Millions of Devices at Risk, Including Macs and iPhones
If you ever get attacked, remember to turn off your computer, go outside, take a breath of air, and enjoy life
 
Thx, I gathered that from your post above mine. I did not see, just replied to your comment way above.

"if", that is really a understanding using WiFi imo.

This entire vulnerability to current wifi is a big if. 99.9% that even understand and can take advantage of it aren't going to get anything of value from others through it. There's little risk as in most situations like this.
 
  • Like
Reactions: LauraJean
Even if Apple patches the exploit, will they only do it for High Sierra, or offer patches all the way back to El Capitan?

I'm thinking they'll only do Sierra/High Sierra because that's what they're shipping now.
 
Even if Apple patches the exploit, will they only do it for High Sierra, or offer patches all the way back to El Capitan?

I'm thinking they'll only do Sierra/High Sierra because that's what they're shipping now.

They often release security updates, especially for something as major as this, for the previous major OS. However it is so close to the High Sierra release I wouldn't be surprised if an El Cap version came out also. Maybe after the High Sierra/Sierra ones.
 
If I can capture all your traffic, I can capture your initial secure session start with HTTPS and possibly have access to that session going forward. Essentially you're setting a password with the secure site when you first visit it. If I can get that password when it's first sent, I can decrypt all the rest of what happens during that session.

That's completely bogus. What you're describing is a replay attack which isn't possible over HTTPS because the initial handshake is done securely as well, assuming the server's certificate is signed by a CA—which is going to be any legit site.

Unless the attacker tricks you into connecting to his spoofed server or he has access to one of the root certificates that also is installed on the victim's machine, you're not going to be able to crack 256 bit encryption. Most decent websites are also doing some sort of CSRF token/nonce protection so even if you were to get a session id, you couldn't effectively use it because whatever they just did was in the past.
 
  • Like
Reactions: RMo and bearda
If I can capture all your traffic, I can capture your initial secure session start with HTTPS and possibly have access to that session going forward. Essentially you're setting a password with the secure site when you first visit it. If I can get that password when it's first sent, I can decrypt all the rest of what happens during that session.

Not with current versions of TLS. Key exchange algorithms exist specifically so parties looking at traffic over the wire can see the values being passed but still not determine the resulting key. Diffie Hellman is a common example:
https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange

There are a few attacks that can be carried out with full man in the middle access, but they're usually the result of another vulnerability somewhere else in the chain.
[doublepost=1508198689][/doublepost]
This entire vulnerability to current wifi is a big if. 99.9% that even understand and can take advantage of it aren't going to get anything of value from others through it. There's little risk as in most situations like this.

That's true until someone releases exploit code and it becomes commoditized. It really only takes one guy who really understands it to do that, and then everyone tends to pile on. Once someone writes a tool or metasploit module the barrier to taking advantage of it lowers tremendously and people start doing stupid stuff.
 
  • Like
Reactions: RMo and SpinThis!
The first thing I did when I moved was hardcable every room.
I have ethernet off the router which is in the basement. I think I will go back to my original rule: banking means I take the MacBook Air downstairs and use ethernet. Too lazy to do that for shopping. Should I? If I connect to an online store and make a purchase over WiF and if a hacker-criminal is parked in a car in front of my house, then my login info can be snitched??? If site is htpps? If site is not htpps?
[doublepost=1508202108][/doublepost]
The long explanation: When your computer or phone connects to a WiFi router, there is a negotiation that takes four steps. The attacker listens in. After step 3, the hacker's hardware shouts very loudly "hey, something went wrong here". At the same time, it manages to convince one of the two devices to throw an important key away. Because both devices think that something went wrong, they repeat step 3, and because that key was thrown away, a key of all zeroes is used, and with that the attacker can crack the encryption (simple because a key of all zeroes was used).

The fix is very simple: If one of the devices refuses to re-negotiate from step 3, but insists on starting all over, then the problem goes away. _Either_ side can do that. It takes a bit longer repeating step 1 and step 2, but in reality this happens so rare that it doesn't matter. So now if the attacker tries the same trick, one of the devices says "sorry, not re-negotating from step 3, we have to start all over again." And the attack doesn't work anymore.

Obviously you _should_ fix all devices, but if either your Mac / iPhone _or_ your router are fixed, you are fine.
Very good explanation, Gnasher, thank you.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.