Ha sido la noticia del día, y previsiblemente seguirá dando coba este mes. Y me habéis estado preguntando por ello durante las últimas horas, así que creo conveniente escribir este artículo con todo lo que se sabe actualmente.
Conforme nos acercamos a la DefCon y la BlackHat (dos de las conferencias de hacking más importantes del mundo), nos empieza a llegar a cuentagotas información sobre nuevos 0days que ponen los pelos de punta.
En este caso, tocaba el turno de Android, que parece presentar una vulnerabilidad (un ataque basado en varias vulnerabilidades, para ser exacto) que por su idiosincracia apunta a ser de las más graves hasta la fecha.
Stagefright (EN) es el nombre elegido, siguiendo la tendencia actual del branding del sector, y con una imagen de marca propia (esa careta que he puesto en la cara de nuestro querido Android enfermo).
Y stagefright es también el nombre de la biblioteca de Android afectada.
Cómo funciona el ataque
Para ello, tenemos que dirigirnos al blog de Zimperium, arriba enlazado, y empresa que alertaba de esta manera lo que Joshua Drake, trabajador de la compañía, va a presentar en estas conferencias.
El objetivo es causar hype de cara a tan citados eventos, por lo que han sido vagos a la hora de definir el ámbito de actuación y demás aspectos técnicos.
Básicamente, estamos ante un ataque que aprovecha una corrupción de memoria (sí, otra más) en Stagefright (EN), la biblioteca de Android, escrita en C++ y encargada de la gestión de medios (ver vídeos y escuchar música, principalmente).
Según comentan en el artículo, han encontrado la forma de, mediante el envío de un MMS convenientemente modificado, llegar a hacerse con el control del terminal.
Y es que es precisamente este hecho uno de los que más controversia está causando, porque hablamos de un ataque en el que la víctima no tiene que hacer absolutamente nada, y que de hecho, y si en verdad el lobo acaba siendo tan fiero como parece, podría incluso ni enterarse (borrando la notificación y el mencionado MMS una vez el terminal está infectado).
Ha sido lanzar la alarma, y varios expertos del sector se han puesto a desgranar las posibles opciones.
Atendiendo a los permisos de Stagefright, en principio para usuarios no root, los atacantes tan sólo podrán tener acceso a la cámara, micrófono y almacenamiento externo del dispositivo. Sin embargo, con permisos de administrador se tendría acceso a todo el sistema.
Por otro lado, Stagefright parece formar parte de un grupo de sandbox con permisos de acceso a internet, así que es posible que este investigador haya encontrado la manera de aprovechar alguna otra vulnerabilidad para hacer escalado de privilegios (quizás apoyándose en algún exploit web más clásico) y tomar el control pese a no ser root. Y en algunos dispositivos, parece tener acceso al gestor de grupos de sistema, que tiene permisos prácticamente de root.
En definitiva, y a unos días de conocer en verdad los entresijos del ataque, la vulnerabilidad apunta a ser de las más críticas a las que se ha enfrentado Android, ya que afecta desde la versión Froyo (2.2) en adelante, lo que representa el 95% de terminales presentes en la sociedad.
Y así llegamos a la guinda del pastel, que es precisamente el punto que me ha llevado a escribir el artículo.
Los investigadores han realizado un Responsible Disclosure (avisar a la compañía, en este caso Google, antes de hacer público la metodología del ataque), y comentan por VentureBeat (EN) que los ingenieros de Google ya han parcheado el ataque en el núcleo de AOSP (ya sabe, el Android sin Google).
Pero esto no asegura, prácticamente en ningún caso, que ese parche acabe llegando a ese 95% de terminales vulnerables, debido a dos factores críticos en la plataforma.
La fragmentación de Android y la externalización de OTAs
Que Google haya liberado ya un parche para Stagefright es solo el primer paso, y no hay seguridad de que este parche acabe llegando a la mayoría de terminales en el mercado.
Primero porque Google no libera directamente hacia los usuarios, sino hacia los fabricantes, que son, en última instancia, los que deben decidir si esa actualización tiene que ser enviada o no a sus clientes.
Y lamento informar que la mayoría rara vez han actualizado el sistema por un parche, por muy crítico que sea.
Los flagship de cada marca seguramente acaben por recibir el parche en alguna OTA lanzada no con la excusa del parche, sino por una actualización mayor donde este parche, junto con otros muchos, viene incluido.
Pero para el grueso de terminales en el mercado, no habrá cobertura por parte de los fabricantes, que suelen disponer recursos únicamente para los nuevos modelos y no para el stock anterior (y que de hecho, hacen así porque así interesa para el negocio).
El que exista una fragmentación aplastante en Android tampoco ayuda. Muchas versiones distintas, que para colmo tienen que pasar por la capa de personalización del fabricante y por la de las operadores, hacen en definitiva impracticable una OTA general.
Es, de hecho, uno de los principales problemas que tiene un sistema operativo abierto a terceros como Android frente al encapsulado de iOS, que depende única y exclusivamente de las decisiones de Apple.
¿Qué podemos hacer para defendernos de Stagefright?
La respuesta obvia sería parchear la vulnerabilidad. Si eres usuario de algún dispositivo de la gama Nexus, es posible que estés de suerte, ya que Google suele tomarse (como es normal) estas cuestiones muy seriamente. En caso contrario, quizás nuestro fabricante acabe por sacar una actualización para ese terminal de última generación del que disponemos, pero si no es así, puede que acabe liberando un parche convenientemente testado en su propia ROM de forma genérica, que podamos descargar de su web y actualizar.
Para el resto de terminales, quizás sería un buen momento para plantearse cambiar a una ROM que se actualiza cada cierto tiempo, como ocurre con la de Cyanogen.
En caso de que esta opción esté descartada, todavía quedaría una alternativa.
La vulnerabilidad se aprovecha de la ejecución automática de mensajes MMS. Por tanto, ¿por qué no desactivar por defecto esta ejecución?
Considere que habitualmente solo el gestor nativo de SMS/MMS suele tener este tipo de ajustes, y que en caso de que no disponga de ellos, quizás debamos instalar otro que si lo ofrezca.
E incluso podríamos considerar desactivar la compatibilidad con MMS, porque seamos sinceros. ¿Quién usa hoy en día MMS más que las operadoras para lanzarnos publicidad?
Estas son las únicas medidas conocidas para evitar ser víctima de un ataque que recuerdo, no depende de ninguna acción por parte de la víctima. En unos días, la metodología del ataque se hará pública, y empezarán a llover botnets, herramientas de control remoto (RATs) y demás malware aprovechándose de la principal debilidad de Android: su nula capacidad (como le pasa a la mayoría de plataformas de IoT) para hacer llegar parches al usuario final.
Voy a ver como desactivo la lkegada de mms, buen dato! Tanto androud tanto android para wsto. Por tas cosas también odio WhatsApp y Facebook
Échale un ojo a los ajustes de la aplicación de SMS. Debería estar por allí Mina.
Saludos!
La seguridad es un eterno problema en lo sistemas operativos. Tomemos el ejemplo de windows: es el So mas usado en PC y es muy inseguro. Cierto que Microsoft libera actualizaciones de seguridad y te las hace disponibles, pero aqui viene el problema de los usuarios. A muchos no nos gusta recibir actualizaciones, porque a veces afectan lo que ya esta funcionando, o inhabilitan cierto componente, o simplemente no las queremos. Peor aún los que tienen sistemas ya no cubiertos como es XP, que sigue siendo muy presente.
Claro que uno decide, pero al final la fragmentación es algo real.
Android en general es mas seguro, pero no es invulnerable. Hasta la fecha ninguno de mis múltiples Android ha sido infectado nunca por un virus, cosa que no puedo decir de mi pobre laptop con windows 7/10.
Es algo con lo que tenemos que vivir y como usuarios solo queda tomar las debidas precauciones.
Android (o iOS) son SO de nueva generación, y vienen con la lección aprendida.
Si te fijas los dos son SO cerrados, en tanto en cuanto gestionan roles y permisos para acceder a funcionalidades del propio sistema. Esto facilita en teoría la gestión del riesgo, cosa que en Windows no tenemos, y han apañado con el administrador por encima.