GuardedBox: Gestor online para almacenamiento y compartición seguros de secretos

NOTE: This post, as another exception, has been published in Spanish, as it is disclosing a new security service whose initial documentation is only available in Spanish (English will be added in the upcoming weeks), although the service is available both in Spanish and English.


El Coronavirus (COVID-19) no solo está poniendo en riesgo la salud pública, sino también la información confidencial y los sistemas de información y comunicaciones requeridos para desarrollar actividades remotas, tanto en el ámbito laboral como personal. Las medidas de confinamiento han llevado a buena parte de la sociedad, de las organizaciones (empresas, administraciones, centros educativos y colectivos de todo tipo) y de los individuos (trabajadores autónomos, profesionales, profesores, estudiantes, etc.) a realizar su actividad profesional fuera de sus puestos de trabajo habituales, para lo cual se han debido establecer procedimientos tecnológicos especiales urgentemente y de forma no planificada. 

A los problemas de dimensionamiento de las infraestructuras y los equipos tecnológicos hay que añadir un componente esencial: el intercambio y almacenamiento de secretos digitales de todo tipo, entre ellos, claves de acceso a sistemas y servicios, credenciales para la autenticación de usuarios (por ejemplo, en conexiones VPN), contraseñas que protegen ficheros confidenciales, certificados digitales, claves criptográficas, y un largo etcétera.

Poner a disposición de las personas estos secretos requiere de mecanismos de intercambio seguro, pero, lamentablemente, pocas corporaciones, en especial PYMES, autónomos e individuos, disponen de procedimientos de compartición de información sensible que dificulten e impidan el acceso no autorizado a ellos por parte de terceros. Debido a esta falta de procedimientos y de despliegue de soluciones técnicas, es frecuente ver que se comparten secretos en claro (a través de correo electrónico sin cifrar, SMS, o aplicaciones de mensajería), propiciándose el robo de credenciales, contraseñas, claves, etc., que ponen en riesgo evidente su confidencialidad y favorecen el acceso ilegítimo a sistemas y redes de comunicaciones, y a los datos que éstos gestionan. 

Testigos de esta problemática, Juan José Torres (@s3curitybug) y DinoSec (@dinosec) han liberado la versión 1.00 de GuardedBox, una solución de almacenamiento seguro y compartición de secretos online gratuita para toda la comunidad (individuos, administraciones o empresas) en la que se han invertido en las últimas semanas muchas horas de trabajo. Dicha versión, disponible en castellano e inglés, reúne los requisitos mínimos para almacenar e intercambiar secretos y datos confidenciales de manera segura, de forma sencilla e intuitiva, ya que no requiere de conocimientos técnicos para su uso.

GuardedBox

GuardedBox emplea técnicas criptográficas modernas, destinadas a garantizar que los contenidos de un secreto únicamente serán accesibles por parte de su propietario y, opcionalmente, de aquellos usuarios de la plataforma con los que el propietario desee compartirlo. Un secreto puede ser compartido con uno o varios individuos, o con un grupo integrado por múltiples usuarios. La implementación delega las operaciones criptográficas al lado cliente, es decir, al navegador web (tradicional o móvil).

Además de ofrecer una implementación basada en las buenas prácticas de desarrollo seguro de software, GuardedBox se ha desplegado utilizando tecnologías e infraestructuras alineadas con los más exigentes estándares de seguridad de nuestra industria.

Te invitamos a consultar la descripción detallada de GuardedBox y su documentación asociada en https://guardedbox.es, desde donde se puede acceder al servicio (en español y en inglés), tanto a nivel personal como profesional.

Reconocimiento a los hackers, investigadores y/o profesionales técnicos de seguridad españoles

NOTE: This post, as an exception, has been published in Spanish, as it is dedicated to the Spanish hacker (and technical cybersecurity) community, for a well deserved recognition.

Es para mí todo un honor haber sido designado como merecedor del premio a la trayectoria profesional en valor de la ciberseguridad por parte del Centro Criptológico Nacional (CCN), especialmente, en estas XII Jornadas STIC CCN-CERT (inolvidables por múltiples motivos), otorgado de la mano de Su Majestad el Rey, Don Felipe VI:

En primer lugar, creo que es muy significativa la presencia de Su Majestad el Rey en este evento, reflejando la importancia que ha adquirido la seguridad de los entornos tecnológicos en nuestro día a día. Esta relevancia aumentará aún más en el futuro, debido a la sobredependencia tecnológica que vivimos actualmente, tanto en el plano personal o como sociedad, como en el plano profesional, institucional o industrial.

Video: Fragmento del momento de la entrega del premio.

Casualmente, este año se podría decir que cumplo la mayoría de edad como profesional dedicado íntegramente a la seguridad informática, de la información, y de las tecnologías (hoy en día denominada ciberseguridad :-), qué comenzó allá por 2000-2001 cuando trabajaba en HP (Hewlett-Packard). Circunstancialmente, 2018 ha sido también el año del décimo aniversario de mi compañía, DinoSec, que fundamos para intentar hacer realidad nuestros sueños profesionales y dedicarnos a aquello que más nos gusta. Después de un intenso año de trabajo y tras casi 20 años de carrera profesional en este campo, este premio es la "culminación" al comienzo de una todavía (espero) larga trayectoria para intentar seguir aportando mi granito de arena al apasionante mundo de la seguridad.

Se trata de un premio aún joven, que comenzó a entregarse el pasado año, pese a que algunos tenemos la suerte de haber participado en las doce ediciones de este evento de referencia, lo que hace que me sienta aún más orgulloso de haberlo recibido en una edición temprana. Estoy seguro de que a tod@s nos vienen, o vinieron en el momento de la entrega, a la cabeza, numerosos otros profesionales que se merecen igualmente este premio, y que estoy seguro, serán reconocidos en años venideros.

Agradezco al CCN su confianza, reflejada en este premio, así como el mensaje difundido este año, y plasmado en la interpretación tan positiva que se ha hecho del mismo por parte de la comunidad a la que pertenezco, y en ocasiones como ésta, represento: los profesionales técnicos de seguridad, investigadores, o hackers (aunque el término es lo de menos), que son tan necesarios para, con su alto conocimiento técnico especializado y dedicación, evaluar e identificar las debilidades y vulnerabilidades de la tecnología, con el objetivo de que sean corregidas y de mejorarla, para que todos dispongamos de entornos más seguros.

Video: Fragmento antes de nuestra ponencia sobre DNSSEC para, muy brevemente (por las limitaciones de tiempo), poder agradecer el premio.

Enfatizar, que de alguna manera, se demuestra que el trabajo duro siempre da sus frutos, ya que este es un premio al talento, al inconmensurable valor que debe tener el conocimiento técnico de unas tecnologías e infraestructuras cada vez más complejas, a las capacidades de análisis y de pensamiento lateral, a la motivación de resolver nuevos retos, y a los valores con los que siempre me he identificado y, que de alguna manera, también se reflejan en este premio: esfuerzo, pasión, dedicación, compromiso, implicación, sacrificio, humildad, profesionalidad, curiosidad, inquietud, y muchas ganas de siempre seguir aprendiendo.

Quizás el término que más se ha repetido en todos los mensajes de felicitación recibidos ha sido "merecido", lo que, viniendo de tantos y tan valiosos profesionales, le da aún más valor y me hace estar más orgulloso y satisfecho. Un mensaje que, ahora más que nunca, siento que no nos debemos de cansar de transmitir a las nuevas generaciones.

Sin duda, la entrega del premio constituyó un emotivo e inolvidable momento, que uno sólo tiene posiblemente la suerte de poder disfrutar una vez en la vida:

Como colofón, uno no tiene la oportunidad de poder departir unos minutos en persona con Su Majestad el Rey, para desde la modestia, intentar transmitirle la importancia de estos valores, de disponer de una educación y formación de calidad en España, y la trascendencia que tiene, y tendrá, para nuestro país, contar con profesionales técnicos altamente cualificados, para cubrir la creciente demanda de nuestro sector. Y todo ello tras haber disfrutado de una demostración en directo del funcionamiento de una máquina Enigma de tres rotores, cifrando y descifrando un mensaje, como ejemplo vivo de la historia de la criptografía. Dejé el trofeo bajo ella durante unas horas, por si se le pegaba algo... :-)

Aunque el premio es entregado a una persona individual, por un lado es justo agradecer y destacar que yo no podría haber recibido este premio sin el incondicional apoyo y compañía de mi mujer, Mónica Salas, que durante un cuarto de siglo ha estado siempre ahí, haciéndome crecer tanto como persona, como en el plano profesional. Este premio es una realidad, sin duda, gracias a ella. Igualmente, a mi familia (tanto a los que aún están con nosotros, como especialmente a los que no), por acompañarme en este camino; con su esfuerzo y cariño siempre se preocuparon de proporcionarme la mejor educación y formación posible, y de crear el entorno ideal para que pudiera llegar donde me encuentro a día de hoy. Y por supuesto, a mis hijos, representando a las futuras generaciones que tendrán que protegernos dentro de muy pocos años... :-)

Por último, y no menos importante, no quiero olvidarme de aquellos con los que he compartido mi carrera profesional de forma más cercana todos estos años (compañeros, colaboradores, clientes, alumnos, conferencias de seguridad, etc.), y quiero también agradecer enormemente el extenso y afectuoso apoyo que he recibido por parte de toda nuestra comunidad, de tantas y tantas personas, que se han visto reflejadas en mí y en este premio. ¡Muchas gracias a tod@s!

Aunque los años no pasan en balde, y siempre uno se considera más joven de lo que es, quiero aclarar que ni mucho menos me ha llegado la hora de jubilarme (como algunos asumen que ocurre tras recibir un premio como éste :-), sino que este premio constituye un aliciente, que sirve para reflexionar, valorar lo realizado hasta ahora y seguir querer haciendo más y mejores cosas, siempre disfrutando.

Para no extenderme más, todas las anécdotas asociadas a mi indumentaria, con frases como "¿Es un fotomontaje o Raúl se ha puesto un traje?", las dejo para círculos más cerrados... ;-)

Autor: Raúl Siles

DinoSec's 10-Year Anniversary... and WPA3

UPDATE: The WPA3 presentation by Raul Siles at Navaja Negra (#NN8ED) in October 2018 has been published, including the video (in Spanish) and an early PDF version that includes all the technical references.

This month, May 2018, is DinoSec's 10-year anniversary and this milestone deserves, at least, a blog post... of appreciation and technical content! ;-)

First of all, we want to say thank you to all our customers for showing their trust and confidence in us and our high quality practices, helping to make DinoSec's adventures and business a reality. We also want to thank our collaborators for their support, allowing us to accomplish more ambitious and complex projects and challenges. Thanks you all for allowing DinoSec's original essence and goals as a company remain after a decade!

We are very aware DinoSec's Blog has remained quite quiet during the last three years. Although I don't want this to sound as an excuse (as the reality is that we are quite busy), it is true that back in the early days, publishing blog articles was one of the main mechanisms we used in the security industry to spread the word about new research, tools and topics. This is what I did throughout the three RaDaJo, Taddong and DinoSec blogs over time. However nowadays, although blogs are still used and relevant, there are many other methods to distribute contents, mainly social networks, team messaging and messaging apps (super)groups (public and private), technical training, and (still) presentations and talks (like the ones you can find at DinoSec's Lab) delivered at a very long list of cybersecurity conferences, local (e.g. Spain) or worldwide.

Switching to the technical content, one of the technologies I have been passionate about during almost two decades has been Wi-Fi security. This is a good reason to focus, once again, on Wi-Fi security in this (last?) DinoSec blog post (coincidentally, I also talked about Wi-Fi security in the latest DinoSec's blog post more than three years ago).

The 2018 Wi-Fi predictions from the Wi-Fi Alliance include various attractive programs they are developing, such as bringing enterprise design practices to new home Wi-Fi networks via the Wi-Fi Home Design initiative, optimizing the Wi-Fi user experience and performance by unifying multiple key technologies in programs such as Wi-Fi Vantage, or improving the retail and shopping experience via Wi-Fi Aware by allowing Wi-Fi devices to discover their word nearby and exchange (peer-to-peer) data with other devices without a Wi-Fi infrastructure, even managing location information through Wi-Fi Location. The Wi-Fi bandwidth and speed keeps growing over the years via new technologies such as WiGig (60 GHz) and High Efficiency (HE) IEEE 802.11ax (2.4 & 5 GHz), with products expected in the market late 2018 or 2019. The predictions also mention how the ongoing Wi-Fi security evolution will introduce new WPA3 (Wi-Fi Protected Access, version 3) enhancements throughout this year.

In 2018 the WPA2 certification program will continue to evolve to meet new security requirements, such as standardizing 128-bit cryptographic suites, or making mandatory the use of Protected Management Frames (PMF), a feature defined in the IEEE 802.11w standard to avoid easy manipulation of sensitive 802.11 management frames, widely used in deauthentication attacks. KRACK mitigations are going to be mandatory too in future WPA2 certified products.

The Wi-Fi Alliance announced in January this year (2018) the upcoming release of WPA3, a new security standard focused on enhancing Wi-Fi security protections in both personal and enterprise networks. It is not clear to what extent this announcement has been influenced by the discovery and publication of KRACK (Key Reinstallation Attacks: Breaking WPA2 by forcing nonce reuse) in October 2017. Last week, the announcement of a large chipset vendor integrating WPA3 in their upcoming products hit the news (really? isn't this something all manufacturers are going to do along this year..?: "According to the Wi-Fi Alliance, new devices supporting WPA3 will be released later in 2018, many of which will likely be announced at Computex in June").

The new WPA3 improvements include four specific security capabilities:

• Robust protections even when users choose passwords that fall short of typical complexity recommendations.
• Simplify the process of configuring security for devices that have limited or no display interface.
• Strengthen user privacy in open networks through individualized data encryption.
• A 192-bit (cryptographic) security suite, aligned with the Commercial National Security Algorithm (CNSA) Suite (more suitable for government, defense, industrial, and other high security sensitive environments).

Unfortunately,  it seems we do not learn from history in the infosec (nowadays called cybersecurity) industry. The Wi-Fi Alliance (WFA) is currently working on an internal WPA3 draft. Wouldn't make sense opening the WPA3 draft specification for a global and public security review?, trying to find potential vulnerabilities beforehand, and with the goal of getting it right before it is already implemented in millions and millions of Wi-Fi products and chipsets... ("...more than three billion (Wi-Fi) devices shipping (just) in 2018 (are expected)."). The reality is that the Wi-Fi Alliance impose tight controls on the specifications confidentiality until they are finalized and published... :(

This is something we have (somehow) learned to do in the cryptographic community, requesting peer reviews and opening competitions for new standards, such as NIST did with the Advanced Encryption Standard (AES, Rijndael), the Secure Hash Algorithm-3 (SHA-3, Keccak), or with post-quantum cryptography. As most Wi-Fi security improvements in WPA3 are crypto-related, perhaps we should learn from others in the wireless and network protocols community...

In the next four sections, due to the limited details available in the initial Wi-Fi Alliance announcement, I will try to provide some additional technical details about these new security capabilities introduced by WPA3, complementing the identified needs or WPA3 analysis and interpretation already published by other researchers. Apart from these four features, WPA3 might remove the option to use WEP or TKIP (considered obsolete nowadays), and (re)define the supported list of EAP methods for WPA3-Enterprise.

Updated and More Secure WPA3 Handshake

"Robust protections even when users choose passwords that fall short of typical complexity recommendations"

The current WPA2 traditional four-way handshake does not implement specific countermeasures against hardware-based offline cracking attacks, although the original design made use of PBKDF2 (a key derivation function, in this case, using 4,096 HMAC-SHA1 iterations) and a salt (the SSID, or Wi-Fi network name) to slow down password cracking attacks (offline dictionary or brute force attacks).

The new WPA3 four-way handshake adds extra protections for the WPA3-PSK password, even when a robust passphrase is not used. WPA3 is based on the Simultaneous Authentication of Equals (SAE) handshake, a variant of an authentication and key exchange protocol (or PAKE, Password-Authenticated Key Exchange) known as Dragonfly.  Dragonfly, currently defined in RFC 7664 and in the 802.11-2016 specification (a PDF with more than 3,500 pages), has been supposedly enhanced to mitigate previously identified Dragonfly offline attacks (and/or other weaknesses), it is also the foundation for TLS-PWD and there is even a security proof for it (... like for WPA2 before KRACK? ;-). SAE was originally used for 802.11-based mesh networks under the IEEE 802.11s security umbrella, although in WPA3 infrastructure networks typically only the Wi-Fi AP (Access Point) will initiate the handshake. For compatibility reasons, both WPA2-PSK (or Personal) and SAE might coexist simultaneously in WPA3-Personal APs.

SAE employs discrete logarithm cryptography (finite fields or elliptic curve cryptography, FFC or ECC) for a mutual authentication exchange using only a password, that is used to derive an ephemeral key, similarly to a Diffie-Hellman (DH) key exchange, and it benefits from associated properties such as forward secrecy (the derived key cannot be recovered in the future even if the password is obtained). It is designed to be (probably) resistant against offline dictionary attacks, as no information about the password (or the key) is disclosed except whether a password guess is correct or incorrect.

The result of the SAE handshake is a strong shared secret (or derived key) that will become the PMK (Pairwise Master Key, 256 bits) in WPA3 (like the PMK in WPA2), therefore, it will be used in the traditional four-way handshake to derive the PTK (Pairwise Transient Key, 512 bits). Thus, the new WPA3 handshake replaces the traditional WPA2 PBKDF2 key derivation process to obtain the PMK from the PSK (Pre-shared Key), or password... or passphrase.

One potential drawback of this new WPA3 handshake is that the Wi-Fi AP might require storing the password in plaintext, as pointed out by Mathy Vanhoef (from KRACK). Although a "balanced" PAKE also allows storing a hash of the password with a random salt, as a "non-augmented" protocol, the stored values (or hashes) can be used directly to authenticate to the AP. Therefore, the stored hash is acting as a plaintext password (even if it cannot be easily read by humans), and becomes vulnerable to PtH-like (Pass-the-Hash) attacks (in which a dictionary or brute force attack to obtain the original password is not required).

Updated and More Secure WPS Alternative

"Simplify the process of configuring security for devices that have limited or no display interface"

WPA3 introduces new capabilities to configure secure Wi-Fi networks in devices without screens or input peripherals, such as IoT (Internet of Things) devices.

The simplification of the initial setup process to join a new Wi-Fi client to a Wi-Fi network in a secure way has been troublesome in the past. The WPS (Wi-Fi Protected Setup) standard has suffered serious online (Reaver) and offline (Pixie) vulnerabilities in recent years.

WPA3 tries to replace WPS with a new technical specification named Wi-Fi Device Provisioning Protocol (DPP), still in draft state (registration required). This new three-way handshake authentication or setup protocol requires the usage of public key cryptography to identify and authenticate all Wi-Fi devices. DPP employs elliptic curve cryptography (ECC), and specifically elliptic curve Diffie-Hellman (ECDH), to derive a shared secret or key. Again, upon successful validation of the peer discovery process, the Wi-Fi devices will  mutually derive a PMK (Pairwise Master Key) that will be used in the traditional four-way handshake to derive the PTK (Pairwise Transient Key). AES-SIV (Synthetic Initialization Vector, RFC 5297) is involved in the protocol for the parties to prove possession of the private keys associated to the public identity keys.

Mutual authentication is desired between the Wi-Fi devices (e.g. client and AP), but due to constraints in some clients, it is not mandatory (thus, more insecure). One of the methods promoted by the new WPA3 mechanism to identify the other device is the usage of QR codes (e.g. containing the public key with the identity of the Wi-Fi network) for client devices with a camera. Other options for bootstrapping trust involve Neighbor Aware Networking (NAN), used in Wi-Fi Aware, USB, NFC, or Bluetooth, or proof of knowledge of a shared code, key, phrase, or word.

Individualized Data Encryption

"Strengthen user privacy in open networks through individualized data encryption"

This feature tries to offer encryption (using individual encryption keys for each connecting client) for open Wi-Fi networks, where the common WPA2-PSK security based on a unique Wi-Fi network password is not even available. This feature will mainly affect open Wi-Fi networks commonly used in public Wi-Fi hotspots (hotels, airports, libraries, coffee shops, restaurants, conferences, etc.).

Long time ago, around year 2010, a few proposals to offer enterprise-level security for open or public Wi-Fi networks were already discussed, named Open Secure Wireless (OSW), promoted by Christopher Byrd, or a variant, Secure Open Wireless Networking (SOWN or SOWA, Secure Open Wireless Access), promoted by Tom Cross & Takehiro Takahashi. These proposals emphasized that open does not mean unencrypted.

OSW main goal was to make use of all the security benefits provided by WPA2-Enterprise, without the need of authenticating the user, that is, providing open access to any user. OSW only requires a slightly modified EAP-TLS type (anonymous authentication) supported by the Wi-Fi clients, and there is even a prototype implementation available. A new OSW 2.0 revision (OSW2) was released afterwards, incorporating IEEE 802.11u improvements. I have found even a related patent for something like OSW/SOWN.

SOWN, also EAP-TLS based, focused more on binding the Wi-Fi network digital certificate (associated to the RADIUS server) to the Wi-Fi network name (or SSID), enhanced as an eXclusive or eXtended SSID (or XSSID). Even before that age, in 2007, George Ou made a proposal to use a WPA2-Enterprise PEAP-based Wi-Fi network with a generic or guest account for anonymous users, to accomplish similar goals.

WPA3 "individualized data encryption" refers to Opportunistic Wireless Encryption (OWE) for Wi-Fi networks, a mechanism designed to provide encryption without authentication, encompassed under the "opportunistic security" concept (RFC 7435), and defined in RFC 8110.

OWE provides protections against passive attacks, such as traffic sniffing. Similarly to the new WPA3 handshake, OWE negotiates or derives a PMK (Pairwise Master Key) using a Diffie-Hellman (DH) key exchange (again using finite fields or elliptic curves), but with no initial password involved this time (as there is no authentication in public or open Wi-Fi networks). The PMK is used again throughout the traditional four-way handshake to derive the PTK (Pairwise Transient Key).

WPA3 APs will advertise support for OWE in their 802.11 beacons and probe responses. Once a Wi-Fi client performs a standard open authentication (request and response), additional information elements (IE) are incorporated into association requests and responses to perform the DH key exchange, allowing both the Wi-Fi AP and the client to exchange their public keys and, as a result, perform the cryptographic computations required to derive the PMK.

A 192-bit Cryptographic Security Suite

"A 192-bit (cryptographic) security suite, aligned with the Commercial National Security Algorithm (CNSA) Suite"

WPA2 (ignoring TKIP, that should not be used anymore) implements an encryption protocol based on AES CCMP (CTR mode with CBC-MAC Protocol). CTR mode, also known as CounTeR mode, turns a block cipher into a stream cipher (as detailed in the KRACK attacks). RFC 3610 defines the Counter with CBC-MAC (CCM) protocol, and specifies that this generic authenticated encryption (AE) block cipher mode is defined for use with 128-bit block ciphers, such as AES.

Therefore, the new 192-bit crypto suite introduced by WPA3 does not simply offer an increased key size, but must use a different encryption algorithm (referred as NIST "Suite B" cryptographic algorithms), most probably, AES GCMP (Galois/Counter Mode Protocol), described in RFC 5288 for TLS. GCMP was already "silently" introduced in WPA2 for 802.11ac, even using longer 256-bit keys, and will be used by WiGig too.

Wi-Fi Hidden Networks... Still in WPA3?

Apart from these four previously detailed WPA3 security enhancements, there are pending security issues that still need to be addressed in the current Wi-Fi specification. Future Wi-Fi-related WPA3 developments might focus on protecting users privacy too (probably a lost battle globally at this point...), including MAC address randomization (using locally administered MAC addresses when the client is not associated to the Wi-Fi network yet, or even post-association...) as well as reducing other types of information leakage (SSID names in probe requests). Thus, WPA3 might introduce privacy enhancements (badly named, as they also have serious implications from a security perspective, not just privacy), such as mitigating Wi-Fi devices from sending directed probe requests until the associated SSIDs have been already discovered via passive scanning (obtaining and processing the 802.11 beacon frames in the area) or active scanning (via wildcard or generic 802.11 probe requests).

One of the main issues I have been really interested in during the last years is Wi-Fi hidden (or non-broadcasting) networks, a useless feature that facilitates attacks against Wi-Fi clients and promotes the disclosure of their PNL (Preferred Network List). In fact, the potential WPA3 privacy enhancements mentioned in the previous paragraph would be equivalent to not considering a Wi-Fi network as hidden anymore or, said otherwise, if WPA3 introduces these mitigating behaviours, Wi-Fi clients won't be capable of connecting to hidden networks anymore, which drives us to my next point.

Wi-Fi PNL disclosure is one of the topics I extensively cover in my "Practical Wireless & Radio Hacking" (PWRH) training, and I do even have a slide (see below) detailing what should be removed from the IEEE 802.11-2012 specification to eliminate support for Wi-Fi hidden networks and, as a result, mitigate the related privacy and security attacks. It is trivial for a potential attacker to fire up a fake Wi-Fi AP impersonating one of the legitimate APs the victim Wi-Fi client has connected to in the past, and is searching for. The attacker has plenty of opportunities to attack the victim Wi-Fi client, no matter what security type was used by the legitimate Wi-Fi network (open, WEP, WPA(2)-PSK or WPA(2)-Enterprise). 

In the past I tried to approach the IEEE to promote the removal of Wi-Fi hidden networks, but I was disappointed about the bureaucracy and obstacles I had to confront, at least, for a security researcher that does not belong to any of the IEEE 802.11 Working Group (WG) members. If you know someone in the 802.11 WG interested on helping with this, please, send me an e-mail. Another approach would be to get it out of the specification through the Wi-Fi Alliance thanks to WPA3. If we are lucky and get it removed from the next IEEE 802.11 specification, perhaps a decade from now, all Wi-Fi products in the market will not disclose their PNL for free via directed 802.11 probe requests... ;-)

Happy WPA3 security testing!

Image source: http://www.systemandgeneration.com/uploads/images/about/logo%2010th%20anniversary.png
Image source: https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgsFqnl356aez9q5ixvtBRlX7hoXCv0NxS1xJVxRWMMDhWrryR42HSDtRiIpj2U-r-6ahDGy_BTGNzHPwtbIml-jAxypQREJuto3J_of0N0U4MHdTU9ziDf6NWiZWpPY2ujXMtICtfW-8pw/s728-e7/wpa3-wifi-security.png
Image source: http://dilbert.com/strip/2013-12-11

Why Do Wi-Fi Clients Disclose their PNL for Free Still Today?

Shameless plug: Don't miss this year 2015 RootedLab, a great opportunity to learn and practice effective client Wi-Fi attacks (& defenses) though a new updated hands-on workshop full of tips and tricks and real-world pen-testing advice: "Técnicas de ataque sobre clientes Wi-Fi". It will take place in Madrid on March 4 (in two weeks) in Spanish, and right now there are only a few seats available (check also the other interesting workshops, called RootedLabs, that are running before this year RootedCON conference). During the workshop we will cover in-depth all the topics from the introductory blog post, from this blog post, and put in practice traditional and new advanced attacks (FreeRADIUS-WPE, EAP LEAP-Down, EAP Dumb-Down, LEAP2PEAP relay...), and much more..., such as (not released yet) new FreeRADIUS-WPE patches for the LEAP-Down attack, or a new iStupid version (v1.4) implementing the DoS Wi-Fi Direct attack against Android 4.x devices (CVE-2014-0997).


The initial introduction to the "Attacking Wi-Fi Clients" DinoSec blog post series highlighted multiple topics involved in current Wi-Fi client weak behaviors and potential attack opportunities. This next installment in the series focuses on understanding why and when Wi-Fi clients disclose their PNL still today.

State-of-the-Art: The PNL

There are scenarios where Wi-Fi clients still disclose their PNL, that is, the list of known Wi-Fi networks the client has connected to in the past, and it is willing to connect to again, now and in the future. This weakness in the default behavior of Wi-Fi clients (part of the IEEE 802.11 specification) was discovered around the end of 2004, early 2005, and tools were released to exploit it by automatically impersonating any open network the client device tries to connect to, such as Karma. Alternative tools have been published over the years, such as Karmetasploit or airbase-ng. Although in January 2007 Microsoft released an optional client update to prevent the wireless advertising of the PNL for Windows XP SP2, still today lots of Wi-Fi clients are vulnerable.

When Do Wi-Fi Clients Disclose their PNL?

The following paragraphs detail different modern scenarios in which Wi-Fi clients still might disclose their PNL, including some curious references to constraints you will find when you try to manage the PNL of your Wi-Fi clients.

Wi-Fi Client State and Other Peculiarities

The PNL disclosure behavior is highly influenced by the Wi-Fi client state, such as if it is currently connected to a known Wi-Fi network, or if there are no well known networks in its vicinity. However, distinct clients and implementations behave differently, and even when connected, it is still possible for a client to disclose its PNL, while looking for more "interesting" known networks. Sometimes, they do when trying to connect to a new network, or when the network they were previously connected to disappears or the signal is low enough. Besides that, an attacker can also force a victim Wi-Fi client to disassociate from the current network, forcing it to disclose its PNL.

Unfortunately, by default there are multiple Wi-Fi clients that continuously disclose their PNL in the air. Others, however, only disclose it sometimes. If you try to fix both of these scenarios, you suddenly realize this behavior is heavily influenced by several complex factors, such as the specific hardware used by the client, that is, the chipset used on its Wi-Fi interface or card, the firmware version, the version of its Wi-Fi drivers (used by the operating system to interact with the card), and the supplicant implementation (the Wi-Fi client capabilities at the software level). For example, I saw iOS 7.0.4 tended to disclose the PNL if running on an iPhone 4, but not on an iPhone 4S (even when running iOS 7.0.3), but iOS 6.1.3 didn't disclose it either when running on an iPad 3.

New features introduced in modern Wi-Fi clients, such as the MAC address randomization capabilities of iOS 8 when it scans for Wi-Fi networks, open the door to evaluating how effective this behavior is both from a privacy and security point of view, and promote additional research.

As a result, while researching about why and when Wi-Fi clients disclose their PNL, I have found difficult to consistently reproduce some scenarios in which it's not very clear why the PNL has been revealed. A complex combination of factors is behind the root cause, such as the surrounding Wi-Fi networks and signal levels, the existence of hidden Wi-Fi networks nearby, the current state of the client mobile (2/3/4G) interface, the current and previous Wi-Fi client states and transitions, the PNL contents, and even if the device is getting power through a computer USB port or from a power plug... a very long list of sometimes unrepeatable facts. But the truth is that Wi-Fi clients still disclose their PNL.

For all these reasons, it is required to design a very thorough methodology to evaluate why and when a target Wi-Fi client discloses its PNL.

Hidden Wi-Fi Networks

Hidden or non-broadcast Wi-Fi networks are one of the most common scenarios why Wi-Fi clients disclose their PNL. In fact, the only way a Wi-Fi client can connect to a hidden network is by disclosing its PNL. This is definitely one of the main reasons why you should never configure Wi-Fi networks as hidden (although still today there are people recommending this as a best practice), as this is not providing any effective security to the Wi-Fi infrastructure, but it is in fact exposing the Wi-Fi clients that connect to it.

A very specific case related to mobile devices is when Wi-Fi networks are added manually to, for example, iOS or Android. In the case of mobile devices, manually adding a Wi-Fi network (check the various advisories I published during the last few years) commonly implies this network will be considered as hidden by the device and, therefore, it will be disclosed. To sum up, if a Wi-Fi network (hidden or not) is manually added to a mobile device, there is a very high probably it will be disclosed by that Wi-Fi client.

Case Study: iOS 5.x

On early 2012 I discovered a scenario where Apple devices based on iOS 5.x (at that time), like iPhones and iPads, fully disclose their PNL (including both hidden and visible networks) every 45 seconds when they enter sleep mode (also referred as suspend or standby mode). Therefore, an attacker can force a victim device to disclose its PNL if he has temporary physical access to it, making the device going to sleep by pressing the power (or Sleep/Wake) button, the device owner can make the device to enter standby mode by its own, or even the device will do it automatically after not being used for a few minutes, depending on its settings.

I can briefly mention this vulnerability at this point as the impact today is clearly low, due to the existence of newer iOS versions, and because this is still the default behavior of lots of Wi-Fi clients.

Managing the PNL

On the one hand, some Wi-Fi clients allow you to manage their PNL, such as Android 4.x devices although it would be great to be able to prioritize the entries in the PNL or identify if they correspond to hidden or visible networks. On the other hand, other widely used Wi-Fi clients, such as Apple devices running iOS, do not provide capabilities to manage it. Therefore workarounds are required in case you want to easily remove some entries from the PNL, such as using iStupid. Although this seems to only affect mobile devices or other "dumb things" from IoT (Internet of Things) with Wi-Fi client capabilities, this is not always the case and surprisingly, even modern operating systems used in traditional computing might be affected, taking a step back.

Case Study: Windows 8 & 8.1

Another more traditional scenario where managing the PNL has taken a step back is Windows 8 (even if it does not disclose the PNL by default, you may want to edit or remove previously added hidden networks). If you thought the already mentioned issues were just affecting mobile or embedded devices nowadays, it is not the case. Although in Windows 7 it was trivial to manage the PNL via the Wireless Profile Manager (for Windows 7), these capabilities were removed from the graphical user interface (GUI) in Windows 8. As a result, you can only view or remove a network from the PNL from the Wireless Network List if it is currently in range (as it is the case with iOS devices); remember you can always use iStupid [0] to help you making those faraway networks reappear ;-)

The other options available to manage the PNL in Windows 8 are through third-party tools, such as WiFi Profile Manager 8 or Classic Shell, using the command prompt via "netsh" (including managing the priority of networks within the PNL), or manually, by accessing or removing the XML files where the Wi-Fi networks profiles are stored: "C:\ProgramData\Microsoft\Wlansvc\Profiles\Interfaces\{Interface-ID}\{Profile-ID}".

Windows 8.1 has slightly improved the manageability of the PNL. Although it does not include full capabilities as Windows 7, at least from the "Settings - Change PC settings - Networks - Connections" menu it is possible to manage and change some properties for each PNL entry. Still, to delete an entry you need to go to the command prompt and execute the "netsh" tool (probably an alternative not suitable for the average user).

[0] For the sharp reader, there are newer versions of iStupid in DinoSec Lab, apart from v1.0, waiting for you :-)

Security & Privacy Risks and Implications of Disclosing the Wi-Fi PNL

Finally, as it seems vendors and manufacturers of Wi-Fi products with client capabilities still do not take this issue seriously, we need to evaluate what are the real privacy and security risks of disclosing the PNL, that is, letting everyone know what are the Wi-Fi networks the Wi-Fi client device wants to connect to.

Privacy

On the one hand, an attacker can gather the PNL details to exclusively fingerprint a Wi-Fi client, with direct privacy implications. The fingerprinting process is based on identifying a very unique network name (SSID) used by that client, match that SSID to the client Wi-Fi MAC address, and be able to track its common locations and activities. If a very unique SSID is not found, most probably the Wi-Fi client will disclose a unique set of SSIDs. Even if some of these SSIDs are commonly used by millions of users, the whole set of SSIDs of a given client PNL tends to be a good distinguishing factor (even when the MAC address is randomized). This fingerprinting capabilities definitely help to launch very targeted attacks against key individuals, such as a high level executives of a given target organization.

Changing the default SSID and selecting a unique value is a positive countermeasure when protecting the Wi-Fi infrastructure, and in particular WPA(2)-PSK networks, as it acts as a deterrent against pre-calculated (raibowtable) password attacks on the PSK, because the master key (PMK) is based on the SSID (it acts as a salt). However, when talking about Wi-Fi clients, that unique SSID can help to identify a specific target.

Security

On the other hand, an attacker can gather the PNL details with the goal of impersonating one of the legitimate networks the client is trying to connect to, and as a result, get the Wi-Fi client to effectively connect to the attacker's infrastructure automatically, with serious security implications. In future installments of this series we will provide more details about these attacks, no matter what security mechanism is used by the legitimate Wi-Fi network (Open, WEP, WPA(2)-PSK, or WPA(2)-Enterprise). At this point, the victim client is sharing the network (at layer 1&2 and above) with the attacker. This is, at least, scary and opens the door to several direct and Man-in-the-Middle (MitM) attacks!

It is time to take this issue very seriously and responsibly address it, specially considering the impact it will have with the upcoming industry trend associated to the Internet of Things (IoT) or Internet of Everything (IoE), and the enhanced Wi-Fi bandwidth capabilities of 802.11ac networks. More and more, critical devices and gadgets used on a daily basis are going to provide Internet and data communication capabilities, some of them through LAN/Ethernet ports, but I foresee most of them (to get away of the uncomfortable wires) through a Wi-Fi interface.

Solutions

The sort term solution is to start evaluating if your personal, or your organization, Wi-Fi client devices disclose their PNL through specific Wi-Fi assessments and research. By Wi-Fi client devices I mean everything that has Wi-Fi client capabilities, from mobile devices to "everything" (IoT) in the residential, corporate, and mobile environments. If they disclose their PNL, at least you know it and can take informed security decisions, although there is not to much you can do if the vendor does not fix it, apart from carefully and diligently managing your PNL. Try to reduce the number of entries in the PNL and be sure all the known networks are using robust security... because you, or your organization employees, never ever connect to a free and open Wi-Fi hotspot, right?

The mid term solution is to implement some of the tools or solutions currently available that try to change the default behavior of some Wi-Fi client platforms, such as Smarter Wi-Fi Manager or Wi-Fi Privacy Police for Android mobile devices, to name a couple.

The long term solution is to promote a modification (I'm making this request public here!) of the next version of the IEEE 802.11 specification to, on the one hand, completely remove the existence of hidden Wi-Fi networks (Wi-Fi access points shouldn’t provide an option to configure a Wi-Fi network as hidden, and Wi-Fi clients should never allow users to add a Wi-Fi network as hidden), and on the other hand, mandate that Wi-Fi clients must never check for the availability of the specific Wi-Fi networks contained in their PNL through directed Probe Request frames. Instead, Wi-Fi clients must always discover the surrounding networks by sending a generic (or broadcast) Probe Request frame with a wildcard (or empty) SSID.


NOTE: For the record, this year updated "Técnicas de ataque sobre clientes Wi-Fi" session, 2015 RootedLab, complements the workshops I run in RootedCON on previous years, 2011 RootedLab, "Seguridad en Bluetooth, Wi-Fi, GSM y GPRS", the 2012 RootedLab, "Analizando y explotando aplicaciones web con Samurai-WTF", and the 2014 RootedLab, "Técnicas de ataque sobre clientes Wi-Fi" (all 2014 links have been removed from the official website).

iOS Passcode Recovery with iPhone Data Protection Tools (Using Yosemite)

Shameless plug: During the first half of this year I will be teaching the 6-day SANS SEC575 training, "SEC575: Mobile Device Security and Ethical Hacking", in Amsterdam, Netherlands (May 11-16, 2015), Madrid, Spain (May 25-30, 2015 in Spanish), and London, UK (July 13-18, 2015).

UPDATE: Xcode 6.2 (March 9, 2015).

Since the early days when the SANS "SEC575: Mobile Device Security and Ethical Hacking" class made its debut around May 2012, Joshua Wright, the SEC575 author, included details for the iPhone Data Protection Tools presented at HITB 2011 in Amsterdam.

We cover this toolset in SEC575 during the "Mitigating the Stolen (or Lost) Device Thread" section on day 2. We like not only covering the tool internals, but are used to run a live demo in class showing attendees how the tool works and how easy it is to obtain a 4-digit passcode in a few minutes without leaving any significant trace on the mobile device. I particularly love to run the live demo and go deeper into the technical details about how the built-in iOS full device encryption and data protection is implemented, the impact of firmware/hardware vulnerabilities (such as the bootrom vulnerability leveraged by the by limera1n's exploitation process), the importance of software and hardware security updates, and how the full keychain contents can be decrypted once the passcode is obtained, exposing multiple sensitive user credentials. Although this particular attack (based on limera1n) can only be launched against Apple devices up to the iPhone 4 and the iPad 1 (using the vulnerable Apple A4 SoC), it can be used to emphasize the attack possibilities and impact of future similar vulnerabilities in other modern Apple devices.

Definitely, running this kind of impressive attack demos in front of C-level executives really help to make the point and create individual users, and corporate, awareness regarding the risks of using 4-digit passcodes, or leaving mobile devices unattended for a few minutes (due to an urgent phone call or meeting, etc) or more (a tablet left in a hotel room during dinner, etc). For this reason, apart from covering the attack details and running the demo in class, in order for the attendees to be able to reproduce it, the SEC575 DVD contains a thorough step-by-step guide describing how to prepare your OS X pen-testing system to launch the attack. Originally, the guide was available for OS X Lion (10.7) and we updated it for OS X Mountain Lion (10.8) a few months later. 

However, due to the fact this is an "old" attack, one of the most challenging tasks over the years is making it work with the latest operating system versions, libraries and modules, development frameworks and languages, and other required dependencies. For this same reason, I have recently updated the guide for OS X Yosemite (10.10), so that you can demonstrate the attack still today if you are running the latest OS X version, and we are making it public out of the SEC575 realm (perhaps reaching out to potential future SEC575 candidates):

• Apple iOS Key Recovery with iPhone Data Protection Tools (Using Mountain Lion) - 10/30/2012
• Apple iOS Key Recovery with iPhone Data Protection Tools (Using Yosemite) - 01/25/2015

This new version of the guide was tested under OS X Yosemite (10.10.1), the associated official Xcode version (6.1.1) and using a couple of target mobile devices, an iPad 1 (running iOS 5.1.1) and an iPhone 4 (running iOS 7.0.4).
 
Is Your Xcode Environment Vulnerable?

UPDATE: Finally, on March 9, 2015, Apple released Xcode 6.2 fixing the following Git vulnerability (CVE-2014-9390) after more than two and a half months. The new default Git version is "1.9.5 (Apple Git-50.3)".

On December 18, 2014, a vulnerability in Git was released (CVE-2014-9390; in reality this CVE includes three vulnerabilities), affecting multiple Git versions both for Windows and Mac OS X Git clients. It allows remote code execution by rewriting the contents of the ".git" directory, such as the "config" file or the "hooks" sub-directory, for example, through "git pull" or "git checkout" operations. Microsoft released patches for their different Git implementations, GitHub also updated their GitHub for Windows and GitHub for Mac clients, and Apple addressed it in Xcode 6.2 beta 3.

On early January 2015 a Metasploit module was released to exploit this specific vulnerability through an HTTP server designed to simulate a Git repository.

If you are an Apple developer, I expect you to update your Xcode environment frequently to be able to benefit and test the latest features, including the iOS 8.2 SDK with WatchKit support (for Apple Watch) in Xcode 6.2 beta versions. But if you are a security professional and use Xcode for security testing, for tasks like the ones described in this blog post, your Xcode environment might be vulnerable.

At the time of this writing, end of January 2015, the latest official Xcode version available through the App Store is Xcode 6.1.1 (released on Dec 02, 2014). This Xcode version still uses Git v1.9.3 and it is still vulnerable (for almost one and a half months) to CVE-2014-9390:

$ git --version
git version 1.9.3 (Apple Git-50)

In order to install Xcode 6.2 beta 3 (or later beta versions) you need to manually download Xcode using a free (or paid) Apple developer account, and proceed with the installation. The Xcode beta version goes into "/Applications/Xcode-Beta.app" (vs. the default "/Applications/Xcode.app" directory). However, even when the beta version has been installed, the Xcode command-line tools (of which Git is part of) will still use the official Xcode version. To switch between the different versions of the Xcode command-line tools, you need use the xcode-select tool (as root):

$ git --version
git version 1.9.3 (Apple Git-50)
$ xcode-select -p
/Applications/Xcode.app/Contents/Developer
$ sudo xcode-select --switch /Applications/Xcode-Beta.app/
$ xcode-select -p
/Applications/Xcode-Beta.app/Contents/Developer
$ sudo xcodebuild -license
$ git --version
git version 1.9.5 (Apple Git-50.3)

Therefore, the Git version for Xcode 6.2 beta 4 is 1.9.5, not vulnerable to CVE-2014-9390. Time to update your Xcode version!

iOS: Back To The Future II

Last year I disclosed publicly the "iOS: Bact to the Future" vulnerability affecting iOS Apple devices, from version 5.x up to version 7.x (the video of the presentation is available in Spanish, and dubbed into English). Anyone intercepting the target mobile device traffic could freeze a iOS victim device into its current operating system (OS) version forever. Once I notified Apple, in March last year they modified their update servers to behave differently when they identify a client request with a future date (in the "If-Modified-Since" header). As a result, the vulnerability could be still exploited but limited to freezing the iOS victim device into its current OS version till the next update is released, that is, bypassing the most recent updates available.

In September 2014, Apple addressed the "iOS: Back to the Future" vulnerability in iOS 8 and identified it with CVE-2014-4383. After doing some research I discovered that the changes introduced by Apple in iOS included similar checks as the ones previously described for the update servers but on the client side, in particular when iOS identifies a server response with a future date (in the "Last-Modified" header). However, again, the new verifications only check for future dates, opening the door to manipulating requests and responses with a date between the date of the last update and the current date.

Therefore, last month I presented the current state-of-the-art for this vulnerability as "iOS: Back to the Future II", emphasizing not only that nothing has changed from an exploitation perspective since March 1, 2014, but some deep thoughts about the fact that vulnerabilities might be supposedly fixed, even when a CVE gets assigned to them, but perhaps they are not. Perhaps involving the researchers in the verification process for the fix might help to confirm if the vulnerability is really solved...

Although the presentation is in Spanish, I think you can easily follow the timelines on slides 11 and 19, and the technical details on slides 12, 14, 16 and 17.

The following videos demonstrate the current iOS 8.x behavior in different exploitation scenarios:

1. The first video shows an iPhone device running iOS 8.0.2 attacked using the StarWars (Jedi) temporary variant, although the most recent iOS version available is 8.1:

2. The second video shows an iPhone device running iOS 8.0.2 attacked using the Matrix permanent variant (as if iOS 8.0 were the most recent version on 07 Nov 2014), although the most recent iOS version available is 8.1 (officially published on 20 Oct 2014):

3. The third video shows how the update server replies with the current update when receiving a request with a date in the future (07 Nov 2024), and how when an iPhone device running iOS 8.0.2 is attacked using the Matrix permanent variant (with a response using a date in the future, year 2024), it does not process it, requesting subsequent updates from scratch. The most recent iOS version available is 8.1 (officially published on 20 Oct 2014):

4. The fourth video shows how a previous victim iPhone device running iOS 8.0.2 is manually forced (on purpose, "07 Sep 2014") to discover the most recent iOS version available, 8.1 (officially published on 20 Oct 2014) and it even downloads the current update documentation. Then, it is attacked again using the Matrix permanent variant (as if iOS 8.0 were the most recent version on 07 Nov 2014), and it becomes a victim again:

5. The fifth video shows how the attack is not possible once the victim iPhone device has already downloaded the most recent update (e.g. iOS 8.1), as it does not even try to check for new updates till the local pending update gets installed:

Attacking Wi-Fi Clients: Introduction

During the last decade, an uncountable number of articles, whitepapers and presentations have been published about Wi-Fi security, hacking, attacks and defenses. Most of that research, including attack techniques and tools, has focused on the infrastructure side, that is, Wi-Fi access points (APs) and networks. These have been the main targets since the early WEP weaknesses announced around 2001. As the Wi-Fi technologies matured, and assuming nowadays (with the right skills and knowledge) it is possible to build a robust and reasonably secure Wi-Fi network, Wi-Fi attacks started to move towards the client side a few years ago. However, despite Wi-Fi client attacks got some early attention around 2005 (thanks to Karma), they blurred over the years. Attacks focused on the Wi-Fi clients have evolved slowly, progressively, sometimes silently but significantly since then, nevertheless from an end user awareness perspective, corporate security perspective, or even from the point of view of major industry leaders and vendors, they have not been taken seriously enough. The reality is that, still today, Wi-Fi clients present multiple vulnerable behaviors that can be leveraged for targeted attacks or even mass exploitation. The situation can only get worse in the upcoming Internet of Things (IoT) or the Wi-Fi Internet of Everything (IoE) age:

On the one hand, the current Wi-Fi client vulnerabilities and misbehaviors might allow an attacker (or pen-tester; I will use the term 'attacker' from now on) to accurately fingerprint specific targets, with significant personal privacy and tracking implications. On the other hand, they can be used to force a victim Wi-Fi client to reveal the networks it is trying to connect to, their security type, and even the associated Wi-Fi network key or user credentials. Additionally, the attacker might force the target Wi-Fi client to connect to its own network, an scenario that opens the door to a huge range of traditional network-based attacks.

The following list briefly outlines multiple aspects that are relevant when describing these kind of Wi-Fi client weaknesses and attacks. These topics are going to be covered in future installments of this "Attacking Wi-Fi Clients" DinoSec blog post series, following this introduction:

• First of all, it is crucial to understand how modern Wi-Fi clients behave, discover and connect to Wi-Fi networks, including the different options available for the end user to select a new network, as well as the technical details and 802.11 frames involved in the process.
• One critical element that is involved in that selection and connection process is the Preferred Network List (PNL), that is, a local client repository (or database) that contains the list of known Wi-Fi networks the client has connected to in the past.
• From a security perspective, the way the PNL is used by Wi-Fi clients determines the attack opportunities. Multiple factors influence the PNL usage, including if the client connects automatically to known networks, which network is selected when multiple known networks are available, what specific Wi-Fi network details the identification process is based on, etc.
• In addition to the PNL usage, the PNL management features available for the end user (or corporate environment) also determine the PNL contents and the defensive capabilities. Wi-Fi clients should provide features to fully manage the PNL, including its visualization, selecting the priority of the different networks available in the PNL, as well as management options to add, delete or edit all the properties of any Wi-Fi network contained inside the PNL. However, we are currently facing various challenges, such as anomalies to be able to properly manage the Wi-Fi PNL (Preferred Network List) in modern mobile devices, like iOS, or even in traditional operating systems whose previous versions had the required capabilities, like Windows 8. The iOS constraints can be partially overcome by skilled users or enterprises via the iStupid tool (that I already described in several previous blog posts).
• Unfortunately, and although some traditional Wi-Fi clients fixed this specific vulnerable behavior a few years ago, still today several Wi-Fi clients disclose the contents of their PNL for free. There are multiple scenarios and reasons where Wi-Fi clients unnecessarily reveal their PNL all over the air (the details will be covered latter in the series). For example, multiple vulnerabilities have been published since 2010 affecting modern mobile devices and the way a new Wi-Fi network is manually added by the user to the PNL through the user interface. Anyone monitoring the wireless traffic can easily obtain the details of the PNL, and as a result, identify the list of Wi-Fi networks the client device is trying to connect to.
• The fact that Wi-Fi clients still disclose their PNL for free today, together with its MAC address, entails significant privacy implications and security risks. Although recently the EFF emphasized the associated privacy risks, something we knew about wireless pervasive technologies since around 2008, the main concern must be centered on the security threats. Anyone that identifies the PNL of a given target, that is the list of Wi-Fi networks the client device is trying to connect to, can easily impersonate these legitimate networks through a fake AP. As a result, multiple attack scenarios are viable, depending on the security mechanisms used by the legitimate network. By the way, the legitimate Wi-Fi network security type can be easily identified using different impersonation techniques.
• The simplest and easiest scenario is targeting an open Wi-Fi network, as only the network name is required to impersonate the legitimate network and get the victim client to automatically connect to it. However, even for the security conscious (or "paranoid") user, that never ever connects to an open (or WEP-based network), there are additional security risks to consider.
• When a WEP or WPA(2)-PSK network is impersonated, the legitimate Wi-Fi network key is required for the victim client to establish a connection with the fake AP. There are two WEP-based attacks that can obtain the original key from the victim Wi-Fi client: Caffe-Latte and Hirte. Similarly, for WPA(2)-PSK networks it is possible to capture two frames of the initial 4-way WPA(2) handshake in an AP-less scenario with the goal of cracking the PSK via dictionary attacks or rainbowtables (for the name of that specific Wi-Fi network). These kind of attacks provide two benefits to the attacker: On the one hand, the valid key for the legitimate network can be obtained, therefore, if the location of that legitimate network is known or can be obtained through other methods, the attacker would be able to connect to it. On the other hand, the victim client will connect to the attacker's network regardless of where the attack is taking place.
• Finally, Wi-Fi network impersonation attacks focusing specifically on Wi-Fi Enterprise networks based on 802.1x/EAP can use various offensive methods to obtain the user enterprise credentials, and once again, even get full client connectivity between the victim and the attacker (in some scenarios). The following handmade draft table shows four different Wi-Fi enterprise client attacks, including their main pros and cons, FreeRADIUS-WPE, EAP LEAP-Down, EAP Dumb-Down, and LEAP2PEAP Relay:

• Once the network is shared at layer 1 & 2 (and above) between the attacker and the victim, traditional full Man-in-the-Middle (MiTM) attacks are possible, via ARP poisoning and other TCP/IP (and upper protocols and services) tricks.
• Besides attacking Wi-Fi clients using legitimate 802.11 traffic through a fake AP, it is possible to manipulate 802.11 frames to launch other types of attacks, such as Denail of Service (DoS) attacks affecting specific Wi-Fi chipsets, launch web-based injection attacks throughout 802.11 frames, or go deeper into the almost forgotten 802.11 driver attacks.
• Finally, understanding in detail these weaknesses and attacks, as well as the associated countermeasures and defensive opportunities and alternatives both at the user and the enterprise level, is the only way to properly mitigate the risk against these real-world Wi-Fi client attacks.

Some related contents are available on my RootedCON 2013 presentation, named "Wi-Fi: Why iOS (Android & others) Fail inexplicably" (video available in Spanish), and several presentations that followed and were part of a subsequent awareness campaign I did at the end of 2013 and early 2014.

How Can I Start Taking a Look At The Wi-Fi Client Activities Around Me?

As this introduction is mainly theoretical, for the curious readers that cannot wait until the publication of the next blog post in this series and want to start taking a look at the Wi-Fi client activities around them, and the potential disclosure of the PNL from vulnerable Wi-Fi clients, there are a few options, depending on the operating system you plan to use: Linux, OS X or Windows

In Linux you only need to have a Wi-Fi card that supports monitor (or RFMON) mode. Configure the card in monitor mode (via the "airmon-ng" command available in the aircrack-ng suite, or by directly using the "iw phy phy0 interface add mon0 type monitor" command), and start using Wireshark (or tshark from the command line) to capture the traffic from that specific Wi-Fi interface (commonly identified as "mon0").

In OS X you can follow similar steps when using the default 802.11 Airport Extreme Wi-Fi card. From the "Capture - Options..." menu in Wireshark, by double clicking on the Wi-Fi card (commonly identified as "en1"), the interface can be configured in monitor mode via the "Capture packets in monitor mode" option.

In Windows, although there have been significant constraints to put Wi-Fi cards in monitor mode in the past, thanks to Acrylic Wi-Fi you can configure its associated Wi-Fi driver in monitor mode for your built-in Wi-Fi card. By running Wireshark as Administrator, start capturing traffic from the Acrylic Wi-Fi driver, named with the prefix "Acrylic NDIS" followed by the name of your native Wi-Fi card in the "Capture Interfaces" windows in Wireshark (available from the "Capture -> Interfaces..." menu). If you want to use tshark instead from the command line, using a command promt (cmd.exe) running as Administrator, run "tshark.exe" with the "-D" option to identify all the network interfaces available. The Acrylic Wi-Fi driver associated to your card (in this case, ID number 3) will look like this:
...
3. \\.\airpcap11_{ABC...-...-...DEF}-{012...-...-...789}-0000 (Acrylic NDIS <your_Wi-Fi_card_name>)

If you are using Wireshark, your favorite display filter in order to capture the 802.11 probe request frames that may disclose specific names for the Wi-Fi networks contained in the PNL of vulnerable Wi-Fi clients should be:

(wlan.fc.type_subtype == 0x04) && !(wlan_mgt.ssid == "")

If you are using tshark from the command line, you can use the following command in order to extract some of the most relevant details from the same interesting 802.11 probe request frames:

(Linux, OS X & Windows; simply change the Wi-Fi interface name with the "-i" option)
C:\Temp>tshark -i 3 -n -l -s 0 -T fields -E separator=, -E quote=d -e wlan.sa -e
 radiotap.dbm_antsignal -e wlan_mgt.ssid -Y "wlan.fc.type_subtype == 4 and !(wla
n_mgt.ssid == \"\")"
or
$ sudo tshark -i mon0 ...

Shameless Plug - "Attacking Wi-Fi Clients: Hands-on Workshop"

I have authored a hands-on technical workshop, called "Attacking Wi-Fi Clients" (or "Técnicas de ataque sobre clientes Wi-Fi" in Spanish), with the goal of bringing together real-world personal experience, research, and pen-testing tips & tricks for Wi-Fi client attacks collected during the last few years. The workshop covers in-depth all the topics of the upcoming "Attacking Wi-Fi Clients" DinoSec blog post series (of which this is the first installment), and much more... The material is available in English and is delivered both in English or Spanish.

This workshop  focuses on providing the attendees real-world hands-on experience identifying and researching Wi-Fi clients weaknesses, and executing multiple Wi-Fi client attacks in different scenarios, with specific emphasis in the layer 2 802.11 and associated protocols, like 802.1x/EAP, versus more traditional TCP/IP client attacks. The attendees get their own Alfa Wi-Fi USB card (in particular the current best model identified for this kind of Wi-Fi client offensive activities) and leave the workshop with a fully functional virtual machine based environment ready for Wi-Fi pen-testing activities or deeper research and vulnerability discovery. At the end of the session, the defensive countermeasures required to mitigate the previously covered Wi-Fi attacks are also analyzed. The workshop is available in both a very intense one-day session (bootcamp style) or in a two-day extended format, that can be delivered in both security conferences and private onsite events (contact me if you are interested).

The first sold-out workshop session took place during the RootedCON trainings (called RootedLabs) on March 3, 2014, with very good feedback from the audience. Recently, the workshop has been significantly updated for an upcoming session that will take place in about three weeks during the NoConName (NcN) trainings (October 30, 2014). The NcN workshop price includes a conference ticket, so... if you are in Spain at the end of this month and speak Spanish, you cannot miss it! :-) My goal by offering this highly specialized but affordable workshop is focused on helping to improve the overall quality of Wi-Fi security pen-tests and assessments, and in particular, in identifying the current Wi-Fi clients risks and threats, while promoting future additional related Wi-Fi research in the upcoming Wi-Fi Internet of Everything (IoE) era (contributing to the health and wealth of the Spanish security conferences and local security community is an added value :-)

Image source: http://www.wi-fi.org/sites/default/files/images/IoE_Graphic.jpg
Image source: http://www.wi-fi.org/sites/default/files/images/Wi-Fi_Connect_your_life.jpg