Slashdot Mirror
WPA2 Security Flaw Puts Almost Every Wi-Fi Device at Risk of Hijack, Eavesdropping (zdnet.com)
A security protocol at the heart of most modern Wi-Fi devices, including computers, phones, and routers, has been broken, putting almost every wireless-enabled device at risk of attack. From a report: The bug, known as "KRACK" for Key Reinstallation Attack, exposes a fundamental flaw in WPA2, a common protocol used in securing most modern wireless networks. Mathy Vanhoef, a computer security academic, who found the flaw, said the weakness lies in the protocol's four-way handshake, which securely allows new devices with a pre-shared password to join the network. That weakness can, at its worst, allow an attacker to decrypt network traffic from a WPA2-enabled device, hijack connections, and inject content into the traffic stream. In other words: hackers can eavesdrop on your network traffic. The bug represents a complete breakdown of the WPA2 protocol, for both personal and enterprise devices -- putting every supported device at risk. "If your device supports Wi-Fi, it is most likely affected," said Vanhoef, on his website. News of the vulnerability was later confirmed on Monday by US Homeland Security's cyber-emergency unit US-CERT, which about two months ago had confidentially warned vendors and experts of the bug, ZDNet has learned.
Public announcement from Mathy Vanhoef is https://www.krackattacks.com/ and his research paper can be found https://papers.mathyvanhoef.co....
Don't use wifi, or wired, or bluetooth, or zigbee, or zwave. Instead live in a cabin in the middle of the woods aware from technology, just don't pull a Kaczynski, please.
At least for in the home !
Good thing the article is served via HTTPS, eh? Oh wait, zdnet, supposedly a techology news site, DOES NOT SUPPORT HTTPS!
Since no one else uses it, WEP might protect you since people have given up looking for it.
This would be a good time to point out how many vulnerable (and probably forever unpatched) devices would result from the push for IoT.
Maybe enable encryption in SMB? What you are still using SMB1, well more fool you then. It's 2017 the world has moved on.
WPA2 enterprise doesn't use a pre-shared key. So which is it? Does the weakness lie with pre-shared key passwords? Or something else which also affects WPA2 enterprise?
Ah, here we go. The answer is "it's complicated." I'm reading through it right now, but as a PSA:
In the future can we link to original source articles or responses by authoritative organizations, instead of trade rags?
Replay packet 3 in the 4 way handshake, and the client will encrypt two different payloads with the same key and nonce. A big mistake with most encryption methods.
Worse, linux wpa_supplicant nulls out the key memory but still processes the replayed packet, causing the client to use a known (zero) key.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
Any why should it? Are you accessing or supplying anything that's top secret?
P.S. The user authentication page does submit the user credentials via HTTPS: https://secure.zdnet.com/user/...
it's an attack on the client machine, not on the access point. ...).
it means that any unpatched device connected to a wifi network with WPA2 encryption can expect the same security as being connected to an unsecured wifi (anyone can eavesdrop your communication, or could inject stuff,
how easy it is to do, don't know yet, but it seems to be a feasible attack to carry out.
Need to build a device with the special software and come within range of a router to sniff the keys. Then can eaves drop on communication between router and client.
It will take a day at least to build it and then one has to come physically close.
Vulnerable places will be coffee shops, malls, airports etc. Stores that use wi-fi between cash registers and router would be the primary target. BTW Target had security cameras and cash registers talking to the same router using same passwords. If I remember it correctly.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Not if the attacker was also able to man-in-the-middle attack you as well.
Can anyone shed any light on how serious this actually is? How easy is it to exploit this?
I don't want some theoretical answer, either. I want to know in very practical terms.
Is this as bad as the "Shellshock" bash bug and the "Heartbleed" OpenSSL bug were, where systems were being compromised within hours of these bugs becoming widely known?
From the disclosure:
When a client joins a network, it executes the 4-way handshake to negotiate a fresh encryption key. It will install this key after receiving message 3 of the 4-way handshake. Once the key is installed, it will be used to encrypt normal data frames using an encryption protocol. However, because messages may be lost or dropped, the Access Point (AP) will retransmit message 3 if it did not receive an appropriate response as acknowledgment. As a result, the client may receive message 3 multiple times. Each time it receives this message, it will reinstall the same encryption key, and thereby reset the incremental transmit packet number (nonce) and receive replay counter used by the encryption protocol. We show that an attacker can force these nonce resets by collecting and replaying retransmissions of message 3 of the 4-way handshake. By forcing nonce reuse in this manner, the encryption protocol can be attacked, e.g., packets can be replayed, decrypted, and/or forged. The same technique can also be used to attack the group key, PeerKey, TDLS, and fast BSS transition handshake.
this just goes to show who is paying attention :
https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=228519&SearchOrder=4
No it is an attack on both. Though it appears that patched clients would be safe while connected to an upatched AP.
Not every networking protocol can be encapsulated in HTTPS ...
Exactly. I was going to mirror an above AC who said, "I'm surprised that this still needs saying on an allegedly technical forum", but he was implying HTTPS was all you needed (wrong).
... (just ask Active Directory)
OH FFS! That's one of the easiest ones to move to a secure protocol - LDAPS (it even has its own extra protocol version that adds the SSL/TLS, but can also upgrade an LDAP connection via TLSStart).
Plenty of traffic is sent in the clear, and those are all better examples than HTTP/HTTPS and LDAP/LDAPS.
SSL attacks generally require a man-in-the-middle position, which this hack can provide. That should be a bigger concern.
I'm really fucking concerned about how Google will fix this for Android, the most popular OS in the world.
Recent stats are showing that only 0.2% of users are using Android 8.0, the latest version. Only about 18% are using Android 7.x releases. A whopping 32% are using Android 6.x! About 28% are using Android 5.x! About 21% are using Android 4.x!
So like 80% of Android users are still using Android 6.x and earlier!
If this problem can be avoided with a software fix, I think that Google should do everything they possibly can to get this fix to as many Android devices as possible.
I'm sure some fools here will come along and just tell affected users to "buy a new phone" or some infeasible bullshit like that. Realistically, that's not happening. Users will continue to use their older devices. It will reflect badly on Android if it's susceptible to this wifi security issue, even on older devices.
While they obviously can't provide updates to all of the Android devices out there, I really hope that Google will do what they can to get the fix to at least all Nexus and Pixel devices from the Nexus 4 onward.
The most sensible solution would be to fix it in Android 8.x, and then port Android 8.x to the Nexus 4 and all devices after it. Then this release would be made available to those who wish to upgrade. Not only would this fix this wifi problem, but it would also help fix at least some of the serious version fragmentation that Android is currently experiencing.
Well I have an ISP that likes to inject stuff into unencrypted connections is that not reason enough to prefer https sites?
Minimum threshold fixed. Thanks!
an expect the same security as being connected to an unsecured wifi
Not quite that bad. An unsecured wifi can have packets manipulated, and can snoop both directions. Here the attack cannot change any of the data and can only read one direction of the communication. Still pretty bad, but no reason to suddenly not care about open networks versus secured networks.
XML is like violence. If it doesn't solve the problem, use more.
And vice versa, a patched AP can prevent a client from breaking. One or the other side needs to prevent it, but either side by itself is sufficient.
XML is like violence. If it doesn't solve the problem, use more.
I wonder about an almost off-hand remark in section 6.2.
"6.2 Example Attack Scenarios
Among other things, our key reinstallation attacks allow an adversary to decrypt a TCP packet, learn the sequence number, and hijack the TCP stream to inject arbitrary data [37]"
This implies that a "read only" (decrypt only) attack allows attacker to hijack the TCP stream. Can someone with better understanding of the issue explain this point? How can TCP connection be hijacked/modified if attacker has no ability to insert or modify packets at the wifi level (which is why that type of attack is "read only")?
Amazing paper, though.
Google can't do anything about that.
It's the fucking telcos who are withholding updates from the end users. Even if you have the patched version on your hard drive, you can't install it, because your wireless provider won't let you. Verizon is the most egregious offender; as long as they continue to refuse to sell devices with unlocked bootloaders, the only way to install an update is when the telco feels like pushing it to the users.
Note that I would *hope* point of sale equipment and security equipment would use TLS regardless of the media. If that were the case, then the WPA2 weakness would not suddenly provide access to that material.
For a private laptop connecting to public wifi-hotspots, this attack is harder than just setting up another credible wifi hotspot. Any place where the wifi password is well known knowledge is never going to be rigorous security.
XML is like violence. If it doesn't solve the problem, use more.
Of course, strictly speaking LDAPS isn't over https. Of course it is over TLS which is the actual relevant part of the discussion (before someone goes off on insisting that LDAP needs to be over *http*).
Of course, it should be considered a grave problem if any sensitive data relies upon the security of the LAN, considering a large chunk of network access is over an untrusted hotspot (no, that WPA2-PSK in the store with a legit-looking captive portal or the passphrase on the wall, or really any internet connection when you get down to it is not trusted).
XML is like violence. If it doesn't solve the problem, use more.
Fnord fnord fnord!
Some years ago it was reported that a large liquor store in our town was using unencrypted communication between cash registers and an on site computer. They got hacked by someone outside the store in the parking lot. After that discovery and for a while they were using the old fashion carbon paper swipe devices for embossed credit cards or took only cash. The problem was solved by replacing cash registers with ethernet wiring.
The lesson here may be to use the ethernet connection on your laptop when possible for sensitive data use until its WPA2 software is updated. Oh, wait, most new laptops and certainly phones don't come with ethernet connectors and would require a dongle. Ah, the wonderful advances brought to us by ultra thin, lightweight portable computing.
In a time of universal deceit, telling the truth is a revolutionary act. George Orwell
According to Vanhoef, when using WPA-TKIP or GCMP for encryption the bad actor can decrypt, forge and inject packets.
Reading comprehension? Do you have it?
Would it not be possible to prevent by setting up a RADIUS server?
Man In The Middle attacks are not newsworthy and should not be making the front page of Slashdot, these are the equivalent of anti-Trump garbage that floods #fakenews sources.
So a flaw that affects every single Wifi network isn't newsworthy? Repeat: Every single Wifi network. Facts don't matter then to you. From what I can tell not all vendors have supplied patches yet so most people are vulnerable as they are unpatched.
Well, there's spam egg sausage and spam, that's not got much spam in it.
Seriously, the whole design process of WIFI "security" is almost as badly broken as that of mobile phone security. Anybody sane tunnels over these connections, using a VPN or SSH, or the like for anything critical.
And for all those confused: No, this is not HTTP security, i.e. SSL or TLS on TCP-Level (ISO/OSI Leyer 4), this is link-level security for the WIFI connection, i.e. below IP layer but above hardware (ISO/OSI layer 2).
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I'm not sure older devices have the hardware capable of supporting Android 8.0.0, aka, Oreo. Even phones a couple of generation old would likely would become unacceptably slow with the newer OS. A huge majority of Android devices are not Nexus or Pixel devices and generally not updated by the carriers. Even older Nexus devices are not guaranteed security updates by Google.
The best thing might be for Google to provide appropriate security patch software for WPA2 for all versions of Android to carriers but it's likely they would never reach customer phones.
In a time of universal deceit, telling the truth is a revolutionary act. George Orwell
Luckily my LMDE distro got a new wpa_supplicant this morning, I think this is to fix this, if yes, this is great!
"Science will win because it works." - Stephen Hawking
The router isn't the problem it's the Wi-Fi devices connected to the router. Examine the article carefully.
In a time of universal deceit, telling the truth is a revolutionary act. George Orwell
For a private laptop connecting to public wifi-hotspots, this attack is harder than just setting up another credible wifi hotspot. Any place where the wifi password is well known knowledge is never going to be rigorous security.
The attack doesn't rely on knowing or compromising the password or securing the network at all. What happens is an attacker sets up "CafeNetwork" on a different channel than "CafeNetwork". A device can connect to rogue "CafeNetwork" assuming it is the real one. As a MITM attack, the rogue network can listen in on traffic. If the traffic was previously encrypted with HTTPS, it provides some security but it is not foolproof.
Well, there's spam egg sausage and spam, that's not got much spam in it.
There's a pretty good write-up at Anantech: https://www.anandtech.com/show...
Basically, they say the vulnerability is worse for some configurations more than others. If you use Android, or WPA-TKIP, or 802.11ad the attacker can do more damage. Normally it's only evesdropping of one side of the communication.
The security industry would define this as a remote exploit as it does not require physical access to any of the devices nor does it require the attacker to be logged into the target devices. While the attack would result in decrypting any clear text being sent over wifi, the saving grace is that an increasing amount of traffic is sent via HTTPS or SSL, which would provide an additional barrier to an attacker seeing login credentials for remote websites, etc.
The most dramatic concern here is that non-HTTPS traffic is prone to injection of malware and exploitation of vulnerabilities on the client devices. Even if a user doesn't browse a sketchy website, suddenly a site like slashdot.org might seem to send code to a user's phone or laptop that could perform a remote code exploit.
As 140Mandak suggests, it would be trivial to assemble a cheap box (think raspberry pi 3) that sits at a public wifi location and automatically attempts to hack all older Android phones that connect to the network.
$5 / month hosted VPS on linux = awesome!
Running your own SSH tunnel for all communications is pretty standard when connecting anywhere. If it's not your wifi, it's not secure. That should be a mantra for everyone.
The cesspool just got a check and balance.
Don't absolve google. I paid $500 for a Nexus 10 tablet a few years back. Straight-up google, through and through. No telco involved. Stopped getting updates a long while back and is slowly decaying to uselessness and, obviously, will not get patched.
This is a silly solution. A bug in WPA2 should not require its corporate user to eat billions of dollars. Just force the telcos to issue the patches and then tell them they're done with this silly customizing-the-OS bullshit that no customers ever wanted.
The telcos have absolutely nothing to do with updates for Android phones, with the exceptions of those that they themselves have branded. It's the manufacturers who are responsible. Your comments were sort-of true for the previous generation of feature phones, but Android devices aren't something telcos have control over.
The problem here is that manufacturers have few incentives, apparently, to keep Android devices up to date.
You are not alone. This is not normal. None of this is normal.
Why pay the troll to use his/her bridge when you can just step over the creek?
Pffft. Cat 5 is so 2001. You can't even get it anymore. You can barely get Cat 5e which is gigabit. Many places will happily sell you Cat 6 though.
Well, there's spam egg sausage and spam, that's not got much spam in it.
For now, WRT the phone, turn off your WiFi, use data, and keep the "media" uproar to a minimum unless you have an unlimited data plan. That means no video, no music, no heavy pages, etc. unless you're willing to eat your data allowance pretty quick (that assumes you've been using wifi to keep from stuffing your phone provider's pockets.)
In any event, watch your data consumption. Overages are a cash cow. And you are the cow.
WRT your home system, use ethernet, and turn off wifi until / unless you know you've got the right level of patch / amelioration.
The problem is not the Internet. The problem is wifi. So get off wifi.
I've fallen off your lawn, and I can't get up.
Google is still providing support for Android 7, and 6, and 5, and 4. IIRC support for 4 ends next year. Carriers and/or handset manufacturers are the ones withholding updates.
That may be true, but it looks like a change to the WAP can prevent the attack too --- It would be good for someone like Apple to patch their router firmware as well as the clients. That way your macbook can be fairly safe regardless of where you connect it, and your unpatched IoT things strewn about the house can also be secure -- so long as they only connect to your patched router/WAP..
Ian Ameline
This was my main disappointment with Android. I had hoped that it would be google, not the carrier or handset manufacturer providing updates. The manufacturer would provide drivers for the hardware, but Google would take care of the rest, similar to how MS rather than a PC manufacturer handles Windows updates. Instead it’s a fragmented mess.
A fix was just released for Linux (e.g. Ubuntu and derivatives).
The phones and tablets will be the hard part here.
2bits.com, Inc: Drupal, WordPress, and LAMP performance tuning.
If it's not your wifi, it's not secure.
To be honest, I don't get this. Who cares if a network operator, or the person sitting next to you at a cafe next to you is snooping your data? With the advent of https everywhere, the data between my computer and the server is encrypted and secure, regardless of whether the underlying transport is compromised.
You always need to consider that the underlying network is insecure. I'll happily do my banking over public wifi, or satellite internet (where the packets are broadcast to the entire continent), because all an adversary sees is a stream of gobblygook.
...si hoc legere nimium eruditionis habes...
I just read that Microsoft has fixed the problem in the latest updates (October, 2017 ?) for all supported Windows versions. Apple has done nothing according to the latest report. Some Google phones will be updated in the November security update. Other Android phones will depend on carriers to do the job, which is not likely unless pushed by Google, or someone else, to do so.
In a time of universal deceit, telling the truth is a revolutionary act. George Orwell
This is where it goes wrong, android updates should be automatic for all phones that have android unless it's a driver issue, which this isn't.
I don't depend on ASRock or Intel to update my OS, Why should I depend on Samsung? Windows updates itself fine, as does Linux. But not Android, and it's clearly a system that doesn't work and will leave literally 100s of millions of devices open to being trojaned.
Things won't change until Mega-Corp A sues Mega-corp B or Little-Corp C for allowing their devices to be used to attack their networks. And get awarded large damages. With situations like this one, they can't say they weren't warned.
Waterfox - a Firefox fork with legacy extension support, security updates and better privacy by default.
It's not a Man in the Middle attack: it's a mitm surveillance. It lets you read (but not modify) some of the traffic going by.
"First they came for the slanderers and i said nothing."
Many bar and restaurants have wireless card readers which use wi-fi.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
Google stops providing security updates for their devices 3 years after they are first available.
I know that my Nexus 5 phone will not get patched by them.
It is more so that those older operating systems does not implement WPA2 correctly (eg. they do not support retransmission). Newer OSes (and ones which implement standard more tightly) are more vulnerable.
Cat5 can do 1gbs, just not as far as cat6. Though last I looked into it cat6 was still an unofficial standard that guaranteed nothing.
Note that I would *hope* point of sale equipment and security equipment would use TLS regardless of the media.
If a server on a LAN doesn't have its own FQDN, what certificate would its TLS use? Well-known CAs require a FQDN.
How would you go about encrypting communication between a browser on your desktop, laptop, tablet, or smartphone, and a web-based management interface on your router, printer, or network attached storage (NAS) device? These servers tend to lack a fully qualified domain name (FQDN), making them ineligible for a certificate from a major certificate authority (CA).
tl;dr: There is no TLS CA for DNS-SD.
Bullshit. Almost every carrier-sold device has a locked bootloader, and some are even SIM-locked.
A locked bootloader prevents you from:
1) Rooting the device.
2) Installing Lineage|Cyanogen|Any-other-OS.
Whereas a non-carrier branded device can usually be unlocked and the OEM has infrastructure in place to enable it - see Xiaomi, Motorola (Lenovo), etc.
It's the fucking telcos who are withholding updates from the end users.
How is this true of Wi-Fi-only tablets or unlocked phones? For example, what power does Comcast have to withhold updates from my Wi-Fi-only Samsung Galaxy Tab A? That'd be like Comcast withholding updates from a Windows PC.
I had hoped that it would be google, not the carrier or handset manufacturer providing updates. The manufacturer would provide drivers for the hardware, but Google would take care of the rest, similar to how MS rather than a PC manufacturer handles Windows updates.
Android 8 "Oreo" introduces Treble, which begins to refactor Android toward what you expected: a stable driver ABI.
What you are still using SMB1
People are still buying new NES-clone consoles to enjoy SMB1.
If it's not your wifi, it's not secure. That should be a mantra for everyone.
Why would I trust "my" wifi either? There's too many devices in the house, some of which are unpatchable by everyone other than the vendor (ie, no patches, ever).
But that's not a concern: if you are already prepared for anyone outside trying to hijack your connection, the first hop is not any different.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Expecting updates on a mobile device made ten years ago? What the hell you smokin? Sure, nowadays that's not quite so unreasonable as the pace of hardware improvement slows, but I don't expect manufacturer's to get in line any sooner than they're forced to. Hell, I'd even settle for allowing unlocking of EOL'd devices and pushing 'em to something like Lineage when available.
When you live in a sick society, just about everything you do is wrong.
Isn't that what endpoint vpn tunneling is for?
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
This is not a WPA2 security flaw, it's a bug in a specific implementation. It's a Linux/Android flaw if anything, but maybe it's not popular to say it when Windows/IOS did something better than Linux/Android?
A customer service rep on TP-Link's chat support this morning was completely unaware of the problem. After checking with the engineers, they said they will be working on it. Hmmm, the vulnerability has been known for about six months, and is only now being reported on news sites after presumably waiting to give vendors time to develop fixes. And TP-Link has done, well, nothing? There's no word on the TP-Link.com website about the issue at all. The rep said that I would be contacted when the fix becomes available, but that is not a credible claim since the company has no information about customers. I'm disappointed, guys.
Great! Now to get manufacturers to provide, if not push, updates on those devices. Best of luck!
When you live in a sick society, just about everything you do is wrong.
If it's not your wifi, it's not secure.
To be honest, I don't get this. Who cares if a network operator, or the person sitting next to you at a cafe next to you is snooping your data?
Because, for starters, you get around the whole MITM should any of this be compromised. Furthermore, as I use keys, the entire process is relatively secure and more importantly, it's transparent and easy to use. Finally, there are things you do that may or may not be across secure links, and I'm perfectly find with everything being guaranteed to be at least secure to a known connection.
The cesspool just got a check and balance.
I have one of the TimeWarner (now Spectrum) wifi modems. The thing will barely reach across my apartment, so I'm safe.
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba
The other end of my connection is 100/100 minimum with low latency to the backbone, so the small additional latency over the whatever wifi connection to begin with normally isn't an issue.
The cesspool just got a check and balance.
Probably because my internal wifi is relatively locked down to known MACs, etc. Yes, stuff can be spoofed, but I just don't have that level of paranoia. If it came down to that, I think I'd have bigger issues to worry about. However, that said, the number of devices in my house on wireless is less than a handful. almost everything is hard-wired.
The cesspool just got a check and balance.
Been hibernating a while? 6 and 6A have been ratified, 6e isn't a standard though.
When you live in a sick society, just about everything you do is wrong.
If the network is using TKIP there's a chance of content injection. AES-CCMP is safe from that, for now. More here.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
It's what layered security is for, sounds like yours is working if you use VPN tunneling over your Wifi...
It's still good to fix that bad layer before something else fails though.
That's my point, that this attack is only valuable if you don't know the PSK. In most public wifi locations, you know the PSK. (Simplified to speak only to WPA-PSK).
So the juicy targets would mostly be home networks and corporate wireless that laptops get on. Practically speaking though it would be much easier for PoS to reliably be secure regardless of the user, they probably send credit cards through telnet or some crap.
XML is like violence. If it doesn't solve the problem, use more.
Disclaimer, I *hope* but realistically these things may be lax.
TLS on private networks is a well known entitiy. The usual flow is using an extra CA to validate the certs that has no meaning outside that private network.
XML is like violence. If it doesn't solve the problem, use more.
Didn't catch the part about GCMP, hopefully for once sluggish wifi implementations being behind the curves mean most are using CCMP.
TKIP should already not be in use for many reasons.
XML is like violence. If it doesn't solve the problem, use more.
and card data is never supposed to be transmitted in clear text, or they fail PCI DSS
Of course, I bothered to look at at least one version of the PCI DSS spec:
This means all CDE data must be encrypted as suggested in PCI DSS
Requirement 4.1. Section 4.4 described Layer 2 specific wireless encryption protocols such as
AES that is used within WPA2 to provide confidentiality and integrity at the wireless link layer.
Higher layer encryption methods such as SSL/TLS and IPSEC and could be used to provide endto-end
cryptographic protection of card-holder data.
So it *looks* like it may have considered WPA-2 built in encryption sufficient, but 'recommended' TLS/IPSEC.... So contrary to common sense there could be implementations with weakness...
XML is like violence. If it doesn't solve the problem, use more.
Couldn't somebody do that with any public wifi network as soon as they get the password? I mean, this will make it harder for the wifi provider to shut the malware server down as changing passwords won't work, but it still only allows access to join the network.
Knowledge Brings Fear
If the network is using TKIP there's a chance of content injection
No one does that.
"First they came for the slanderers and i said nothing."
What does this have to do with closed source code? In this case, the closed source implementations are less vulnerable than the open ones.
It's not a single attack vector. There are multiple CVE's for this. Some attack vectors do involve the AP, most involve the client. Both should be patched.
or you could join a GOOD network, with a BAD guy within range, able to receive your wifi packets.
While the attack would result in decrypting any clear text being sent over wifi, the saving grace is that an increasing amount of traffic is sent via HTTPS or SSL, which would provide an additional barrier to an attacker seeing login credentials for remote websites, etc.
If you watch the video posted by Mathy Vanhoef, you'll see at 1:16 he's also using sslstrip.
I predict that millions are now turning off their WiFi on their mobile devices and may keep it off for some time. Mobile data usage will surge over the next few weeks. The providers couldn't have asked for a better Christmas present.
Defense in depth. If you come to my house I will happily give you my wifi access code. It's only 1 small part of the security process.
I'm really fucking concerned about how Google will fix this for Android, the most popular OS in the world.
Recent stats are showing that only 0.2% of users are using Android 8.0, the latest version. Only about 18% are using Android 7.x releases. A whopping 32% are using Android 6.x! About 28% are using Android 5.x! About 21% are using Android 4.x!
And? What's your point? I got an OTA security update for a 5 year old Android 4.4 device in February this year, one which I voluntarily chose not to upgrade to 5 (though that also got a security update at the same time). Just because it isn't the latest OS version doesn't mean that it isn't getting security updates.
And likewise just because it's a security issue doesn't mean that the fix requires an OTA update. A great many are done by patching up drivers and core components through the Play Store.
Read up on how security in Android is handled before you get too concerned. Stress is not healthy.
A patched AP won't fix this. This is an attack against WiFi clients only.
That's my point, that this attack is only valuable if you don't know the PSK. In most public wifi locations, you know the PSK. (Simplified to speak only to WPA-PSK).
Knowing the PSK does not mean you can snoop on someone else's traffic unless you've compromised the AP. Whether you know the PSK of "CafeNetwork" does not mean you can listen to John Doe using the same network. This attack lets you eavesdrop on a device.
Well, there's spam egg sausage and spam, that's not got much spam in it.
but Android devices aren't something telcos have control over.
I take it you're not American? Yeah in most of the world the telcos in general don't get in the way much. However in America, the latest and greatest Android phones are telco specials, telco controlled, with telco specific firmware.
For example if you're the owner of a Galaxy S7 in the USA you will have one of these models depending who you buy it from:
SM-G930U
SM-G930V
SM-G930VL
SM-G930AZ
SM-G930A
SM-G930T1
SM-G930R6
SM-G930R7
SM-G930P
SM-G930T
SM-G930R4
If you're in Europe / The rest of the world with the exception of South Korea you will have:
SM-G930F
Or the dual sim model: SM-G930FD
Each of these have custom firmwares, and the US carriers are notoriously bad at providing firmware updates.
Mind you all of this is irrelevant since the OP was quoting Android core OS versions and not security updates. Even KitKat phones still receive security updates through some vendors, and yes even American Telcos will sometimes roll these out to customers, albeit a bit later than the international firmware.
Maybe in the USA, but in most of the world we regularly still receive updates to older phones.
My Galaxy Tab 3 got an update earlier this year for Kitkat even though I voluntarily haven't installed Lollipop. My over 3 year old phone now 3 Android versions behind received its latest security update 3 weeks ago.
Kitkat introduced a security patching framework independent of the core OS. Since then, people quoting Android version install base when discussing security has been completely irrelevant.
Bullshit, or you would have said what device. The phone is likely 512MB ram, 1GB max. That shit was obsolete years ago.
If you know the PSK, then you can set up your own AP with the same SSID as the legit AP. The client doesn't know which one is the 'correct' "CafeNetwork". You don't have to compromise the AP to do that, you have enough knowledge to impersonate it. In both cases the client wants to get to the internet, so it's not like that AP provides something uniquely qualifying it other than the correct PSK.
XML is like violence. If it doesn't solve the problem, use more.
Didn't catch the part about GCMP, hopefully for once sluggish wifi implementations being behind the curves mean most are using CCMP.
TKIP should already not be in use for many reasons.
CCMP always had higher security bounds than GCMP. GCMP exists for speed only because it is parallelizable and GCM was initially introduced for ethernet linksec as a workaround for the OCB patents. There is still no compelling reason for GCMP in 802.11. Modern logic is perfectly capable of keeping up with CCMP.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Of course, I bothered to look at at least one version of the PCI DSS spec:
This means all CDE data must be encrypted as suggested in PCI DSS
Requirement 4.1. Section 4.4 described Layer 2 specific wireless encryption protocols such as
AES that is used within WPA2 to provide confidentiality and integrity at the wireless link layer.
Higher layer encryption methods such as SSL/TLS and IPSEC and could be used to provide endto-end
cryptographic protection of card-holder data.
So it *looks* like it may have considered WPA-2 built in encryption sufficient, but 'recommended' TLS/IPSEC.... So contrary to common sense there could be implementations with weakness...
Yet the shiny new PCI-DSS compliant card payment machine we got recently for the store had a sticker on the bottom proudly proclaiming it used triple DES. I shit you not.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Which in a roundabout way exposes the flaw in removing end user options from many operating systems. Today you basically get a choice of "WPA2 Enterprise" or "WPA2 Personal", without finer grained option (ie, advanced options). Users are being trained to just click the networks that have a lock symbol, but not think further than that.
Except you can have a rogue router that is rerouting your data to a false facade of your bank. Sure, it might show up as bogus if you're paying attention, but not a lot of people are trained to mistrust everything and double check every time.
This is a snag for many operating systems. Their "support" model is to always get the latest version, even if it's not the version you like. Ie, would Microsoft backport a fix to Windows 7 when they prefer to force people to upgrade to Ugly Edition? Will Android or phone makers backport to older models that the user wants to keep or force them to get the latest $800 phone if they want the fix? I can seriously see some companies thinking about this as a profit opportunity rather than priority bug.
Remember, WPA came about as an interim soltuion because the wifi makers wanted to get the products out and for sale quickly rather than wait for WPA2 or 802.11i, and yet it's still in wide use today as an option even in some new products.
So how would a non-technical user understand how to install the extra CA's root certificate on each of his devices? From where would he download this certificate in the first place, if the local WLAN isn't secure?
What I get for skimming through too quickly. Oops. Still, ~4 yrs is a longer than most manufacturers support anything lately. Which sucks, is sad, condolences, etc.
When you live in a sick society, just about everything you do is wrong.
Been hibernating a while? 6 and 6A have been ratified, 6e isn't a standard though.
Well, last I looked into it was 10 years ago when I bought a lot of cat6 cables, but had to use reviews as it didn't mean much at the time. Either that or I confused it with 6e ;)
What else would you use to encrypt 8-byte long sequence, which after decryption still looks like random data?
Triple DES is used to encrypt your PIN, which is stored in the following manner:
PIN may be from 4 to 12 digits long. Let's assume 1234.
First you create pin-block sequence 4C1234FFFFFFFFFF, where 4C is constant (min and max length of PIN), and Fs are padding. Then you XOR it with PAN, which is also secret, so you end up with semi-random sequence, which rules out brute-force attack. Then you encrypt the whole thing with Triple DES.
Obviously, the key is stored in special, tamper-proof module.
Transaction journal, on the other hand, must be encrypted at least with AES-128, with key in safe memory as well.
What is best in life? Hot water, good dentishtry and shoft lavatory paper.
>What else would you use to encrypt 8-byte long sequence.
I would establish a secured session using authenticated key agreement and use that session to carry all the traffic.
If the PCI pixies forbid me from having a secured session, I would randomize it with nonces to achieve what the PAN does without the additional key.
But crypto protocol design is not a solo sport. You do it with a group like minded of cryptographers and implementers so you get it right.
I read the PCI specs once. It was like they wrote a set of thousands of statements and then randomized the order. They are still true, but the structure and purpose it lost.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
If you know the PSK, then you can set up your own AP with the same SSID as the legit AP. The client doesn't know which one is the 'correct' "CafeNetwork". You don't have to compromise the AP to do that, you have enough knowledge to impersonate it. In both cases the client wants to get to the internet, so it's not like that AP provides something uniquely qualifying it other than the correct PSK.
That's a lot of work to almost achieve the same thing but not really. If you set up a rogue AP, you still have to fool the target into thinking it is the same network. That requires the target to join the new network. Also setting a rogue AP does not send the same encryption key in the handshake unless you use this flaw. This flaw allows you to bypass all of that. Again, knowing the PSK or not knowing the PSK gives you nothing.
If you don't believe me, set up your scenario and see for yourself. Your device doesn't automatically join your rogue AP. Thus it doesn't leak traffic.
Well, there's spam egg sausage and spam, that's not got much spam in it.
>What else would you use to encrypt 8-byte long sequence.
I would establish a secured session using authenticated key agreement and use that session to carry all the traffic.
Session between what and what? And is loading key in air-gapped secure room into secure memory separately by several security officers enough key authentication enough?
I write user application for POS terminals for a living. I agree that the specs are all over the place, but cryptography is actually the only parted of it which is just fine.
What is best in life? Hot water, good dentishtry and shoft lavatory paper.
That must have been a long time ago:
"The standard for Category 6A is ANSI/TIA-568-C.1, defined by the TIA for enhanced performance standards for twisted pair cable systems. It was defined in 2009.[citation needed] Category 6A is defined at frequencies up to 500 MHz—twice that of Cat 6."
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
>Session between what and what? The PoS terminal and the credit card processor. Isn't that what we were talking about?
Disclaimer, I wrote the software for a PoS once. The shame still haunts me.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
I imagine that if I sat at a starbucks and made an AP called 'StarbucksWifi' or whatever, people would join and be totally oblivious to the network not being the same.
XML is like violence. If it doesn't solve the problem, use more.
yeah, but that's the problem. Google pushed out android "oooh, do what you want with it, customize, free!". But when security issues arise, it's all "Ooops, not our fault, talk to the manufacturer". They share some of the blame.
I may not like apple, but at least they're consistent in updating, fairly long in fact.
Communication between POS and card processor goes via TLS, usually also over VPN. So content encrypted by TDES has another layer of encryption (or two) added when it leaves the POS device.
What is best in life? Hot water, good dentishtry and shoft lavatory paper.
With RSA1024 according the printouts on our terminal. How many years ago was that deprecated?
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
2048 here.
What is best in life? Hot water, good dentishtry and shoft lavatory paper.
So PCI certification is approving new devices with both 1024 and 2048?
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
At this point 2048 is minimum. https://comodosslstore.com/blo...
What is best in life? Hot water, good dentishtry and shoft lavatory paper.
Which raises the question "Why when you buy a brand new PCI certified payment terminal in 2017, does it still use RSA1024?".
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
It is not allowed.
What is best in life? Hot water, good dentishtry and shoft lavatory paper.
It is not allowed.
Have you tried buying a PoS terminal recently? 1024 RSA, DES. The whole parade of 1990s bad crypto with a certified PCI sticker.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Better yet, I work for a company that sells them.
1024 RSA for TLS is not allowed and we would be in great trouble if it turned out we have it. It is used by some legacy EMV credit cards for dynamic authentication, but those cards are no longer issued and will soon all expire.
3DES is only used for pinblock encryption and such encrypted pinblock is later encrypted further, along with the rest of transaction data, with AES.
What is best in life? Hot water, good dentishtry and shoft lavatory paper.
That's interesting. There's a clear delta between what comes in the box and what the specs say. There's fame for a grad student in needling through that swamp of card swipers.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
On that I can offer no insight. On my end everything looks fine. Have you tried to reseal the package and open it again?
What is best in life? Hot water, good dentishtry and shoft lavatory paper.