On Monday Mathy Vanhoef and Frank Piessens released research demonstrating multiple vulnerabilities in the WPA / WPA2 standard. This has received significant media coverage, especially since any vendor who implemented the 802.11 standard correctly is likely vulnerable.

I want to share my notes, as I found seriously misleading information in much of the reporting, even on tech outlets. It is worth reading the full paper, which explains the research in great detail and checking out the vulnerability website. Amazing work by Vanhoef and Piessens.

The vulnerabilities cover three primary attacks, all involving the new technique of key reinstallation. These attacks manipulate various handshakes between wireless clients and access points to alter cryptographic values which are insecure if used more than once. (Hint NONCE = Number Used Once. If you use it twice, bad things happen.)

Both clients and wireless access points must be patched to fully resolve these issues.

Key Points and Practical Impacts

Attack against the 4-way handshake.

• This manipulates cryptographic parameters on the client - the device connecting to the wireless network.
• If the wireless network is using WPA2-AES-CCMP impacts include the ability to replay packets from AP to client, and decrypt packets from client to AP . This could reveal sensitive data including session IDs, cookies, and credentials for plain HTTP connections. Exposure of TCP SYN/ACK packets could allow TCP session hijacking. HTTPS is relatively safe.*
• If the wireless network is using deprecated WPA-TKIP, impacts are severe and include the above with the additional ability to forge packets from the client, allowing malicious code injection and malicious data manipulation. In this instance the AP can be used as a gateway to inject packets towards any device on the network.
• If the wireless network is using GCMP, impact also allows bi-directional packet forging.
• Specific client patch / exposure information:
  • Windows 7/8/10 - These were never vulnerable to this attack due to Microsoft not strictly following the 802.11 standard. (Media outlets are reporting Microsoft patched this but it is inaccurate. They patched the group key issue (see below) in their October releases).
  • MacOS - Vulnerable. Patch in beta, not yet available.
  • iOS - Latest versions not vulnerable. Unclear when Apple patched this.
  • Android < 6.0 - Vulnerable, will not be patched.
  • Android 6.0+ - Vulnerable with additional severity. See below. Patching announced for November.
  • Linux - Desktop distributions mostly vulnerable with additional severity, see below. Patches to wpa_supplicant available as of 10/16/17 for all major distributions.

Attacks against 802.11r Fast BSS Transition (FT) handshake

• This manipulates cryptographic parameters on the access point, irrespective of the client patch status. Some media outlets have reported things like “latest Windows not vulnerable to KRACK”. This is misleading, as while the client may not be vulnerable directly, it could still be severely impacted via attacks to a vulnerable access point.
• If the wireless network is using WPA2-AES-CCMP impacts include the ability to replay packets from client to AP, and decrypt packets from AP to client (note the direction is reversed from the attack on the 4-way handshake). As above, this could reveal sensitive data including session IDs, cookies, and credentials for plain HTTP connections. Exposure of TCP SYN/ACK packets could allow TCP session hijacking. HTTPS is relatively safe.*
• If the wireless network is using deprecated WPA-TKIP, impacts are severe and include the above with the additional ability to forge packets from the AP, allowing malicious code injection and malicious data manipulation.
• As above, if the wireless network uses GCMP this also allow bi-directional packet forging.
• Can be fully mitigated by disabling 802.11r “fast roaming”. Although, doing this has negative impact for clients moving between access points.
• Most vendors are vulnerable. CERT notice with vendor links here. Cisco advisory here.

Attacks against the group key handshake

• This manipulates cryptographic parameters on the client, as the attack against the 4-way handshake.
• In all WPA implementations (TKIP, AES, GCMP) this allows replay of packets from AP to client.
• Impact here is less severe, but the authors note this can impact NTP (which is relied on by Kerberos, etc.), and some home automation protocols. Other impacts are likely.

All-Zero Encryption Key Vulnerability

• Due to a bug in wpa_supplicant, the software implementation of 802.11i for Linux, Android 6.0 and up, and almost all modern Linux distributions actually install a null encryption key when the 4-way handshake is attacked. This is catastrophic and negates WPA encryption completely.
• For newish IoT devices this will have an especially long-lived impact, as many will never see patches, nor will many Android phones still in use. Patches for supported Android devices have been announced for November. All major Linux distributions have patches available now.

Other Notes

• There are currently no known (to my knowledge) attack tools in the wild, or test scripts for that matter. Both will be coming soon, but at least there is a window to patch.
• Where threat modeling is concerned, these attacks do require physical proximity to targets and reasonable sophistication by the attacker. Yes these are bad vulnerabilities that must be addressed, but media coverage has been largely overblown in my opinion. This is not the end of the world (or even of WPA2).
• A vulnerability in a commercial RSA library was also disclosed this week, which has been overshadowed by the WPA issues. For high security facilities this is very serious. It also applies to Yubikeys used for RSA / PIV / PGP.
• *HTTPS certainly mitigates the impacts above to a large extent for those connections. However, as the researchers note, there are multiple known issues with various implementations of HTTPS as well.

I recently setup a new server at home to act as a NFS share for backups of other systems, shared files, etc. I had initially planned to use mdadm for a RAID, but after some research decided that btrfs would provide better flexibility and protection against bitrot. Some of the stored data is archived digital photos from years ago, which will be kept for years into the future. Protecting these from bitrot, drive failures, or system failures is critically important to me. Btrfs can do RAID1 by itself and since it does checksums for each block, can detect bitrot and fix it. I opted to use Fedora for this system instead of CentOS7 largely due to recent kernels having better btrfs support.

After a fresh Fedora Server install using full disk encryption with LUKS, I erased two 1GB disks and created a single partition on each, /dev/sdb1 and /dev/sdc1 which will be made into a LUKS encrypted btrfs RAID1.

I wanted the full system to be encrypted with one passphrase at startup unlocking all drives. This can be done by using key files for the non-system drives. (Note that these will be stored on the root partition and accessible in clear text anytime the system is running.) First, create the directory where the key files will be stored, and then create the key files themselves with some random data - this could be done a few ways but I chose to pull 500 characters of base64 from /dev/urandom.

mkdir /etc/luks-keys
cat /dev/urandom | base64 | head -c 500 > /etc/luks-keys/sdb1key
cat /dev/urandom | base64 | head -c 500 > /etc/luks-keys/sdc1key

Next, use cryptsetup to create the LUKS volumes on each drive, using those key files, typing all caps YES after each command:

cryptsetup --key-file=/etc/luks-keys/sdb1key luksFormat /dev/sdb1
cryptsetup --key-file=/etc/luks-keys/sdc1key luksFormat /dev/sdc1

In order to decrypt and map these LUKS devices at boot, add lines to /etc/crypttab containing the desired device name, UUID, keyfile path, and in this case luks, to force LUKS mode. If /etc/crypttab doesn’t exist, create it. Obtains the UUIDs for each partition with:

cryptsetup luksUUID /dev/sdb1

Then add lines to /etc/crypttab.

data1 UUID=35fd668d-9e1a-4b61-8ac9-8883b21c3c23 /etc/luks-keys/sdb1key luks
data2 UUID=b8408310-cb8c-47c0-a0a5-f3d0a28d6fd5 /etc/luks-keys/sdc1key luks

At this point the LUKS volumes should automatically map on startup. You could map them manually with

cryptsetup --key-file=/etc/luks-keys/sdc1key luksOpen /dev/sdc1 data1

but I prefer to test that things are working correctly up to this point by rebooting. Upon startup the device names specified in /etc/crypttab should be listed in the output of ls /dev/mapper along with any other encrypted block devices in use.

Next, creating the btrfs-RAID1 filesystem across those two devices. These options tell btrfs to use RAID1 for both data and metadata, not specifiying them would default to RAID0 for data, and RAID1 for metadata.

mkfs.btrfs -m raid1 -d raid1 /dev/mapper/data1 /dev/mapper/data2

Mounting the new filesystem manually (only one mapped device needs to be mounted):

mkdir /mnt/data
mount /dev/mapper/data1 /mnt/data

btrfs filesystem show should now display:

Total devices 2 FS bytes used 640.00KiB
devid    1 size 931.51GiB used 2.03GiB path /dev/mapper/data1
devid    2 size 931.51GiB used 2.03GiB path /dev/mapper/data2

And btrfs fi df /mnt/data should now show:

Data, RAID1: total=1.00GiB, used=512.00KiB
System, RAID1: total=32.00MiB, used=16.00KiB
Metadata, RAID1: total=1.00GiB, used=112.00KiB
GlobalReserve, single: total=16.00MiB, used=0.00B

In order to automatically mount at startup, a line needs to be added to /etc/fstab

/dev/mapper/data1	/mnt/store	btrfs	defaults,device=/dev/mapper/data1,device=/dev/mapper/data2 0 0

Reboot to test. Note: If your fstab file isn’t right and your system won’t boot, you can press e at the GRUB screen, locate the line starting with kernel or linuxefi and append init=/bin/bash to the end, then hit ctrl-x to boot. This will get you a shell prompt where you should be able to go modify your broken fstab file.

References

• Using btrfs with multiple devices
• Man pages for crypttab and fstab

Last August Microsoft enabled by default a new feature in Office 365 called Clutter which, when enabled tries to automatically filter low-priority messages out of a user’s inbox, instead placing them in a Clutter folder. While this might be helpful for some, if your users frequently receive external emails that are at all important it will probably annoy the hell out of them. PowerShell to the rescue.

You’ll need a Windows 8+ or Server 2012+ system with PowerShell.

First, we’ll create a credential variable. Fill in the resulting dialog box with your Office 365 administrator email address and password.

$UserCredential = Get-Credential

Then we’ll create a remote session to Exchange Online and authenticate with that credential.

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection

Make that new session the active one:

Import-PSSession $Session

Check if you’re successful with a Get-Mailbox and if you get results, run this to disable Clutter for all mailboxes in your organization:

Get-mailbox -ResultSize Unlimited | Set-Clutter -Enable $false

That may take a while to run through. Once it’s done, disconnect your remote PowerShell session with:

Remove-PSSession $Session

That should do it. Users who previously had Clutter enabled with still have a Clutter folder, but new emails will go to their inbox as normal. The items in Clutter can be moved and the folder deleted, if desired.