BAC-Schwachstelle in Elektronischen Tagebüchern: Werden Sie Lehrer ohne Berechtigungen

# # Kritische BAC-Schwachstelle in schulischen Elektronischen Tagebüchern: So werden Sie zum Lehrer ohne Berechtigungen

Bei der Reverse Engineering einer beliebten App für schulische Elektronische Tagebücher wurde eine kritische Broken Access Control (BAC)-Schwachstelle entdeckt, die es jedem Nutzer ermöglicht, vollen Zugriff auf Lehrerfunktionen zu erlangen. Die Code-Analyse ergab fehlende serverseitige Berechtigungsprüfungen und geheime Schlüssel, die im Klartext gespeichert waren.

Reverse Engineering deckt Schwachstellen auf

Die Untersuchung begann mit der Analyse der APK-Datei der App mithilfe des JADX-Decompilers. Die ersten Erkenntnisse waren alarmierend:

• Debug-Cookies in Logs: Session-Cookies X1_SSO wurden unverschlüsselt in logcat protokolliert, was eine Session-Hijacking ermöglicht.
• Eigenbau-Verschlüsselung: Statt des angepriesenen AES wurde eine einfache XOR-Verschlüsselung mit einem hartcodierten Schlüssel verwendet – dem Paketnamen der App (ru.vendor.schoolapp).
• Universeller Fallback: Ohne Geräteschlüssel griff die App auf eine feste ID 000xpda zurück.

Diese Mängel ermöglichten bereits automatisierten Zugriff auf personenbezogene Schülerdaten. Doch eine tiefere API-Analyse brachte ein noch schwerwiegenderes Problem ans Licht: fehlende serverseitige Berechtigungsprüfungen. Ein einfaches Ersetzen der guid des Nutzers in Anfragen ohne X1_SSO-Token gewährte Zugriff auf die Daten beliebiger Schüler.

Bemerkenswert: Identische Schwachstellen wurden in Apps aus mindestens drei russischen Regionen gefunden, wodurch die Daten Hunderttausender Schulkinder gefährdet sind.

Verantwortungsvolle Offenlegung: Bedrohung ignoriert

Der Autor versuchte, die zuständigen Behörden über Verantwortungsvolle Offenlegungsverfahren zu informieren. Die Kontaktaufnahme mit dem Ministerium für Digitale Entwicklung wurde an regionale Stellen weitergeleitet, insbesondere das Regionale Zentrum für Informationstechnologien (RCIT), das als Entwickler genannt wird.

RCIT reagierte mit Versprechungen, "die Probleme zu beheben", doch die Korrekturen waren oberflächlich:

• Entfernung der leicht erkennbaren XOR-Verschlüsselung.
• Ersetzung durch AES, wobei die Schlüssel im App-Code belassen wurden.

Beispiel aus der Klasse 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");
    }
}

Nachfolgende Kontaktaufnahmen über Roskomnadzor konnten die Schwachstellen in anderen Regionen ebenfalls nicht beheben. Das System verließ sich weiterhin auf clientseitige Rollprüfungen, was die BAC-Schwachstelle kritisch machte.

Broken Access Control: So werden Sie in einer Minute zum Lehrer

Die zentrale Schwachstelle resultierte aus der Speicherung von Session-Daten im Klartext in der shared_prefs-Datei. Zwei Parameter steuerten den Zugriff:

• user_sys_guid — Nutzerkennung.
• rolename — Rollenstring ("Student" oder "Teacher").

Das Experiment wurde auf Waydroid (containerisiertem Android) mit Root-Zugriff durchgeführt:

• Mit einem Schülerkonto anmelden.
• Die Datei /data/data/ru.vendor.schoolapp/shared_prefs/ bearbeiten:

* rolename auf "Teacher" ändern.

* Eine Lehrers-user_sys_guid einsetzen (zuvor über API ermittelt).

• App neu starten.

Ergebnis: Die Oberfläche wechselte sofort in den Lehrer-Modus mit vollem Zugriff auf das Klassenbuch, inklusive "SAVE"- und "ADD COLUMN"-Buttons. Der Server prüfte die Rolle des Nutzers nicht und vertraute blind auf clientseitig übermittelte Daten.

Dies ist ein Lehrbuchfall von Broken Access Control (BAC), bei dem der Server Zugriffsrechte bei jeder Anfrage nicht validiert.

Erkenntnisse: Sicherheit als Fassadenschein

Die Recherche deckte systematische Mängel bei der Entwicklung staatlicher IT-Lösungen auf:

• Keine Grundlagen-Sicherheit: Schlüssel im Code speichern und Berechtigungsprüfungen auslassen sind fatale Fehler.
• Oberflächliche Korrekturen: XOR durch AES austauschen ohne architektonische Überarbeitung löst nichts.
• Umfang der Bedrohung: Schwachstellen betreffen mehrere Regionen und gefährden Daten von Millionen Schulkinder.

Solche Mängel ebnen den Weg für massenhafte unbefugte Zugriffe, einschließlich Manipulation von Noten und personenbezogenen Daten. Zuständige Behörden ignorieren die Bedrohung trotz der Belege weiterhin.

Wichtige Punkte

• Die BAC-Schwachstelle erlaubt es jedem Nutzer, durch Änderung nur zweier Parameter in einer lokalen Datei zum Lehrer zu werden.
• API- und Verschlüsselungsschlüssel sind hartcodiert in der App und leicht nach Decompilation extrahierbar.
• Behörden beschränken sich auf oberflächliche Korrekturen und ignorieren die Ursachen.
• Das Problem erstreckt sich über mehrere Regionen und deutet auf vorgefertigte Entwicklung mit Sicherheitsvernachlässigung hin.

— Editorial Team