En cuanto al método de prueba, en buena parte se basa en herramientas públicas, pero con añadidos propios. Han utilizado una versión de OpenBSC modificada para permitir inyectar mensajes y detectar los fallos de los teléfonos, además de una aplicación java en los teléfonos que monitoriza que los teléfonos sigan vivos.
Eso sí, no todo el mundo tiene una caja de Faraday como ellos para poder operar las pruebas sin necesitar una licencia de uso del espectro.
Con esto pueden automatizar gran parte del proceso de enviar 120 mil mensajes a cada teléfono para ver cuál de ellos tiene algún efecto negativo sobre el teléfono, variando los diferentes parámetros de un SMS que son vulnerables: la cabecera utilizada para mensajes multiparte, la notificación de MMS que tiene varias cadenas de longitud variable, los Flash SMS (una funcionalidad poco utilizada y por eso poco depurada) y el propio alfabeto del texto, sobre todo.
Contodo esto, ¿qué han encontrado? Pues que casi nadie se salva...
- En el sistema operativo de Nokia S40, sobre todo en teléfonos antiguos (en los nuevos los errores ya están arreglados), hay un mensaje que causa que el teléfono rearranque. Además, hay un "watchdog" en el teléfono que si detecta varios rearranques seguidos, apaga el teléfono. Para empeorar las cosas, el error causa que el mensaje no sea confirmado, y así la red intenta reenviar el mensaje, causando los rearranques.
- Sony Ericsson: Con un campo TP-PID inválido, el teléfono le pasa más o menos lo mismo que al Nokia, el teléfono rearranca. Eso sí, un teléfono se estropeó permanentemente.
- LG: aunque sólo probaron con un teléfono (GM360), también era vulnerable a notificaciones de MMS alteradas que causan un "buffer overflow". En este caso, además si el teléfono tiene PIN se queda permanentemente desconectado de lared.
- Samsung: en el caso del Samsung Star y el Corby, encontraron dos problemas: uno que muestra un mensaje de varios Megas que no se puede borrar y otro lo desconecta de la red sin que el usuario se entere (la maldición del silencio).
- Motorola: Los Razr y Rockr son bastante frágiles y si se mandan mensajes multi parte incompletos no se muestran pero tampoco se pueden borrar. No lo probaron demasiado porque se caían fácilmente.
- Micromax (un teléfono de la India, el tercer fabricante del país): También se desconecta de la red mediante un mensaje incompleto (pero Flash SMS).
El hecho de que algunas vulnerabilidades hagan que los mensajes no sean asentidos ha prmitido probar el tiempo de reenvío de los operadores alemanes: van aumentando el tiempo entre reenvios, y algunos se dan por vencidos antes que otros, siendo el que más intentos hace T-mobile, que además va aumentando gradualmente el tiempo entre intentos.
Si existen todas estas posibilidades de ataque, ¿qué problemas plantean? Por un lado, alguien podría atacar un teléfono concreto a base de enviar SMS cada segundo... lo cual sólo es útil si un teléfono concreto es muy importante.
Pero por otro lado, ¿qué pasaría si hubiese ataques a gran escala? Tres ejemplos de ataque:
- Desconectar 10k usuarios a la vez de un operador móvil virtual. ¿sobreviviría su red a un grupo tan grande de usarios reconectándose todos al mismo tiempo?
- Alguien malicioso que ataca los teléfonos de un fabricante, para que parezcan malos podría arruinarlo...
- Incluso se podría causar serios problemas a los servicios públicos de emergencia o a las grandes concentraciones de gente...
- Operadores de envío de SMS, que no suelen comprobar demasiado qué hacen los clientes (HSL, clickatell, routomessaging).
- Crear una botnet con smartphones y utilizarla para el ataque. Tiene la ventaja que al atacante le sale barato... aunque todavía no es fácil de conseguir.
- El nirvana sería claramente tener un enlace SS7 de verdad, lo cual sólo está al alcance de unos pocos....
La conclusión es que claramente es necesario mejorar este proceso de actualizaciones de los teléfonos y revisar su seguridad.
No hay comentarios:
Publicar un comentario