viernes, 27 de diciembre de 2013

Evolución de los ataques a las redes móviles

La charla de Karsten Nohl y Luca Melette está centrada en la respuesta de la industria a las vulnerabilidades de seguridad que se han encontrado en este último año en las SIM, y las que han descubierto hace varios años sobre el cifrado de las llamadas GSM.

Ataques a las tarjetas SIM

Había tres problemas que permiten ataques contra tarjetas SIM remotamente simplemente enviando mensajes SMS de mantenimiento a un teléfono.
  1. Cualquiera puede enviar mensajes SMS de mantenimiento a cualquier persona.
  2. La aplicación de actualización OTA de las SIM no está protegida por un cifrado adecuado.
  3. Las aplicaciones SIM se pueden salir de su "sandbox"
La respuesta al primer punto de muchos operadores ha sido filtrar los mensajes que se usaron al describir la vulnerabilidad demostrada. Pero el problema es que este filtrado sólo previene contra este ataque, y no contra toda la familia de mensajes que pueden llegar a las tarjetas SIM.
En el segundo caso, primero hay  que describir el problema: una tarjeta SIM puede tener hasta 16M aplicaciones, y hay 16 tipos de claves que se pueden usar para acceder a ellas, y para cada tipo de clave se definen las medidas de seguridad que se utilizan para acceder a las aplicaciones de la SIM. Muchos operadores simplmenente han actualizado el cifrado de las claves para que sea 3DES en vez del anterior DES, que es más vulnerable, pero han dejado otras aplicaciones completamente desprotegidas de modo que no es necesario ninguna clave para acceder a ellas.
A continuación han hecho una demostración con una nano SIM introducida en un iPhone. Conectándolo a una BTS especial que no tiene el filtrado de la red, le envía unos mensajes SMS e infecta esa SIM con un código java que envía la ubicación del teléfono vía SMS al atacante cada 5 minutos. En el iPhone esto no se ve pero se introduce el SIM en un Nokia que se conecta a la red real y pide permiso antes de dejar a la SIM enviar el SMS.
Asociado a esta demostración, tras esta charla van a liberar una herramienta, llamada SIMtester, que puede ejecutarse con cualquier lector de smartcards o un Osmocom (que puede ejecutar el software).

Captura de tráfico GSM

La mayor parte de las llamadas de teléfono hoy utilizan GSM. El problema es que las llamadas van cifradas con uno de dos protocolos: A5/1 que es inseguro y que ha sido atacado anteriormente pero que y A5/3 que por ahora es seguro. Los ataques de A5/1 se pueden dificultar mucho a base de introducir aleatorización en el contenido de los paquetes de tráfico GSM, pero no parece que las compañías hayan
El segundo problema es que el protocolo A5/3 es sólo 1M de veces más complejo que el A5/1, pero como el A5/1 se puede descifrar por un ordenador en un segundo, entonces varios centeneres de ordenadores que costarían cerca de un millón de dólares podrían descifrarlo en un minuto.
Para impulsar que la comunidad de seguridad pueda comprobar la seguridad de las redes, van a liberar tres herramientas que comprueban la vulnerabilidad de las redes a los ataques mencionados:
  • GSMmap.apk: una herramienta para Android
  • xgoldscanner, basada en Linux que se puede usar con modems USB.
  • OsmocomBB: que se puede ejecutar en los famosos teléfonos Osmocom.
Y por último, han actualizado su página web gsmmap.org, que registra los resultados de las aplicaciones anteriores. La web todavía no tiene información sobre la seguridad de las SIM.

Cómo se ha robado un cajero automático electrónicamente

En esta charla, tw y sb muestran cómo se ha utilizado malware para robar cajeros electrónicos.
Básicamente el proceso es que los ladrones hacen un agujero en el cajero automático, conectan una memoria USB en el puerto de la impresora, y vuelven más tarde para recoger el dinero. Tw y sb se vieron implicados en esto porque un banco se encontró con muchos cajeros vacíos, reforzó sus medidas de vigilancia y consiguió atrapar a un ladrón con una memoria USB. Con esa memoria, hicieron la ingeniería inversa de cómo fue posible robar con ese malware.
Para poder entenderlo han comenzado explicando cómo es un cajero automático: es simplemente un ordenador que ejecuta Windows (XP en los casos analizados), con una cajafuerte adjunta y unos cuantas piezas de hardware adicionales. Sólo la caja fuerte está blindada, y por eso los ladrones pudieron hacer un agujero en el cajero por el cual accedieron a conectar la memoria USB al puerto de la impresora del cajero.
No es la primera vez que ha habido cajeros automáticos que han sido hackeados, pero esta parece que es la primera vez que se utilizan estos métodos para robar:
  • Barnaby Jack hizo una demostración en el Black Hat de 2010.
  • Ha habido muchos tipos de malware orientado a los terminales de caja de las tiendas (POS).
  • El malware Plotus descubierto en México y Colombia en 2013 funciona de manera parecida al aquí demostrado, aunque funciona con un CD.
El USB capturado tiene una imagen de Windows arrancable que copia cosas del disco duro del cajero y tiene un directorio con programas que se arrancan automáticamente al rearrancar el cajero. He entendido que los ladrones no pueden forzar la ejecución automática del software y esperan uno o dos días a que un rearranque del cajero complete la infección.
Luego los ladrones se llevan el dinero y el USB, que contiene múltiples datos extraídos de los cajeros (datos del sistema, de los billetes, de las tarjetas y las transacciones).
El hack.bat que se autoarranca es muy refinado y amigable, con muchas opciones, y está basado en un ejecutable llamado atm.exe. Controla que no se reinfecte el sistema y es capaz de limpiar todas sus trazas del sistema infectado.
El programa está empaquetado con UPX y tiene unos recursos cifrados de Windows, cifrados con XOR y una clave que a su vez es un XOR del Número de serie del Volumen y el número 0xaf73c521, por lo que el malware se personaliza para cada cajero. Todavía no se sabe cómo el malware consigue el número serie del volumen del disco duro del cajero, que es particular de cada cajero. También comprueba de que una vez descifrado el checksum es correcto. La infección se hace a base de copiar una DLL en el directorio del sistema.
Esa DLL además registra lo que va haciendo en el disco USB. En el USB capturado había un registro de tres infecciones previas, en el que se puede ver que los cajeros usan Windows XP.
La DLL tiene siete recursos adicionales:
  • 6 imágenes que luego veremos que se utilizan como base de un segundo desktop.
  • La herramienta sdelete para borrar de manera segura los ficheros de la infección.
Para recargarse en caso de rearranque, se añade la DLL a la variable AppInit_DLL, de modo que se añade a todos los procesos del sistema. Por ello, la DLL lo primero que hace comprobar el proceso al que se ha adjuntado, y en función del proceso ejecuta una funcionalidad u otra (hay diferentes programas de entrega de dinero según los diferentes modelos de cajeros).
La DLL escucha todos los eventos del teclado y procesa las teclas numéricas. En particular, presta atención a un número mágico de 12 dígitos que activa el menú secreto que permite controlar el cajero (000507607999). Para independizarse del programa normal, el malware arranca un segundo desktop y cambia la pantalla principal de uno a otro en función de si está se accediendo normalmente o no.
Para sacar dinero, además del número de 12 dígitos hay que dar una segunda clave dependiente del cajero mediante un proceso de desafío y respuesta de modo que sólo los propietarios del software son capaces de acceder al menú secreto. Esto es así porque las personas que retiran el dinero no son las que han hecho y controlan el software, y típicamente no llevan la clave que permite el acceso, sino que tienen que llamar por teléfono para que se lo den, por lo que han dado a entender que el código que calcula la respuesta está en otro programa que no ha sido capturado.
Hay dos trozos de código que han sido especialmente protegidos para dificultar su comprensión e ingeniería inversa:
  1. El código de pregunta y respuesta para controlar el acceso al cajero
  2. El código de extracción del dinero.
La protección del código funciona a base de ofuscar el control del código mediante una máquina de estados que recibe como entrada un buffer estático y calcula el siguiente tramo de código en función del estado, además de tener mucho código embarullado para que no se pueda entender bien. Pero se ha conseguido hacer la ingeniería inversa poniendo breakpoints adecuadamente, ya que la máquina de estados está en un rango de direcciones diferente que el código ejecutado.

Demostración del malware

Como debe ser, la charla ha acabado con una demostración del funcionamiento del malware. Tras arrancarlo lo primero que hace es presentar el desafío mencionado (y la opción de salir). Una vez superado el desafío (simulado saltando el código que comprueba si es correcto, el malware muestra el saldo de cada tipo de billete del cajero, de modo que el cobrador puede enfocarse en los billetes que le van a dar más dinero.
Ejecutando la opción de de retirar el dinero, se llega a una pantalla que muestra que el terminal está indisponible, pero simplemente requiere el mismo código de antes. Esto lleva a una pantalla
Las opciones de 1 a 4 sirven para sacar un tipo diferente de billete.
Las opciones 7 y 8 sirven para desconectar el cajero del sistema mediante la activación o deshabilitación de los interfaces de red. Esto impide que el sistema pueda avisar de la retirada o la activación del cajero.
La opción 5 se denomina formatear el sistema y después de pedir resolver otro desafío, lo que hace es eliminar el malware, eliminando toda traza del software.
El código permite deducir que la banda de ladrones tiene mucho conocimiento de los cajeros, tanto de de la plataforma como del software de cliente de efectivo, quieren conseguir mucho dinero y tienen diferentes roles dentro del proceso de robo. El código tiene muchas partes para eliminar las trazas y no dejar huellas.
La charla ha terminado con otro código: el que permite indicar la desinstalación directa del malware (000507607999000753951000).
En la sección de preguntas y respuestas, han aclarado que el software no capturaba PINs de las tarjetas que usaban el cajero, pero lo podrían haber hecho.
Me ha llamado la atención la firma del malware: atmh4ck m0dul0

OpenWRT: 10 años de diversión con dispositivos embebidos

En esta charla, ndb, uno de los principales desarrolladores de Open WRT nos describe el sistema y su historia.

Historia del desarrollo

El sistema operativo comenzó su vida cuando se descubrió que Linksys había usado linux para el router WRT54G, sin publicar el código, como requería la licencia GPL.
Cuando finalmente Linksys presionado por el descubrimiento, ditribuyó la tarball del sistema operativo comenzó su historia openWRT. En aquella época Linux no estaba muy distribuido entre los routers, y el sistema operativo que dominaba lo sistemas embebidos era VxWorks, sin requisitos GPL.
  1. Ruso blanco (0.9): los primeros trabajos que llevaron a una versión publicable se centraron en liberarse del tarball para tomar sólo las dependencias principales. Y lo segundo actualizar el kernel a una versión más moderna que la 2.0 de entonces. Ndb empezó con esta versión, 0.9, con la creación del sisetma de construcción. Con esta versión se inició la costumbre de nombrar versiones en función de cócteles de vodka.
  2. Kamikaze (8): A partir de ahí, los trabajos se dedicaron a independizarse del chipset de Broadcom del WRT, creando soporte multiplataforma y con nuevos sistemas de compilación, configuración y administración Web. El nombre venía por todos los cambios con respecto a la versión anterior. 
  3. Backfire (10): A partir de ahí, el foco fue estabilizar la versión y hacerla más robursta.
  4. Attitude Adjustmente (12): Después de Backfire, el objetivo fue liberarse del soporte 2.4, conseguir una buena integración de IPv6 y la parte de usuario y los scripts y las opciones de configuración. Esta es la última versión estable distribuida.

Descripción del sistema

¿Qué es lo que diferencia de openWRT de otras versiones?:
  • El sistema RPC ubus, mucho más simplificado que el normal dbus de las otras distribuciones Linux
  • El configurador de la red, netifd, que sustituye a múltiples scripts pero que permite cambios de configuración más rápido haciendo el mínimo número de cambios..
  • El demonio de sistema procd, que monitoriza los demonios que corren en el sistema, rearrancándolos cuando son necesario, como sustituto de systemd, mucho mejor testeado y ligero que el normal.
  • Tienen su propia implementación de IPv6, con un demonio dhcpv6 propio, con capacidad de redistribuir prefijos delegados, que no están bien resueltos en otras versiones de Linux, que no están tan restringidas como openWRT, que tiene que trabajar hasta en equipos con 32 MB de RAM.
En este momento, están trabajando en su nueva página web, LuCI2, que ya no está basada en Lua, sino en Javascript y RPCs JSON, que permite mover buena parte del trabajo de crear las páginas al navegador del usuario, ya que hasta los navegadores móviles tienen buenas implementaciones de Javascript.
Con esto, prevén distribuir una nueva versión llamada "Barrier Breaker", llamada así porque se supone que va a romper muchos moldes.

Impacto en la industria

Varios fabricantes de equipos les han entrevistado para intentar entender por qué su proyecto tenía éxito, aunque no tuvieron mucho éxito. Y el sucesor en Linksys del WRT54G estaba lleno de código propietario que no podía ser sustituido por código abierto lo que retrasó la adopción del equipo.
Otros fabricantes (ODM) han adoptado openWRT pero de manera extraña adoptaron las partes más inestables y descartaron las más estables en muchos casos, por lo que los fabricantes acabaron teniendo produtos peores en su intento de tenerlos mejores.
Subiendo más arriba en la cadena alimenticia, sí que consiguieron buenas colaboraciones con los  fabricante de circuitos integrados: Atheros, Broadcom, Lantiq, Mediatek y Ralink.
El problema para entenderse con todos, ya que openWRT tiene mucho énfasis en estabilidad y calidad del código mientras que los fabricantes están enfocados en producir nuevos equipos lo más rápidamente posible y con el menor coste, lo que les deja poco tiempo para enfocarse en el largo plazo.
Los fabricantes además de tener mucha burocracia y gestores de producto poco cualificados, tienen muchos problemas de desarrollo, particularmente con las ramas de desarrollo de modo que no tienen discirplina para mantener una rama principal operativa y periodicamente mezclar el código de las ramas laterales con la principal.
Otras actividades relacionadas con el proyecto son todos los trabajos para integrar sus parches en las distribuciones principales (upstream), en muchos casos desarrollando en ambos sistemas simultáneamente.
Una de las grandes colaboraciones es la de Freifunk, un proyecto que tiene como objetivo la creación de redes inalámbricas malladas (mesh).
También colaboran con Bufferbloat, cuyo objetivo es disminuir el impacto de los buffers en el routing, que está probando cosas más avanzadas que ellos.
Los trabajos para integrar IPv6 en el routing del hogar del IETF están también basados en openWRT.

30c3 también virtual

Este año, también acudo sólo virtualmente al CCC congress, pero esta vez sí que voy a poderme conectar online algunos días, ahora que ya soy capaz de ver el Congress Everywhere en mi Apple TV.