Food Store
Este desafío gira en torno a una aplicación ficticia llamada "Food Store" y pone de relieve la grave vulnerabilidad de seguridad que supone la inyección SQL (SQLi) en el marco de la aplicación.
Information
English version: FoodStore
Explota la vulnerabilidad de inyección SQL, lo que te permitirá registrarte como usuario Pro, eludiendo las restricciones habituales para los usuarios.
| FILE INFORMATION | APP INFORMATION |
File Name com.mobilehackinglab.foodstore.apk | App Name Food Store |
Size 9.54MB | Package Name com.mobilehackinglab.foodstore |
MD5 ddeaf207bc7ffb4ca89326492eb9ac06 | Main Activity com.mobilehackinglab.foodstore.LoginActivity |
SHA1 be7f460da3dfae9e6ccbe5bf12cbcca631d22dcb | Target SDK 34 Min SDK 27 Max SDK |
SHA256 9b3f9e03772d037d055933d26da94a4063c159f23971228e1a10e8fed8552ae5 | Android Version Name 1.0 Android Version Code 1 |
Application Analysis
Al abrir la aplicación, se presenta un formulario de Login que permite introducir un usuario y contraseña. También es posible registrar un nuevo usuario desde Signup. Una vez logueados, el sistema asigna el rol Regular User y otorga 100 créditos Credits para gastar en los productos.
La app no incluye demasiado código propio. En AndroidManifest encontramos las Activities Signup, MainActivity y LoginActivity. Esta última funciona como LAUNCHER, por lo tanto se ejecuta “primero” y lo dirige al usuario apenas inicia la aplicación.
AndroidManifest.xml
Mirando la clase LoginActivity, podemos ver cómo gestiona la lógica de inicio de sesión para los usuarios registrados.
com.mobilehackinglab.foodstore;LoginActivity
Aquí, onCreate$lambda$1 busca y valida las credenciales contra la base de datos. Luego, si la verificación resulta correcta, mediante un Toats muestra Login Successful y construye un Intent hacia MainActivity con datos del usuario.
Esta parte presenta varios puntos delicados y mal implementados. Al consultar la base de datos local, la comparación de contraseñas (Intrinsics.areEqual(user.getPassword(), inputPassword)) utiliza los valores en texto plano tal y como estan almacenados (CWE-312).
La lógica de roles también queda expuesta. La asignación de créditos (user.isPro() ? 10000 : 100) depende exclusivamente de un atributo local, permitiendo ser manipulada en runtime.
Además, construye un Intent que transporta y expone información sensible del usuario, USER_ADDRESS, IS_PRO_USER y USER_CREDIT. Estos valores determinan tanto el estado de privilegio como la cantidad de créditos asignados. El diseño actual confía completamente en datos enviados desde el cliente. Mediante adb es posible inyectar valores arbitrarios en los extras del Intent para forzar el acceso como un usario privilegiado o directamente manipular los creditos del mismo (CWE-602) .
1
$ adb shell am start -n com.mobilehackinglab.foodstore/.MainActivity --es USERNAME user --ei USER_CREDIT 10001 --ez IS_PRO_USER true --es USER_ADDRESS "home"
Otro punto de explotación aparece al analizar la clase DBHelper.
com.mobilehackinglab.foodstore;DBHelper
El método addUser implementa dos decisiones críticas que debilitan completamente la seguridad de los datos.
Por un lado, la línea String encodedPassword = Base64.encodeToString(bytes, 0); encodea la contraseña utilizando Base64, la cual no cumple ninguna función criptográfica.
Por otro lado, la construcción de la query introduce una concatenación directa de input controlado del Username dentro de la sentencia SQL, permitiendo manipular la query original mediante injeccion SQL (CWE-89) .
1
2
String sql = "INSERT INTO users (...) VALUES ('" + Username + "', ...)";
db.execSQL(sql);
Initial Access
De este modo, resulta posible modificar la query antes de que llegue a la base de datos, forzando la creación de un usuario privilegiado prouser1', '', '', 1); -- -.
El payload cierra la cadena original e inyecta una nueva instrucción donde el campo isPro toma el valor 1. El resto de la query queda comentado, por lo que los datos legítimos ingresados por el usuario pierden efecto. Y solo basta con autenticarse utilizando las credenciales definidas en el payload, username:"prouser1"/password:" ".
Initial Access
Common Weakness
| CWE ID | CWE Name |
|---|---|
| CWE-312 | Cleartext Storage of Sensitive Information |
| CWE-602 | Client-Side Enforcement of Server-Side Security |
| CWE-89 | SQL Injection |
MITRE ATT&CK Matrix
| Tactics | Techniques | Sub-Techniques | ID |
|---|---|---|---|
Initial Access | TA0001 | ||
| Exploit Public-Facing Application | T1190 |