Han pasado ya algunos años desde que el estándar 802.11i fue ratificado en Junio de 2004, y algunas cosas han cambiado desde aquel entonces, dando énfasis en la capacidad de computación de las máquinas. No obstante, sobre la misma línea, nada nuevo está presente en la autenticación WPA, que como ya sabemos se encuentra dividida en dos bloques:
- WPA Enterprise Authentication: donde se utiliza el estándar 802.1x y normalmente un servidor Radius para efectuar Authentication, Authorization y Accounting (AAA).
- WPA Personal Authentication: donde se emplea una passphrase precompartida por todos los integrantes de la red (similar a WEP).
En esta secuencia de artículos, primeramente veremos los fundamentos del ataque sobre la autenticación
PSK (Pre Shared Key), también conocida como autenticación "Personal", y posteriormente lo pondremos en práctica sobre el
Cloud de
NIMBIX y de
Amazon para extraer nuestras propias conclusiones.
Partiendo de la base de tener en posesión un
handshake, sólo nos queda por dar una pequeña pincelada a la generación de la PTK
(Pairwise Transient Key):
(http://hacking-etico.com/wp-content/uploads/2016/05/Diagrama-generaci%C3%B3n-PTK-300x99.jpg) (http://hacking-etico.com/wp-content/uploads/2016/05/Diagrama-generaci%C3%B3n-PTK.jpg)
Como podemos ver, la clave precompartida, denominada
passphrase, se pasa a una función conocida como PBKDF2, utilizada en PKCS#5, conjuntamente con los siguientes parámetros:
- El SSID y su longitud.
- El número de iteraciones a realizar, 4096.
- La longitud de la clave resultante, 256.
El resultado de esta función es la conocida PSK, que según la sección 5.9.2.2 del estándar 802.11i, cuando se trata de un sistema de autenticación
Personal, la PMK
(Pairwise Master Key) es equivalente a ésta. Posteriormente, a la PMK y al resto de atributos se les aplica un algoritmo de
hash denominado HMAC-SHA1, el cual genera un conjunto de
bits, conocido como PTK, que en CCMP (WPA2) tiene una longitud de 384
bits, mientras que en TKIP (WPA) una longitud de 512
bits. La PTK se divide en subclaves, donde cada una realiza una tarea específica en el proceso de establecer el cifrado de la información.
Cuando capturamos un
handshake, la única parte que no podemos obtener es la PMK, por el hecho que no se transmite y que no somos capaces de generarla sin el conocimiento de la
passphrase. No obstante, sí que resulta factible el conocimiento del resto de valores, los conocidos
ANonce y
SNonce, y las direcciones MAC del punto de acceso y la estación cliente.
Veamos la secuencia de intercambio de mensajes que se produce en el
handshake de forma gráfica:
(http://hacking-etico.com/wp-content/uploads/2016/05/Diagrama-4-Way-Handshake-294x300.jpg) (http://hacking-etico.com/wp-content/uploads/2016/05/Diagrama-4-Way-Handshake.jpg)
Y ahora, veamos la misma secuencia interpretada por
wireshark:
(http://hacking-etico.com/wp-content/uploads/2016/05/4-Way-Handshake-Wireshark-300x134.png) (http://hacking-etico.com/wp-content/uploads/2016/05/4-Way-Handshake-Wireshark.png)
En realidad, los valores
ANonce y
SNonce que se intercambian en el primer y el segundo mensaje, no son nada más que un par de números aleatorios generados por el punto de acceso y la estación cliente, respectivamente, los cuales permiten la generación de claves PTK de forma temporal, es decir, que para un mismo cliente y un mismo punto de acceso, con exactamente la misma configuración de SSID y
passphrase, en cada nueva conexión se derivará una PTK completamente diferente. Este hecho significa que, teóricamente, no podemos descifrar las tramas de una sesión en particular aunque tengamos en posesión la
passphrase correcta.
Por otro lado, en la imagen, observamos remarcado en rojo el campo "WPA Key MIC", un valor que es esencial para el ataque. Se trata de un resultado derivado de los primeros 0-128
bits de la clave PTK, los cuales representan una de las subclaves que hemos comentado anteriormente, conocida con el nombre de KCK
(Key Confirmation Key). Este valor es utilizado por el punto de acceso para comprobar que la estación cliente tiene en posesión la
passphrase correcta y, para realizar esta comprobación, simplemente verifica que el valor de ese campo sea igual al que es capaz de generar él mismo.
De esta forma, la esencia de todo el proceso del ataque a la clave PSK, queda representada por la siguiente imagen:
(http://hacking-etico.com/wp-content/uploads/2016/05/Diagrama-generaci%C3%B3n-PTK-MIC-Dict-300x112.png) (http://hacking-etico.com/wp-content/uploads/2016/05/Diagrama-generaci%C3%B3n-PTK-MIC-Dict.png)
Como vemos, se ha substituido el valor inicial de
Passphrase por
Dictionary, del cual se extraerán una por una las distintas palabras que contenga para posteriormente generar las PSKs a través la función PBKDF2. Además, en la imagen también se ha añadido la comprobación final del valor MIC, que es necesaria para detectar la
passphrase correcta, es decir, la frase de paso precompartida por todos los integrantes de la red.
Pero, en la ilustración anterior tenemos un problema, ¿Lo detectáis?
Se trata del valor de iteración 4096, que significa que para un millón de
passphrases contenidas en el diccionario, se realizarán un total de 4.096 millones de iteraciones en la función PBKDF2, con lo cual se obtendrá un escaso rendimiento en el procesamiento de las mismas. De hecho, este inconveniente se detecta fácilmente cuando aplicamos
Aircrack-ng:
(http://hacking-etico.com/wp-content/uploads/2016/05/Aircrack-ng-lentitud-300x117.png) (http://hacking-etico.com/wp-content/uploads/2016/05/Aircrack-ng-lentitud.png)
Notamos que para una contraseña de 10 caracteres compuesta por mayúsculas y números, a la velocidad de 836 claves/segundo, se necesitan 143.000 años para comprobar todas las posibles combinaciones, una auténtica barbaridad. El motivo por el cual obtenemos este bajo rendimiento en gran parte es debido al cálculo derivado la función PBKDF2.
Por lo tanto, en este escenario debemos buscar alternativas, las cuales, principalmente, se centran en:
- Mejorar el rendimiento de Keys/s.
- Aplicar un ataque de diccionario dirigido.
La generación de un diccionario dirigido quedará pendiente, ya que en el siguiente
post, nos centraremos en cómo mejorar el rendimiento de cómputo de claves aprovechando la gran potencia que podemos obtener de los servicios de computación del
Cloud.
Este segundo artículo, de carácter más práctico, define el conjunto de herramientas a utilizar y además, se ha esquematizado para que sea un pequeño tutorial que nos permita efectuar la instalación de las mismas en las máquinas del
Cloud.
Para los lectores que no desean conocer en profundidad los detalles técnicos, se recomienda obviar esta parte y saltar directamente a la tercera.
Empecemos.
Primeramente, necesitamos localizar un herramienta que sea capaz de utilizar toda la potencia de cómputo de nuestro
hardware con el fin de cumplir con nuestro objetivo, que es calcular el mayor número posible de claves PSK por segundo, tal y como hemos comentado en la primera entrega. Para lograr la tarea, se propone la utilización de
Pyrit.
PyritEs una herramienta muy potente que permite realizar ataques a la autenticación WPA/WPA2-PSK. Destaca por tener la propiedad, a diferencia de otras herramientas, de utilizar la potencia extra de las GPUs para acelerar de forma extraordinaria el proceso de cómputo de las claves PSK. Se encuentra escrita mayormente en Python, pero también cuenta con algunos módulos escritos en C
(cpyrit-cuda, cpyrit-opencl) que se encargan de permitir el uso de las tarjetas gráficas. Además, entre otras funcionalidades, nos brinda la posibilidad de crear tablas de claves PSK precomputadas.
Por otro lado, necesitamos un
software intermediario que permita la interacción con las tarjetas gráficas. En este caso, se trabajará con CUDA
Toolkit.
CUDACUDA son las siglas de
Compute Unified Device Architecture (en Castellano, Arquitectura Unificada de Dispositivos de Cómputo) y hace referencia a un
framework desarrollado por NVIDIA que permite a los programadores de C y C++ aprovechar la potencia del procesamiento paralelo de sus tarjetas gráficas, con el fin de proporcionar un incremento del rendimiento del sistema.
Con las dos herramientas anteriores y conjuntamente con el
Cloud, ya tenemos todos los componentes necesarios. Sólo nos queda realizar la instalación de este
software a una máquina remota y en el caso del panel de
NIMBIX, la secuencia de pasos a realizar es la siguiente:
1) Creamos una instancia de
Ubuntu 14.04 dentro de la pestaña
Images:
(http://hacking-etico.com/wp-content/uploads/2016/05/001-Create-Image-300x145.png) (http://hacking-etico.com/wp-content/uploads/2016/05/001-Create-Image.png)
2) A continuación, nos vamos a la pestaña
Launch y ejecutamos una máquina que cumpla con nuestras expectativas de
hardware, en este caso, una instancia de
dual NVIDIA M2090:
(http://hacking-etico.com/wp-content/uploads/2016/05/002-Launch-300x238.png) (http://hacking-etico.com/wp-content/uploads/2016/05/002-Launch.png)
3) Nos dirigimos a
Dashboard para ver los parámetros de conexión de la máquina, y establecemos una sesión SSH:
(http://hacking-etico.com/wp-content/uploads/2016/05/003-Conexion-300x117.png) (http://hacking-etico.com/wp-content/uploads/2016/05/003-Conexion.png)
4) Procedemos a la instalación de CUDA
Toolkit mediante la guía de instalación que nos ofrece el propio desarrollador NVIDIA, disponible en este enlace (http://docs.nvidia.com/cuda/cuda-getting-started-guide-for-linux/).
Como podemos pensar, para poder operar con CUDA, debe existir el controlador de NVIDIA apropiado para el
kernel que se encuentra compilado en el sistema. Normalmente, las plataformas de
Cloud ya nos proporcionan esta utilidad, la cual podemos comprobar con las sentencias indicadas en la guía (las dos últimas de la imagen):
(http://hacking-etico.com/wp-content/uploads/2016/05/004-Check-Driver-297x300.png) (http://hacking-etico.com/wp-content/uploads/2016/05/004-Check-Driver.png)
Seguimos con la descarga de la versión de CUDA correspondiente a nuestra máquina:
(http://hacking-etico.com/wp-content/uploads/2016/05/005-Download-CUDA-300x236.png) (http://hacking-etico.com/wp-content/uploads/2016/05/005-Download-CUDA.png)
Recordad que es posible utilizar directamente el comando
wget sobre el enlace de
Download para realizar la descarga sobre la máquina del
Cloud. Una vez descargado el ejecutable, realizamos la instalación y obtendremos una salida similar a la siguiente:
(http://hacking-etico.com/wp-content/uploads/2016/05/006-CUDA-Installed-300x117.png) (http://hacking-etico.com/wp-content/uploads/2016/05/006-CUDA-Installed.png)
Finalmente, realizamos el último paso de la instalación de CUDA, que es la modificación de las variables de entorno PATH y LD_LIBRARY_PATH, y posteriormente verificamos la versión de CUDA
Toolkit que se encuentra instalada en el sistema:
(http://hacking-etico.com/wp-content/uploads/2016/05/007-Check-CUDA-Toolkit-300x62.png) (http://hacking-etico.com/wp-content/uploads/2016/05/007-Check-CUDA-Toolkit.png)
5) Una vez instalado CUDA, es el turno de
Pyrit. Empezamos con él instalando las dependencias:
sudo apt-get install libpcap-dev subversion python-dev libssl-devSeguidamente, realizamos la descarga del código fuente:
sudo svn checkout http://pyrit.googlecode.com/svn/trunk/ pyritPara, a continuación, efectuar su instalación:
cd pyrit/pyritsudo python setup.py installEn este instante,
Pyrit debe ser capaz de listar las CPU disponibles:
(http://hacking-etico.com/wp-content/uploads/2016/05/008-pyrit-list_cores-280x300.png) (http://hacking-etico.com/wp-content/uploads/2016/05/008-pyrit-list_cores.png)
Notamos que no detecta las tarjetas gráficas, debido a que aún no hemos instalado el módulo
cpyrit:
cd ../cpyrit_cuda/sudo python setup.py installUna vez hecho, si volvemos a efectuar un listado de los
cores disponibles,
pyrit ya detecta las tarjetas de NVIDIA:
(http://hacking-etico.com/wp-content/uploads/2016/05/009-pyrit-list_cores-with-GPU-300x95.png) (http://hacking-etico.com/wp-content/uploads/2016/05/009-pyrit-list_cores-with-GPU.png)
Finalmente, procedemos a lanzar una estimación de la capacidad de cómputo del
hardware disponible:
(http://hacking-etico.com/wp-content/uploads/2016/05/010-pyrit-benchmark-300x143.png) (http://hacking-etico.com/wp-content/uploads/2016/05/010-pyrit-benchmark.png)
En este caso, tal y como se puede observar en la imagen, sobre la configuración de nuestra máquina de
NIMBIX, se ha obtenido un rendimiento total de 66324 PMKs por segundo, una diferencia importante respecto las 836 claves/s que
Aircrack-ng ofrecía sobre una simple máquina virtual.
Como último paso de configuración, sólo nos queda la instalación de la herramienta
Scapy, la cual
Pyrit utiliza para el procesamiento de los paquetes de las capturas:
wget http://www.secdev.org/projects/scapy/files/scapy-2.3.1.zipunzip scapy-2.3.1.zipcd scapy-2.3.1/sudo python setup.py installEn este instante, ya tenemos el escenario preparado y por lo tanto, en el siguiente artículo lanzaremos su ejecución para analizar los resultados obtenidos, con la diferencia que la máquina de trabajo no será de
NIMBIX, sino que será una máquina del
Cloud de
Amazon, simplemente por el hecho de que sus instancias
g2.8xlarge nos ofrecen 4 GPUs en lugar de las 2 que subministran las de
NIMBIX.
Espero que haya sido de vuestro agrado.
¡Saludos!
Autor: Ferran Verdés
Fuente: hacking-etico
Muy buen aporte Stiuvert, gracias por compartir.
Realmente creo que la la computacion en la nube terminara dandole un giro a la seguridad de las redes WPA ya que a medida que vamos avanzando tendremos mas poder de procesamiento por cada vez menos dinero. Recientemente estoy escribiendo algo sobre los contenedores Docker y es una barbaridad las cosas que se pueden hacer.
E teoria seria posible hacer ataques por diccionario de forma fragmentada, creando varias instancias y pasandole a todas el handshake con la diferencia de que segmentamos el diccionario para cada instancia. Y con los buenos precios de AmazonWebService podriamos conseguir por 2 dolares la hora una instancia con 22Gb de RAM, 33.5 EC2 (2 x Intel Xeon X5570, quad-core "Nehalem"), y 2 NVIDIA Tesla "Fermi" M2050 GPUs.
Es decir que por 8 dolares la hora podriamos tener 4 instancias buscando hashes hasta dar con el valido.
Muy interesante todo esto..!!
Gracias por tu respuesta Cl0ud.
Es cierto, además no estamos muy lejos de adquirir ese hardware en nuestros PCs de hogar.
Saludos