Monitorización del tráfico en dispositivos Android (y IV)

Seguimos con la contribución de Angel Alonso-Parrizas, que ya llega a su cuarto y último post después de ESTE, ESTE y ESTE.

En los últimos dos posts vimos varios casos prácticos con malware real. Las firmas creadas en el análisis han sido incluidas en emerginghthreat.

Ahora vamos a explicar los pasos a seguir para hacer la respuesta a incidentes.

Detección de malware sin firmas

En esta categoría tenemos malware del que se sabe su existencia y ha sido reportado pero para el que no existen firmas.

• Preparación: En esta fase se debe elegir a un analista de seguridad que se encargará de monitorizar foros y listas de seguridad de Android y malware con el fin de estar al tanto de cualquier posible amenaza. Además, es necesario preparar el laboratorio donde se van a realizar las pruebas. Los componentes son:
• Dispositivo Android dónde ejecutar el malware
• PC con Linux para subir el malware al smartphone. El PC debe tener tarjetas de red y herramientas para el análisis de tráfico (Snort, tcpdump, Wireshark). El tráfico será enviado a la tarjeta de red a través de mirroring o SPAN.
• Un AP WiFi con una read aislada (separada del entorno de producción) y con acceso a Internet. El tráfico del AP se enviará al PC (por ejemplo algunos modelos de Linksys permiten hacer forwarding del tráfico).
• Política de backup y restauración del Android para poder recuperar el dispositivo después de la infección. Se creará una imagen base y limpia que se reinstalará para hacer nuevas pruebas.
• Identificación: durante esta fase el analista de seguridad identificará malware potencial que pueda suponer un riesgo. Como el malware ha sido reportado existirá información que puede ser de ayuda. Por ejemplo, las conexiones que realiza o qué hace el malware a nivel funcional. Una vez se obtiene una muestra del malware, el analista debe instalarlo en el smartphone, capturar el tráfico con tcpdump y analizarlo con snort. El analista debe ser capaz de crear firmas en función de los flujos de datos generados y corroborándolos con el report (si existe) del malware. Una vez la firma ha sido creada se puede analizar el tráfico capturado previamene contra Snort 
• Contención: al ejecutarse en un entorno controlado y ser test esta fase no es aplicable
• Erradicación: análogo a contención.
• Lecciones aprendidas: aunque las pruebas se ejecutan en un entorno controlado la información obtenida debe ser usada para informar a los usuarios de la potencial amenaza (vías de infección, impacto, etc).

Detección de malware 0-day

Este escenario es diferente del anterior ya que no hay información ni firma del malware. Por ello, el análisis es más complicado y en muchos casos el malware y la infección no será detectado al principio. Por lo tanto, el proceso de respuesta a incidente será diferente.

• Preparación: en esta fase y al tratarse de un entorno en producción todos los dispositivos deberán ser configurado según la arquitectura propuesta en el post 1. Esto implica que todo el tráfico es capturado y analizado por Snort en tiempo real. Durante esta fase se debe de nombrar a una analista de seguridad como se hizo en el caso anterior. Además, se definirá una política de backup (diaria, semanal..) de todos los dispositivos y las copias se almacenarán en un lugar seguro (hay diferentes herramientas que se encargan de hacerlo). El analista tendrá accesso por SSH a través del túnel VPN al smartphone como se describe aquí
• Identificación: esta es sin duda la parte más complicada ya que al no existir firmas ninguna alerta saltará, si tenemos suerte alguna de las firmas creadas para detectar tráfico no estándar generará una alerta que podrá ser usada como punto de inicio para la investigación, pero si no es el caso hay que ver otras alternativas:
• Detectar si alguna aplicación ha sido instalada sin nuestro conocimiento. Para ello, se puede hacer uso del comando ‘pm list packages’ que muestra todos los paquetes instalados. O bien, es posible ver las aplicaciones instaladas con el comando 'ls –lahtr /data/app' en la shell de Android.
• Comprobar que puertos están a la escucha con el fin de detectar alguna puerta trasera. En algunos casos de malware en Android se han creado puertas traseras. Para ello la herramienta 'netstat' puede ser útil. Si existe algún puerto a la escucha podemos correlar esta información con el tráfico capturado en tiempo real por tcpdump y podríamos analizar lo que ha pasado antes y despues de usarse ese puerto.
• Detectar ficheros que han sido modificados o añadidos en las últimas horas (el timestamp es crucial para correlarlo con el tráfico capturado). Con el comando 'find' y algunos parámetros podemos hacer esto. Una vez tenemos la lista de ficheros tenemos que investigar para que sirven. Por ejemplo, el malware 'Kungfu Variant' modifica el fichero /data/data/data/com.noshufou.android.su/databases/su.db con el fin de dar permisos 'su' (root) a ciertas aplicaciones. Esto es un ejemplo de que debe ser investigado y correlado con el tráfico.
• Comprobar los permisos de las aplicaciones desde el GUI del terminal. Normalmente la mayoría del malware configura permisos innecesarios (acceso a la SD, lectura de los SMS, etc). Con esta información se puede averiguar qué aplicaciones tienen demasiados permisos, chequear cuando fue instalada esa aplicación y correlar con el tráfico capturado.
• Con esto tendremos  suficiente información (básicamente timestamp) que usaremos para correlar con los flujos de tráfico. Por ejemplo, podemos ver qué sitios web han sido visitados antes de cierto momento o después, o bien si alguna aplicación fue instalada o descargada después de visitar una página web. Podemos ver qué ha pasado después de que el sistema haya sido comprometido. Con toda esta información es posible crear firmas de Snort.
• Contención: Al tener control sobre el tráfico que fluye sobre el VPN podemos crear reglas de filtrado en función de un puerto, una IP, etc. Esta es la manera más sencilla de contener el incidente. Por ejemplo, supongamos que hay una conexión hacia la IP 1.1.1.1 donde se envía información robada por HTTP al puerto 80, con lo que podríamos crear una regla así:

/sbin/iptables iptables -A INPUT  -i tun0 -p 6 --dport 80 –d 1.1.1.1/32  -j DROP

• Erradicación: en esta fase el malware debe ser borrado/desinstalado. Esto se puede hacer desde la shell con los comandos: 'pm clear package_name' y 'pm uninstall package_name'
• Recuperación: Algunas veces no es suficiente con desinstalar o borrar los archivos por lo que hay que recuperar del último backup limpio y es por esto que es muy importante definir una política de backups durante la fase de preparación. Además es importante durante esta fase monitorizar el tráfico con las reglas de snort creadas con el fin de detectar si otros dispositivos han sido afectados o bien el mismo es comprometido otra vez. También, se puede analizar si ha habido algún match de la regla de iptables creada. 
• Lecciones aprendidas: una vez se tiene claro como se ha comprometido el smartphone, hay que informar al usuario la razón de la infección y como evitarlo en el futuro. También es buena práctica informar al resto de usuarios de la amenaza y como evitarlo.

Hasta la próxima.