Black Hat Europa 1 day briefings (II)

Continuando con la crónica de la BH Europa, un magistral Christopher Tarnovsky vino a presentarnos Hacking Smartcards, un trabajo de más de seis meses que ha comenzado a dar sus frutos durante este último mes y que ha expuesto en exclusiva para la Black Hat.

Para que todos nos hagamos una idea sobre que ha versado su trabajo o su impacto, comentar que en nuestra vida diaria vivimos con Smartcarts: monederos electrónicos, gestiones bancarias, soporte para albergar el certificado del DNI-e. Una Smartcard era uno de los dispositivos más seguros y donde fabricantes de tarjetas y entidades bancarias depositaban su confianza. Pues bien, este “monstruo” pensó lo que es obvio, en algún punto de la circuitería interna del chip existe un bus de datos donde la información viaja en claro antes de pasar al módulo de cifrado. Esta frase, que resulta muy fácil decir, es una tarea faraónica dado los millones y millones de transistores, puertas lógicas y buses que puede tener el integrado.

En el mundo existen prácticamente 3 fabricantes de estos tipos de tarjetas que implementan una unidad de proceso 6805 (ST), 8051 (NXP) o AVR (ATMEL). Su estudio ha sido orientado al fabricante INFINEON, aunque como él comentaba el ataque puede ser extendido a otros modelos. Las fases que ha seguido Christopher para llevar a cabo el Hack son:

[Read more…]

Black Hat Europa 1 day briefings

Como era de esperar una de las conferencias de seguridad más importantes del mundo, la Black Hat, no ha defraudado en su vertiente europea. Un gran escenario, el Palau de Congresos de Catalunya, ha servido de perfecto telón de fondo para albergar a la crème de la crème de los profesionales de la seguridad mundial, es por eso que S2 Grupo no podía faltar. Nada más llegar, un dato aportado por la organización resulta a un servidor sensiblemente preocupante, la distribución de asistentes por países refleja un escaso interés por parte del auditorio español (empresas, entidades públicas, I+D) haci las seguridad y la protección de la información. Con una participación entorno a 500 personas, tan solo 28 españoles constaban como inscritos. Por el contrario colegas de la profesión con un importante número de horas de vuelo a sus espaldas el día anterior, como Estados Unidos, aportaban 58 asistentes. Vietnam, la India, Alemania, Argentina, Francia o Rusia hacían presencia de forma significativa.

El evento fue en su primer día inaugurado por Max Kelly, máximo responsable de seguridad del bien conocido portal social Facebook. Éste introdujo los valores de seguridad que son aplicados en su política y que muchos de nosotros en nuestras organizaciones deberíamos seguir. En primera instancia, según palabras de Max, Facebook persigue mediante su equipo legal a todo aquel atacante o intruso que realice acciones ilícitas contra sus sistemas, mediante la CAN-SPAM (15 USC 7701), Computer Security Fraud And Abuse Act (18 USC 1030) y evidentemente los Facebook’s Rights and Responsabilities. Para dar soporte a acciones técnicas se apoyan en la comunidad mundial de la seguridad White-Hats, analizando los ataques recibidos con el objetivo de conocer a tu enemigo. Por último hubo una frase de su presentación que debe incitar a la reflexión colectiva: Compliance isn’t security. Ahí queda eso.

Como entrantes, Joe Grand, presentador del programa de televisión de Discovery Channel Prototype This, presentó la charla Hardware is the new Software. Mientras los pentesters normalmente suelen dirigir sus acciones contra aplicaciones, servidores de correo o páginas web, el hardware es el gran olvidado. Joe comentó que hoy en día la preocupación por la seguridad a este nivel sigue avanzando en menor medida que la relativa al software, pudiendo comprometer los dispositivos mediante simples tipos de ataques que siguen funcionando desde hace años. Esto es debido a la escasa preparación en materias de seguridad de los diseñadores de hardware. Pero, ¿cómo adentrarse en este mundo? Entre otras, sugirió dos paginas donde fundamentalmente se puede adquirir material para ello, www.adafruit.com y www.makershed.com. Es necesario básicamente: ChipQuickSMD (kit de eliminación limpia de integrados), Picoscope (osciloscopio software), microscopio y un soldador claro.

[Read more…]

I Encuentro Internacional CIIP: Taller de Gestión de Incidentes

Como ya hemos comentado en anteriores entradas, el pasado 18 de febrero S2 Grupo estuvo presente en el 1er Encuentro Internacional CIIP para la Ciberseguridad y Protección de Infraestructuras Críticas, organizado por el CNPIC, Centro Nacional para la Protección de las Infraestructuras Críticas.

Como parte de la agenda participé en el Taller “Gestión de Incidentes y Sistemas de detección preventiva / alerta temprana”, orientado a la implantación de las medidas de detección y alerta de incidentes, que permitan monitorizar toda aquella actividad TIC ilícita que pueda suponer un riesgo para las infraestructuras críticas. Al respecto, he de expresar mi descontento con la manera en que se enfocó el taller, compartido por la mayoría de presentes, ya que consistió principalmente en la presentación de un producto comercial, algo para lo cual existen lugares y oportunidades mejores. Esto provocó que el contenido «útil» del taller fuese muy inferior al de otros talleres.

En cualquier caso, uno de los aspectos más interesantes del taller residió en el análisis de la capacidad de las organizaciones para establecer un sistema o motor de correlación que permita aplicar una lógica avanzada a los flujos de información que tienen como origen los agentes de monitorización desplegados. En algunas ocasiones una entidad puede implantar sistemas de monitorización de intrusos, agentes de control de la disponibilidad de los servicios TIC o incluso herramientas de detección de vulnerabilidades, pero, ¿cómo poder obtener información que aporte un mayor valor de los datos cruzados de las diferentes sondas? Aquí es donde entra en acción el motor de correlación. Imaginemos una situación donde un agente de control de autenticación a nivel del SO detecta un acceso de un usuario A, pero no tenemos constancia de que el sistema de control de accesos físico o de acceso por red privada virtual haya detectado una entrada de A o una conexión remota. En este momento el motor de correlación podría deducir que existe, un robo o cesión de las credenciales de acceso al sistema o que simplemente el usuario A no ha pasado por el control de acceso físico, lo ha burlado.

Situaciones como la anterior otorgan un gran potencial a la correlación de eventos; tan sólo hay que identificar que agentes se tienen desplegados y echarle un poco de imaginación para establecer las reglas de correlación que deseemos. Por último, qué duda cabe que la información procesada por el motor de correlación debe tener como output un sistema de alertas capaz de trazar en todo momento el estado de la incidencia, permitiendo consultar toda aquella información aportada por las sondas de seguridad y que permita al gestor de incidentes aplicar las medias de actuación pertinentes.

Hacking RFID, rompiendo la seguridad de Mifare (II)

Tras introducir el pasado viernes algunos aspectos teóricos relevantes de RFID, en esta segunda parte entraremos en cuestiones prácticas que nos darán resultados muy interesantes.

Comencemos profundizando un poco más en como Mifare realiza el proceso de autenticación. En primera instancia el lector le comunica a la tarjeta que quiere realizar una operación sobre un sector de datos determinado N. El tag o tarjeta en ese momento remite un número aleatorio Nc (Nonce del cliente) de 32 bits a modo de reto, para que sea cifrado con la clave privada compartida previamente. Como respuesta, el lector remite el reto cifrado y un número aleatorio Nr (Nonce del lector) para que el tag lo cifre con la clave privada, generando una trama de 64 bits. En última instancia la tarjeta le envía al lector su reto cifrado. En este momento ambos tienen la certeza de que los dispositivos son legítimos. Destacar que los dos últimos intercambios se realizan ya de forma cifrada, permaneciendo en claro tan solo el envío de la petición de lectura y Nc. La figura de la izquerda ilustra el proceso de handshake.

Este proceso de saludo a 4 bandas es importante ya que de él extraeremos la información necesaria para inferir la clave privada del sector.

Procedamos ahora a realizar una prueba de concepto que nos permitirá, a partir de la captura de la información anterior, inferir la clave privada. Pero, ¿cómo podemos capturar una comunicación real entre un tag y un lector? Aquí es donde juega un papel importante el PROXMARK III. Este dispositivo desarrollado por Jonathan Westhues permite realizar sniffing de varias tecnologías RFID desde baja frecuencia (LF 125 Khz) a alta frecuencia HF (13.56 Mhz) y entre ellas la que nos interesa ISO14443 tipo A sobre la que se basa Mifare. En un principio el PROXMARK III supondría el Hardware sobre el cual se pueden implementar diversas capas físicas y de enlace, de diferentes protocolos, simplemente programando sus integrados con la especificación que se requiera.

[Read more…]

Hacking RFID, rompiendo la seguridad de Mifare (I)

(Actualización: Ya tenemos el Esquema Nacional de Seguridad y el Esquema Nacional de Interoperabilidad aquí, recién salidos del horno. Real Decreto 3/2010 y 4/2010, respectivamente. Véase la página del BOE del 29 de enero para acceder a los PDFs)

En este post y los siguientes de la serie vamos a ver cómo conseguir romper la seguridad de las tarjetas de proximidad RFID basadas en tecnología Mifare. Ello conllevará la lectura y modificación interna de sus datos e incluso el clonado de las mismas.

La tecnología RFID (Identificación Mediante Radio Frecuencia), conforma, hoy en día, una solución extensamente utilizada en sistemas de pago en transportes públicos, controles de acceso a edificios u oficinas, pasaportes, monederos electrónicos o sistemas de control de encendido en automóviles entre otras aplicaciones. Existen diversas soluciones como Mifare, Keeloq o RFID EM4102, que permiten al portador interactuar de forma inalámbrica con los sistemas desplegados. La seguridad de este tipo de tecnologías presenta deficiencias que pueden permitir a usuarios malintencionados realizar acciones ilícitas como fraude en sistemas de pago, bypass del sistema de encendido de automóviles, suplantar la identidad de personas o acceder a áreas de acceso restringido, entre otras cosas.

[Read more…]

WWW. Una ventana al mundo, una ventana para los intrusos

A menudo las organizaciones securizan su dominio protegible implantando una serie de controles tecnológicos que permiten impedir o en todo caso minimizar el impacto de actividades ilícitas por parte de terceras personal, o incluso las realizadas por el propio personal corporativo. Instalación de cortafuegos perimetrales, software de detección y eliminación de malware, proxys, sistemas de detección de intrusos y un largo etcétera, serían algunas de las medidas empleadas.

En este momento el responsable de TI de la organización siente una falsa sensación de seguridad, ya que descuida, entre otras cosas, las posibles vulnerabilidades latentes en el software de los servicios de DMZ. Normalmente estos servicios perimetrales (servidores de correo, DNS…) se sustentan en software de amplia distribución y con un soporte de actualizaciones de seguridad pero, ¿qué ocurre con la pagina web corporativa? Estos sites que ofrecen la imagen y la marca de la organización al resto del mundo son desarrollados de forma personalizada, sin un soporte, muchas veces, de actualizaciones de seguridad. Si quieres que corrija estos errores, paga el esfuerzo que requiere ese desarrollo adicional. Sí, esta frase es bastante común, dado que este tipo de situaciones no se contemplaron en el alcance del proyecto, ni se requirió que el desarrollo siguiera un marco de trabajo de desarrollo seguro.

En bastantes de las auditorias y test de intrusión de aplicativos web que S2 Grupo ha realizado, no sólo se obtuvo el control del site auditado (acceso a insertar modificar o eliminar el contenido de la web), sino que se pudo obtener numerosa información confidencial (credenciales de acceso a zonas privadas, números de cuenta bancarias, cuantas de correo electrónico, documentos confidenciales de la organización…), sin comentar la posibilidad de realizar ataques de phishing y robo de sesiones. Todo ello tan sólo a través de la página web de la corporación, esa ventana al mundo accesible desde el sitio más recóndito del planeta.

Para hacerse una idea de los potenciales puntos de entrada que un intruso tendría a través de la web basta con tener en cuenta el conjunto de parámetros POST y GET de los posibles recursos dinámicos (jsp, asp, php, cgi’s…), así como cookies o cualquier otro tipo de información que sea enviada desde el cliente para que el servidor la procese. En un site de tamaño medio donde su funcionalidad sea informativa y presente una zona privada, el total de puntos de entrada del atacante es inmenso.

He aquí el papel relevante que juega la seguridad en este tipo de servicios, y que en general se tiene totalmente descuidados. Pero, ¿cómo es posible mitigar estos riesgos? Pues aplicando principalmente dos estrategias:

  • Usar un Framework de desarrollo seguro que se integre en el ciclo de vida de desarrollo del software.
  • Realizar auditorias de seguridad, preferiblemente con test de penetración, cuyo alcance abarque tanto el análisis de las vulnerabilidades de la web como los permisos de la base de datos que la sustenta (en caso de que use, claro). Este último punto es de vital importancia porque en numerosas ocasiones los permisos del usuario de la BD que la aplicación utiliza son inadecuados, permitiendo obtener información que no tendría porqué ser accesible. Recordar que siempre hay que aplicar la máxima del mínimo privilegio.

A todo esto cabe añadir que las aplicaciones en general tienden cada vez mas a desplegar su interfaz gráfico hacia la web, e incluso programas típicos de edición de texto como Microsoft Word tienen sus homólogos en la web (ver Google Docs). Dado el auge de esta tendencia y la escasa preocupación por la seguridad de estos servicios, nos lleva hacia un panorama desolador e inseguro, haciendo necesaria la aplicación de controles preventivos y reactivos, que mitiguen estas amenazas para las organizaciones y usuarios particulares.

Pero, ¿quién tiene la responsabilidad de que estos fallos permitan al intruso acceder a la información confidencial? Indudablemente para mí, el programador web, que a menudo es contratado sin experiencia, no solo en seguridad sino en cuanto a skill de programación se refiere, por empresas que lo único que quieren es obtener un producto en poco tiempo, bonito y que cumpla las especificaciones requeridas por el cliente; preocupándose por la funcionalidad y descuidado el rendimiento y la seguridad de su plataforma. ¿Sería conveniente aplicar algún tipo de castigo? Una de las medidas que el equipo de auditoria del ACE Team de Microsoft aplica sobre sus proyectos de desarrollo es penalizar a los jefes de proyecto y programadores que desarrollen de forma insegura, reduciendo el presupuesto de sus proyectos según el número y grado de vulnerabilidades encontradas. Sería una opción a considerar.

Al respecto, y en la línea de lo comentado, la encuesta de esta semana es la siguiente:

[poll id=»10″]

* * *

(N.d.E.) En relación con la encuesta anterior, cuyo resultado les muestro debajo, ha quedado claro (siempre teniendo en cuenta el ámbito en el que nos movemos y el público de este blog) que en general, la preocupación por los datos gestionados por las (empresas propietarias de las) redes sociales es legítima y compartida por gran parte de nuestros lectores.

[poll id=»8″]

In-session Phishing

insession.jpgRecientemente ha sido publicado un nuevo vector de ataque de phishing de mayor complejidad que el clásico envío masivo de correos electrónicos, y que podría permitir el robo de credenciales en aplicaciones bancarias, juegos-online, etc. El denominado In-session Phishing se vale de una vulnerabilidad en la mayoría de los navegadores web: Internet Explorer, Firefox, Safari, o Chrome, al hacer uso de ciertas funciones javascript.

Para explotar con éxito este fallo de seguridad es necesario que se den las dos situaciones siguientes:

1. El usuario este autenticado en la aplicación objetivo del robo de credenciales.
2. Un segundo site que alberga cierto código malicioso es visitado por el usuario, mientras en la web objetivo se esta todavía autenticado.

Al parecer el navegador procede a albergar una huella cuando una página web que utiliza ciertas funciones javascript es visitada, funciones muy habituales según sus descubridores, Trusteer. De esta manera es posible desde una segunda página interrogar al cliente con preguntas binarias sobre si se está o no autenticado en un cierto dominio. Si la respuesta es afirmativa, el código malicioso presenta un sencillo pop-up que informa al usuario sobre una falsa caducidad de la sesión y la necesidad de reautenticarse en la aplicación. En ese momento el usuario no percibe ningún comportamiento extraño puesto que hasta el momento confía en que estaba registrado en un site totalmente lícito.

[Read more…]

Ofuscación de la barra de estado en Firefox 3.0.5 / Clickjacking PoC

Pueden comprobar, si miran el código fuente de la prueba de concepto (adjunta debajo), que el enlace del «a href» efectivamente apunta a Google, y que por tanto, al pasar sobre el enlace, la barra de estado muestra la dirección de Google. Tengan cuidado con estas cosas.

https://www.securityartwork.es/PoC_clickjacking.html

El precio de los sentidos

Estas navidades fui obsequiado con una flamante sudadera azul con un inmenso logotipo en letras blancas que anunciaba Nike just do it! Me parece que no es necesaria una descripción más detallada puesto que todos tenemos en mente el popular icono de esta marca deportiva.

Tras la abundante pitanza de la cena y enfundado en mi nueva prenda me dispuse a abrir el Pub de la plaza del pueblo, bar que junto con mi primo con gran ilusión compramos hace ya algunos años. Subí con gran esfuerzo la persiana oxidada del local golpeándome súbitamente un olor, como diría yo… un olor así como a mueble-bar antiguo, ya sabéis, esa puerta de obertura horizontal que nuestros abuelos tenían en el salón de casa y que siendo niño no te dejaban abrir. Tres botes de ambientador en spray solucionaron el problema, así mucho mejor.

Me dirigí al fondo del local donde tengo, en el privado, una caja de herramientas. Sacando un gran martillo y un par de enormes clavos me dispuse a colocar en la pared el cuadro que me amiga Silvia me había pintado y que desde hacia tiempo le había prometido que colocaría a la entrada. Precioso quedó arriba de las butacas de raso, y es que esta chica tenía casi tanto talento como el mismísimo Picasso.

Iba siendo hora ya de comenzar a crear ambiente, así que puse uno de los últimos discos que había adquirido y de un par de brincos me metí detrás de la barra. En ese preciso instante una voz grave desde la puerta dijo:

—Buenas Noches.
—Buenas noches —contesté yo— ¿Qué desea?
—Mire, represento a la Sociedad General de Autores Gráficos, SGAG y venia a reclamarle el canon visual por su sudadera y… ¡ese cuadro que tiene en la pared!
—Canon visual, ¿usted está loco?, ¿qué quiere decir con canon visual? —respondí enérgicamente.
—Sí mire, ya que usted tiene una obra creada por un autor de nuestra sociedad, este debería percibir una modesta parte de sus ingresos debido a que todo cliente de su local puede disfrutar visualmente de su sudadera o de su flamante cuadro. Así que debe pagar 300 euros mensuales si quiere exhibir públicamente esos objetos.
—Pero bueno, esta usted en sus cabales, quiere decir que ¿tengo que pagar por ponerme una prenda que he comprado o un cuadro que me han regalado?
—Sí —contestó el cuervo negro.
—¡Márchese ahora mismo de mi local y no vuelva por aquí!

canon.jpg

Madre mía, ¿había enloquecido este hombre pasto de los polvorones navideños? Cuando todavía no me había repuesto de semejantes barbaridades, oí nuevamente una voz estridente que decía:

—Buenas Noches.
—Buenas noches —contesté yo. Era un tipo bajito con un maletín negro de piel. —¿Qué desea?
—Mire, represento a la Sociedad General de Autores de Perfumes, SGAP y venia a reclamarle el canon aromático por el ambientador que utiliza.
—¡¿Canon aromático?! —¡Madre mía! parece que el especial de “Mira quien baila» navideño ha hecho bastante daño este año.
—¿Qué quiere decir con canon aromático? —respondí desconcertado.
—Sí mire, ya que usted utiliza un ambientador con derechos de autor, nuestra sociedad debería percibir una modesta parte de sus ingresos, debido a que todo cliente de su local puede disfrutar olfativamente de su fragancia y su persona se esta lucrando haciendo uso de ella. Así que debe pagar 300 euros mensuales si quiere dispersar públicamente su ambientador.
—Joder, el mundo esta lleno de tarados, ¡me está diciendo que tengo que pagar por que mis clientes huelan mi spray perfumado!
—Efectivamente —contestó la pequeña alimaña.
—Lárguese de aquí enseguida antes de que le eche a patadas.

Dios mío, salió más rápido que el anterior. No daba crédito a lo que me estaba sucediendo; parece ser que la gente se estaba buscando la vida de forma un tanto extraña últimamente, pero a mi no me iban a engañar.

—Buenas Noches. —Madre mía, ¿quien será ahora?, pensé.
—Mire, represento a la Sociedad General de Autores y Editores, SGAE y venia a reclamarle el canon de derechos de autor por toda la música que usted tiene en el local y de la cual se esta lucrando al emitirla a sus clientes.

Reflexiones navideñas…

¿Romper WPA/WPA2 con GPUs? ¡Chorradas y más chorradas!

En primer lugar, decir que es desalentador el tono con el que algunos lectores de este blog hacen llegar sus comentarios. Les insto a que moderen sus formas ya que este pretende ser un foro de discusión técnica, donde argumentos y datos se superpongan a insultos y ofensas, que no tienen cabida. Dicho esto, me gustaría contestar uno a uno los comentarios realizados durante este fin de semana sobre el post de seguridad WPA anterior que ha aparecido recientemente en menéame.net.

Por lo que respecta al usuario Anónimo que afirma que el cálculo ha sido realizado para el caso peor, es decir aquel en el que la “Primary Master Key» (PMK) se encuentra al final de nuestro diccionario, estoy totalmente de acuerdo: se debería considerar el caso medio. Los cálculos reflejan el coste de computar las “Rainbow Tables» (tablas hash precomputadas) para un ESSID y una PSK concreta, obteniendo un ratio mas desalentador (300 p/s) del propuesto inicialmente en el post (400 p/s, y ya dije que fui benévolo) según el estudio realizado en el proyecto final de carrera adjunto [Seguridad en Redes 802.11, PDF, 5MB]. Para ello se compararon los dos algoritmos que actualmente pueden realizar ataques de fuerza bruta a WPA/WPA2: Cowpatty y Aircrack-ng, utilizando para ello diversos procesadores.

Los resultados obtenidos fueron que en un Intel 3 Ghz Core Duo se llegaron a computar un ratio máximo de 300 palabras por segundo, por lo que recalculando tendríamos que para el caso medio, utilizando un alfabeto de 100 caracteres (mayúsculas, minúsculas, números y símbolos) y una PSK de 8 caracteres, un espectro de (100)^8 = 10.000.000.000.000.000 posibles palabras del lenguaje. Multiplicando por 100 la capacidad de cálculo anteriormente comentada (300 palabras/seg.), según dice el fabricante del software:

“With the latest version of Elcomsoft Distributed Password Recovery, it is now possible to crack WPA and WPA2 protection on Wi-Fi networks up to 100 times quicker with the use of massively parallel computational power of the newest NVIDIA chips. Elcomsoft Distributed Password Recovery only needs a few packets intercepted (with any network sniffer that can export data in tcpdump format) in order to perform the attack.» [Referencia]

tardaríamos 10569,930661255 años en el peor de los casos y 5284,965330627 años en el caso medio. Como se puede ver los resultados todavía son mas desalentadores que los comentados en el post inicial.

Ahora supongamos que tenemos una granja de 1000 tarjetas NVIDIA GFORCE y que dividimos el espacio de palabras a calcular repartido en todas ellas. Se tardaría 10,5 años en el peor de los casos y 5,2 años en el caso medio, lo que parece acercarse a valores temporales manejables. No obstante, todos estos cálculos se habían realizado para el mejor de los casos, es decir que el usuario hubiera utilizado una PSK de 8 caracteres. Aumentar tan sólo en 1 la longitud de la contraseña multiplica por un factor de 100 el tiempo necesario para la recuperación, por lo que con sólo 12 caracteres el tiempo necesario tanto en el peor como en el caso medio se dispara de nuevo. Ni cabe tiene que decir que si seguimos aumentando el tamaño de la PSK obtenemos tiempos de recuperación inmanejables.

Por lo que respecta a los comentarios de ValaV afirmado que consigue un incremento «de unas 5000 – 1000 tests por segundo, a 50 millones», pueden ocurrir dos cosas: que estés confundiendo de protocolo de seguridad (esos cálculos se asemejan más a ataques estadísticos WEP), o que estés utilizando tablas precomputadas, las cuales dudo que lleguen a 50 millones como afirmas. A eso hay que añadir que esas tablas solo son válidas para un ESSID concreto, por lo que no sirven para un ataque genérico.

“Pobrecito Hablador» comenta “deja de pensar en ataques de fuerza bruta que ya no se usan desde hace 20 años». No voy a comentar tal afirmación, pero sí que me gustaría que comentara cómo realizar un ataque criptológico a RC4 (WPA) o AES (WPA2) sin el uso de la fuerza bruta; quizá estemos ante un nuevo «Bruce Schneier». Es relevante indicar que con unos simples paquetes capturados de la red no es posible obtener la PSK, dado que lo único que se consigue es la PTK temporal, que no te serviría de mucho ya que que se regenera para cada sesión (se necesita el Handshake). Te aconsejo pegues un vistazo a la serie de posts sobre WPA.

Por lo que respecta a los comentarios de Heffeque, que dice que se aplican datos falsos e ignoran detalles, respeto su opinión pero en ningún momento presenta información que contradiga lo analizado en el post. El calculo CPU:GPU que indicado está basado en la información que la empresa fabricante del software ha dado, para mí “Phising Comercial», término que parece que ha levantado ampollas.

En relación con este aspecto, cuando una empresa realiza afirmaciones demasiado aventuradas, desde mi punto de vista, sobre una tecnología ampliamente extendida tirando por tierra al grupo de trabajo de IEEE 802.11i, para mi es un Phising en toda regla. Tratando de vender un producto que permite reducir en tiempo de recuperación de la PSK de WPA/WPA2 pero que dista mucho de las afirmaciones que algunas publicaciones han reflejado “WiFi encryption cracked by Russians using Nvidia graphics cards«, me parece apropiado utilizar este término cuando lo que se pretende es “Pescar Clientes».

Por último, agradezco a todos los comentaristas sus intervenciones (a pesar, en algunos casos, de las formas utilizadas), e insto a los lectores a que tras leer la serie de entradas sobre seguridad en WPA publicados en este mismo blog, aporten argumentos de peso que permitan mostrar que estoy equivocado, o que al contrario estoy en lo cierto y esto no es más que una estrategia comercial apoyada (no intencionadamente, en cualquier caso) por varios medios de comunicación.