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.

(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.

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.

Recientemente 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.

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.

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.

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.

Se ha publicado recientemente que la empresa Elcomsoft ha desarrollado una nueva tecnología que permite utilizar la GPU de la tarjeta gráfica Nvidia para romper el cifrado de WPA/WPA2 hasta 100 veces más rápido que utilizando un PC normal [engadget, ItWire, securityandthe.net]. Aunque no dudo en absoluto que dicho anuncio sea cierto, permitidme una sarcástica carcajada para lo que es un phising comercial en toda regla, y veamos por qué.

Dado que la longitud mínima de una PSK de WPA o WPA2 es de 8 caracteres y el alfabeto manejado es de [A-Za-z0-9Sym32], tenemos (29+29+10+32)⁸ = 10.000.000.000.000.000 posibles palabras del lenguaje, que son… bastantes. Teniendo en cuenta que, siendo benévolo, los procesadores actuales mas potentes (utilizando el algoritmo de Aircrack) pueden a lo sumo barrer 400 palabras por segundo, y multiplicando por el incremento de la capacidad de procesamiento de la tarjeta Nvidia tenemos un total de 40.000 palabras del lenguaje por segundo.

Todo jefe, director o gestor de proyectos informáticos conoce las fases del ciclo de vida de un proyecto cual patrón de barco conoce la ruta a puerto seguro. Concepción, Organización, Desarrollo y Cierre conforman esa hoja de ruta que conducirá a patrón y marineros hacia el éxito de la aventura. Es sabido que ningún proyecto emprendido está exento de contingencias y desviaciones en la planificación trazada a priori, mapa en mano.

Así pues, a menudo se encuentran escollos y arrecifes que no estaban documentados en los mapas cartográficos y que generan retrasos y costes que en ocasiones pueden ser desmedidos. Esta situaciones son normales, así como es habitual que ese otro capitán que saborea un trago de ron junto a nuestra persona en la taberna te susurre de forma arrogante:

—¡Ja ja! ¡Yo estuve navegando el mes pasado por esas aguas y ví los arrecifes que hundieron parte de tu nave esta mañana!
—¡Valiente grumete, ¿y no los identificaste en el mapa para que los demás patrones no incidieran en el error?!— contestamos golpeando la mesa y derramando el poco ron que quedaba en el vaso.

Si hace un par de meses se consiguió determinar el sistema de cifrado de las tarjetas Mifare, esta vez le ha tocado el turno a los chicos de microchip en la serie de integrados criptográficos que implementan KeeLoq, dejando en evidencia las deficiencias de seguridad de algunas de las soluciones propietarias criptológicas que pretenden otorgar a sistemas RFID del uso de trasmisiones seguras.

Este tipo de chips son ampliamente utilizados como sistema inmobilizador o de apertura de puertas por compañías del automóvil como Chrysler, Daewoo, Fiat, General Motors, Honda, Toyota, Volvo, Volkswagen y Jaguar, así como en sistemas de acceso a garajes.

Según afirma el investigador y profesor Christof Paar de la “School of Electronics and Information Technology” un individuo situado en un rango de 100 metros al transponder puede capturar el tráfico intercambiado por el sistema para clonar la clave digital y hacerse con el control del coche o incluso denegar el acceso al propio dueño.

El sistema propietario parece que utiliza un algoritmo de encriptación no lineal, que genera la clave de 64 bits a partir de un vector de inicialización de 32 bits y un código aleatorio. Pero el problema reside en una clave maestra que la compañía fabricante introduce en sus integrados y que el profesor Paar ha descubierto mediante el analisis de la señal mediante DPA (Differential Power Analysis) y DEMA (Differential ElectroMagnetic Analysis). De esta forma, una vez determinada la clave maestra tan solo es necesario hacerse con cierto tráfico transmitido por el sistema para conseguir la clave del usuario utilizada. Puede consultar en este enlace los detalles del ataque.