Security Art Work

En esta ocasión me gustaría hablar de uno de los retos que solucioné hace poco y que encontré bastante interesante. En éste, debíamos conseguir acceder a la zona privada de una página web protegida con htaccess que contenía un blind SQL injection (vulnerabilidad ampliamente conocida, pero si alguien no la conoce, en Internet hay multitud de información, como por ejemplo https://www.owasp.org/index.php/Blind_SQL_Injection).

En MySQL disponemos de la función load_file, la cual nos permite acceder a un fichero siempre y cuando tengamos el privilegio FILE. Así que lo primero que debemos hacer es comprobar los permisos del usuario con que se están ejecutando las consultas.

Antes de continuar, me gustaría aclarar que todas las consultas se pueden hacer de forma manual, o con scripts realizados por uno mismo, pero hay veces que existen herramientas que nos facilitan mucho la tarea y se puede obtener el mismo resultado mucho más rápido. Como por ejemplo con sqlmap (http://sqlmap.org/), que sirve para explotar vulnerabilidades SQL injection.

[Read more…]

Para aquellos que os habéis enfrentado alguna vez a un análisis forense de memoria RAM, lo más seguro es que conozcáis Volatility. Esta potente herramienta desarrollada en Python permite obtener hasta la marca de café que beben los usuarios/atacantes que han hecho uso de un determinado equipo.

Como todo en la vida, se puede utilizar la mejor raqueta del mercado, pero uno no golpeará como Nadal, o se puede disponer de las mejores zapatillas de running pero uno nunca será Carl Lewis. Con Volatility pasa un poco lo mismo: no es una herramienta sencilla y tratar de encontrar un “bicho” o hallar evidencias de una intrusión no es trivial. Sí que es verdad que listar los procesos, obtener sus DLLs o incluso ver las conexiones establecidas en un momento determinado por la máquina es relativamente sencillo. Lo que ya no lo es tanto es la interpretación de la información que Volatility nos devuelve.

Es por eso que tras bucear por la estupenda wiki del proyect, e ir leyendo los diferentes posts o artículos recopilados por sus autores uno puede ir aprendiendo pequeños “trucos” sobre cómo detectar contextos anómalos y comportamientos específicos del malware. Con esta idea nace VolWrapper, una envolvente para Volatility escrita en Python que permite analizando la salida de los diferentes comandos de esta, identificar posibles anomalías presentes en la captura.

¿Cómo funciona VolWrapper? Pues simplemente redirigiendo la salida de la aplicación a la entrada de VolWrapper mediante una pipe.

root@hal9000:/home/ramado volatility  -f imagecapture.raw --profile 
   Win7SP1x86 dlllist | ./volWrapperV0.1.py

En estos momentos la envolvente soporta tan solo 3 comandos identificando situaciones anómalas para cada una de ellas: dlllist, psscan, pslist:

• Dlllist lista las librerías dll cargadas en cada uno de los procesos de la máquina. A menudo el malware pude trabajar en user space, inyectándose en un determinado proceso a través de estos métodos, por lo que durante la acción forense es recomendable revisar las diferentes librerías residentes en memoria. Este trabajo puede ser tedioso, por lo que en este punto entra en acción VolWrapper mostrando mediante una leyenda de colores información sobre las diferentes Dlls identificadas. Puede alertarnos de librerías fuera de los directorios tradicionales como system32, de capacidades de comunicación o de cifrado, incluso proporcionarnos una descripción de la funcionalidad de la dll.

  Esto no quiere decir que mágicamente no señale donde está el problema, pero sí que puede ser un soporte para cribar un montón de información que de otra manera podría suponer mucho tiempo de estudio. Ejemplo de ejecución (pinchar en la imagen para verla a tamaño completo):

  #volatility –f imagecapture.raw –profile Win7SP1x8 dlllist | ./volWrapperV0.1.py –c 
  

  

  Por ejemplo, de esta manera podemos identificar rápidamente si un proceso que aparentemente tiene una funcionalidad concreta como es notepad.exe está utilizando librerías de cifrado de datos o de comunicación, situación en un principio anómala. A su vez permite también centrarnos en todas aquellas librerías que a priori no están presentes en una instalación por defecto de un entorno Windows (listadas de color negro), centrando nuestra atención en ellas.

• Pslist permite obtener los procesos en ejecución en un momento determinado de la captura analizada. Una posible anomalía en cuanto a los resultados listados por Volatility puede ser procesos huérfanos, es decir sin PID padre aparente. Esta situación puede deberse a que un rootkit puede estar ocultando el verdadero proceso padre. VolWrapper permite identificar mediante un código de colores los procesos sospechosos.

  

• Psscan es similar al anterior, siendo un apoyo a psxview.

Resumiendo, la idea de la herramienta es ir ampliándola incorporando todas aquellas situaciones anómalas que identifiquen la presencia de algún artefacto. Por ahora tan solo soporta estos tres métodos pero irá creciendo, permitiendo a gente con menos conocimientos realizar un forense de RAM de forma más sencilla. Tenéis la herramienta en el siguiente enlace https://github.com/ramado78/volWrapper y en breve la añadiremos a la sección de herramientas “self-made” en SAW ;)

En este primer artículo vamos a explicar la instalación de este firewall basado en FreeBSD (), así como las múltiples opciones de instalación de paquetes que contiene. PFsense deriva de otra distribución anterior llamada monowall, más centrada en instalación de equipos embebidos (se ejecuta por completo en memoria RAM), ya que PFsense se puede instalar prácticamente en cualquier PC y tiene la capacidad de poder ser instalado en un disco duro.

Entre las funciones más destacables de PFsense se encuentran:

• Firewall: Filtrado (por IP, protocolo, puerto etc…), Limitación de conexiones, enrutamientos por regla, creación de alias.
• Tabla de estado: informa del estado de los servicios y conexiones.
• NAT (Network Address Translation): con cuatro tipos de configuraciones.
• Multi-WAN: Se pueden agregar varias conexiones de Internet con diferentes proveedores para poder usar balanceo de carga, usándose para distribuir equitativamente el ancho de banda o utilizar otra conexión en caso de que un ISP falle.
• Servidor VPN: con OpenVPN, IPsec o PPTP.
• PPPoE Server.
• Gráficos RDP.
• Soporte de DNS dinámico.
• Servidor DHCP.
• Portal cautivo, servidor Radius, Proxy Squid, IDS/IPS Snort etc.

[Read more…]

Como ya hemos comentado en alguna ocasión en este blog, las listas de control acceso en dispositivos Cisco, en adelante ACLs, nos ayudan a identificar tráfico ‘interesante’ para que posteriormente sea procesado por el sistema. Las ACLs pueden usarse por varios motivos, siendo el más habitual la identificación de tráfico para su filtrado posterior sobre una de las interfaces del dispositivo (access-group). Otro uso habitual es la indentificación de tráfico interesante dentro de un cryptomap de una conexión VPN o cuando usamos NAT.

Sin entrar en detalle, podríamos considerar como las ACLs más usadas las siguientes:

• ACL estándar: nos permite identificar (autorizar o denegar) tráfico basándonos únicamente en la IP origen.
• ACL extendida: nos permite identificar tráfico a nivel 4, es decir, aparte por las direcciones IP origen/destino, podemos identificar protocolos o puertos TCP/UDP (incluido el flag established).

No obstante, existen otros tipos de ACLs, algunos de ellos que no aparecen nombrados aquí, que al menos yo prácticamente no he usado nunca:

• ACL nombrada: similar a las anteriores pero con la posibilidad de usar nombres en lugar de números.
• ACL dinamica (lock-and-key): donde necesitamos establecer una sesión autenticada con el dispositivo para autorizar el tráfico.
• ACL reflexiva: donde se autorizan las conexiones salientes y permitiendo la respuesta de dichas conexiones.
• ACL basada en tiempo: similar a la extendida pero con la posibilidad de poder establecer un control de acceso según un patrón horario.
• ACL basada en contexto (CBAC): donde podemos inspeccionar el tráfico para permitir accesos temporales a las sesiones establecidas, como retorno de las mismas o como conexiones adicionales.

Un caso que quizás nos podría llevar a confusión (a mi me pasó la primera vez que lo ví), sería por ejemplo cuando trabajamos con un switch de capa3, como podría ser el Cisco 3750, en donde podemos aplicar VACLs, es decir, aplicar ACLs a las Vlans existentes. Supongamos por ejemplo que tenemos una ACL como la siguiente:

ip access-list extended ACL_FILTRADO
 deny ip host 192.168.1.100 any
 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

Si nos centramos únicamente en esta configuración, podríamos asumir que el tráfico de la dirección IP 192.168.1.100 será denegado; el tráfico desde la red 192.168.1.0/24 a la red 192.168.2.0/24 será permitido y finalmente, el resto de tráfico será denegado por defecto, ya que habitualmente asociamos las ACLs a un filtrado de tráfico en una interfaz, pero recordemos que estamos identificando tráfico para su procesado posterior.

Efectivamente, si después encontramos un comando access-group en una interfaz del dispositivo, nuestra suposición será correcta. No obstante, podemos encontrar una VACL sobre una de nuestras VLAN, en este caso la 22, de la forma:

vlan access-map VACL_FILTRADO 10
 match ip address ACL_FILTRADO
 action drop
vlan access-map VACL_FILTRADO 20
 action forward
vlan filter VACL_FILTRADO vlan-list 22

Según esta configuración, la ACL se comporta al contrario de lo que habíamos supuesto. El tráfico que hace match con ella la ACL (permit), será denegado (action drop), y el resto de tráfico se reenviará para su procesado.

Es muy importante tener presente que en una ACL estamos identificando tráfico el cual será procesado más tarde y no asumir por error, aunque es lo habitual, que un deny será tráfico denegado en el dispositivo. Esto nos ayudará a reducir el tiempo en un proceso de troubleshooting a nivel de red para centrarnos identificar y solucionar el verdadero problema.

Si queremos más información de ACLs en Cisco, podemos consultar los siguientes enlaces:

• http://www.cisco.com/c/en/us/support/docs/security/ios-firewall/23602-confaccesslists.html
• http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/15-0SY/configuration/guide/15_0_sy_swcg/vlan_acls.html

Algo habitual a la hora de configurar una red donde podemos encontrar dispositivos de distintos fabricantes como switches o routers, es configurar los equipos de forma manual y por separado, lo cual, dependiendo de la complejidad de la red, puede llegar a hacer prácticamente imposible disponer de mejoras de forma rápida. Por ejemplo, para cubrir por ejemplo las necesidades de ancho de banda o conectividad de nuestros clientes.

Teniendo esto presente y más con la evolución en la actualidad de los sistemas cloud, donde ya se dispone de herramientas para gestionar y desplegar sistemas de forma prácticamente automática, disponer de una red compleja es algo poco factible de mantener de esta forma, por lo que grandes compañías están dedicando gran cantidad de recursos en encontrar una solución, de forma que la gestión de la red no sea nodo a nodo, como hemos dicho, muchas veces cada nodo de un fabricantes distinto, sino de forma centralizada. En la actualidad, ya se disponen de herramientas de gestión centralizada pero habitualmente suelen ser propietarias de cada fabricante.

Desde hace algunos años, todo esto ha dado lugar al concepto conocido como SDN (Software Defined Network), una red donde existe una separación entre el plano de control (control plane) y el de datos (data forwarding plane), dando lugar a la aparición de interfaces independientes que se encargan de gestionar este plano, de forma que sea posible disponer de redes más flexibles y automatizables.

Aparte de la mejora notable a la hora de gestionar la red, por ejemplo a en cuanto a tiempo se refiere, podríamos pensar en la simplificación de los dispositivos de red, ya que éstos dejarían de entender y procesar protocolos diversos y simplemente aceptarían instrucciones del controlador SDN. A nivel de seguridad, también podríamos filtrar el tráfico anómalo en distintos dispositivos de forma centralizada o redirigir dicho tráfico a nuestro IDS o firewall para inspeccionarlo.

(Imagen de la Wikipedia por Denwid)

Dentro de estas interfaces destacaría, por ser la primera, OpenFlow, un protocolo abierto creado por Open Networking Foundation, para permitir la gestión remota de tablas de enrutamiento. No obstante, existen otras interfaces como ONOS, de Open Networking Lab, Netconf/Yang, o directamente la gestión habitual mediante SNMP.

Actualmente, SDN se encuentra en una etapa inicial donde esta siendo adoptada por grandes operadores, proveedores de cloud o centros de investigación, aunque se prevé que para final de este año empiecen a aparecer de forma masiva aplicaciones y controladores SDN en el mercado. A pesar de ello, ya se dispone de una lista de equipos con soporte en la web de ONF, como la arquitectura Cisco ONE para la progamacion y provision automaticada de la red, o contrail de Juniper.

En esta entrada vamos a presentar un complemento para Nagios llamado Nagmap. Es una herramienta que nos va a permitir representar geográficamente los dispositivos monitorizados en Nagios. Nagmap utiliza la API de Google Maps para ubicar en el mapa los dispositivos a través de las coordenadas de cada uno de ellos. Nagmap se alimenta de los ficheros de configuración incluidos en nagios.cfg y del fichero de estado de los dispositivos status.dat. De estos ficheros obtiene los datos necesarios de cada host o dispositivo y, si tienen la información necesaria, los ubicará en el mapa.

Para que un dispositivo pueda ser representado tiene que tener, al menos, los siguientes campos completados en el fichero de definición de hosts correspondiente de Nagios:

define host{ 
	host_name         localhost 
        alias             localhost 
       	address           127.0.0.1 
        notes             latlng:+41.9031536,-1.726998500000036
	} 

Como se puede observar, el campo “notes” ha sido designado por Nagmap para indicar las coordenadas geográficas de este dispositivo. El formato en el cual hay que indicar las coordenadas para que Nagmap las reconozca tiene que ser:

latlng:latitud,longitud

A modo de ejemplo, vamos a instalar Nagmap en un servidor en el que ya se encuentra Nagios funcionando. Comenzamos descargando Nagmap desde la página de su proyecto. Una vez descargado, descomprimimos el fichero, lo renombramos y lo movemos al directorio correcto del servidor web (Apache).

$ wget https://github.com/hecko/nagmap/archive/master.zip
$ unzip master.zip 
$ mv nagmap-master /var/www/html/nagmap

En este momento ya está disponible a través de la URL que hayamos indicado en la configuración del servidor web:

Como se puede ver en el mapa, han sido dibujados los “markers” o “pinchos” coloreados de cada uno de los dispositivos con información sobre su estado. Además, dispone de un pequeño cuadro de mandos en el “sidebar” con información estadística sobre el estado y, una lista de todos los dispositivos representados.

Supongamos ahora que una empresa tiene cientos de sucursales repartidas por el territorio nacional. Si quisiera visualizar el estado de la conexión a la red de cada una de ellas en Nagmap, la cantidad de “pinchos” dibujados dificultaría una visión clara del estado de las oficinas.

Como posible solución, podemos modificar el código PHP de Nagmap para establecer un filtro de modo que solo muestre aquellas oficinas cuyo estado sea anormal (distinto de “OK”). Esto simplifica enormemente la visualización de aquellas oficinas con problemas de conexión, que realmente son las que nos interesan. Una posible modificación para conseguir este resultado sería modificar el fichero marker.php de Nagmap de la siguiente forma:

File marker.php

line 140 ===	//put markers and bubbles onto a map 
line 146 ---	$javascript .= ("window.".$h["host_name"]."_pos = new ...
line 149 ===	// if host is in state OK 
line 151 ---	$javascript .= ('window.'.$h["host_name"]."_mark = new google.maps.Marker({". 
line 152 ---	"\n  position: ".$h["host_name"]."_pos,". 
line 153 ---	"\n  icon: 'http://www.google.com/mapfiles/marker_green.png',". 
line 154 ---	"\n  map: map,". 
line 155 ---	"\n  zIndex: 2,". 
line 156 ---	"\n  title: \"".$h["nagios_host_name"]."\"". 
line 157 ---	"});"."\n\n"); 
line 159 ---	$sidebar['ok'][] = '<a href="javascript:'.$h["host_name"] ...	 
line 160 ===	// if host is in state WARNING 
line 162 +++	$javascript .= ("window.".$h["host_name"]."_pos = 
new google.maps.LatLng(".$h["latlng"].");\n"); 
line 171 ===	// if host is in state CRITICAL / UNREACHABLE 
line 173 +++   	$javascript .= ("window.".$h["host_name"]."_pos = 
new google.maps.LatLng(".$h["latlng"].");\n"); 
line 182 ===    	// if host is in state UNKNOWN 
line 184 +++   	$javascript .= ("window.".$h["host_name"]."_pos = 
new google.maps.LatLng(".$h["latlng"].");\n"); 
line 194 ===	// if host is in any other (unknown to nagmap) state 
line 195 +++   	$javascript .= ("window.".$h["host_name"]."_pos = 
new google.maps.LatLng(".$h["latlng"].");\n"); 
line 218 +++	//COMPROBAR SI STATUS != OK, PARA QUE GENERE INFO BUBBLE 
line 219 +++	if ($h['status'] != 0) { 
line 224 +++	}

Tras esta modificación, tan solo se mostrarán en el mapa las oficinas que tengan un estado de error. En el “sidebar” seguirán apareciendo las estadísticas generales pero solo se mostrará el listado de las oficinas con problemas (ha desaparecido “localhost” porque su estado es “OK”).

Como hemos visto, podemos crear vistas personalizadas del estado de los dispositivos de nuestra red, además, puede utilizarse como un cuadro de mandos meramente informativo para los ejecutivos de la empresa si lo personalizamos algo más, por ejemplo:

• Personalizar los “pinchos” con unos diseño más adecuado.
• Incluir un “header” de empresa en la interfaz web.
• Añadir información al globo: dirección postal de la oficina, población, teléfono, etc. (para esto habría que modificar el código para que Nagmap procese los campos correspondientes, al igual que se realiza con “notes”).
• Personalizar las opciones disponibles en config.php de Nagmap : zoom en el mapa, centrado, estilo del mapa (roadmap, satellite, hybrid, terrain).

¡Os animo a que juguéis con la API de Google Maps y con Nagmap, ya que el código es bastante amigable y se pueden hacer cosas muy interesantes!

Una de las tareas más repetitivas cuando se gestionan incidentes es el análisis de alertas relacionadas con correos electrónicos.

Cuando se recibe un correo, ya sea relacionado con un spear phishing o una alerta de IDS hay ciertas cosas que se deben mirar, ya sea para el análisis del incidente actual, como puede ser en el caso de las cabeceras o ficheros adjuntos, o para un posterior análisis, como determinar los receptores más habituales que aparecen en una campaña dirigida.

Para realizar todo este trabajo que es bastante tedioso, llevaba un tiempo queriendo escribir un script que hiciera la parte de extracción de datos de manera automática, de forma que pudiera tener todos los datos que necesitase poner un informe tan solo copiando y pegando, pudiendo así emplear más tiempo en el análisis de los adjuntos realmente interesantes. He podido sacar algo de tiempo y escribir una primera versión en modo quick and dirty y con pocas funcionalidades añadidas.

Funcionalidades

Como funcionalidad básica está la extracción de los datos de las cabeceras, es decir, remitente, receptores, asunto e identificador del mensaje. Además de estos datos por separado, también se extraen las cabeceras completas, ya que pueden ser necesarias para la investigación y nos permite en un vistazo saber los saltos que ha realizado ese correo para llegar a su destino.

Además de estos datos, es interesante conocer las direcciones IP implicadas en el correo, por lo que el script también las extrae y, por defecto, chequea el historial de dominios que resuelven a esa dirección y que tienen al menos una detección en Virustotal (VT).

Para la revisión de los correos con contenido malicioso se extraen los datos relativos a los archivos adjuntos del correo y los enlaces que se puedan encontrar en el cuerpo del mensaje. Además se comprueban los ficheros extraídos en VT.

En este último caso, únicamente se comprueba el hash del fichero, no se envía nunca el fichero a VT, ya que en ese caso podríamos estar exponiendo información confidencial en el caso de se tratase de un ataque dirigido.

Script

No hay mucho que comentar del script, es bastante simple, aunque empezaron siendo unas 40 líneas y ya va por más de 200 y me gustaría comentar algún detalle.

El primer detalle en el que me quiero parar es en el uso de Virustotal. En las partes del código en la que se llama a las rutinas de análisis de direcciones IP y de archivos adjuntos, se ha puesto un contador que se reinicia al llegar a 4. Esto es para que el script sea usable con la API pública de VT, la cual limita el número de peticiones a un máximo de 4 por minuto.

Por cierto, para que esto funcione necesitáis meter vuestra clave de la API en la variable global VT_API que se encuentra al comienzo del script.

Tened en cuenta que el script es usable pero está en alpha y es posible tanto que falle, como que cambie bastante en las próximas semanas, así que si os interesa permaneced atentos a las actualizaciones en github.

Con la opción -vt se saltan los chequeos en Virustotal.

Aquí os dejo el link del script.

Ejecución

Para lanzar el script basta con ejecutar:

$ python mailextractor.py -f mail.eml

En mi caso lo hago sobre un correo al que luego le he modificado una de las cabeceras para que contenga una IP con detecciones en VT, un fichero que previamente he escaneado en VT y otro que no.
El correo es el siguiente:

Al ejecutar el script nos da los datos del correo:

Las cabeceras, entre las que se incluye la cabecera falsa:

Análisis de las direcciones IP encontradas en las cabeceras:

Se puede ver que en la dirección falsa que he metido salen varios dominios que en algún momento resolvieron a esa dirección IP con algún positivo en Virustotal.

Y por último el análisis de los ficheros adjuntos:

Se ven ficheros: lotus.jpg y mlwre_logo.png. Ambos son imágenes. Subrayado se puede ver que el fichero lotus.jpg ha sido analizado anteriormente en Virustotal y que en el momento del análisis ningún antivirus lo detectó como positivo.

Todo

También os dejo algunas de las ideas que planeo realizar en el script y que no he podido terminar para este post:

• Limpiar el código.
• Análisis de todos los correos almacenados en un directorio.
• Distintos formatos de salida (txt, html, etc).
• Checkeo de URL y direcciones IP contra blacklist.
• Opción para el envío de los ficheros a analizar a Virustotal.
• Muchas ideas para incorporar otros servicios como malwr.com.

Cualquier idea o comentario para mejorarlo es bienvenida, también podéis enviar actualizaciones o errores a través de la página de github.

NOTA: La función para extraer el cuerpo del mensaje a veces falla, estoy trabajando en ella.

NOTA2: Si los análisis de VT fallan a menudo podéis solucionarlo subiendo el tiempo de espera, lo he dejado en 30 segundos para no eternizar la ejecución del script.

Recordarán que, tras la divulgación de las revelaciones de Edward Snowden en relación con las actividades de la NSA, y las diferentes evidencias que comenzaron a surgir en relación con la monitorización y el análisis de la actividad en la red de los ciudadanos del mundo en general y el espionaje dirigido de cerca de dos tercios de los líderes mundiales, a la administración nortemericana no le quedó más remedio que entonar el ya famoso: “Lo siento, me equivoqué. No lo volveré a hacer más”.

Que está muy bien, pero que no es suficiente. De pequeñito me enseñaron que la secuencia era algo así como examen de conciencia, dolor de los pecados, propósito de enmienda y cumplir la penitencia. En este caso se ha limitado al propósito de enmienda y poco más. Alguna propuesta de iniciativa legislativa, algún posicionamiento de cara a la galería, y no mucho más. Aquí paz y después gloria.

Supongo que estarán al tanto de la noticia. USA acusa formalmente de ciberespionaje industrial a cinco militares chinos. Nada nuevo que no sepamos. Todos sabemos a qué juega China. Pero como todos sabemos también, en esto de la ciberguerra no hay ni buenos ni malos, pues el que no corre vuela.

Lo que me ha llamado la atención es la rotundidad y diligencia con la que se está tratando el tema. Ha habido una reacción airada de la administración norteamericana con protesta oficial y acusación formal incluida, y se están tomando medidas inmediatas de respuesta.

Porque claro, aquí no se están vulnerando los derechos de privacidad de las personas. Aquí se trata de intereses empresariales, intereses estratégicos y de defensa. Con la iglesia hemos topado, amigo Sancho.

Recapitulemos. Quien antes se consideraba con derecho, en defensa de su seguridad nacional, a espiar a los ciudadanos de todo el mundo, ahora reacciona airadamente y clama al cielo porque otro está haciendo lo mismo, sólo que ahora contra sus intereses económicos y empresariales.

Quiero dejar muy claro que no estoy defendiendo el derecho de China a llevar a cabo estas prácticas, ni mucho menos. Además, sabemos que no se dedican a esto desde hace poco. Son pioneros en temas de ciberespionaje y ciberguerra. Pero a la vez, creo que ha quedado meridianamente claro cuáles son las prioridades en materia de ciberdefensa, y qué intereses prevalecen sobre qué derechos.

Quizás por no haber prestado mucha atención, gran número de usuarios ya disponen de una de las nuevas tarjetas de crédito sin contacto (NFC) y no tienen ni idea de lo que eso significa. A primera vista son iguales que las anteriores, la única diferencia exterior es un símbolo que representa unas ondas para indicar la presencia de la nueva funcionalidad.

Hace poco, ví a un compañero pagar en un restaurante con su tarjeta de crédito NFC. La camarera procedió a cobrarle acercando la tarjeta al punto de venta (TPV) móvil. Y sin pedirle más cosas, la terminal imprimió el recibo para confirmar la transacción. La característica que más nos llamó la atención fue la posibilidad de realizar compras sin tener que introducir el PIN, siempre y cuando el pago no sobrepase los 20€.

Navegando un poco por internet y después de leer “Hacking the NFC credit cards for fun and debit ;)” se puede ver que es posible recuperar datos personales de manera sencilla ya que no van protegidos y/o cifrados. Entre otros, se puede llegar a obtener:

• Nombre y Apellidos.
• Número de tarjeta de crédito.
• Fecha de Caducidad.
• Track2 de la banda magnética.
• Historial de compras.

Lo que no devuelven es el código de seguridad CVV (menos mal), aunque existen páginas web (p.e. Amazon) que no piden ese código para aceptar los pagos.

Requisitos materiales para investigar un poco:

• Disponer de una tarjeta de crédito NFC o como en mi caso tener un compañero a quien pedir ‘amablemente’ que nos deje jugar con su tarjeta.
• Un lector de NFC: En este caso reutilizamos nuestro Touchatag que nos permite comunicar con la tarjeta de crédito basada en la ISO 14443. También se puede usar un móvil con NFC.

En cuanto a software podemos encontrar varios programas junto a su código fuente. Recomiendo revisar el código y compilarlo nosotros mismos. No hay que fiarse y usar software ya compilado tanto en PC como en Android pues no sabemos si por detrás mandan los datos a algún lugar de dudosa reputación.

Aquí cabe destacar que se usa el estándar EMV que es el mismo que se usa en las tarjetas de crédito Smartcard (tarjetas con chip). En poco minutos tenemos armado un sistema para la lectura de datos.

Funciona con la mayoría de los casos y tarjetas, pero con la tarjeta de mi compañero ningún programa de los usados consiguió respuesta, parece que la haya bastionado antes de dejármela.

Después de estar investigando el código fuente de varios programas, podemos ver que la mayoría (o todos) necesitan una lista de tarjetas soportadas. Lo que hacen es probar los AID de una lista hasta que la tarjeta responde correctamente a alguno de ellos (en el siguiente post de la serie destriparemos un poco el protocolo que usan las tarjetas).

¿Es algún nuevo tipo de protección? Para resumir… ¡No! Simplemente que la tarjeta no está en la lista de tarjetas soportadas y no conocemos su AID. ¿Como hace entonces el TPV para seleccionar la AID correcta? Existe un directorio que le dice cual es la AID a seleccionar. ¿Solución? Lo implementamos nosotros.

Personalmente me basé en el readnfccc. Para hacerlo un poco más universal, le agregué la lectura del PPSE (directorio con información relativa al pago sin contacto) para sacar el AID correcto. También existe el PSE que corresponde al directorio con información relativa al pago insertando la tarjeta en un terminal que soporta solamente Smartcard.

Se puede encontrar el código fuente en GitHub.

¿Cómo protegerse?

• Usar una cartera especial que actúa como jaula de Faraday y no permite el paso de ondas. O envolverla en papel de plata.

  

• Inutilizar la antena de la tarjeta haciendo un pequeño agujero por donde pasa. Estas tarjetas disponen de una antena formada por unas pistas que rodean la tarjeta. Haciendo un corte o un agujero en la pista anula la comunicación NFC de la tarjeta dejando intacto el chip y la banda magnética.

  

• Se rumorea que un par de segundos en el microondas puede quemar el chip NFC, pero unos segundos más pueden dejar inutilizable la smartcard. Con unos cuantos segundos más se puede conseguir prenderle fuego (que no es la idea, pero soluciona el problema ;). Al ser una ciencia poco exacta y tratándose de rumores este ultimo método no es recomendable y se menciona a titulo de anécdota.

En el próximo post analizaremos con un poco más de detalle el protocolo EMV y su implementación en tarjetas NFC. Finalmente en otro post analizaremos algunos ataques posibles.