Inicio / Blog / El problema de la fragmentación en las plataformas móviles

El problema de la fragmentación en las plataformas móviles

Publicado el 30/09/2014, por Asier Martínez (INCIBE)
móviles

A lo largo de los últimos años Google ha trabajado para reducir este problema con medidas como por ejemplo «Google Play Services», que permite actualizar las aplicaciones de Google y de Google Play sin necesidad de una actualización completa del sistema operativo. Aun así, como se observa en el siguiente gráfico los usuarios de Android todavía están repartidos en 5 versiones del sistema operativo.

Distribución de las versiones de ANdroid

Este hecho supone que el rendimiento de las aplicaciones sea distinto dependiendo de la versión de Android en la que se ejecute, o incluso el acceso a distintas características o funcionalidades del dispositivo. Es por todo ello que las aplicaciones en Android se desarrollan estableciendo diferentes parámetros como «MinSDKVersion», «MaxSDKVersion» y «TargetSDKVersion». Estos valores corresponden a la versión mínima de Android compatible con la aplicación, a la versión máxima de Android compatible con la aplicación y a la versión óptima, y normalmente con la que la aplicación ha sido testeada.

Desde el punto de vista de la seguridad de los usuarios, la fragmentación supone un problema mayor ya que la mayoría de las vulnerabilidades que se identifican, únicamente son parcheadas para la última versión del sistema operativo, dejando en peligro a la mayor parte de los usuarios de la plataforma.

Este hecho, en el caso de iOS, es un problema que no está tan presente ya que en el momento en el que Apple lanza una nueva versión del sistema operativo, transcurre un breve período de tiempo hasta que la mayoría de sus dispositivos adoptan dicha versión. Si bien es cierto que hay dispositivos para los que no está disponible la nueva versión, normalmente son aquellos con una antigüedad que puede considerarse que han finalizado su vida útil, cosa que no sucede con los de Android.

Distribución de las versiones de iOS

El motivo principal de dicha fragmentación es que Google, con el fin de que Android estuviera presente en el mayor número de dispositivos móviles, lo hizo de código abierto, de modo que cualquier fabricante puede desarrollar terminales que incorporen dicho sistema operativo, recayendo sobre ellos la responsabilidad de hacer disponibles las nuevas versiones del sistema operativo. Un estudio de la empresa OpenSignal certifica la existencia de más de 18.000 modelos distintos de terminales que incluyen sistema operativo Android, lo que supone un incremento del 60% con respecto al año 2013.

18.000 modelos distintos de dispositivos Android

Este incremento hace prever que el objetivo de alcanzar una solución para la fragmentación está lejos de cumplirse. En el caso de Apple, al ser los únicos fabricantes de terminales con sistema operativo iOS, tienen un mayor control tanto sobre los dispositivos como sobre las actualizaciones. A continuación se indican algunas de las vulnerabilidades de Android que suponen un mayor riesgo y que todavía no han sido parcheadas para las versiones anteriores a la última, es decir, para alrededor de un 79% de los usuarios de la plataforma.

Master Key – Bug #8219321 - CVE-2013-4787 – Fichero duplicado

Android, como medida de protección, obliga a firmar todas las aplicaciones. Dicha firma, permite comprobar la integridad de la APK, ya que contiene el hash de cada uno de los ficheros de la misma. De este modo, en el momento de la instalación, el gestor de aplicaciones de Android, comprueba que dichos hashes sean correctos y así se cerciora de que la APK no haya sido modificada. Desafortunadamente, los certificados no pasan obligatoriamente el control de una autoridad certificadora sino que pueden ser autofirmados, por lo que no supone un mecanismo de seguridad especialmente seguro.

En marzo del 2013, investigadores de Bluebox dieron a conocer una vulnerabilidad conocida como «MasterKey», que fue posteriormente detallada en la conferencia «Android: One Root to Own Them All», en la Black Hat USA 2013. El fallo de seguridad permitía incluir código arbitrario en cualquier APK firmada por un desarrollador sin alterar la firma. Para ello, se debía incluir en la APK dos ficheros con el mismo nombre, de modo que la verificación de Android se aplicaba únicamente sobre el primero ejecutando posteriormente el segundo.

Con el fin de corregir este fallo, Google implementó una medida de seguridad, la cual analiza los nombres de los ficheros incluidos en el fichero APK, de modo que si existe algún nombre duplicado muestra un mensaje de error durante el proceso de instalación.

Dicha solución fue implementada en la versión de Android 4.2. La solución para las versiones anteriores quedó a la espera de las actualizaciones provistas por los fabricantes de los terminales que, como se ha comprobado, después de más de año y medio, en algunos casos, todavía no han llegado a los usuarios. Investigadores de System Security Lab y Duo Security lanzaron una aplicación móvil para dispositivos rooteados llamada ReKey que corregía la vulnerabilidad, con el fin de que los usuarios no tuvieran que esperar dichas actualizaciones. Para comprobar si un dispositivo está afectado se puede utilizar la aplicación Bluebox Security Scanner disponible en Google Play. play.google.com/store/apps/details?id=com.bluebox.labs.onerootscanner&hl=es (Enlace no disponible actualmente)

Bug #9950697 - «Name Length Field»

La vulnerabilidad, descubierta por Jay Freeman (saurik) (desarrollador de Cydia) a principios de Noviembre del 2013, es una variante de la anteriormente descrita «Master Key». Dicho fallo está relacionado también con la verificación de las firmas de las APKs y afecta a todas las versiones de Android anteriores a la 4.4 (KitKat).

Es posible acceder a un análisis detallado de la misma en el propio blog del investigador.

Para comprobar si un dispositivo está afectado por esta vulnerabilidad es posible utilizar la aplicación SRT AppScanner disponible en Google Play. play.google.com/store/apps/details?id=de.backessrt.appintegrity (Enlace no disponible actualmente)

Heartbleed - CVE-2014-0160

A principios de Abril del 2014, investigadores de Google hicieron pública una vulnerabilidad descubierta en las librerías OpenSSL. Mediante dicha vulnerabilidad, que ha sido conocida como «HeartBleed», es posible obtener información sensible como credenciales o datos cifrados de los sistemas afectados con la funcionalidad Heartbeat activada.

Para comprobar si un dispositivo está afectado por esta vulnerabilidad, que afecta a las versiones de Android anteriores a la 4.3, es posible utilizar las aplicaciones Bluebox Heartbleed Scanner play.google.com/store/apps/details?id=com.bblabs.heartbleedscanner (Enlace no disponible actualmente) o Heartbleed Segurança Escáner disponibles en Google Play.

Bug #9950697 - «Extra field»

A principios de Julio del 2014, un investigador chino hizo pública una vulnerabilidad en Android mediante la cual era posible modificar el contenido de una APK sin modificar la validez de su certificado. Pese a que dicha vulnerabilidad es difícil de explotar y sólo se da en ciertos casos (modificando aquellos ficheros classes.dex con un tamaño inferior a 64kb), podría permitir a un atacante obtener información sensible del usuario afectado.

Es posible acceder a un análisis detallado en el blog de Sophos

Para comprobar si un dispositivo está afectado por esta vulnerabilidad es posible utilizar la aplicación SRT AppScanner disponible en Google Play.

CVE-2013-6272

A principios de Julio del 2014, investigadores de Curesec hicieron pública una vulnerabilidad que afectaba a todas las versiones de Android anteriores a la 4.4.3, más del 70% de los usuarios de la plataforma. Mediante el aprovechamiento de dicha vulnerabilidad relacionada con com.android.phone, una aplicación, expresamente diseñada para ello, podría realizar llamadas telefónicas a números de tarificación adicional sin interacción por parte del usuario, lo que podría provocarle un importante perjuicio económico.

Es posible comprobar si un dispositivo está afectado por la vulnerabilidad mediante la instalación de la aplicación habilitada por Curesec para tal fin.

FakeID – Bug #13678484

A finales de Julio de 2014, investigadores de Bluebox hicieron pública la vulnerabilidad conocida como «FakeID», que ha sido posteriormente detallada en la conferencia «Android Fake ID Vulnerability», en la Black Hat USA 2014. La vulnerabilidad, que lleva afectando a usuarios de Android desde Enero del año 2010, reside en que el instalador de paquetes de Android no comprueba la cadena de certificación, de modo que si se falsea el emisor del certificado de una aplicación, Android no se percatará de tal hecho y lo tomará como un certificado válido.

Dicha vulnerabilidad afecta a todas las versiones de Android, a excepción de la 4.4 (KitKat) que ya fue parcheada por Google.

Al igual que en el caso de «Master Key», para comprobar si un dispositivo está afectado se puede utilizar la aplicación Bluebox Security Scanner play.google.com/store/apps/details?id=com.bluebox.labs.onerootscanner&hl=es (Enlace no disponible actualmente) disponible en Google Play.

CVE-2014-6041

Recientemente, el investigador Rafay Baloch ha publicado una vulnerabilidad que afecta al navegador por defecto presente en cerca del 75% de los dispositivos Android. Esta vulnerabilidad permite eludir la política de SOP (Same Origin Policy), de manera que es posible obtener tanto información del resto de las páginas abiertas en el navegador como acceder a las cookies, y en el caso de que no estén protegidas, utilizarlas para suplantar a los usuarios afectados o secuestrar sus sesiones.

A esta lista de vulnerabilidades hay que añadirle aquellos fallos provocados por el desarrollo inseguro de las aplicaciones. Investigadores de FireEye han llevado a cabo el análisis de las 1.000 aplicaciones más descargadas de Google Play, evaluando para ello diferentes aspectos como la validez de los certificados digitales mediante la comprobación de la cadena de certificación «certificate pinning», verificación del host de conexión y gestión de errores SSL cuando se utiliza Webkit como motor de renderizado de páginas web en una aplicación, como el caso cuando se desarrollan aplicaciones con frameworks multiplataforma como Córdova.

Tras llevar a cabo el análisis han llegado a las siguientes conclusiones:

  • El 73% de las aplicaciones analizadas no comprueban la validez de los certificados.
  • El 8% de las aplicaciones analizadas no verifican los hosts de conexión.
  • El 77% de las aplicaciones analizadas no gestionan los errores SSL cuando se utiliza Webkit.

Así mismo, como fue demostrado también por investigadores de FireEye, gran parte de las librerías de monetización que incorporan las aplicaciones con el fin de obtener beneficio económico están desactualizadas, son vulnerables y exponen directamente la información de los usuarios frente a ataques «Man In The Middle».

Conclusiones

Es por todo ello que, como se ha indicado en otras ocasiones, Google como máximo responsable en el desarrollo de Android, debe tomar las medidas necesarias y hacer un esfuerzo para mejorar la seguridad de la plataforma que ya ha alcanzado los 1.000 millones de usuarios activos y una cuota de mercado de más del 87% en España. Dichas medidas deben incluir reducir la fragmentación en la medida de lo posible. Un paso importante al respecto es el lanzamiento de Android One, el sistema operativo de Android para terminales de bajo coste. Con esta versión de Android, Google se responsabiliza de enviar las actualizaciones directamente a los dispositivos móviles sin necesidad de interacción por parte de los fabricantes de los mismos, y así asegurar que la gama de terminales que lo incluyan no sufran el acusado problema de la fragmentación.

Obviamente, pese a que la responsabilidad final recaiga sobre Google, es responsabilidad de todos los agentes implicados tomar las medidas oportunas para mitigar los riesgos y fallos de la plataforma:

Los fabricantes de dispositivos móviles deben involucrarse más en la seguridad de los terminales que fabrican, y ser rápidos y eficientes a la hora de proveer de actualizaciones a los mismos.

Los desarrolladores de aplicaciones deben seguir metodologías cuya máxima sea el «security by design» y que permitan evaluar la seguridad de las aplicaciones, como es el caso de OWASP u OASAM. Como se indicó en el post «Desarrollo seguro de aplicaciones para dispositivos móviles», dichas metodologías tienen como objetivo identificar los peligros correspondientes a la seguridad de dispositivos móviles y proporcionar los controles necesarios en el desarrollo para reducir su impacto y la probabilidad de explotación de los mismos.

Otro aspecto muy importante que deben tener en cuenta los desarrolladores es que a la hora de desarrollar una aplicación se acostumbra a reutilizar código; no vamos a reinventar la rueda. Según un informe de la compañía Codenomicon publicado en RSA Conference USA 2014, entre el 80% y el 90% del software desarrollado para dispositivos móviles se realiza a partir de código reutilizado. En la mayoría de los casos no se tienen en cuenta los fallos de seguridad que puede tener el código reutilizado. De este modo, en muchas ocasiones se da el caso que ni los desarrolladores, ni los usuarios finales tienen constancia de los fallos que incluyen dichas aplicaciones, estando expuestos estos últimos.

Por su parte, los usuarios finales deben seguir los consejos que se indican en el portal de la Oficina de Seguridad del Internauta: