Tuesday, October 17, 2017

KRACK is wack on Power Macs

After WEP fell due to the 2001 Flurher-Mantin-Shamir attack, WPA2 became the standard way to secure a WiFi connection. Now, the mighty have fallen due to KRACK (Key Reinstallation AttACK), meaning no WiFi network is safe.

The attacks concentrate primarily on the handshakes used to distribute keys, including the 4-way handshake used to bring up a new client ("supplicant"). This last point is particularly relevant because Mavericks and Sierra were both vulnerable to attacks on the 4-way handshake but iOS 10.3.1 is not.

We can confidently assume that 10.4 and 10.5 (and 10.6, for that matter) are vulnerable in the same or similar ways that at least 10.9.5 are (I'll dive into this in a moment), but the situation is really bad for Linux. wpa_supplicant 2.6 and prior are vulnerable to all of the variants, including current PPC Linux users and devices running Android 6.0+. These will almost certainly be patched eventually, even considering the shrinking support for 32-bit PowerPC in Linux. OpenBSD is also vulnerable, but patches emerged prior to the embargo, and its close relative NetBSD will likely be repaired in a similar fashion. Microsoft has quietly issued a Patch Tuesday update that covers KRACK. There are reports that the issue is already patched in current betas of macOS and iOS, but it's not clear yet if these patches will be backported to Sierra or El Capitan.

10.5 and earlier exclusively use the private framework Apple80211.framework for WiFi connectivity. Although the public wireless networking framework CoreWLAN was introduced with 10.6, the later private framework CoreWifi is not present and a comparison of symbols shows subsequent upgrades to Apple80211's functionality in Snow Leopard, so it is very likely in use invisibly there as well. Although this framework still exists in 10.12, it does not appear to be used or linked by CoreWLAN, implying it was since internally deprecated. Apple never documented this framework or made it open source, but there have been attempts to reverseengineer it. However, the necessary changes likely mean inserting more sanity checks during the key handshake, which would require a bit more than just patching the library in place. I've done a little preliminary disassembly of it but I haven't found where this critical section exists yet. However, there is a tool in this framework which will be very helpful to determine your actual risk; read on.

WPA2 has three major encryption protocols, only two of which are supported by PPC Mac OS X, namely TKIP (a legacy encryption protocol from WEP intended as an interim compatibility measure), and AES-CCMP, a more secure protocol which is supported in 10.3.3+ and is sometimes just abbreviated "AES" (incorrectly) or "CCMP." TKIP was deprecated in 2012, but is still often used. The last form is GCMP, which no Power Mac supports in OS X and is part of 802.11ac Gigabit WiFi. This turns out to be a blessing, because KRACK can actually recover the key from GCMP-based connections and forge packets in both directions. This is even worse than TKIP's exposure, despite being the older and historically more insecure means of encryption.

The router situation is probably worst of all. Many older WiFi access points will never receive firmware updates, and even if they do, just patching the router is insufficient; every connecting client must also be patched. Some information circulated earlier that said only patching the router is adequate to mitigate the risk, but the discoverer of the flaw is clear both clients and the router must be updated to eliminate the risk completely.

Given it's not currently clear how we can patch OS X, then, what can you do with your Power Mac? Well, obviously, if you have the ability to hardwire your system, that would be preferable. All of my desktop Power Macs connect to a secured internal network over wired Ethernet that cannot directly route to the Internet.

If your connection to the router you control is still using TKIP (or any form of WPA or WEP), you should make sure it is WPA2 AES-CCMP. Log into your router and look at your security settings and change them if necessary; while you're at it, also see if your manufacturer has a firmware update for your router. While AES-CCMP is still vulnerable to some of these attacks and traffic secured by it can be decrypted, the actual key cannot be forged, so an attacker cannot actually join your network and attack it in place; they would have to clone your WiFi router's MAC address to a new access point with the same name on a different channel that's in range. This might be a risk in a hotel or apartment building but probably not in your house unless your neighbour is naughty and needs a baseball bat education. (If you have an Apple AirPort base station, this old TidBITS article can help you with the steps.) You can confirm your setup by opening a Terminal and entering these commands ([...] means not important for this usage):

These steps use a command line utility called airport that comes with Apple80211.framework; you can see other commands with ./airport --help. The first airport command scans for access points. In place of the SSID yournetwork, you should see the name you assigned your router in its settings; its channel may or may not be six, its BSSID will almost certainly differ from this example, and you may see any number of other access points your PowerBook is in range of. What you should not see under ordinary circumstances are multiple copies of your network SSID with the same BSSID on multiple channels. If you do, something might be wrong!

The second airport command tells you what access point you are currently associated with. Verify the SSID matches the one you expect and that the security is WPA2 and AES2 (notice this appeared in the first command, too). Periodically recheck these commands as you get suspicious-looking new neighbours or black vans and helicopters show up on your block. Consider replacing your router if there is no update; this won't help your Power Mac, but it would potentially help other connecting devices that were themselves updated.

If you are connecting to a router you can't control, like a public access point in your coffee shop or hotel, you should treat any WiFi connection you make to it as if it were open and unencrypted and that an attacker can see and forge any traffic you generate. Though the commands above can give you an idea of your instantaneous risk, even if AES-CCMP is in use a wily attacker may choose to deploy their malicious access point intermittently or when you're not checking, so your best defense is to encrypt what you send and receive. Only use https:// URLs and prefer sites that use HTTP Strict Transport Security and HTTP Public Key Pinning, both of which TenFourFox supports, so that an initial HTTP-to-HTTPS redirect is less likely to be intercepted and stripped and it is much harder for an attacker to impersonate a HPKP-secured site. There are still some sophisticated ways to get around even these added precautions, however, so if you need to do something highly secure like banking or taxes I'd strongly advise going home and plugging into your router's Ethernet ports directly. Even a VPN might not be enough.

Meanwhile, I guess I'll be rewriting that Power Mac security rollup post again. Assuming the current state of AES-CCMP holds, though, there may be a way to design a tool to programmatically/automatically detect a forged connection even if the underlying vulnerability cannot be corrected. I have a few ideas about that. More later.

The discoverer of the flaws on his own site says, "both the client and AP must be patched to defend against all attacks!" Although he also mentions that his primary attack is against clients, and certainly client functionality should be disabled if no updates are available, "[w]e strongly advise you to contact your [router] vendor for more details."

Given that uncertainty I think saying otherwise is unreasonably cavalier at this point.

From https://www.krackattacks.com/:"In general though, you can try to mitigate attacks against routers and access points by disabling client functionality (which is for example used in repeater modes) and disabling 802.11r (fast roaming)."

The manufacturer of my router says that only their repeaters are affected but none of their routers because of lacking support for 802.11r:https://en.avm.de/news/short-notes/2017/wpa2-flaw-fritzbox-on-broadband-connections-are-secure/

No, I agree that those will reduce the attack surface, but it's noteworthy that he uses the phrase "try to mitigate." Those words are a bit weak, and I don't think that's a coincidence. I think it's just safer for people to consult with their router manufacturers and that's what he recommends too.

The first one I saw doing the research for this (primarily part 1), though. Unfortunately it doesn't particularly help here because it's too new and references subsequent changes to the framework. There are no functions named Apple80211* in 10.4's framework, for example, despite what the framework is actually called.

The sample code he provides (in your second link) suffers from this problem, but more importantly it's mostly just a demonstration on how to get this information programmatically from the operating system. The airport tool I demonstrated in the main post already does this. The trick is figuring out how to alter the handshake code to fix the client bug, and he doesn't really go into that (even if he did, it likely changed between 10.4/5 and more recent versions of OS X).

One company to keep an eye on it Iogear - as their Universal Wifi adapters (WiFi to Ethernet) are very popular and are in their second generation now). If anybody is going to have a patch it would be them, and this is such a practical device anyway - 150N in OSX AND OS9!

Also, the evidence that WiFi is not particularly healthy to have permeating your body (especially nervous system) is getting a lot more compelling today. Perhaps this is just the excuse we've all needed to cut-back our N.I.R. burdens.

When I took Ham Radio years ago, we asked the instructor about Microwaves and radio energy in general and he had the best explanation for the danger ever.

He said that it's not the waves themselves that cause problems - it's the modulation. His metaphor was that of taking a pieces of bailing wire and pulling it across the inside of your arm. "You might not even feel it". But he went on to say, that if you put a few thousand knots in the wire and then tried that - you'd wind up in the emergency room! So the induction of a few million stray impulses every minute to the nervous system can cause a heavy excitotoxic reaction to the tissue. I don't know - not building a Faraday cage just this week, but perhaps this new threat makes getting that home ether-network make more sense than before.

So got a VERY disappointing reply from Iogear. They plan to wait until they get actual reported breaches through their products before they make a patch. Attempting to guilt-trip this a bit further, but they seemed completely unconcerned with the issue - and this is a current product.