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!)