Vulnérabilité BAC dans les Journaux Électroniques : Devenez Enseignant Sans Permissions

# Vulnérabilité critique de contrôle d'accès défaillant dans les carnets électroniques scolaires : Comment devenir professeur sans autorisations

Lors de l'ingénierie inverse d'une application populaire de carnet électronique scolaire, une vulnérabilité critique de contrôle d'accès défaillant (BAC) a été découverte, permettant à n'importe quel utilisateur d'accéder pleinement aux fonctions de professeur. L'analyse du code a révélé l'absence de vérifications de permissions côté serveur et des clés secrètes stockées en clair.

L'ingénierie inverse révèle des faiblesses

L'enquête a commencé par l'analyse du fichier APK de l'application à l'aide du décompilateur JADX. Les premières découvertes étaient alarmantes :

• Cookies de débogage dans les logs : Les cookies de session X1_SSO étaient enregistrés dans logcat sans chiffrement, rendant possible l'usurpation de sessions.
• Chiffrement maison : Au lieu de l'AES annoncé, il utilisait un simple XOR avec une clé codée en dur — le nom du package de l'application (ru.vendor.schoolapp).
• Solution de repli universelle : Sans clé d'appareil, l'application utilisait par défaut un ID fixe 000xpda.

Ces failles permettaient déjà un accès automatisé aux données personnelles des élèves. Mais une analyse plus approfondie de l'API a révélé un problème plus grave : l'absence de vérifications de permissions côté serveur. Il suffisait simplement d'échanger le guid de l'utilisateur dans les requêtes sans jeton X1_SSO pour accéder aux données de n'importe quel élève.

Notamment, des vulnérabilités identiques ont été trouvées dans des applications utilisées dans au moins trois régions russes, mettant en danger les données de centaines de milliers d'élèves.

Divulgation responsable : Menace ignorée

L'auteur a tenté d'informer les autorités compétentes via des procédures de divulgation responsable. La prise de contact avec le Ministère du Développement numérique a été redirigée vers des organismes régionaux, en particulier le Centre régional des technologies de l'information (RCIT), indiqué comme développeur.

Le RCIT a répondu par des promesses de « résoudre les problèmes », mais les correctifs étaient superficiels :

• Suppression du chiffrement XOR facilement détectable.
• Remplacement par AES, mais en laissant les clés dans le code de l'application.

Exemple tiré de la classe 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");
    }
}

Les relances via Roskomnadzor n'ont pas non plus permis de corriger les vulnérabilités dans d'autres régions. Le système continuait à s'appuyer sur des vérifications de rôles côté client, rendant la vulnérabilité BAC critique.

Contrôle d'accès défaillant : Comment devenir professeur en une minute

La vulnérabilité principale provenait du stockage des données de session en clair dans le fichier shared_prefs. Deux paramètres contrôlaient l'accès :

• user_sys_guid — identifiant utilisateur.
• rolename — chaîne de rôle (« Student » ou « Teacher »).

L'expérience a été menée sur Waydroid (Android conteneurisé) avec accès root :

• Connexion avec un compte élève.
• Édition du fichier /data/data/ru.vendor.schoolapp/shared_prefs/ :

* Changement de rolename en « Teacher ».

* Remplacement par un user_sys_guid de professeur (obtenu précédemment via API).

• Redémarrage de l'application.

Résultat : L'interface bascule instantanément en mode professeur avec accès complet au cahier de notes, y compris les boutons « SAVE » et « ADD COLUMN ». Le serveur ne vérifiait pas le rôle de l'utilisateur, se fiant aveuglément aux données soumises par le client.

C'est un cas d'école de contrôle d'accès défaillant (BAC), où le serveur omet de valider les droits d'accès à chaque requête.

Leçons : La sécurité comme vernis

La recherche a mis en lumière des failles systémiques dans le développement de solutions informatiques gouvernementales :

• Absence de sécurité de base : Stocker les clés dans le code et omettre les vérifications de permissions sont des erreurs fatales.
• Correctifs superficiels : Remplacer XOR par AES sans refonte architecturale ne résout rien.
• Échelle de la menace : Les vulnérabilités touchent plusieurs régions, mettant en péril les données de millions d'élèves.

De telles failles ouvrent la voie à des accès non autorisés massifs, y compris la modification des notes et des données personnelles. Les agences responsables continuent d'ignorer la menace malgré les preuves.

Points clés

• La vulnérabilité BAC permet à n'importe quel utilisateur de devenir professeur en modifiant juste deux paramètres dans un fichier local.
• Les clés secrètes de l'API et du chiffrement sont codées en dur dans l'application, faciles à extraire après décompilation.
• Les autorités se limitent à des correctifs superficiels, ignorant les causes profondes.
• Le problème touche plusieurs régions, indiquant un développement templatisé qui lésine sur la sécurité.

— Editorial Team