07 enero 2014

Actualidad del malware en Android (3 de 3)

En los post anteriores (aquí el primero y aquí el segundo) se han visto los temas más generales sobre la actualidad del malware en Android y 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).

En este último post pretendo finalizar ese resumen de vulnerabilidades, ver por encima algunas amenazas que quedaron pendientes y terminaremos con una descripción del funcionamiento de la demo que mostré.

1. Resumen de vulnerabilidades pendientes


Librerías externas maliciosas[1]
Solemos preocuparnos por aplicaciones que provienen de desarrolladores poco confiables pero... ¿qué ocurre si se introduce código malicioso en librerías que utilizan muchas aplicaciones legítimas?. Un ejemplo lo encontramos en el estudio que publicó hace unos meses la empresa FireEye sobre una librería de anuncios (presente en más del 2% de las aplicaciones con más de 1M de instalaciones -en total más de 200M-) a la que denominó "Vulna" que podía ser utilizada para recopilar información del dispositivo (IMEI, IMSI, SMS, contactos, etc) o incluso ejecutar código malicioso (activación oculta de la cámara, JS/WebView, etc).

El caso de AdBlock Plus[2]
Este caso es bastante curioso. Resulta que a partir de la versión 4.2.2 de Android se corrigió una "vulnerabilidad" que permitía a las aplicaciones con permiso internet actuar como "proxy". Esta "funcionalidad" la aprovechaba la aplicación AdBlock Plus para eliminar la publicidad de forma totalmente transparente, sin necesidad de tener el móvil rooteado. A raiz de su corrección, los desarrolladores de la aplicación la retiraron del Google Play provocando que los (ciber)delincuentes publicaran copias maliciosas de la misma y los usuarios, al seguir buscando la aplicación legítima para instalársela en sus dispositivos, se encontraran únicamente con versiones maliciosas de la misma (consiguiendo un ratio de infección muy elevado). A pesar de que la referencia es el blog de Kaspersky Lab, cabe destacar que el seguimiento de estas aplicaciones lo realizó Sergio de los Santos.

Otras aplicaciones maliciosas:
Además de todas las vulnerabilidades descritas en esta serie de posts, además destaqué algunos otros ejemplos de aplicaciones de Android de las que se habían publicado vulnerabilidades:
  • eBay: vulnerabilidad en sus Content-Providers (de tipo inyección)[3]
  • Facebook: envío de fotografías por un canal no seguro[4]
  • Skype: permitía evadir el bloqueo del terminal[5].
  • Any.DO: vulnerable a ataques de tipo MitM y almacenamiento en claro de información privada (datos de usuario, credenciales, etc)[6].
Vulnerabilidades en dispositivos
Al igual que hemos visto vulnerabilidades en Android (SecureRandom, MasterKey, etc) y en aplicaciones (Firefox, Cerberus, eBay, etc), existen muchas vulnerabilidades provocadas por las "personalizaciones" que añaden los fabricantes en Android (o por el hardware que incorporan los dispositivos). Algunos ejemplos:
  • Vulnerabilidad de tipo Smishing en Samsung Galaxy S4[7]
  • Instalación silenciosa de aplicaciones y elevación de privilegios en terminales LG[8]
  • La famosa vulnerabilidad de los dispositivos Samsung con procesador Exynos[9]
2. Troyanos y ExploitKits

Troyano Obad.a[10]
Este troyano fue denominada como "el más sofisticado de todos los tiempos dirigido contra Android" por la empresa Kaspersky. Utilizó parte de la red de OpFake (de ahí que se crea que su uso fue alquilado, dado que únicamente se utilizó una porción de los dispositivos infectados) para propagar un mensaje cuyo contenido era "Has recibido un mensaje MMS, descárgalo de www.otkroi.com". El APK que se descargaba tenía por nombre "mms(ka).apk" y una vez instalado solicitaba permisos de administración y explotaba una vulnerabilidad presente en versiones anteriores a Android 4.3 que permitía ocultar aplicaciones del listado de aplicaciones con permisos de administración, por lo que no era posible desinstalarla (primero hay que revocarle los permisos pero al no aparecer en el listado, no era posible -había que utilizar métodos manuales de desinstalación-). Algunas de las características de este troyano son:
  • Presentaba un AndroidManifest incompleto (p.e faltaban nombres de atributos)
  • El código estaba ofuscado (además de explotar una vulnerabilidad en la aplicación DEX2JAR) y las cadenas de texto estaban cifradas.
  • Utilizaba reflexión para los métodos externos.
Malware tradicional & Malware de dispositivos móviles[11][12]
No es raro encontrarse malware "tradicional" con componentes móviles, como fue el caso de ZitMo o SpitMo. En este caso concreto mostré el componente móvil del troyano Hesperbot el cual hacía la función de "proceso de activación". El usuario se encontraba un código en la web y se le solicitaba que lo introdujera en la aplicación móvil, entregándole éste un código de respuesta. Como es de esperar, la aplicación quedaba en segundo plano a la espera de mensajes SMS para interceptarlos y reenviarlos o ejecutar las acciones que en ellos estén indicadas. También ha ocurrido el caso contrario en el que aplicaciones maliciosas han infectado la SDCard para intentar propagarse por ordenadores en los que se conecte el dispositivo, como fue el caso de la aplicación Superclean.

Malware-Kits
Como era de esperar, también nos encontramos múltiples ejemplos de "malware-kits" para dispositivos móviles, como es el caso de Perkele (se trata de un malware que afecta a una serie de bancos alemanes, ver Figura 1) o Adwind (ha incorporado AndroRAT para la gestión de terminales Android, ver Figura 2).

Figura 1 - MalwareKit Perkele
Figura 2 - Vídeo promocional de Adwind

Nota: 
El apartado de "evasión por transformación" lo trataré con más detalle en un post propio.

3. Resumen de la DEMO

Al final del post tenéis un enlace al vídeo de la ponencia en el que podréis ver la demo en directo. Ésta consistía en la instalación de una aplicación que haga uso de una de las vulnerabilidades MasterKey descritas en el post anterior para mostrar que ninguno de los antivirus más descargados la detectaban y, posteriormente, mostrar un panel (alias "DroidHole") que utilizo a nivel personal (en la demo tiene contenido ficticio) para las pruebas de concepto y que me permite desplegar dinámicamente nuevas funcionalidades a dispositivos infectados.

Con respecto al panel, básicamente permite gestionar aplicaciones instaladas en el GooglePlay y otros markets "alternativos" (acceder a estadísticas y demás información de interés). A través del mismo se pueden activar campañas de malware a las que se les asocia un determinado "payload" y las aplicaciones maliciosas se lo descargan automáticamente y lo inyectan en memoria (haciendo uso de la técnica explicada en el post "Google Play, ocultación de malware y ExynosAbuse > Pwned!"). Si bien el código fuente del panel no lo voy a publicar (tampoco tiene mucho misterio... cuatro líneas de PHP), todos los recursos técnicos asociados se encuentran aquí.

Figura 3 - Ejecución del payload desplegado desde el panel "DroidHole"


He subido la presentación a slideshare para evitar los solapamientos existentes en el PDF que se publicó en su momento. Adicionalmente, podéis acceder al video de la ponencia en el siguiente enlace.



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

2 comments :

caballer dijo...

Si me envian un mensaje por whatsaap y llamo a esa persona y me dice que no sabe de lo que hablo que no me conoce, como puedo averiguar quien tomo su numero para enviarme un mensaje?

Shakira de la Cruz dijo...

yo e querido insalar el Whatsapp el mi movil pero pasa que despues que yo pongo mis datos para insalarlo dura mucho tiempo... el Whatsapp dura mucho para instarse?
que pasen buenas tardes ttodos...!