Vulnerabilidad BAC en Diarios Electrónicos: Conviértete en Profesor Sin Permisos

Vulnerabilidad crítica de BAC en diarios electrónicos escolares: Cómo convertirse en profesor sin permisos

Durante la ingeniería inversa de una popular app de diario electrónico escolar, se descubrió una vulnerabilidad crítica de Broken Access Control (BAC) que permite a cualquier usuario obtener acceso completo a las funciones de profesor. El análisis de código reveló la falta de verificaciones de permisos en el lado del servidor y claves secretas almacenadas en texto plano.

Ingeniería inversa revela puntos débiles

La investigación comenzó analizando el archivo APK de la app con el descompilador JADX. Los hallazgos iniciales fueron alarmantes:

• Cookies de depuración en logs: Las cookies de sesión X1_SSO se registraban en logcat sin cifrar, lo que permite secuestrar sesiones.
• Cifrado casero: En lugar del AES anunciado, usaba un simple XOR con una clave hardcodeada: el nombre del paquete de la app (ru.vendor.schoolapp).
• Respaldo universal: Sin clave de dispositivo, la app recurría a un ID fijo 000xpda.

Estos fallos ya permitían acceso automatizado a datos personales de estudiantes. Pero un análisis más profundo de la API reveló un problema más grave: ausencia de verificaciones de permisos en el servidor. Bastaba con cambiar el guid del usuario en las solicitudes sin un token X1_SSO para acceder a los datos de cualquier estudiante.

Notablemente, se encontraron vulnerabilidades idénticas en apps usadas en al menos tres regiones rusas, poniendo en riesgo los datos de cientos de miles de escolares.

Divulgación responsable: amenaza ignorada

El autor intentó notificar a las autoridades relevantes mediante procedimientos de divulgación responsable. El contacto con el Ministerio de Desarrollo Digital fue redirigido a entidades regionales, específicamente el Centro Regional de Tecnologías de la Información (RCIT), listado como desarrollador.

RCIT respondió con promesas de "abordar los problemas", pero las correcciones fueron superficiales:

• Eliminaron el cifrado XOR fácilmente detectable.
• Lo reemplazaron con AES, pero dejaron las claves en el código de la app.

Ejemplo de la clase Crypt.java:

package ru.vendor.schoolapp2.common;

import android.util.Base64;
import javax.crypto.Cipher;
import javax.crypto.spec.SecretKeySpec;

/* JADX INFO: loaded from: classes2.dex */
public class Crypt {
    public static String alt_api_key = "gqhy671nmn3478fhsdjf4f09f45sf4fg4lf842d1";
    private static Cipher cipher = null;
    public static String encryptedTOKEN = "";
    private static SecretKeySpec key = null;
    public static String session_apikey = "0xt25240s9s12xv767v1ll17757e32e34x12ppix332vdi2i";
    private static String transformation = "AES/ECB/PKCS5Padding";

    private static byte[] encrypt(SecretKeySpec secretKeySpec, byte[] bArr) {
        try {
            Cipher cipher2 = Cipher.getInstance(transformation);
            cipher = cipher2;
            cipher2.init(1, secretKeySpec);
            return cipher.doFinal(bArr);
        } catch (Exception unused) {
            return null;
        }
    }

    private static byte[] decrypt(SecretKeySpec secretKeySpec, byte[] bArr) {
        try {
            Cipher cipher2 = Cipher.getInstance(transformation);
            cipher = cipher2;
            cipher2.init(2, secretKeySpec);
            return cipher.doFinal(bArr);
        } catch (Exception unused) {
            return null;
        }
    }

    public static String encryptString(String str) {
        return Base64.encodeToString(encrypt(key, str.getBytes()), 2);
    }

    public static String decryptString(String str) {
        byte[] bArrDecrypt = decrypt(key, Base64.decode(str, 2));
        if (bArrDecrypt != null) {
            return new String(bArrDecrypt);
        }
        return "";
    }

    public static void initKey() {
        key = createSecretKey();
    }

    private static SecretKeySpec createSecretKey() {
        return new SecretKeySpec(new byte[]{10, 20, 30, 40, 50, 23, 19, 31, 0, 0, 0, 0, 0, 0, 0, 0}, 0, 16, "AES");
    }
}

El seguimiento vía Roskomnadzor tampoco corrigió las vulnerabilidades en otras regiones. El sistema seguía confiando en verificaciones de roles en el lado del cliente, haciendo la vulnerabilidad BAC crítica.

Control de acceso roto: Cómo convertirse en profesor en un minuto

La vulnerabilidad clave provenía del almacenamiento de datos de sesión en texto plano en el archivo shared_prefs. Dos parámetros controlaban el acceso:

• user_sys_guid — identificador de usuario.
• rolename — cadena de rol ("Student" o "Teacher").

El experimento se realizó en Waydroid (Android containerizado) con acceso root:

• Iniciar sesión con una cuenta de estudiante.
• Editar el archivo /data/data/ru.vendor.schoolapp/shared_prefs/:

* Cambiar rolename a "Teacher".

* Sustituir con el user_sys_guid de un profesor (obtenido previamente vía API).

• Reiniciar la app.

Resultado: La interfaz cambió instantáneamente al modo profesor con acceso completo al libro de calificaciones, incluidos los botones "SAVE" y "ADD COLUMN". El servidor no verificaba el rol del usuario, confiando ciegamente en los datos enviados por el cliente.

Este es un caso de libro de texto de Broken Access Control (BAC), donde el servidor falla en validar los derechos de acceso en cada solicitud.

Lecciones: Seguridad como fachada

La investigación expuso fallos sistémicos en el desarrollo de soluciones de TI gubernamentales:

• Sin seguridad básica: Almacenar claves en el código y omitir verificaciones de permisos son errores fatales.
• Correcciones superficiales: Cambiar XOR por AES sin una reforma arquitectónica no resuelve nada.
• Escala de la amenaza: Las vulnerabilidades afectan múltiples regiones, poniendo en peligro los datos de millones de escolares.

Tales fallos abren la puerta a accesos masivos no autorizados, incluida la manipulación de calificaciones y datos personales. Las agencias responsables siguen ignorando la amenaza pese a las pruebas.

Puntos clave

• La vulnerabilidad BAC permite a cualquier usuario convertirse en profesor ajustando solo dos parámetros en un archivo local.
• Las claves secretas de API y cifrado están hardcodeadas en la app, lo que las hace fáciles de extraer tras la descompilación.
• Las autoridades se limitan a correcciones superficiales, ignorando las causas raíz.
• El problema abarca múltiples regiones, lo que apunta a un desarrollo basado en plantillas que escatima en seguridad.

— Editorial Team