Google ha publicado un informe en el que resume el estado de seguridad de su plataforma móvil Android.
El documento recoge un año de correcciones y mejoras del sistema operativo móvil en materia de seguridad. Implementación de nuevos mecanismos y parches que cierran agujeros de seguridad conocidos. El informe gana peso en un importante aspecto que Android tiene como asignatura pendiente: El Malware.
Vamos a hacer un repaso de los puntos destacados del informe, teniendo siempre en cuenta que no se trata del informe de un tercero independiente, por lo que las conclusiones aportadas en el siempre estarán contrapesadas con dosis apropiadas de optimismo dogmático.
Comentar que las nuevas medidas de seguridad, adoptadas durante 2014, van orientadas a su uso en la versión 5.0 del sistema operativo. 4.4 representa ya el pasado y es costumbre el borrón y cuenta nueva. Tabula rasa.
SELinux
En primer lugar tenemos la activación por defecto del modo «enforced» para todos los dominios en SELinux. Hasta la versión 4.4, SELinux solo se aplicaba en este modo a los dominios asociados al sistema. Este modo es el que permite a SELinux funcionar denegando los accesos a recursos si no se cumplen los requisitos adecuados.
Hasta ahora solo los procesos del sistema se beneficiaban de esta medida, estableciendo una capa extra para obstaculizar la explotación o minimizar su impacto. A partir de Android 5.0 todos los procesos pasarán por el filtro de SELinux.
Cifrado de disco
Hasta la versión 3.0 de Android, el cifrado de disco tomaba como clave el patrón o contraseña de desbloqueo de la pantalla de acceso. A partir de la versión 5.0 la contraseña del usuario es usada para obtener una clave derivada usando una implementación de ‘scrypt‘. Es dicha clave derivada la que se usará para cifrar el disco. Esto permite mejorar la resistencia frente a ataques de fuerza bruta sobre la clave de cifrado. Adicionalmente, en sistemas que dispongan del hardware adecuado, la clave se almacenará en un chip dedicado a almacén de claves.
Perfiles de usuarios
A partir de Android 5.0 se habilita en teléfonos inteligentes la capacidad para añadir perfiles y un modo invitado que no permite acceso a datos ni aplicaciones. Hasta ahora y desde la versión 4.2 solo los dispositivos Tablet permitían múltiples perfiles.
Autenticación «mejorada«
De nuevo, solo en la versión 5.0, se permite el desbloqueo automático del terminal si se encuentra cerca de un dispositivo autorizado o se efectúa un reconocimiento positivo del rostro del usuario.
Tal y como es descrito no se entiende como esto es presentado como medida de seguridad. A pesar de los avances en identificación y autenticación biométrica esta tecnología suele usarse como segundo factor. Recordemos la evasión del lector de huellas del iPhone 5s o la de reconocimiento facial que ya se empleaba en la versión Jelly Bean del propio Android.
Respecto del desbloqueo por proximidad radio (NFC, Bluetooth…) entendemos que se trata de una funcionalidad que aumenta la usabilidad por comodidad del equipo pero naturalmente la moneda de cambio habitual suele ser un detrimento de la seguridad. Un desbloqueo automático suena mal, muy mal, desde el punto de vista de la seguridad. ¿Necesitas acceder al teléfono de alguien? ¿Está en una reunión? ¿Se ha dejado el teléfono y las llaves del coche sobre la mesa? ¿Necesitamos poner otra interrogativa a modo de pregunta retórica?
Parches
En total, según el equipo de seguridad de Android, se han corregido 30 parches de gravedad alta, 41 moderados y 8 de gravedad baja. Los parches de seguridad no son publicados directamente en el repositorio de código público. En vez de ello, existe una rama con acceso a esta clase de parches para los fabricantes, con el fin de que corrijan las vulnerabilidades en sus propias versiones de Android antes de que sean reveladas.
Llama la atención un dato. Solo han observado una explotación «significante» de una vulnerabilidad: CVE-2014-3153. Usada para elevar privilegios en local o lo que es lo mismo, usada para rootear el dispositivo.
De la misma forma comentan que no han observado explotación de vulnerabilidades asociadas a SSL y que lo poco que han visto «parece» estar vinculado a labores de investigación.
Sobre FakeID, la vulnerabilidad presentada en la conferencia BlackHat USA de 2014, que permitía instalar una aplicación sin necesidad de que el usuario concediese permisos, indican que han detectado una aplicación subida a Google Play y otras 258 procedentes de fuentes de terceros que hiciesen uso de esta vulnerabilidad.
Android y los fabricantes
La relación entre fabricantes y Android (Google) es de una tensa calma. Por un lado los fabricantes introducen modificaciones y aplicaciones propias que les permite aportar diferenciación entre la competencia. Por otro lado, ese dechado de buena voluntad e individualización abre la puerta a nuevos y únicos defectos que son aprovechados como vectores por los atacantes.
De manera característica los fabricantes demoran la publicación de parches, esto se traduce en una ventana de exposición larga y en cierta medida una percepción negativa de Android en su conjunto para el usuario final. Esto mismo no ocurre en la misma medida con los dispositivos administrados por Google, que suelen experimentar actualizaciones de seguridad más frecuentes. Por supuesto, siempre en el caso de que la versión de Android no esté condenada al ostracismo.
El equipo de seguridad de Android mantiene una observación de este tipo de vulnerabilidades y sostiene que la mejora de operación de SELinux permitirá contener los daños del impacto en caso de explotación. Un palo en medio de mar montañosa, sin embargo no pueden hacer mucho más si el fabricante tiene el canal de actualización del sistema por el mango.
Verify Apps
Android incluía un sistema para detener y avisar al usuario de aplicaciones maliciosas. Una suerte de antivirus básico. Su ámbito se circunscribía en las aplicaciones descargadas a través de Google Play. En abril del pasado 2014 se anunció que ese ámbito estaba siendo ampliado a todas las aplicaciones, incluidas las de otros mercados. El usuario también tiene la opción de subir aplicaciones fuera de Google Play a Google para su análisis.Actualización de componentes fuera del OTA
Interesante. Google ha habilitado un canal de actualización para que ciertos componentes pueden ser parcheados sin tener que esperar a una actualización completa del sistema a través de OTA (Over The Air). De momento solo puede efectuarse sobre una versión de SSL mantenida por Google y el infame componente WebView que podrán ser actualizados sin necesidad de esperar a un ciclo de publicación de actualizaciones. Por supuesto, a partir de Android 5.0.
Google asume que ciertos componentes pueden y deben ser tratados con prioridad. Además le toman la iniciativa a los fabricantes. Los usuarios podrían ver como ciertas vulnerabilidades son corregidas sin necesidad de esperar meses o indefinidamente a que el fabricante publique un parche.
Aviso a desarrolladores
Desde el pasado mes de julio, las aplicaciones subidas a Google Play son examinadas en busca de vulnerabilidades conocidas. Evidentemente es un proceso automatizado, pero se agradece que los desarrolladores sean avisados de la supuesta presencia de errores de seguridad conocidos en sus aplicaciones a fin de que puedan corregirlos.
Decir proceso automatizado y búsqueda de vulnerabilidades en el mismo párrafo es lo mismo que hablar de falsos positivos. Naturalmente se corre el riesgo de alarmar sobre algo que no existe pero es siempre preferible comprobar algo que darlo por bueno.
Estadísticas de infección
Los datos proceden de su servicio, el comentado «Verify Apps«. Las aplicaciones de Google Play son escaneadas cuando son subidas y periódicamente durante el tiempo que están alojadas. Con ello, Google cuenta con datos directos de las aplicaciones alojadas en Google Play y aquellas que están instaladas en los terminales Android.
Según se puede leer en el informe, Google sostiene que menos de un uno por ciento de dispositivos (entiéndase, con Verify Apps activo) contiene una PHA (Potentially Harmful Application) instalada. Es más, reduce ese porcentaje al 0,15% si se trata de dispositivos que instalan aplicaciones exclusivamente desde Google Play.
Destaca la tasa por encima de la media de dispositivos Android en Rusia y China. Explicable en parte por la no presencia (Google Play fue prohibido en China) o preferencia por mercados de terceros en el ámbito nacional.
El problema quizás no es ese «menos del 1%» en su imagen y sí ese «más de 90%» comparado con otras plataformas móviles.
Tipos de malware
Bajan los clásicos: spyware y los SMS senders. Mientras el malware tipo Ransomware es visto «rentable» a ojos de los desarrolladores de malware y comienza a despuntar progresivamente.
Safety Net
Por último cierra el informe los datos relativos a Safety Net. Una suerte de hookeo de ciertas API marcadas como posible «uso por abuso«. Dicho sistema comprueba cómo son llamadas estas funciones y reacciona si detecta un abuso.
Llama la atención el apartado de «Hombre en el medio«. Desde Android 4.2 fue introducido el «Certificate pinning«, a partir de la versión 4.4 el sistema avisa de aquellos certificados instalados en la CA del sistema y que son usados para efectuar capturas de comunicaciones cifradas en texto claro. Una ventanita que venimos «padeciendo» quienes hacemos auditoría de aplicaciones cuando instalamos un certificado en la CA.
En la parte positiva se ven los esfuerzos y los frutos conseguidos por la inversión de seguridad. Más medidas de seguridad, menores tasas de infección. Sin embargo el malware sigue creciendo en Android, se siguen detectando más tipos de familias y técnicas de infección más avanzadas que permiten ir por debajo de la línea del radar de la detección automatizada o evadir ciertas medidas de seguridad.
Lo dicho anteriormente. Android reduce la tasa de infección a ojos de los datos expuestos por el informe de Google. Ese «1%» es cada vez menos uno por ciento. Sin embargo ese «más del 90%» (que evidentemente no dice) cuando se compara con el resto de sistemas móviles pesa mucho, muchísimo.
Más información:
Android Security State of the Union 2014 (PDF)
«Mobile Thread Report Q1 2014» F-Secure (PDF)
una-al-dia (22/09/2013) El grupo Chaos Computer Club consigue saltar el sistema TouchID del iPhone 5s
una-al-dia (24/09/2014) El lector de huellas del iPhone 6 sigue siendo vulnerable
David García
Twitter: @dgn1729
Deja una respuesta