25 mayo 2011

Hace unos días AegisLab detectó en el market de Android una nueva amenaza camuflada en aplicaciones de terceros. El malware (en esta ocasión apodado zsone por ser el pseudónimo del autor que desarrolló las aplicaciones, yo le he llamado Cudeiro en honor a Chino Cudeiro) se caracteriza por enviar sin el consentimiento del usuario mensajes de texto a servicios de suscripción en China.

En esta ocasión además de centrarnos en el análisis estático del malware, vamos a ver algunas utilidades que integra el emulador del SDK de Android, además de otras bien conocidas que nos facilitaran la tarea en el análisis dinámico.

Adentrándonos en el reversing

El procedimiento por el que vamos a guiarnos para hacer el análisis estático será el mismo al que estamos acostumbrados, primero dex2jar para obtener los ficheros de clase y posteriormente jd-gui para leer los ficheros con extensión .class.

Posteriormente para el análisis dinámico vamos apoyarnos de utilidades como monkey, tcpdump, logcat y wireshark para observar el comportamiento de la aplicación.

Análisis estático

Las apks infectadas han sido varias, nosotros trabajaremos con iCalendar (md5: acbcad45094de7e877b656db1c28ada2) que presenta el siguiente AndroidManifest. Solicitando permisos como android.permission.SEND_SMS y android.permission.RECEIVE_SMS.

De su estructura de clases obtenida, destacamos los ficheros SmsReceiver y iCalendar como los principales contenedores de código malicioso.
El funcionamiento del malware es muy básico, por un lado la primera parte la podemos resumir así:
  • Una vez iniciada la aplicación tras hacer una carga de cinco imagenes el método ShowImg hace una llamada a SendSms
  • SendSms recoge el valor del fichero XML que se crea de comprobación y comprueba si el SMS de suscripción ya ha sido enviado.
  • Si el SMS no ha sido enviado crea una instancia de SmsManager y se pasa como atributos entre otros, el número premium 1066185829 y el mensaje de texto 921X1.
  • Acto seguido se llama al método save() para que cree un fichero XML donde almacene el string Y que sirva de comprobación para no volver a enviar el SMS de suscripción

Por otro lado con el método onReceive el teléfono se queda monitorizando todos los SMS entrantes a la espera de recibir uno procedente de 10086, 10000, 10010, 1066185829, 1066133, 106601412004 que indique que la suscripción al servicio premium ha sido realizada con éxito, estos mensajes nunca serán mostrados al usuario. De forma que el proceso se ejecute en todo momento en un segundo plano.


 Investigando los parámetros que son enviados al método sendTextMessage averiguamos que el número pertenece a la compañía China Telecom y su procedencia está asociada a la ciudad costera de Zhejiang.



Análisis dinámico

Nuestra intención en esta etapa será recabar la mayor cantidad posible de información enviada por nuestro teléfono. Utilizando para ello:
  • tcpdump Para obtener en un pcap la actividad que realice nuestro teléfono interna y externamente
  • monkey Para simular actividad falsa en la aplicación y ver cómo se comporta esta
  • Wireshark Para analizar el pcap obtenido con tcpdump y obtener las evidencias buscadas
A veces, en situaciones no tan esclarecedoras podemos guiarnos de utilidades que nos realicen Diffs del sistema momentos previos y posteriores a la instalación de la aplicación. Simular el envío de mensajes de texto, llamadas de teléfono, cambiar nuestras coordenadas o simular conectarnos a una nueva red. Son sólo algunos ejemplos.

Nosotros comenzaremos automatizando el proceso y levantamos el emulador junto a tcpdump con el fin de realizar lo anteriormente descrito.

sebas@Helios:~/Android/sdk/tools$ ./emulator -port 5560 @Cudeiro-Malware -tcpdump cudeiro.pcap 

Instalamos la aplicación en el teléfono:

sebas@Helios:~/Android/sdk/platform-tools$ ./adb install ~/Android/infected/iCalendar.apk 
1278 KB/s (782964 bytes in 0.597s) 
pkg: /data/local/tmp/iCalendar.apk 
Success 

Creándose la siguiente jerarquía de directorio:

# cd com.mj.iCalendar 
# ls 
lib 

Si utilizamos monkey para simular actividad en el teléfono podremos ver el comportamiento que tiene el malware, para ello hacemos uso de:

sebas@Helios:~/Android/sdk/platform-tools$ ./adb shell monkey -v -p com.mj.iCalendar 1000 > ~/Escritorio/monkey-report 

La actividad simulada podéis revisarla aquí. Comprobemos si ha habido algún cambio en los ficheros del teléfono:

# sebas@Helios:~/Android/sdk/platform-tools$ ./adb shell 
# cd data/data/com.mj.iCalendar 
# ls -l 
drwxrwx--x app_32   app_32            2011-05-12 14:05 shared_prefs 
drwxrwx--x app_32   app_32            2011-05-12 14:05 cache 
drwxr-xr-x system   system            2011-05-12 13:44 lib 
# cd share* 
# ls -l 
-rw-rw---- app_32   app_32        148 2011-05-12 14:05 iBookT.xml 
# cat i* 

Contenido de iBookT.xml

Vemos que han creado nuevos directorios y ficheros, entre ellos un xml, y en su contenido hay algo que llama la atención, el string Y es lo que comentábamos antes que era usado para evitar reenviar el SMS más de una vez al servicio de suscripción.

Revisando los eventos producidos en el sistema, tenemos:

... 
I/am_create_activity(   59): [1157008240,3,com.mj.iCalendar/.iCalendar,android.intent.action.MAIN,NULL,NULL,270532608] 
I/am_proc_start(   59): [276,10032,com.mj.iCalendar,activity,com.mj.iCalendar/.iCalendar] 
I/am_proc_bound(   59): [276,com.mj.iCalendar] 
I/am_restart_activity(   59): [1157008240,3,com.mj.iCalendar/.iCalendar] 
I/am_on_resume_called(  276): com.mj.iCalendar.iCalendar 
I/activity_launch_time(   59): [1157008240,com.mj.iCalendar/.iCalendar,2927,2927] 
I/binder_sample(  276): [com.android.internal.telephony.ISms,5,41,com.mj.iCalendar,8] 
I/am_finish_activity(   59): [1157008240,3,com.mj.iCalendar/.iCalendar,app-request] 
I/am_pause_activity(   59): [1157008240,com.mj.iCalendar/.iCalendar] 
I/am_on_paused_called(  276): com.mj.iCalendar.iCalendar 
I/am_destroy_activity(   59): [1157008240,3,com.mj.iCalendar/.iCalendar] 
... 

Por último si revisamos el fichero pcap buscando las cadenas que se encuentran en el XML nos encontramos con:



Con esto demostramos que el proceso de infección ha tenido éxito, y ahora nuestro teléfono móvil se encuentra adscrito a un servicio de tarificación premium. A la espera de recibir semanal o mensualmente el mensaje que nos cobre el coste de la suscripción.

Conclusión

A decir verdad desconozco qué política siguen en Google para aceptar una aplicación antes de incluirla en el market, pero ya no es la primera vez que vemos como le cuelan un cargamento completo de APK's infectados.

Mucho se ha debatido sobre si entraña esto algún tipo peligro para los usuarios de dispositivos Android, o simplemente se tratan de meros intentos de la competencia por pisotearse unos a otros. Artículos hablando sobre la verdad, que no reside ahí fuera pero sí en el sentido común, permisos extraños, fuentes no fidedignas y demás parafernalias. En lo que respecta a mi opinión permitidme no entrar al trapo y hacerme el sueco.

Lo que si quiero comentar es que Google no está haciendo bien las cosas, hace tiempo que perdió la batalla contra el malware y parece que todo sigue igual y no tiene intención de cambiar. No hablo ya de lo relativamente sencillo que puede ser burlar la seguridad propuesta. Me quejo ante el modelo en que se han basado para presentarnos un producto que ha sido diseñado para llevar nuestros datos y vida 2.0 a nuestro bolsillo. Problemas como la fragmentación de versiones disponibles en el mercado, la extrema facilidad con la que se pueden piratear aplicaciones de pago, los más de 350 fallos en el kernel de Android (ahí es nada PDF aquí), el reciente fallo en la ausencia de cifrado de las comunicaciones.

¿Realmente Google se preocupó de pulir y prevenir todo esto?

----------------------- 
Contribución por Sebastián Guerrero

7 comments :

Madrikeka dijo...

Me he pillado mi primer android por obligación....

y creo que lo voy a seguir usando solo para llamadas XD

Waskas dijo...

Estos programas infectados están en el market oficial de android? He buscado la aplicación icalendar desde el market y no la encuentro... es que la han quitado? 
Al instalar el programa te avisa que pide permisos para enviar y recibir SMS? Esos permisos los pide también la aplicación original?

EyeSec dijo...

Google perdió la batalla contra el malware?? Probablemente, como todos. Pero hay que destacar que es de los pocos que les está plantando cara... muy sensacionalista ese comentario, eso si, queda muy bonito.

Sobre la aplicación... obvias datos importantes. Cuanto tiempo estuvo en el Market? Cuantas descargas consiguió? Son cosas importantes para ver si google tardó en actuar o no. Si google lo hiciera tan mal como dices, estariamos delante de millones de terminales android con malware, algo que de momento, por suerte no tenemos.

Sobre lo que comentas de Android, capaz a ti te interese más un sistema completamente cerrado por tu "seguridad", a mi no.

Borrame dijo...

hace falta la posibilidad de limitar permisos de forma global, ya esta bien

Sebastián Guerrero Selma dijo...

Inicialmente comenzaron a introducirse las aplicaciones infectadas en markets de dudosa reputación por el tema de que era más fácil llegar a los usuarios. 

Si en el market oficial tenías una aplicación de pago, y acudías al de un tercero y te encontrabas el mismo APK gratis... Aquí la forma de operar consistía en coger e infectar el código de un tercero, ensamblar el APK y lanzarlo nuevamente.

Ahora la cosa cambio al punto de diseñar aplicaciones desde cero que si bien ofrecían cierta funcionalidad al usuario, por detrás tenían su trozo de código malicioso.

El tema de los permisos, en el caso del malware, a la hora de ser instalado son mostrados que requiere enviar y recibir mensajes de texto. El usuario confiado acepta y aquí nadie se ha enterado de nada.

En lo que respecta a la aplicación original, estos permisos no existen.

Sebastián Guerrero Selma dijo...

El malware ira siempre al palo que más caliente en ese momento. Sobre que Google está plantando cara... ¿Qué menos no? Eres una gran compañía con una reputación considerable ofreciendo un servicio, lo mínimo que puedes hacer es preocuparte por un correcto funcionamiento de la misma y tratar de erradicar en lo posible un problema que hay en tu plataforma.

Ahora mismo no tengo información exacta sobre esos datos, cuando disponga de ella te la comento. Sé que esta vez el ataque ha sido masivo nuevamente, y que han colado cerca de 15 aplicaciones infectadas en el market. El tiempo de respuesta ha sido de 2 semanas aproximadamente, el que tardó AegisLab en informar a Google, y que algunas aplicaciones tenían un total de 200.000 descargas.

Obvias que Google se suele enterar de toda esta pesca gracias a las empresas antivirus que reportan estas aplicaciones, sino el tiempo sería muchísimo mayor.

En ningún momento me habrás oído quejarme de que Android no sea un sistema cerrado. Problemas de seguridad vas a tener igualmente en un sistema abierto o en uno que se apoye en la seguridad por oscuridad, otra cosa muy distinta es la facilidad y la disponibilidad que tengas de meterle mano al código y detectar más rápidamente fallos de implementación, agujeros en el sistema, etc...

Android evidentemente tiene muchas ventajas al ser una plataforma abierta en cuanto código a sus usuarios, véase el tema de las roms, el tema de las mejores,  y la facilidad que hay para desarrollar aplicaciones. De ahí se hereda también el problema de que exista aun mayor facilidad para desarrollar malware.

 

Sebastián Guerrero Selma dijo...

Tal y como te comenté, aquí te dejo una lista de esos datos que me pedías:

http://bit.ly/mQd7HA

Como ves, algunas aplicaciones llegan a tener casi las dos mil descargas. Y un periodo de actividad en el market de casi 125 días.