Atacando teléfonos con SMS

Hoy en día, hay un montón de teléfonos que han sido atacados y vulnerados por la parte del sistema operativo, el acceso a Internet y todas sus funcionalidades más avanzadas, que al ser más complejas son más difíciles de asegurar. Pero la charla de Collin Mulliner se centra en los ataques mediante la parte telefónica, que suele tener un procesador separado y especializado que sólo se conecta al general por una conexión serie.

Como dice el autor, el principal peligro de problemas en esta parte es que no es fácil poner un firewall para protegerse de SMS malformados, y el ataque no requiere más conocimiento que el del número de teléfono (bueno, y posiblemente el modelo) del destinatario.

En la charla, se comienza por explicar la estructura de los mensajes SMS tal y como vienen del procesador de GSM al procesador principal a través de la conexión serie, que utiliza comandos AT para enviar los mensajes tal y como se han recibido de la red, lo cual habilita la posibilidad de muchos test de "fuzzing", mediante una librería desarrollada por el autor y un colega de una empresa de seguridad.

Pero queda un segundo problema: las pruebas. Hacer correr una herramienta de fuzzing sobre la red real sería prohibitivo, y aparte de lo que se ha contado en el congreso (que todavía está en desarrollo), no es fácil emular una red GSM. Por tanto, la segunda parte de la charla ha versado sobre la manera de enviar los mensajes "fuzzed" sin necesidad de pasar por la red, para identificar aquellos que tienen algún efecto en los teléfonos con tres sistemas operativos: iPhone, Android y Windows Mobile (para luego probar los que tienen efectos negativos en una red de verdad).

La solución empleada ha sido crear un nivel intermedio de software que simula el modem hacia la parte aplicativa del teléfono. Tiene la ventaja adicional de que permite crear un sniffer de SMS sin esfuerzo adicional.

El primer objetivo fue el iPhone, cuyo proceso llamado CommCenter maneja todos los SMS y las llamadas, que se ejecuta con privilegios de root sin "sandbox". El ataque consiste en inyectar una librería modificada en el proceso, que intercepta la llamada a "open" y que redirige el tráfico a un demonio, que además de pasar todo el tráfico hacia y desde el modem, envía los mensajes recibidos por WiFi de un PC, encargado de generar los mensajes.

Para detectar las caídas y los problemas se usan dos técnicas: por un lado se monitoriza la aparición de crashes en el programa CrashReporter y por otro lado se envían mensajes normales mezclados con los demás para ver que todo sigue funcionando correctamente después de cada mensaje mediante consultas a la base de datos de mensajes.

En Android es relativamente sencillo, cambiando de nombre el dispositivo y rearrancando el demonio que escucha a ese dispositivo se puede redirigir la entrada de mensajes a un proceso arbitrario... el poder del software abierto. La monitorización de crashes es sencilla mediante logcat y la monitorización de los mensajes recibidos es igual que en el iPhone porque también usaba sqlite. El primer resultado obtenido, es que el procesado de SMS con Android no es demasiado robusto, y era fácil bloquear el teléfono o el proceso de mensajes.

Para Windows Mobile es mucho más complicado, ya que se requiere escribir un nuevo serial driver que tiene el mismo interfaz que el driver original pero igual que los demás se comunica con el PC por WiFi. La monitorización es también más complicada porque hay que mirar dos procesos y ver que los dos siguen vivos tras el envío de los mensajes potencialmente malformados.

Después de desarrollar los tres entornos de pruebas y poner los teléfonos a prueba, se encontraron muchos mensajes potenciales, pero en muchos casos no funcionan a través de la red. Y hay mucha diferencia entre operadores ya que no todos aceptan todos los mensajes.

En concreto:

• Para el iPhone, un mensaje que mate el proceso CommCenter, deja al teléfono totalmente incomunicado ya que no sólo bloquea las llamadas y los SMS sino también el WiFi y el Bluetooth. Si el mensaje sólo mata el proceso Springboard, el teléfono se queda 15 segundos fuera de la red. Colin contaba que en Defcon hicieron un ataque a un amigo, al que le mandaron mensajes como para dejarle sin servicio durante 1 hora. Sin embargo, la red se vio tan saturada de mensajes, que aún estaba enviándolos al cabo de 2,5 horas (y por supuesto, el teléfono seguía incomunicado...). Un segundo ataque consiste en enviar 519 mensajes, uno cada segundo, que como son todos parte de un mensaje multiparte, al usuario le aparecen como uno sólo y que al final son capaces de ejecutar código (aunque no tienen todavía escrito ningún exploit).
  

• Android: Un mensaje cualquiera enviado al puerto de WAP push mata el proceso com.android.phone, que es el que se comunica con el SIM, el teléfono se queda incomunicado, ya que requiere el PIN del usuario para acceder al SIM. Además, el teléfono falla silenciosamente (y una vez desconectado no recibe mensajes) y por tanto el usuario no se va a dar cuenta de que está incomunicado hasta que mire el teléfono. Esto sólo funciona en las redes europeas, en AT&T no funciona.
  

• Windows Mobile: Se atacó el teléfono HTC Touch, y en ese caso si se envía un mensaje sms conteniendo %n, el proceso GUI (TouchFlo) se muere y no puede volver a arrancarse mientras el SMS no se borre de la bandeja de entrada (con las herramientas de SMS incluidas en Windows Mobile). Al ser previsiblemente el problema derivado de una sustitución de cadenas incorrecta, el problema debería ser explotable, aunque al no ser genérico para todos los Windows Mobile su amplitud es limitada. Sin embargo, la explotación de una vulnerabilidad tan simple se puede hacer con herramientas muy sencillas, como por ejemplo, directamente desde una cabina de teléfono (que ya casi todas permiten mandar SMS).
  

De todos modos, ya hay soluciones para todos los problemas en las últimas versiones de los tres sistemas operativos (bueno, salvo para el de los 519 mensajes).