Analizando Malware en Android

 

El problema en cuestión

Hace unos días llego un terminal de importación asiático de una clienta, el problema era que continuamente le saltaba un aviso procedente del Play Protect.

Malware Android

 

Play Protect es la capa de seguridad contra malware para Android. El funcionamiento concreto se puede consultar en la documentación de google. El problema es como se comportó en este caso con un servicio que se llama com.android.service y que por su nombre podría pasar como uno más del sistema. El tema es que Play Protect lo cazó, y se pone muy pesado con el mensaje continuamente mostrándolo. Si elegimos la opción de desinstalar, no consigue desinstalarlo y en un breve lapso de tiempo el mensaje vuelve a aparecer, si le damos mantener aplicación o desde los ajustes del Play Store desactivamos la característica de Play Protect, perderíamos el control de la app.

Vamos a ver como resolver esta incidencia y para ello vamos a necesitar tener activado el adb, recordemos menú ajustes – información del sistema y en numero de compilación pulsamos 7 veces, salimos de ese menú y se nos abrá activado otra opción nueva que se llama modo developer o ajustes avanzados y checkeamos la casilla de Depuración USB, de paso si nuestro android fuese superior a la versión 5.1 checkeamos también el OEM Unlock, para tener la protección FRP desactivada que protege ciertas particiones de nuestros terminales y nos permite escritura del recovery por ejemplo, que utilizaremos más adelante.

Que vamos a hacer

En resumidas cuentas, vamos identificar los componentes de ese servicio detectado, apk y package, descargar del teléfono el apk, desensamblarlo, estudiar sus permisos, eliminarlo sin root, para que no correr riesgos, utilizando la misma “puerta trasera” que usa Cellebrite para realizar sus labores forenses, pero evidentemente el proyecto open source original, ya explicaremos esto.

Que nos va a hacer falta

  • El adb.exe que forma parte del SDK de Android. No nos hace falta todo el SDK, nos apañamos con el adb.exe, el fastboot.exe y las dos librerías que suelen acompañarlo.
  • El apktool.jar para desensamblar apks y tener el manifest en claro, en github
  • El custom recovery del proyecto TWRP para este modelo de teléfono de este estudio (para otros consultar la página del proyecto y la instalación) en su página
  • El JDK de java para lanzar programa en java, como el apktool.jar en Oracle
  • El SP Flash Tools para instalar el custom recovery de TWRP, www.spflashtools.com

El terminal del caso

Bien en este caso el terminal de importación que nos atañe es un GRETEL A7 con android 6.0.1. Es un terminal basado en procesador MTK.

Manos a la obra

Por fortuna el servicio esta identificado como hemos dicho com.android.service. Bien pues vamos a ver cual es el apk y el package que le corresponde a ese servicio, para ello abrimos una terminal donde tengamos nuestro adb.exe instalado. Y tecleamos:

adb shell “pm list package”

Como esta orden nos va a mostrar toda la lista de packages y demasiada información que no concierne de momento usaremos grep para cribar la búsqueda, ademas vamos a utilizar el parámetro -f para que nos muestre también el apk que corresponden a cada package.
Entonces lanzaremos:

adb shell “pm list package -f | grep service”

Si hacemos lo mismo con cualquier otro terminal, en mi caso un Lg G3 con android 6, veremos que ese servicio no esta disponible, algo que evidentemente llama la atención, como se puede ver en la imagen:

Malware

Como podemos ver en la imagen el servicio corresponde al package com.android.service y que lo normal es que tenga en la carpeta /data/com.android.service algunos ficheros de recopilación y de trabajo como cualquier otra app instalada en nuestro sistema.

La apk que corresponde al package es com.android.service-9002_0711.apk y esta ubicada en /system/priv-app/com.android.service-9002_0711.

Como sabemos esa carpeta esta protegida contraescritura y tampoco podemos desinstalarlo directamente como se verá ahora después. Ahora si podemos leer el contenido y realizar un pull para descargar el apk, para ello como en la imagen anterior escribimos desde la terminal:

adb pull /system/priv-app/com.android.service-9002_0711/com.android.service-9002_0711.apk

Lo que descargará nuestro apk en cuestión en al carpeta actual. Como simple observación el del nombre de la carpeta y del apk , 9002 corresponde una norma ISO que ya esta obsoleta, que nos querrán decir con ese nombre?

Una vez descargada, vamos a ver los permisos que tiene dentro del archivo AndroidManifest.xml. Pero en vez de descomprimir con zip directamente, lo vamos a hacer con apktool.jar, ya que si no lo hacemos así, ese ArchivoManifest.xml será un fichero binario y no podremos leerlo, he de decir que hay otras formas de convertirlo muy sencilla, pero a mi me interesa más la herramienta apktool.jar.

Por tanto copiamos nuestro com.android.service-9002_0711.apk en la carpeta del apktool.jar abrimos la terminal y lanzamos la orden, igual que aparece en la imagen anterior.

java -jar apktool.jar d -f com.android.service-9002_0711.apk

El parámetro d indica que decompile y el -f que tome el fichero y lo haga en una carpeta con el nombre de la aplicación al no darle una ruta de salida. Nos quedará algo como esto:

Malware

Una vez hecho esto abriríamos el fichero el AndroidManifest.xml y que no estará en binario sino que serán perfectamente legible los nombres, los permisos y la acciones que realiza es función. Es otro cantar el análisis completo del malware. Que hace, como se comporta y esas cosas. A nosotros nos interesa ver a simple vista que permisos tiene, y poder discriminar con rapidez si es normal o no esos permisos que tiene.

Malware

No son la verdad permisos alarmantes, pero INSTALL_PACKAGES no pinta bueno, desvelando un poco el misterio, y ajeno a esta investigación, lo que hace este servicio o app, es instalar programitas de publicidad de esos que te dejan la ventana bloqueada hasta que
pulsas la x después de desbloquear la pantalla, dejando un backdoor coladero para que el mejor postor o amiguete del diseñador pueda seguir instalando más apk. Para mi un malware en toda regla que hace de base control para seguir instalando más app. Varias de ellas se
instalan en el teléfono con el mismo nombre media, en las aplicaciones descargadas.

Resolviendo la incidencia.

Evidentemente a esto hay que ponerle solución. Pero porque no preguntarnos, como narices ha entrado esto, la verdad es que tiene pinta de ser una app del Play Store, porque esta clienta es una persona mayor y la seguridad de applicaciones de terceros NO esta desactivada, al descargar algún jueguecito para los niños o sobrinos, o bien porque no, no iba a ser la primera vez que sucede, que ya viene cargada de regalo con el firmware (stock ROM) del teléfono, que como si de una bomba se tratase y que explote rebosando publicidad por todo sitios, algo que puede ser habitual en los teléfonos baratos de importación.

El caso es que recordemos que la ruta de la app y del package estás protegidas contra escritura, aunque esto no debería ser un problema si intentamos desinstalar con uninstall.

Pero resulta que desde el teléfono ni nos deja desinstalar, tampoco en modo seguro, ni nos deja vaciar. Tampoco nos deja desde la terminal de adb, y de momento recordemos que no somos root. Podríamos rootear el terminal, con decenas de aplicaciones tanto en formato apk
como desde el PC.

Pero, hay que tener cuidado con esas apps, que si que rootean el teléfono, pero también llevan regalos publicitarios que se instalan, nada es gratis, limpiadores innecesarios con mas publicidad y backdoors, en fin llamemosles aplicaciones de mierda. Sin descartar que el proceso de rooteo escribe en el área del sistema para escalar privilegios y soltar el exploit de rooteo. Y OJO!!! algunos procesos de rooteo escriben partes del firmware que pueden ocasionar la inestabilidad del arranque del sistema, no quiero ser alarmista pero el riesgo esta ahí. Sin contar que en procesos judiciales nos pueden tirar a la mierda un informe por culpa de ello. Yo solo me limito a comentarlo, ahora veremos que hacer.

Volviendo al tema, después de ese paréntesis, íbamos por que el uninstall no nos deja desinstalar y no somos root tal como podemos ver:

si lanzamos adb uninstall com.android.service desde la terminal también falla. Si intentamos hacerlo con:

adb shell “pm uninstall -k com.android.service”

el sistema no nos deja. Vamos a ver que hacemos y hago un inciso para hacer otra reflexión personal.

Malware

 

Bien para la reflexión a lo Wyoming, mirad esta foto que me mando un colega, y por esta razón quería realizar esta entrada en el blog, sentía en la necesidad de hacerlo.

Malware

 

Parece ser que la imagen corresponde a la extracción con Cellebrite, “la pepa” para los amigos, a un Samsung.

No me ofende que la pepa use un proyecto open source como es TWRP, porque sinceramente es el mejor proyecto para android que conozco junto con el propio SDK. Tampoco me ofende que la pepa cueste UN PASTIZAL de euros, junto con un mantenimiento
astronómico de euros.

Lo que realmente me parece cómico es que se base en un proyecto open source, y si me equivoco que me corrijan, es que uno intente hacer uso del proyecto TWRP para hacer un informe y le tachen de que esta usando una ñapa que se ha encontrado en internet o tenga que dar 150000 explicaciones de como ha hecho ese proceso de extracción y te miren con cara rara, y que llegue otra, mmmmmmm…, llamemosle “organización” que tiene Cellebrite y diga, esta extracción se ha hecho con Cellebrite y esto va a misa, que claro como se puede ver en la imagen la pepa hace uso del proyecto TWRP.

Entonces después de esta reflexión, incluso desahogo, porque escribir desahoga, volvemos a lo nuestro y vamos a usar TWRP para realizar lo que nos queda del caso. Y porque vamos a usar TWRP, pues sencillo, el custom recovery nos va a permitir decenas de operaciones de
montaje, de recuperación del terminal, actualizaciones customizadas, extracciones de datos en tarjetas sd (esto lo veremos en otra entrada), explorar los ficheros, borrar protecciones, … entre otras opciones y lo que a nosotros nos interesa, montar las particiones /system, /cache y /data. Además corremos menos riesgos, porque solamente escribimos una parte que no influye en el arranque normal del sistema, con lo cual los riesgos de brick son menores que haciendo el root, siempre que no nos equivoquemos de ficheros, claro está,
seamos responsables con el uso.

Pero es más y esto es lo que más mola nos deja desde el modo recovery activado el adb para interactuar sin restricciones en principio e incluso hacer dd (copias bit a bit), de esas 3 particiones, además nos firma la extracción con md5, obsoleto pero bueno ahí queda.

Así que tomamos el custom recovery TWRP de nuestro modelo en cuestión, para este caso el del Gretel A7, si fuera un Samsung, el de Lg, el de Sony, en fin el que corresponda, y si no esta pues con revisar la documentación del proyecto podríamos generar el nuestro. Y como
el procesador es un Mediatek haremos uso del SP Flash Tools para Windows o Linux.

Malware

Para este caso nos hace falta cargar el scatter (mapa de particiones) y el recovery.img en el SP Flash Tools.

Malware

 

Después pulsamos en download, y con el teléfono apagado forzamos el modo download, que para este modelo es con el teléfono apagado pulsar el botón de bajar volumen y enchufar el cable usb. Comenzará si todo es correcto la instalación del recovery hasta que nos de el ok,
tardará apenas unos segundos y el programa nos confirmará dicha finalización, tal como podemos ver en la imagen.

Malware

 

Una vez hecho esto desconectamos el teléfono y entramos en el modo recovery, hay que buscar la documentación de como entrar en ese modo para el terminal con el que estemos trabajando, en muchos modelos el pulsando el botón subir volumen y encender sin soltar,
suele ser siempre una combinación de esas, o bien con el teléfono encendido, abrimos una terminal y con adb reboot recovery podemos acceder a el. Si todo a ido bien veremos nuestro flamante TWRP recovery. Montamos la unidades:

Malware

Enchufamos de nuevo nuestro teléfono y abrimos una terminal para el adb shell. Intentamos desintalar la app con pm uninstall com.android.service , pero falla, entonces no hay nada mas bonito que coger una katana y fulminar lo que se nos ponga por medio, así que con

rm -r com.android.service

Malware

Malware

 

Hacemos lo mismo con el apk de /system/priv-app la borramos e incidencia solucionada, que se encargue en el siguiente reinicio el Android de finalizar los enlaces incorrectos de nuestras acciones.

Por cierto si colgamos en los sitios de análisis de malware el apk de estudio, podríamos confirmar también de que bicho se trata, en nuestro caso, esto es lo que nos dice hybridanalysis.com y virustotal.com

Malware

 

Malware

 

Malware

 

Si te gustó búscame en Telegram como @nomed1, próximamente también

en www.eltallerdelosandroides.com, hasta la próxima.

Buenaventura Salcedo | @nomed1

0 respuestas sobre "Analizando Malware en Android"

Deja un mensaje



Tú escuela de Hacking Ético.
Avda. de Las Américas 3, 4º A
29002, Málaga, Málaga,
(+34) 951 043 792 - info@comunixgroup.com

Suscríbete a nuestro Boletin

  Suscribirse ahora

By

Copyright © 2018 - Todos los derechos reservados.

X