Análisis de app móvil Android con cifrado AES

Hace un tiempo nos toco pelearnos en una auditoria de una app móvil Android perteneciente a un producto que se encargaba de realizar pagos a través de internet. El objetivo del trabajo, desde una perspectiva de caja negra, era analizar la seguridad de la infraestructura Web que daba soporte a la aplicación, así como analizar qué información se intercambiaba.

El primer paso del análisis de la app era monitorizar el tráfico HTTP intercambiado con los servidores mediante el uso de un proxy de interceptación como Burp. Dado que la aplicación hacía uso de conexiones HTTPS también ha sido necesario instalar una CA en el teléfono Android para que el teléfono confíe en el certificado digital emitido por el proxy.

Lo que sucedió a continuación nos dejo a todos un poco sorprendidos, las peticiones HTTP enviadas por la app móvil eran todas como las que se muestran a continuación:

https://www.domain.com:443/Endpoint?VvHkvcA3Vy5T0VwE/G3JZlsQuPVJDsF9owX84PReWLPFqCDT+8MYBo1K0OAy+8BfTrBlDILYiw9MlVroMdcMfw==

Y la respuesta del servidor Web, ante peticiones correctas era la siguiente:

ffBOHiseQ+ciPk2WY8pN/5j+g0nLnFspuguWvigGRUyKHC5si/6nF/dQQbbYGSlI5vgSWXYnT7KuKO/0sUq8VeTYSlVYuia
 DxpqtguFXdLQclz+QTzhtXTzaGRuNi8wRgUByWrs79e4UmDG4truE04ypMUAHgwJXwxG6xKwfIsbtqYIaZx4mby60rZDMtxw4pyfp
 qOPwpb6GrW4rwsNokIxBG/PgqrxuzHuPosnWrNxYXQ+LC2gOATxB3MXsSIV3k397l/KjXYkKblWW3yRn8RSFQCzT65C8UZ4PfiOcY
 Dqw4Fbe0OtwrzOG8XDhxWhFMl0EiuigXcTpqhqzLiRQV57FocFWythbb2tqmh44cf8=
 

Tras varias pruebas adicionales, todo permitía intuir que la aplicación móvil integraba, además de las conexiones seguras por HTTPs, una capa de cifrado por bloques (CBC) que codificada su resultado en base64. Para evitar hacer pruebas a ciegas con las peticiones HTTP, la estrategia adecuada era analizar el binario de la app móvil para descubrir que tipo de cifrado utilizaba.

Por suerte la aplicación android apk no disponía de ninguna capa de cifrado y podía ser decopilada mediante el uso de herramientas públicas en el mercado. Tras descargar el fichero .apk de la tienda de google este puede ser descomprimido mediante el uso del comando unzip.

En este punto se extrae el contenido y se convierte el fichero clasess.dex con la aplicacion dex2jar. Este proceso permite exportar y convertir el código a un fichero jar. Este fichero es fácilmente editable con herramientas comerciales.

A través de un decompilador de java, se ha procesado el fichero generado y se ha accedido a las clases y código fuente de la aplicación.

Android APK decompile

Una búsqueda rápida de cadenas como cifrar o encriptar en el fichero jar revela la clase donde se encuentra dichas funciones, con un código muy claro:

public class AES
{public static String desencriptar(String s)
{
String s1;
try
{
Key key = generateKey();
Cipher cipher = Cipher.getInstance("AES");
cipher.init(2, key);
s1 = new String(cipher.doFinal(Base64.decode(s)));
}
catch(Exception exception)
{
System.out.println((new StringBuilder()).append("AES decrypt error: ").append(exception).toString());
s1 = "";
}
return s1;
}
public static String encriptar(String s)
{
String s2;
Key key = generateKey();
Cipher cipher = Cipher.getInstance("AES");
cipher.init(1, key);
s2 = Base64.encode(cipher.doFinal(s.getBytes()));
String s1 = s2;
_L2:
return s1;
Exception exception;
exception;
System.out.println((new StringBuilder()).append("AES error: ").append(exception).toString());
s1 = "";
if(true) goto _L2; else goto _L1
_L1:
}
private static Key generarClave()
{
return new SecretKeySpec("xxxxxxxxxxxxxxxxxxx ".getBytes(), "AES");
}
}

El análisis del código revela que se esta usando AES como capa de cifrado en la aplicación. Con esta información ya podemos empezar la construir las herramientas de cifrado y descifrado de datos así como la interceptacion de las peticiones HTTP.

Dado que nuestro objetivo es poder interactuar con el frontend de la aplicación de forma directa, se decidió montar un servidor web apache que hiciese de proxy inverso contra el el servidor original. Este proxy debería cifrar y descifrar las peticiones directamente permitiendo lanzar herramientas como burp intruder o burp repeater.

La opción mas fácil, con unas pocas líneas en PHP, ha sido desplegar un script que hiciese de proxy inverso y generase las peticiones con el padding adecuado.

A partir de este momento, es posible lanzar toda la batería de pruebas automáticas y manuales, ignorando la capa de cifrado inicial, y empezar a descubrir las vulnerabilidades en los servicios Web y en el proceso de comunicación de la APP.

Algunas conclusiones que se han extraido en esta auditoría de la app móvil:

• La seguridad por oscuridad no es una buena estrategia si no va acompañada de controles de seguridad adicionales.

• El uso de capas de cifrado adicional es contraproducente, dado que una inyección de código SQL dentro de un bloque cifrado con AES no va a ser detectada por soluciones IDS/IPS/WAF.

• Es recomendable proteger el código de las app para evitar que el proceso de ingeniería inversa sea directo.

Descubre nuestro trabajo y nuestros servicios de ciberseguridad en www.tarlogic.com/es/

En TarlogicTeo y en TarlogicMadrid.