BAC Vulnerability in Electronic Diaries: Become a Teacher Without Permissions

# Critical BAC Vulnerability in School Electronic Diaries: How to Become a Teacher Without Permissions

During reverse engineering of a popular school electronic diary app, a critical Broken Access Control (BAC) vulnerability was uncovered, allowing any user to gain full access to teacher functions. Code analysis revealed a lack of server-side permission checks and secret keys stored in plain text.

Reverse Engineering Reveals Weak Spots

The investigation started with analyzing the app's APK file using the JADX decompiler. The initial findings were alarming:

• Debug cookies in logs: Session cookies X1_SSO were logged to logcat unencrypted, making it possible to hijack sessions.
• Homemade encryption: Instead of the claimed AES, it used simple XOR with a hardcoded key—the app's package name (ru.vendor.schoolapp).
• Universal fallback: Without a device key, the app defaulted to a fixed ID 000xpda.

These flaws already enabled automated access to student personal data. But deeper API analysis uncovered a more severe issue: no server-side permission checks. Simply swapping the user's guid in requests without an X1_SSO token granted access to any student's data.

Notably, identical vulnerabilities were found in apps used in at least three Russian regions, putting the data of hundreds of thousands of schoolchildren at risk.

Responsible Disclosure: Threat Ignored

The author attempted to notify the relevant authorities via Responsible Disclosure procedures. Outreach to the Ministry of Digital Development was redirected to regional bodies, specifically the Regional Center for Information Technologies (RCIT), listed as the developer.

RCIT responded with promises to "address the issues," but the fixes were superficial:

• Removed the easily detectable XOR encryption.
• Replaced it with AES, but left the keys in the app code.

Example from the Crypt.java class:

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");
    }
}

Follow-up outreach via Roskomnadzor also failed to fix vulnerabilities in other regions. The system continued to rely on client-side role checks, making the BAC vulnerability critical.

Broken Access Control: How to Become a Teacher in a Minute

The key vulnerability stemmed from the app storing session data in plain text in the shared_prefs file. Two parameters controlled access:

• user_sys_guid — user identifier.
• rolename — role string ("Student" or "Teacher").

The experiment was conducted on Waydroid (containerized Android) with root access:

• Log in with a student account.
• Edit the file /data/data/ru.vendor.schoolapp/shared_prefs/:

* Change rolename to "Teacher".

* Swap in a teacher's user_sys_guid (obtained earlier via API).

• Restart the app.

Result: The interface instantly switched to teacher mode with full access to the gradebook, including "SAVE" and "ADD COLUMN" buttons. The server didn't check the user's role, blindly trusting client-submitted data.

This is a textbook case of Broken Access Control (BAC), where the server fails to validate access rights on every request.

Takeaways: Security as Window Dressing

The research exposed systemic flaws in developing government IT solutions:

• No basic security: Storing keys in code and skipping permission checks are fatal errors.
• Superficial fixes: Swapping XOR for AES without architectural overhaul doesn't solve anything.
• Scale of the threat: Vulnerabilities affect multiple regions, endangering data for millions of schoolchildren.

Such flaws pave the way for mass unauthorized access, including tampering with grades and personal data. Responsible agencies continue to ignore the threat despite the evidence.

Key Points

• The BAC vulnerability lets any user become a teacher by tweaking just two parameters in a local file.
• API and encryption secret keys are hardcoded in the app, making them easy to extract after decompilation.
• Authorities limit themselves to superficial fixes, ignoring root causes.
• The issue spans multiple regions, pointing to templated development that skimps on security.

— Editorial Team