WPA2 KRACK – What you should know so far … (in simple terms)

As most people, we have been waiting for the release of the technical details surrounding the  WPA2 vulnerabilities discovered by Mathy Vanhoef  (@vanhoefm).

While the details and the full paper (https://papers.mathyvanhoef.com/ccs2017.pdf) are now available, here is a summary aimed at providing the big picture as well as a few recommendations about this attack.

Note that we could at this stage not experiment ourselves with this attack (no PoC or exploit tool is publicly available yet) so this article is solely based on the information published by Mathy Vanhoef and on common knowledge about WiFi and WPA2 (aka Wikipedia).

WPA2

WPA2 is currently the standard security protocol used to protect WiFi networks. It replaces WPA (which was used a temporary standard) which in turn was meant to replace the original (and very weak) WEP protocol. Since March 2006, all devices bearing the WiFi logo must be WPA2-certified.

WPA2 comes in two different flavours, usually referred to as WPA2-PSK and WPA-Entreprise and that differ by their authentication details and, consequently, by the details of the Master Key (called Pairwise Master Key) derivation mechanism. While WPA2-PSK derives this key from a shared secret (called Pre-Shared Key), WPA-Entreprise derives it from an underlying authentication mechanism.

However, whatever the authentication and PMK derivation details, both flavours of WPA2 then use this master key to derive sessions keys (called Pairwise Transient Key) that are ultimately used to encrypt data over the air. This encryption also comes in various flavours which are :

  1. TKIP
    A deprecated encryption mechanism based on RC4 and meant to be retro-compatible with hardware initially designed for WEP encryption;
  2. CCMP
    The currently recommended encryption protocol, based on AES (in CTR mode) and CBC-MAC authentication code;
  3. GCMP
    A new mechanism (also based on AES but operating in Galois/Counter Mode) that is used by the 802.11ad variant of WiFi (branded WiGig). This protocol seems to be still mostly unknown today (to be honest I had never heard about it before reading Mathy’s paper) but is apparently meant to become very widespread in the future.

In order to encrypt the data that is sent over the network, these encryption algorithms operate as stream-ciphers (RC4 actually is a stream-cipher, AES is called a block-cipher but both CTR and GCM modes of operation are meant to allow it’s used as a stream-cipher). Stream-ciphers produce a continuous key-stream that is used to encrypt data (e.g. by XORing the two). This can result (depending on the cipher itself) on a very strong encryption mechanisms as long as some constraints are respected (e.g. having a strong randomness source for (random) elements used to generate the key-stream and never to re-use the same key-stream).

KRACK attacks in a nutshell

When a device connects to a (non-open) WiFi network, it establishes a dialog with (one of) the access point(s) that is meant to authenticate the device (prove that it has the Pre Shared Key or valid authentication credentials depending on the “flavour” used) and that ultimately leads to the establishment of a session key (PTK) that is used to encrypt the data over the network. This dialog is part of the WPA2 standard and is called “4-way handshake”. This “handshake” is not only used upon initial connection but it is also performed again afterwards, on a regular basis (e.g. every hour) to refresh the session key (agree on a new key).

As the name suggests, this exchange is based on 4 messages, carrying, among other things, a pair of nonces (“numbers used once”) – one chosen by the client (called supplicant in the standard) and the other by the access point (called authenticator) that have a direct impact on the key-stream that is generated by the ciphers.

An overview of the WPA2 4-way handshake is reproduced below (source: https://papers.mathyvanhoef.com/ccs2017.pdf)

Now … In very simple terms (much more technical details are available in Mathy Vanhoef’s paper ) Key Reinstallation Attacks leverage the fact that – because of a design flaw in the WPA2 protocol – if an attacker replays Msg3 of the handshake above, the (target) device will usually treat this replayed packet as if it had not already been received before and will used it to derive (again) the session key (remember that this message contains one of the nonces used to generate the key-stream).

This issue is partly due to the fact that – because it is a wireless protocol – WiFi (and thus WPA2) has to be designed to account for the possibility of having lost packets (interference, jamming, low signal, …). However the problem lies in the details of how this re-transmitted message is then used by the device (e.g. accepting to re-install a key that had already been used in the past).

In very simple terms, the attack is as follows : the attacker waits for the client device to receive Msg3, process it (thus establishing the session key) and respond with the last message of the exchange (Msg4). The attacker then blocks this message (more details below) thus preventing the access point from receiving it. After a timeout, having received no response to its previous Msg3, the access-point will re-send Msg3 again which will cause the client to re-process it and derive (again) the session key, re-setting the nonces (and various internal counters) to previously used values.

In the meantime (between the moment when Msg4 hs been sent by the client, and the new Msg3 is received) if the client has already used the session key to encrypt and send data on the network this will result in the same key-stream being used twice to encrypt data which is a major violation of the proper use conditions of a stream-cipher.

By using this the attacker can (under some additional constraints) decrypt the contents of the affected data packets.

What does the attacker need ?

In order to carry this attack, the attacker must be capable of, not only sniffing the (encrypted) data that travels over the air (that is always granted) but also to block and replay data packets that are exchanged between the client and the access point.

For that, Mathy Vanhoef relies on a technique called channel-based Man-in-the-Middle attack. Basically, the attacker creates a rogue access-point, with the same characteristics (including the AP’s MAC address) but on a different channel (frequency) and tricks the client in connecting to it instead of the legitimate AP. As a result of that, the client and the AP are on different frequencies and don’t “see” each other. The attacker then relays the messages between the two channels with the capability of blocking, delaying or replaying them as wanted.

What are the consequences ?

As the discovered flaws are inherent to the WPA2 standard, one could think that the attack and the consequences do not depend on the device’s manufacturer and/or software… However the reality seems to be quite different. Actually, many different behaviours are described by Mathy Vanhoef, depending on the device details (including some systems being less affected by the attacks because they are in actual violation of the standard).

But roughly speaking, the attacker will be able to perform one or several of the actions below (depending on the targeted devices and software) :

  • Decrypt the data packets sent over the network thus having access to the data sent by sent by the targets. Note that this data may still be encrypted by another mechanism (e.g. if the target is browsing an HTTPS website) however any clear-text traffic (e.g. HTTP) would be compromised;
  • Replay packets that have been previously sent by the targets;
  • Forge new packets and send (“inject”) them on the network. This could be used, for instance to inject malicious content in browsed webpages or replace downloaded files.

On the other hand, note that the attacker will NOT be able to (at least based on the information available so far) gain full access to your WiFi network (i.e. this attack does not allow to recover your WiFi’s password). This attacks thus does not have the same consequences as what has been observed in the past with WEP et even WPS (used to gain access to WPA2 networks).

The special case of Android…

The use of WPA(2) on most Linux systems relies on the use of a program called wpa_supplicant, that implements all the magic related to authenticating and connecting to WiFi networks.

During his research, Mathy Vanhoef discovered that a series of versions of wpa_supplicant – (2.3 to 2.6) in addition to being vulnerable to the key reinstallation attacks – suffered from an additional implementation flaw that resulted in much more catastrophic consequences for this attack. When targeted with this attacks, these versions of wpa_supplicant do not “simply” re-install the previously used key but they actually end up installing an all-zero key thus resulting in catastrophic consequences (the attacker can basically decrypt all the traffic sent by the device).

Android – being a Linux system – also relies on wpa_supplicant. Consequently, it seems that Android 6.0+ versions are affected by this issue thus exposing millions of devices to the most critical form of this attack.

Note that, from the results observed by Mathy Vanhoef, if you have an iOS device (or a Windows computer by the way) you are – on the other hand – only exposed to a very limited subset of these attacks.

What should we do ?

The affected device manufacturers and software editors have been informed by Mathy Vanhoef several months ago in order to allow for the development of fixes, several of which have already been published. A list of affected vendors (and status information) is available at this URL:

https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=228519&SearchOrder=4

Consequently, you should  :

  1. Don’t panic ! It is not WiFi’s doomsday…
  2. Update and fix all your WiFi devices for which patches are available (access-points, routers, laptops, smartphones, tablets, “smart”-devices, …) as soon as possible;
  3. If possible, rely on additional layers of encryption (HTTPS, IPSec, …) on top of your WiFi network (that’s always true and recommended);
  4. Prefer the use of 4G over WiFi (as long as your devices are not patched). Note however that – in its worst case scenario – this attack does not have more serious considerations to your smartphone/tablet than being connected to any public WiFi network;

What’s next ?

Mathy Vanhoef did not – at this stage – publish an actual exploit tool and some of the attacks require non-trivial conditions to be carried. However it is quite obvious that these attacks will very soon be implemented in existing or new tools and ultimately be easily available.

Moreover it most probable that millions of devices (cheap Android smartphones/tablets, IoT devices, …) will never be updated (because the users will never apply the patches and – most of the time – because such patches will not be available).

Consequently, even if this issue will probably be solved on the long run in many corporate environments (as “easily” as deploying patches on a large scale on often non-centrally managed devices may be…), it may leave many home networks and end-user devices vulnerable for a long time.

More interestingly it may very well open the door for similar attacks on other protocols.

Bypassing TPM-based Bitlocker

Attack on Windows authentication mechanism

At the recent BlackHat Europe conference (November 10 – 13, Amsterdam) a security researcher called Ian Haken presented a very interesting, simple yet powerful attack allowing to bypass Windows (Kerberos) authentication on machines being part of  a Domain.

The attack in itself allows someone – having physical access to the Windows workstation or laptop – to log into the system by resetting the password of a domain account. For that the attacker will just need to setup a rogue Domain Controller and configure it to declare the target account as expired. Indeed Haken identified a loophole in the mechanism which allows an attacker to force the local update of the cached Domain credentials despite the Kerberos KDC failing to prove it’s identity to the target workstation.

The whole attack, whose details are well explained in Ian Haken’s paper, can be setup using common open-source software and very simple configuration steps.

By itself, this would not be a significant breakthrough as other means of achieving similar results are widely known (e.g. by booting the machine on a live system and tampering with the system). This attack however becomes very interesting when applied to systems using Microsoft Bitlocker for full-disk encryption and configured for using the machine’s TPM (without PIN or USB key) in order to avoid explicit pre-boot authentication.

In this context, the encryption keys are automatically retrieved by the Windows bootloader from the TPM without any user (or attacker) input in order to provide a transparent Windows boot. In this scenario, the whole security of the (encrypted) data on the system falls back on the Windows login mechanism as any user being capable of logging into the system would (transparently) have access to all or part of the local data (depending on the user privileges).

Obviously in this context, Haken’s attacks turns out into a way of bypassing Bitlocker encryption in order to have access to the (encrypted) system and data.

Mitigation

A security bulletin (and corresponding patch) has been issued by Microsoft : MS15-122.

According to Microsoft, “the update addresses the bypass by adding an additional authentication check that will run prior to a password change.”

Recommendations

Microsoft’s security bulletin is rated as Important which does not correspond to the highest severity level. However, as the attack targets a common Bitlocker configuration (actually Microsoft does not generally recommend the use of pre-boot authentication) this attacks appears as very easy to implement against stolen or lost laptops with potentially critical consequences in terms of data confidentiality.

For that reason SCRT heavily recommends this patch to be applied as quickly as possible on affected systems, taking care not to neglect mobile systems that may be used by employees “on the field” or “on the road” and that may not be subject to frequent system updates (e.g. because they are often out of reach from standard company’s infrastructure and update workflow).

SCRT Security Day 2015

secDay_banner

Jeudi 17 septembre
09:00 – 17:00
Hôtel Best Western à Chavannes-de-Bogis

PROGRAMME

09:00 – 09:30      Accueil & Petit déjeuner
09:30 – 10:00      Introduction par SCRT
10:00 – 10:45      Tenable : From vulnerability management to continuous network monitoring
10:45 – 11:00      Pause
11:00 – 11:45      HP TippingPoint : HP TippingPoint Advanced Threat Appliance (ATA) solution.
11:45 – 12:30      Fortinet : Internal Segmentation Firewall
12:30 – 13:45      LUNCH
13:45 – 14:30      Varonis : La gouvernance des données à l’aide des solution Varonis
14:30 – 15:15      Splunk : Introducing Splunk; SIEM VS Security Intelligence
15:15 – 15:30      Pause
15:30 – 16:15      Entrust : Entrust eliminating the password in the enterprise
16:15                   APÉRITIF

INSCRIPTIONS

Le nombre de places étant limité, nous vous remercions de bien vouloir confirmer votre présence via le lien suivant : https://www.eventbrite.fr/e/billets-scrt-security-day-2015-17305044855 avant le 7 septembre 2015.

The “Bourne” Ultimatum *

Cet article a pour but de résumer brièvement les informations utiles sur la faille ShellShock. Il n’a toutefois pas pour objectif d’être exhaustif (les informations varient encore en fonction des sources et l’état de correction de cette faille, ainsi que des celles qui en découlent n’est pas forcément encore très clair).

Informations générales

Une faille dans le programme BASH (Bourne Again Shell) a été trouvée.
Cette vulnérabilité permet d’injecter du code dans des variables d’environnement. Ainsi, lorsqu’un programme appellera le shell système, ce code sera exécuté.

Le risque est particulièrement présent sur les scripts CGI accessibles en WEB. Les en-têtes HTTP étant passées dans l’environnement (HTTP_USER_AGENT, etc.), cette vulnérabilité pourrait être exploitée si le script appelé contient lui-même du code effectuant un appel système (system(),popen(), backticks “`”, etc.) De plus, la vulnérabilité est présente seulement si /bin/sh est un symlink vers /bin/bash

Considérons l’exemple suivant appellé en CGI et non pas via mod_php:

<?php
system("cat /var/log/auth.log | grep root");
?>;

Bien qu’il n’y ait pas de paramètre, il est possible d’exécuter du code en définissant une en-tête HTTP telle que

test: () { ignored;}; cat /etc/passwd

L’en-tête test sera passée dans l’environnement du shell appelé par la commande system().

Cette faille peut être testée avec la commande:

$ env var='() { ignore this;}; echo vulnerable' bash -c /bin/true

Cependant, ce premier patch est incomplet. Il est donc toujours possible d’exploiter cette faille avec la commande suivante :

$ env var='() {(a)=>' bash -c "echo date"; cat echo
bash: var: line 1: syntax error near unexpected token `='
bash: var: line 1: `'
bash: error importing function definition for `var'
Fri Sep 26 15:22:39 CEST 2014

Si la date s’affiche, la vulnérabilité est toujours présente.

Normalement, la plupart des distributions Linux ont publié des correctifs, y compris pour la deuxième faille.

Aussi, les distributions Debian et Ubuntu ne sont pas vulnérable dans une configuration par défaut car /bin/sh est un symlink vers /bin/dash.

Fortinet

La société Fortinet a publié une liste des produits affectés par cette vulnérabilité : http://www.fortiguard.com/advisory/FG-IR-14-030/

– FortiAnalyzer (versions 5.0.X and 5.2.0) – authentication required to exploit
– FortiAuthenticator – authentication required to exploit
– FortiDB
– FortiManager (versions 4.3, 5.0.X and 5.2.0) – authentication required to exploit
– AscenLink v7.X

Il est toutefois à noter que les équipements FortiGate ne sont pas affectés. Pour les équipements concernés, un correctif sera publié par Fortinet dès que possible.

De plus, une signature IPS (“Bash.Function.Definitions.Remote.Code.Execution“) est d’ores et déjà disponible et peut être appliquée sur le FortiGate dans le but de protéger les systèmes se trouvant derrière celui-ci.

SEPPMail

La société SEPPMail a confirmé que ses équipements n’étaient pas vulnérables à cette faille.

 

* https://twitter.com/markstanislav/status/514811987759755265

CoPS2013

CoPS2013Le 30 septembre dernier a eu lieu le « Congress on Privacy & Surveillance » (CoPS) organisé et hébergé par l’Ecole Polytechnique Fédérale de Lausanne. Dans le sillage de « l’affaire Snowden » et ses nombreuses révélations quant à la surveillance globale d’Internet par la NSA et d’autres agences gouvernementales, cet événement avait visiblement pour but d’amener à la discussion et au débat sur le sujet. A en juger par le nombre de personnes présentes, le thème semble bien être au coeur de l’attention.

La première demi-journée était (volontairement ou non) orientée vers les aspects légaux de cette surveillance ainsi que – de manière plus générale – de la protection des données personnelles. Durant celle-ci, Casper Bowen et Axel Arnbak ont, tour à tour, présenté les implications de la section 702 du FISA (Foreign Intelligence Surveillance Act) américain dans le contexte de cette surveillance. N’étant pas féru de droit, certains aspects de la discussion ont très certainement échappé à votre humble auteur néanmoins ce qui paraît clair c’est que, du point de vue de américain, s’il peut y avoir matière à discussion quant à la légalité de la surveillance de citoyens américains (protégés par le 4ème amendement de la Constitution Américaine) cette discussion n’a pas lieu d’être lorsqu’il s’agit de nous autres « étrangers ». Presque en réponse à cela, la présentation de Nikolaus Forgó rappelait que, en Europe, nous sommes historiquement sensibles à la protection des données privées (encore faut-il définir clairement le terme) et que pour cette raison nous disposions – sur la papier – de nombreuses lois pour aider à l’assurer… lois qui bien souvent ne parviennent pas à l’étape de la mise en pratique. Mais, à nouveau, étant hors du sujet, il vaut mieux laisser ce débat à des spécialistes.

L’après-midi a démarré avec celui qui était probablement une des « têtes d’affiche » de la journée : Bruce Schneier. Au cours d’une présentation orale d’une heure – qui telle une keynote abordait beaucoup de sujets sans réellement dire quoi que ce soit de concret sur chacun d’entre-eux – il a entrouvert la porte à un avenir lointain (une génération selon lui) dans lequel notre rapport à la sphère privée et à la surveillance aura complètement changé. Encore faudra-t-il d’ici là que ces questions commencent à être abordées et traitées par des personnes qui en connaissent les mécanismes et non par des politiques ou des dirigeants qui se targuent de ne pas savoir envoyer un e-mail…

La fin de journée a été rythmée par le discours de Bill Binney, un ancien haut-placé de la NSA elle-même – qu’il a quittée après plus de 30 ans de service suite à de sérieux différents sur la question de la surveillance – suivie par le dernier intervenant de la journée : Jacob Appelbaum. Celui-ci a livré une présentation en deux parties visant à démontrer, d’une part pourquoi nous avons déjà tous perdu face à la surveillance des institutions gouvernementales et d’autre part pourquoi cela vaut néanmoins la peine de continuer à résister. Bien que très pessimiste (vous avez dit réaliste?) quant aux possibilités de surveillance des « adversaires », l’hacktiviste a néanmoins affirmé qu’il continuait à avoir confiance dans la robustesse des mathématiques (affirmation qui avait par ailleurs été également faite plus tôt par Bruce Schneier) en rappelant le fait (ou du moins l’hypothèse) que les possibilités d’attaque contre les algorithmes cryptographies reposent bien plus souvent sur des problèmes logiciels que purement mathématiques. Venant de la part de Appelbaum et Schneier cette affirmation est rassurante mais semble toutefois une maigre consolations face aux questions de “back-doors” dans les logiciels et à son étendue encore largement méconnue.

Au final de cette journée il faut bien avouer que peu de réponses ont été apportées quant aux questions de la surveillance globale d’Internet mais ce n’était bien évidemment pas là le but non plus. S’il semble d’ores et déjà qu’il y aura – dans l’histoire d’Internet – un avant et un après « Snowden » ce type d’événements contribuent à soulever le débat et à combattre une certaine « naïveté » dont nous avons peut-être fait preuve jusqu’à maintenant…