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
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)
https://static.googleusercontent.com/media/source.android.com/en/us/devices/tech/security/reports/Google_Android_Security_2014_Report_Final.pdf
"Mobile Thread Report Q1 2014"
F-Secure (PDF)
https://www.f-secure.com/documents/996508/1030743/Mobile_Threat_Report_Q1_2014.pdf
una-al-dia (22/09/2013) El grupo
Chaos Computer Club consigue saltar el sistema TouchID del iPhone 5s
http://unaaldia.hispasec.com/2013/09/el-grupo-chaos-computer-club-consigue.html
una-al-dia (24/09/2014) El lector
de huellas del iPhone 6 sigue siendo vulnerable
http://unaaldia.hispasec.com/2014/09/el-lector-de-huellas-del-iphone-6-sigue.html
David García
dgarcia@hispasec.com
Twitter: @dgn1729