viernes, 22 de febrero de 2013

Yet another APT1 analysis (y posibles contramedidas)

Sin duda el informe sobre APT1 de Mandiant es el tema de moda, lo más comentado tanto en círculos profesionales como entre gente de la calle. Seguramente llego tarde a hacer mi pequeña aportación a este tema, porque ya ha habido mucha gente que ha escrito sus opiniones e incluso que han publicado sus soluciones, pero aquí va mi granito de arena.

Hablando de posibles soluciones con gente ha surgido un tema importante. Yo parto de la base que el que se desea proteger de APT1 es una empresa grande, con infraestructura y con medios. Si una empresa quiere protegerse de estos ataques y no tiene la infraestructura para ello, una de dos, o lo que protegen no tiene ningún valor, o están tomando muy malas decisiones en materia de seguridad,

Otra cosa que asumo es que lo que queremos es aprender de lo ocurrido. En el proceso de gestión de incidentes existe una última fase que se llama "lecciones aprendidas", en la que se pretende analizar el incidente y tomar medidas para que ni este, NI SIMILARES vuelvan a ocurrir. Bloquear los nombres DNS o certificados SSL de un APT tiene una utilidad relativa, ya que en cuanto hayan visto que empezaban a perder el control de servidores comprometidos habrán empezado a registrar otros nombres y certificados, que seguramente son los que estarán usando en este momento, así que hay que ampliar un poco la visión e intentar aplicar medidas de protección que puedan ayudarnos también en el futuro. Por poner un ejemplo práctico, si nos infectan porque no hemos aplicado el parche para MS12-1234, de poco sirve que instalemos este parche, porque el atacante mañana utilizará un exploit que aproveche la ausencia del parche MS12-1235. Es mejor ver con perspectiv que ha ocurrido y establecer un mecanismos para que todos los parches sean aplicados a la mayor brevedad posible.

Dicho esto, vamos al lio:

Nombres DNS utilizados

En el Apéndice D del informe de Mandiant tenemos una lista de un montón de dominios que han sido utilizados por el malware que ha sido detectado. Una manera de protegernos es, sin duda, evitar que estos nombres sean resueltos. Ha habido propuestas, como por ejemplo la de Snortby Labs, que consisten en crear reglas de Snort para detectar la resolución de los nombres de dominio utilizados por el malware. En mi opinión, esta aproximación tiene algunos riesgos debido a la cantidad de reglas que hay que crear (2046). Hace años que no trabajo diariamente con IDSs, pero el tema del rendimiento en sistemas de detección de intrusos sobre redes con gran cantidad de tráfico siempre ha sido un problema, ya que corres el riesgo de perder paquetes por no ser capaz de procesarlos, y por lo tanto perder capacidad de detección. En este caso, crear 2046 reglas para esta amenaza, y otras tantas para otra, y otras tantas para otra, puede hacer que el rendimiento de nuestro IDS se vaya a hacer gargaras, y que perdamos parcialmente su utilidad.

En mi opinión, la mejor solución para este caso es usar un DNS Sinkhole/Blackhole (lo oigo con los dos nombres), que no es más que un servidor DNS que impide la resolución de los nombres de dominios presentes en una lista negra. Este es un sistema especialmente pensado para esto, para bloquear nombres de dominio maliciosos, y es lo que mejor rendimiento nos va a dar. Además tiene varias ventajas sobre el uso de Snort: La primera de ellas que que protege automáticamente toda la red, no solamente los puntos en los que hemos colocado un IDS, y en segundo lugar es que bloquea los accesos, no solo los detecta (si el Snort está "inline" también podría, pero en ese caso su sobrecarga sería mucho más peligrosa).

En el caso de que no dispongas un DNS Sinkhole... ¿a que esperas?! Es sencillo de desplegar, depende del servidor DNS interno que estés utilizando quizá no tengas ni que añadir otra máquina. El el peor de los casos, puedes mantener toda tu infraestructura, y hacer que tu DNS interno resuelva, en lugar de al servidor DNS de tu ISP, contra el DNS Sinkhole, y este contra internet.

Certificados SSL

En el Apéndice F del informe se muestran una serie de certificados autofirmados que emplean las diferentes familias de malware utilizadas para realizar las conexiones. Esta ha sido la aproximación que han tomado otros como por ejemplo SourceFire, los "papis" de Snort. 

Los creadores de malware usan conexiones SSL para que los analistas o detectores de intrusos no puedan encontrar patrones, pero... ¿no es el uso de un certificado auto-firmado algo sospechoso en si mismo? Creando una regla de IDS que detectara cuando un usuario (o un servidor!) está conectando por SSL a un lugar de remoto con un certificado auto-firmado podríamos detectar estas y otras muchas amenazas futuras ¿Peligros? El exceso de falsos positivos, ya que, queramos o no, hay muchos sitios legítimos que emplean certificados auto-firmados. En cualquier caso, siempre se puede aplicar sobre esta regla un poco de correlación. Si un PC de usuario accede a una web con un certificado SSL auto-firmado, quizá no es muy sospechoso, pero si lo hace de forma repetitiva igual sí que puede servir como señal del compromiso del equipo.

Otra cosa que suelen hacer los atacantes es emplear certificados que están firmados por una CA de confianza, aunque según creo esto es menos común. Hay CAs que te hacen un certificado SSL para tu dominio de forma gratuita, válida tan solo para unas semanas o pocos meses, para que lo pruebes ¿Cómo hacemos entonces para detectar esto? Es sin duda más complicado, pero se podría detectar a través de la fecha de inicio y fin de validez del certificado. Si ambos son en el mismo año, por ejemplo... es probable que se trate de un certificado temporal, lo cual también es sospechoso.

HTTP en puerto 443

Otras de las cosas curiosas que he visto en el Apéndice C del informe, donde se detallan cada una de las familias de malware y como actúan, es que algunas de ellas emplean HTTP sin SSL a través del puerto 443, algo que es raro raro raro en una conexión legítima, pero que puede ser usado por atacantes para evitar las reglas de detección. Si solo el puerto 80 y 443 están permitidos de salida (lo habitual), es posible que los administradores de seguridad configuren la detección únicamente para el puerto 80, asumiendo que en el puerto 443 "no van a ver nada".

El caso es que, si vemos signos de HTTP (GET, POST, HTTP/1., etc) en el puerto 443, no creo que sea nada bueno, así que tampoco estaría de más una regla de IDS para detectar esto, o en el proxy corporativo si lo usamos. Hay diferentes alternativas de donde podríamos aplicar esta detección.

User agent de navegadores

Algo que se repite constantemente en todo el Apéndice C del informe es el uso de User-Agent de navegadores específicos. Podríamos bloquear estos User-Agent en un IPS o Proxy, pero ocurre lo mismo que con los nombres DNS: mañana el creador del malware nos cambia una coma y ya la hemos fastidiado, además de que muchos de ellos son User-Agent idénticos a los que usan navegadores legítimos.

Si somos una empresa grande, seguramente nuestros equipos estarán construidos sobre una maqueta, así que sabemos exactamente que navegadores están autorizados a existir en nuestra empresa. Si esto lo tenemos así, podemos optar por la aproximación contraria, establecer reglas en el IDS o Proxy para que se generen alarmas cuando un navegador con User-Agent diferente a los autorizados intente navegar. Esto puede ayudarnos a detectar malware y, además, violaciones de la política por parte de nuestros usuarios. No es una medida infalible, pero obliga al atacante a hacer un ataque muy dirigido.

Firmas específicas por familia

Esta medida es similar a la de configurar los nombres de dominios maliciosos en un Sinkhole, ya que es totalmente reactiva, es decir, nos protege de lo que ya conocemos, pero no de ataques similares en el futuro.

En el Apéndice C del informe, cuando se habla de cada una de las familias, hay un apartado llamado "Network based signatures" que nos da unas pistas de como podríamos detectar este malware en la red. Alguna veces hace referencia a técnicas como las que hemos visto antes, y otras veces son aspectos especifico como por ejemplo que aparezca una cadena concreta que es característica de la comunicación con este malware. Si este apartado no os da una respuesta que os guste mucho, leed con detalle el resto de la descripción, porque yo he visto que hay varios casos en los que se puede hacer algo más en la red de lo que pone en este apartado. Algunas otra veces me doy cuenta que no se proporciona mucho detalle, con lo que vais a tener que recurrir al especimen original.

Conexiones TCP "de toda la vida"

He visto solo un caso en todo el informe de malware que empleaba una conexión TCP en lugar de conexiones HTTP. Esto hoy en día es menos común ya que existe un control del tráfico de salida (o al menos debería existir). Si en tu empresa no controlas el tráfico de salida de los usuarios y servidores, quizá es un buen momento para que te emplees en empezar a hacerlo, así te evitarás este y otros riesgos "tradicionales".

Canales cubiertos encubiertos (gracias @mgesteiro por la corrección)

Por último, he visto en el mismo Apéndice C que también se han utilizado canales cubiertos encubiertos a través de servicios bien conocidos y ampliamente utilizados, principalmente servicios de Google (Calendar, GTalk y Docs) y Microsoft (Messenger). Sin duda, el uso de canales cubiertos encubiertos es órdenes de magnitud más complejo que el de canales "normales", ya que conectan a un dominio conocido y de buena reputación, a través de SSL con un certificado perfectamente legítimo, así que las opciones de detección son mucho más reducidas, a no ser que directamente prohibamos estos servicios en nuestra red, algo que muchas veces no es posible.

El año pasado publiqué en el SANS Institute un paper sobre canales cubiertos encubiertos en redes sociales que podéis ver AQUÍ o que podéis verme contando en las SOURCE Conferences AQUÍ (también dí la charla en GSIC en La Coruña). Tenía prevista una serie de posts contándolo que al final por lo que veo se me pasaron poner. En las próximas semanas los pondré, ya que viene al hilo del tema.

miércoles, 20 de febrero de 2013

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 ESTEESTE 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.

miércoles, 13 de febrero de 2013

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

Seguimos con la contribución de Angel Alonso-Parrizas, que ya llega a su tercer post después de ESTE y de ESTE:

Al final del segundo post sobre esta serie analizamos el malware  ‘Android - Fake Installer /Fake Lookout (TrojanFakeLookout.A.)’ y ahora seguiremos haciendo el análisis de otros tres ejemplos.


 Análisis of ‘Android Fakelash - Android SMS trojan’


Este malware simular ser el popular plugin para visualizar contenido flash. No vamos a entrar al detalle de como funciona el malware ya que se puede encontrar el informe aqui, pero a modo de resumen este malware se dedica a leer los SMS recibidos y mandarlos por HTTP a un servidor (por ejemplo, para robar tokens de autenticación enviados por SMS para acceder a banca online). Como hicimos en el anterior caso, lo que haremos es ejecutar el malware, ver si existen alguna alerta  y analizar los flujos de datos que se producen. En este caso particular, ya existe una firma creada por emergingthreats  para detectar el malware:

/etc/snort/rules/malware-cnc.rules:alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"MALWARE-CNC Android/Fakelash.A!tr.spy trojan command and control channel traffic"; flow:to_server,established; content:"/data.php?action="; nocase; http_uri; content:"&m="; distance:0; nocase; http_uri; content:"&p="; distance:0; nocase; http_uri; content:"&n="; distance:0; nocase; http_uri; metadata:policy security-ips drop, service http; reference:url,blog.fortiguard.com/android-malware-distributed-by-malicious-sms-in-france/; classtype:trojan-activity; sid:24251; rev:1;)

Esta firma basicamente mira lo siguiente:
  • Tráfico HTTP sobre TCP con origen la red interna y destino cualquier otra red
  • Que el contenido de la URI contenga: /data.php?action 
  • Seguidamente de: &m=, &p=, &n=
Es decir, que la URI sea así: data.php?action=XXX+&m=YYY+&p=ZZZ+&n=TTT (a través de estos valores se el envía la información 'robada' al servidor).
Pero desafortunadamente no se genera ninguna alerta en snort, lo que significa que la firma no funciona.
Mirando la captura del tráfico con Wireshark podemos ver el siguiente tráfico:

GET /data.php?action=cmd&online=ffffffff-c32c-1f6d-2bbc-fab90033c587&m=null&ver=Flash HTTP/1.1

User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; HTC Vision Build/GRI40)

Host: androidoutdate.co.cc

Connection: Keep-Alive
Accept-Encoding: gzip

En este caso, la URI solicitada es:

/data.php?action=cmd&online=UUID&m=PHONE NUMBER&ver=flashpayer11

Lo que nos permite generar una firma usando la firma inicial pero adaptándola:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"MALWARE-CNC Android/Fakelash.A!tr.spy trojan command and control channel traffic - VERSION aparrizas"; flow:to_server,established; content:"/data.php?action="; nocase; http_uri; content:"&online="; distance:0; nocase; http_uri; content:"&m="; distance:0; nocase; http_uri; content:"&ver="; distance:0; nocase; http_uri; metadata:policy security-ips drop, service http; reference:url,blog.fortiguard.com/android-malware-distributed-by-malicious-sms-in-france/; classtype:trojan-activity; sid:88888802; rev:1;)


Análisis of ‘Android SimpleTemai’


Este especimen se dedica a bajar ficheros e instalar un backdoor en el dispositivo comprometido. El análisis completo se puede encontrar aquí. Después de ejecutar el malware vemos que ninguna alerta se ha generado pero mirando con Wireshark la captura del tráfico podemos ver lo siguiente:

GET /control.html?imei=352212045402919&sim=null&imsi=null&model=HTC%20Vision&release=2.3.7&qd=01300602323&gamename=com.polarbit.rthunderliteok&script=001 HTTP/1.1
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; HTC Vision Build/GRI40)
Host: wap.juliu.net

El dominio wap.juliu.net esta incluido en el análisis. En este caso podríamos crear una firma para ese dominio pero si miralos en la URI podemos ver que uno de los parámetros enviados es el IMEI (imei=352212045402919).
Si buscamos firmas existentes para la cadena IMEI encontramos lo siguiente:

/etc/snort/rules/emerging-mobile_malware.rules:alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET MOBILE_MALWARE Possible Mobile Malware POST of IMEI International Mobile Equipment Identity in URI"; flow:established,to_server; content:"POST"; http_method; content:"imei="; nocase; http_uri; reference:url,www.met.police.uk/mobilephone/imei.htm; classtype:trojan-activity; sid:2012848; rev:1;)

La razón por la que no ha saltado la alerta es porque el metodo HTTP de la firma es POST, pero el malware usa GET. Lo más sencillo es crear una firma cambiando el método POST por el GET, es decir cambiando el string POST por GET.

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET MOBILE_MALWARE Possible Mobile Malware GET of IMEI International Mobile Equipment Identity in URI"; flow:established,to_server; content:"GET"; http_method; content:"imei="; nocase; http_uri; reference:url,www.met.police.uk/mobilephone/imei.htm; classtype:trojan-activity; sid:888888889; rev:1;)


 Análisis of ‘Android KungFu variant’


El análisis completo de este malware se puede ver aquí. Este malware es bastante más agresivo ya que modifica ficheros claves del sistema operativo. Para ello, descarga ciertos ficheros de un servidor a través de HTTP pero usando un puerto no estandar.
Si ejecutamos el malware, vemos que se generan varias alertas:

[**] [1:9999999:0] NOT STANDARD TCP PORTS [**]
[Priority: 0]
11/24-04:10:50.237622 172.16.1.99:54122 -> 114.112.190.30:7500
TCP TTL:64 TOS:0x0 ID:61659 IpLen:20 DgmLen:60 DF
******S* Seq: 0xD6B7A4BF  Ack: 0x0  Win: 0xFAF0  TcpLen: 40
TCP Options (5) => MSS: 1350 SackOK TS: 21604 0 N

Estas alertas son generadas por la firma que creamos inicialmente para detectar tráfico que no es estándar.
Si miramos las reglas existentes de snort podemos ver que ya existen firmas para definidas para este malware, pero por desgracia ninguna de ellas ha generado una alerta.

emerging-mobile_malware.rules:alert tcp $HOME_NET any -> $EXTERNAL_NET 8511 (msg:"ET MOBILE_MALWARE DroidKungFu Checkin"; flow:established,to_server; content:"POST "; depth:5; nocase; content:"/search/sayhi.php"; distance:0; nocase; sid:2013020; rev:1;)

emerging-mobile_malware.rules:alert tcp $HOME_NET any -> $EXTERNAL_NET 8511 (msg:"ET MOBILE_MALWARE DroidKungFu Checkin 2"; flow:established,to_server; content:"POST "; depth:5; nocase; content:"search/rpty.php"; distance:0; nocase; sid:2013022; rev:1;)

emerging-mobile_malware.rules:alert tcp $HOME_NET any -> $EXTERNAL_NET 8511 (msg:"ET MOBILE_MALWARE DroidKungFu Checkin 3"; flow:established,to_server; content:"POST "; depth:5; nocase; content:"/search/getty.php"; distance:0; nocase; sid:2013063; rev:1;)

emerging-mobile_malware.rules:alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET MOBILE_MALWARE Android/KungFu Package Delete Command"; flow:established,to_server; content:"/search/isavailable"; http_uri; content:".php?imei="; http_uri; content:"&ch="; http_uri; content:"&ver="; http_uri; content:"User-Agent|3A 20|adlib/"; http_header; classtype:trojan-activity; sid:2013968; rev:1;)

Analizando el tráfico generado podemos ver que el malware realiza varias conexiones a diferentes IP y puertos 114.112.190.30:7500, 58.221.44.102:7500, 180.210.34.207:8511.
Las primeras peticiones web son las siguientes:


En la segunda petición se puede ver que se envía el IMEI del teléfono con el parámetro: 'u=352212045402919'. La razon por la cual no ha saltado la alerta para la firma del IMEI que creamos anteriormente es que el string no contiene la cadena IMEI.
Existe, además otra conexión sospechosa a 58.221.44.102:7500, pero esta vez se trata de una petición POST:

imei=352212045402919&packagename=com.tebs3.cuttherope&versionname=1.1.5&versioncode=6&IMEI=352212045402919&login_way=1&user_detal_info=1&rq_poster=1&user_detal_info=1&dId=10000

Claramente se ve el string IMEI en la petición, ¿por qué tampoco hay una alerta con la firma 'ET MOBILE_MALWARE Possible Mobile Malware POST of IMEI International Mobile Equipment Identity in URI' analizada anteriormente?. La respuesta es sencilla: la firma esta creada para detectar solo el IMEI en el tráfico HTTP en puertos estándar, y el puerto 7500 no es un puerto normalmente utilizado para HTTP.
La última petición web que se realiza es la siguiente:

GET ad.pandanew.com:8511/search/s2.php?i=352212045402919&c=NCuttherope&v=17&b=htc_wwe&m=HTC+Vision&sv=10

Al igual que las anteriores el IMEI se envía en la petición sin generar ninguna alerta.
Como vemos, existen varias peticiones y ninguna genera alertas a excepción de la de tráfico en puertos no estándar.
Mirando las firmas existentes para este malware podemos ver que todas tienen en común el string 'search' en la petición HTTP y este string tambien esta en la última petición web realizada por el malware a a ad.pandanew.com:8511/search/s2.php. Llegados aquí las posibilidades de crear una firma que detecte este malware son varias, pero seguiremos el patrón de las existentes, es decir, usar la petición con la cadena 'search'. Así la firma sería la siguiente:

alert tcp $HOME_NET any -> $EXTERNAL_NET 8511 (msg:"ET MOBILE_MALWARE DroidKungFu Variant - aparrizas"; flow:established,to_server; content:"GET"; content:"/search/s2.php";  sid:88888804; rev:1;)

(¡continuará una última vez!)

lunes, 11 de febrero de 2013

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

Seguimos con la contribución de Angel Alonso-Parrizas, que ya empezó la semana pasada:

En el primer post dejamos configurado el túnel VPN de tal manera que en el endpoint se podía lanzar tcpdump sobre el interfaz virtual para capturar el tráfico y guardarlo en un fichero.

Lo que vamos a hacer ahora es instalar snort y configurarlo. Por defecto, la versión de Linux usada tiene Snort 2.9.4 en el repositorio así que la podemos instalar de allí sin problemas. Los paquetes a instalar son: snort, snort-common and snort-common-libraries.

Lo siguiente a instalar son las firmas de emergingthreats en las cuales ya se incorpora algunas firmas para Android. En nuestro caso los ficheros de las firmas que vamos a dejar configuradas en el snort.conf son: blacklist.rules, botnet-cnc.rules, community-bot.rules, community-virus.rules, malware-backdoor.rules, malware-cnc.rules , malware-tools.rules, emerging-trojan.rules, emerging-malware.rules, emerging-botcc.rules. Además, en el fichero local.rules crearemos nuestras propias firmas.

Para configurar correctamente snort tenemos que definir cual es la red interna, es decir, que tráfico se considera local y cual externo. Para ello, hay que definir la red asignada al VPN y el interfaz del que queremos analizar el tráfico y esto se hace en el fichero /etc/snort/snort.debian.conf de la siguiente manera:

DEBIAN_SNORT_HOME_NET="172.16.1.1/24"
DEBIAN_SNORT_INTERFACE="tun0"

Lo único que falta es lanzar snort y ver que el proceso esta ejecutándose:

/usr/sbin/snort -m 027 -D -d -l /var/log/snort -u snort -g snort -c /etc/snort/snort.conf -S HOME_NET=[172.16.1.1/24] -i tun0

Lo siguiente es definir que tráfico es considerado normal y cual no. Esto dependerá de cada caso particular, pero para este proyecto se considera que 53/tcp, 53/udp, 80/tcp, 123/udp, 443/tcp y 5228/tcp es tráfico permitido. Cualquier otro tráfico debe levantar una alerta y debe ser investigado ya que puede ser síntoma de que el dispositivo ha sido comprometido.  Las reglas de snort que generarán las alertas son:

alert tcp $HOME_NET any -> $EXTERNAL_NET !$HTTP_PORTS,!5228,!53 (msg:"NOT STANDARD TCP PORTS";sid:9999999; rev:0;)
alert udp $HOME_NET any -> $EXTERNAL_NET !53,!123(msg:"NOT STANDARD UDP PORTS";sid:9999998; rev:0;)

Estas reglas son bastante sencillas si se tiene un conocimiento de snort. La primera regla genera una alerta si se detecta tráfico TCP con puerto destino distinto a los puertos HTTP/s (80 y 443), 5228/tcp o el puerto 53/tcp. La segunda regla es análoga pero para el tráfico UDP a puertos DNS y NTP.

Para probar las reglas y ver que funciona lanzamos un netcat desde la consola del Android a un puerto no estándar (9999/tcp) y podemos ver la alerta en el fichero /var/log/snort/alert:

[**] [1:9999999:0] NOT STANDARD TCP PORTS [**]
[Priority: 0]
11/12-19:29:56.422536 172.16.1.99:37946 -> 147.156.1.1:9999
TCP TTL:64 TOS:0x0 ID:25761 IpLen:20 DgmLen:60 DF
******S* Seq: 0xA82B1A31  Ack: 0x0  Win: 0xFAF0  TcpLen: 40
TCP Options (5) => MSS: 1350 SackOK TS: 492084 0 NOP WS: 1

A su vez, podemos ver que el tráfico se ha almacenado en el fichero capturex.cap sobre el que escribe el tcpdump ejecutado en modo background (post 1):

root@lab1:/var/log/snort# tcpdump -nr /home/angel/capturex.cap host 147.156.1.1
reading from file /home/angel/capturex.cap, link-type RAW (Raw IP)
19:29:47.402027 IP 172.16.1.99.37946 > 147.156.1.1.9999: Flags [S], seq 2821397041, win 64240, options [mss 1350,sackOK,TS val 491182 ecr 0,nop,wscale 1], length 0

Ahora que sabemos que todo funciona bien vamos a probar a hacer lo mismo con malware.

De la página http://contagiominidump.blogspot.com.es/ podemos bajar muestras de malware para Android, subirlas al smartphone y luego ejecutarlo.
En teoría, como ya existen firmas para Android (de emergingthreat) debería haber alertas generadas en algunos de los casos que vamos a analizar, pero esto es sólo la teoría. En la práctica ninguno de los ejemplos de malware que vamos a testear son detectados con las firmas por defecto.

Análisis de ‘Android - Fake Installer /Fake Lookout (TrojanFakeLookout.A.)’
El informe de lo que hace este malware se puede encontrar aquí. Sin entrar al detalle de como funciona este malware lo que hace básicamente es robar información del smartphone y enviarla por HTTP a un servidor. En esta comunicación HTTP el servidor puede enviar comandos al dispositivo también. Como he comentado antes, cuando ejecutamos el malware en el dispostivo y miramos los logs de snort no hay ninguna alerta, por lo que hay que indagar en el fichero con las capturas del tcpdump.
Lo mejor es tirar de Wireshark por la comodidad de lo visual, aunque se podría hacer el mismo análisis con Tshark o alguna otra herramienta.
Lo que vemos es una conexión GET a la IP 68.178.232.10 con el siguiente contenido:

GET /controls.php HTTP/1.1
User-Agent: Dalvik/1.4.0 (Linux; U; Android 2.3.7; HTC Vision Build/GRI40)
Host: thelongislandpress.com
Connection: Keep-Alive
Accept-Encoding: gzip

Correlando esta información con la del report, vemos que la URL http://thelongislandpress.com/controls.php es la misma, así que lo más sencillo es crear una regla que haga un match de este host en la cabecerar HTTP además del recurso controls.php.

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"MALWARE Android TrojanFakeLookout.A"; flow:established,to_server; content:"/controls.php";nocase; http_uri; content:"Host: thelongislandpress.com"; http_header; metadata:service http; reference:url,blog.trustgo.com/fakelookout/; sid:88888801; rev:1;)

Sin entrar al detalle del lenguaje usado en Snort, lo que hace la regla es hacer un match de lo anteriormente comentado y alertar cuando hay tráfico TCP desde la red interna a cualquier otro sitio y el puerto es HTTP.

Una vez tenemos las regla creada debemos de probarla con el tráfico capturado y ver si funciona:

/usr/sbin/snort -m 027  -d -l /var/log/snort2 -u snort -g snort -c /etc/snort/snort.conf -S HOME_NET=[172.16.1.1/24] -r /home/angel/capturex.cap

Asi vemos la alerta en el fichero de snort:

 [**] [1:88888801:1] MALWARE Android TrojanFakeLookout.A [**]
[Priority: 0]
11/08-21:00:55.125712 172.16.1.99:59058 -> 68.178.232.100:80
TCP TTL:113 TOS:0x0 ID:24542 IpLen:20 DgmLen:223 DF
***A**** Seq: 0x393EB8F8  Ack: 0x9A02E635  Win: 0xFF48  TcpLen: 20
[Xref => http://blog.trustgo.com/fakelookout/]

(continuará)

lunes, 4 de febrero de 2013

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

Contribución de Angel Alonso-Parrizas, que ya publicó en Pentester.Es una serie sobre securización de dispositivos Android:

Hola de nuevo por estos lugares :)

El post de hoy va de cómo es posible monitorizar y analizar el tráfico de smartphones con Android. El paper original en inglés se puede encontrar en la web del SANS.

La idea es enviar todo el tráfico de red que pasa por nuestro dispositivo tunelizándolo a través de OpenVPN de tal manera que podemos capturar y analizar en tiempo real las trazas de red.
Inicialmente esta idea la propusé en el paper 'Securely Deploying Android Devices' (que también fue publicado en esta serie de posts 1 2 3) con el propósito de cifrar el tráfico de red para garantizar la confidencialidad al conectarnos desde cualquier WiFi o del 3G. Además, en ese paper comentaba como era posible implementar políticas de filtrado de tráfico.

Lo que vamos a hacer ahora es capturar todo el tráfico con tcpdump y a su vez analizarlo con Snort, lo que nos permitirá crear nuestras propias reglas y definir un 'network baseline' para detectar cualquier tráfico no autorizado. Aprovechando este diseño, ejecutaremos malware en el dispositivo para testear la efectividad de las reglas de Snort, crear nuevas reglas o bien adaptarlas. Como último punto, y dado que tenemos todo el tráfico capturado, podremos hacer 'Incident Handling' y definir los pasos para la respuesta a malware sin firmas exitentes y para malware 0-day.





Damos por hecho que el túnel OpenVPN ya se ha configurado con los certificados digitales como se explica en el post 1 por lo que vamos a configurar iptables para tunelizar el trafico.

Reglas aplicadas al Smartphone:

#!/system/bin/sh
/system/bin/iptables -F
# Trafico hacia el loopback
/system/bin/iptables -A INPUT -i lo -j ACCEPT
/system/bin/iptables -A OUTPUT -o lo -j ACCEPT

# Politica por defecto para INPUT, OUTPUT, FORWARD
/system/bin/iptables --policy INPUT DROP
/system/bin/iptables --policy OUTPUT DROP
/system/bin/iptables --policy FORWARD DROP

# ACEPTAR todo el trafico establecido
/system/bin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# ACEPTAR el traffico SSH para gestionar el dispositivo
/system/bin/iptables -A INPUT -i tun0 -p 6 --dport 22 -j ACCEPT

# ACEPTAR el trafico que viene del tunel
/system/bin/iptables -A INPUT -i tun0 -p 1 -j ACCEPT
# ACEPTAT el trafico que va hacia la IP del tunel /system/bin/iptables -A OUTPUT -d 50.19.152.221/32 -j ACCEPT
# ACEPTAR el trafico que va hacia el interfaz del tunel
/system/bin/iptables -A OUTPUT -o tun0 -j ACCEPT


Resultado de las reglas:
















Reglas aplicadas al VPN Gateway:

#!/bin/sh
/sbin/iptables -F
# Trafico al interfaz de loopback y del tunellocalhost and VPN interface tun0 allowed
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT
/sbin/iptables -A INPUT -i tun0 -j ACCEPT
/sbin/iptables -A OUTPUT -o tun0 -j ACCEPT

# Politica por defecto DROP 
/sbin/iptables --policy INPUT DROP
/sbin/iptables --policy OUTPUT ACCEPT
/sbin/iptables --policy FORWARD ACCEPT

# Permitimos tofo el trafico  HTTP, HTTPS, FTP y el trafico establecido (gestion del VPS y actualizaciones)
/sbin/iptables -A INPUT  -i eth0 -p 6 --dport 80 -j ACCEPT
/sbin/iptables -A INPUT  -i eth0 -p 6 --dport 443 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport ftp -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport ftp-data -j ACCEPT
/sbin/iptables -A INPUT -p ALL -i eth0 -m state –state ESTABLISHED,RELATED –j ACCEPT

# Regla para el trafico que va desde el VPN a internet  
 /sbin/iptables -A FORWARD -i tun0 -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -j ACCEPT
# Permitir el trafico del VPN al interfaz publico y hacer NAT
/sbin/iptables -A FORWARD -i eth0 -o tun0 -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# Filtramos el trafico VPN
/sbin/ip6tables --policy INPUT DROP
/sbin/ip6tables --policy OUTPUT DROP
/sbin/ip6tables --policy FORWARD DROP

Resultado de las reglas:






Ahora ya podemos empezar a capturar el tráfico con tpcdump con el siguiente comando:

screen tcpdump -i tun0 -s 0 -w /home/angel/capturex.cap

(continuará)