26 diciembre 2013

Actualidad del malware en Android (2 de 3)

Autor: Contribuciones 26 diciembre 2013 [ 8:00 ]
En el post anterior se trataron los temas más generales que se vieron en la charla de 7ENISE sobre la actualidad del malware en Android. En este segundo post pretendo realizar un resumen sobre las vulnerabilidades más importantes que aparecieron en Android desde julio de 2013 (varias de ellas se presentaron en la Blackhat/DEFCON).

1. El caso de la vulnerabilidad en SecureRandom

A principios del mes de agosto saltó una noticia relacionada con una supuesta vulnerabilidad en las aplicaciones de gestión de carteras bitcoin de Android. No fue hasta el 11 de agosto cuando se publicó un post al respecto en la página bitcoin.org en el cual se alertaba de un problema en la generación de números aleatorios en Android que provocaba que cualquier monedero generado desde alguna aplicación de este sistema operativo era susceptible a ser robada. Tres días más tarde, se publicó un post en el blog de desarrolladores de Android en el que se dieron detalles técnicos de la vulnerabilidad y el código que tenían que incorporar los desarrolladores a sus aplicaciones para solucionar el problema.

El problema se encontraba en la inicialización del generador de números aleatorios -PRNG- (ya sea el de JCA o el de OpenSSL). Tal y como se comentaba en el post "oficial", básicamente era necesario (por parte del desarrollador) añadir una semilla aleatoria al PRNG para aumentar la entropía de éste. De ahí que no se vieran afectadas las conexiones TLS/SSL establecidas por "HttpClient" o "java.net.*" dado que éstas sí incializaban correctamente el PRNG.

Podéis acceder al código que soluciona esta vulnerabilidad en el propio post "oficial". Simplemente tendréis que añadir a vuestra aplicación la clase "PRNGFixes" y llamar a "PRNGFixes.apply()" al iniciarla.

2. Modificación del orden de uso de las suites criptográficas

Relacionado con el caso anterior (aunque no diese mucho que hablar) se hizo público un estudio en el que se mostraba como, desde el año 2010, en Android se había modificado el orden de preferencia de las suites criptográficas para SSL y se había pasado de AES256-SHA a RC4-MD5 (claramente vulnerable).

Si nos fijamos en la evolución del orden de preferencia entre las diferentes versiones de Android (ver Figura 1) podemos observar cómo éste era correcto hasta la versión 2.2 y cómo en versiones posteriores se estableció un nuevo orden manualmente en el propio código de Android, generando uno que prioriza suites criptográficas inseguras (ver Figura 2).

Figura 1 - Orden de preferencia de suites criptográficas
Figura 2 - Cambio del orden de prioridad de las suites criptográficas

Buscando una posible explicación a tan extraña situación se llegó a la conclusión (no-verificada) de que es posible que se tomase esta decisión por temas de compatibilidad (es un order definido por Sun en 2002). Tomad vosotros vuestras propias conclusiones...

3. Vulnerabilidad Master-Key

Durante la conferencia BlackHat USA 2013 la empresa Bluebox hizo pública una vulnerabilidad presente en las librerías de manejo de ficheros comprimidos en Android que permitía realizar la instalación de APKs modificados sin que la comprobación de la firma de éstos fallara[1]. 

Como todos sabemos, cualquier aplicación de Android ha de estar (auto)firmada por su desarrollador. Este procedimiento consiste en calcular el hash(SHA1) de cada uno de los ficheros del APK, y añadir éste junto con el nombre del fichero, en el archivo MANIFEST.MF que, posteriomente, será firmado con la clave del desarrollador (ver Figura 3). En el momento en el que se  modifica un fichero de un APK, al intentar instalarlo en un dispositivo Android se comprobará el hash de cada uno de los ficheros que contiene con el registrado en el fichero MANIFEST.MF y en el caso del fichero modificado éste no será el mismo por lo que la instalación fallará (en el caso de que se añada uno nuevo ocurrirá lo mismo).

Figura 3 - Fichero MANIFEST.MF
Ahora bien, ¿qué ocurre si introducimos entradas duplicadas? Ahí se encontraba la vulnerabilidad... Debido al uso de varias librerías diferentes de manejo de ficheros comprimidos en el proceso de instalación, no se controlaban correctamente los ficheros con entradas duplicadas y, por tanto, al comprobar el hash el proceso no fallaba (existía el fichero legítimo) pero finalmente se instalaba la aplicación con los ficheros modificados (ver Figura 4). Para evitar esta situación, actualmente se comprueba si existe alguna entrada duplicada y, en tal caso, se anula el proceso de instalación (ver Figura 5).

Figura 4 - Fichero APK con entradas duplicadas
Figura 5 - Parche que comprueba si existen entradas duplicadas
 
Posteriormente aparecieron nuevas técnicas[2][3] adicionales a la que mostró Bluebox que permitían seguir modificando aplicaciones sin que la comprobación de la firma de los APKs se viera afectada.

Para comprobar si una aplicación hace uso de alguna de las técnicas que se han publicado, puedes utilizar la aplicación Bluebox Security Scanner u otras como el portal de Zscaler. Con respecto a parchear nuestro sistema (4.3-), se puede hacer uso de aplicaciones como ReKey (pero... ¡requieren root!).

4. Otras vulnerabilidades

A parte de las vulnerabilidades comentadas en los puntos anteriores, también mencioné otras igualmente interesantes, como:

Vulnerabilidad en WebLogin[4]
En la conferencia DEFCON 21 Craig Young de Tripwire mostró una vulnerabilidad existente en el "sistema de autenticación en un solo clic" de Android. Este servicio nos permite generar tokens para distintos servicios de Google sin necesidad de reautenticarnos constantemente. La vulnerabilidad consistía en un error del servicio WebLogin (ya os hablé de él en el post sobre XMPPloit) que permitía otorgar a un token autorización para acceder a todos los servicios de Google (y no únicamente al servicio para el que el usuario lo había autorizado). Por lo tanto, una aplicación podía solicitar un permiso no-crítico como el de acceso al calendario de la cuenta, y apartir del mismo, obtener acceso a los correos de Gmail, archivos en Drive e incluso a Google Play -con lo que ello conlleva...-.

Vulnerabilidades en Firefox[5]
En septiembre Sebastián Guerrero (viaForensics) hizo pública una vulnerabilidad en Firefox para Android que permitía acceder a los ficheros internos de la aplicación (p.e cookies) y a los de la SDCard (lectura permitida para cualquier aplicación). Si bien no permitía una explotación remota (limitándose mucho su usabilidad), se podría haber combinado con otra vulnerabilidad que se publicó en esas fechas que permitía la ejecución automática del instalador de aplicaciones en Firefox (nuevamente, requiere ingeniería social, no es un ataque automático). Su explotación seguiría siendo bastante limitada pero con mayor proyección.

Vulnerabilidad en Cerberus Anti-Theft[6]
En este caso se trata de una vulnerabilidad que afectaba a la conocida aplicación de gestión remota y antirobo de dispositivos Android. Resulta que era posible comprobar si un determinado IMEI estaba registrado en el sistema y, en caso afirmativo, el servicio de Cerberus devolvía el usuario asociado a dicho IMEI y el hash(SHA1) de la contraseña. Si bien hasta aquí ya resulta una situación anómala y delicada (permite realizar un "crackeo" offline de la contraseña), se descubrió que el proceso de recuperación de contraseñas únicamente requería el IMEI del dipositivo y la nueva contraseña. Por lo tanto, uniendo ambos casos nos encontramos con que era posible resetear la contraseña de cualquier dispositivo que utilizara Cerberus y obtener el usuario asociado para poder controlar remotamente el dispositivo. En el caso de que os queráis montar vuestro propio MDM y no depender de servicios de terceros, podéis probar ownMdm (XDADevelopers)

Vulnerabilidad en WebView[7]
En el 6ENISE y en la NocONName 2012 estuve presentando una técnica para inyectar dinámicamente código malicioso en aplicaciones Android que a priori parecen inofensivas[8]. Durante estas ponencias comenté otra técnica que se había presentado ese mismo año en BlackHat USA que consistía en modificar el código JS para modificar el comportamiento de la aplicación y ejecutar código nativo a través de JSBridge. Si bien siempre se comentaba que la aplicación debía de contener el código nativo al que llamase el JS (por ejemplo, el método concreto de envío de SMS), posteriormente se demostró que, dado que por defecto los métodos eran exportables (permitían su invocación a través de JS), no era necesario contener los métodos en la aplicación sino que se podía realizar una llamada directamente a las APIs del sistema. Por lo tanto, ahora únicamente era necesario que la aplicación maliciosa (o "victima" si se estaba explotando en cualquier aplicación que incorporara el componente WebView) tuviera el permiso SMS para que pudiera hacer uso del mismo a través de JS, ver Figura 6). A partir de la versión 4.2 de Android es el propio desarrollador el que tiene que marcar con "@JavascriptInterface" qué métodos son accesibles a través de JS.

Figura 6 - Ejemplo de acceso a APIs del sistema a través de JS
En el próximo y último post terminaremos de analizar las vulnerabilidades que faltan, veremos por encima algunas amenazas pendientes y terminaremos con la demo que mostré.

Información de interés relacionada con el post:

Etiquetas: , ,

1 comments :

Ignacio Agulló Sousa dijo...

Excelente artículo. Enhorabuena a los desconocidos autores.

26 de diciembre de 2013, 15:01

Publicar un comentario

Suscribirse a: Enviar comentarios ( Atom )