Zpět na domů

Zranitelnost BAC v elektronických denících: stát se učitelem bez oprávnění

Výzkum odhalil kritickou zranitelnost Broken Access Control ve školních elektronických denících. Zranitelnost umožňuje získat přístup k funkcím učitele změnou lokálních parametrů. Odpovědné struktury problém ignorují navzdory rizikům úniku dat milionů školáků.

Jak získat práva učitele ve školním deníku prostřednictvím zranitelnosti BAC?
Advertisement 728x90

# Kritická zranitelnost BAC ve školních elektronických denících: jak se stát učitelem bez oprávnění

Během reverzního inženýrství populárního školního elektronického deníku byla odhalena kritická zranitelnost Broken Access Control (BAC), která umožňuje jakémukoli uživateli získat plný přístup k funkcím učitele. Analýza kódu aplikace ukázala absenci serverové kontroly oprávnění a ukládání tajných klíčů v otevřeném textu.

Reverzní inženýrství odhalilo slabá místa

Výzkum začal analýzou APK souboru aplikace pomocí dekompilátoru JADX. První nálezy byly znepokojivé:

  • Debugovací cookies v logách: Sesijní cookies X1_SSO byly vypisovány do logcat bez šifrování, což umožňovalo jejich zachycení.
  • Domácí šifrování: Místo deklarovaného AES byl použit jednoduchý XOR s pevně zakódovaným klíčem – názvem balíčku aplikace (ru.vendor.schoolapp).
  • Univerzální zástup: Při absenci klíče zařízení aplikace používala pevný identifikátor 000xpda.

Tyto zranitelnosti již umožňovaly automatizovaný přístup k osobním údajům žáka. Další analýza API však odhalila vážnější problém: absenci kontroly oprávnění na serveru. Nahrazení guid uživatele v požadavku bez tokenu X1_SSO poskytlo přístup k údajům libovolného žáka.

Google AdInline article slot

Pozoruhodné je, že identické zranitelnosti byly nalezeny v aplikacích používaných nejméně ve třech ruských regionech, což ohrožuje údaje stovek tisíc školáků.

Zodpovědné odhalení: ignorování hrozby

Autor se pokusil upozornit odpovědné orgány prostřednictvím postupu Responsible Disclosure. Oslovení Ministerstva digitálního rozvoje bylo přesměrováno do regionálních struktur, konkrétně do Regionálního centra informačních technologií (ŘCIT), uvedeného jako vývojář.

ŘCIT reagoval slibem „odstranit připomínky“, ale reální změny byly pouze kosmetické:

Google AdInline article slot
  • Odstranili XOR šifrování, které bylo snadno detekovatelné.
  • Nahradili ho AES, ale klíče nechali v kódu aplikace.

Příklad z třídy 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");
    }
}

Opakované oslovení prostřednictvím Roskomnadzoru také nepřineslo opravu zranitelností v jiných regionech. Systém nadále spoléhající na klientskou kontrolu rolí činil zranitelnost BAC kritickou.

Broken Access Control: jak se stát učitelem za minutu

Klíčová zranitelnost spočívala v tom, že aplikace ukládala data relace do souboru shared_prefs v otevřeném textu. Dvě parametry určovaly přístup:

Google AdInline article slot
  • user_sys_guid — identifikátor uživatele.
  • rolename — řetězec s rolí („Žák“ nebo „Učitel“).

Experiment probíhal na Waydroid (kontajnerizovaném Androidu) s root přístupem:

  • Přihlášení pod účtem žáka.
  • Úprava souboru /data/data/ru.vendor.schoolapp/shared_prefs/:

* Nahrazení rolename za „Učitel“.

* Dosazení user_sys_guid učitele (získaného dříve přes API).

  • Restart aplikace.

Výsledek: rozhraní se okamžitě přepnulo do režimu učitele s plným přístupem k žurnálu, včetně tlačítek „ULOŽIT“ a „PŘIDAT SLOUPec“. Server roli uživatele nekontroloval a plně důvěřoval datům odeslaným klientem.

Jedná se o klasický příklad Broken Access Control (BAC), kdy server nevaliduje práva přístupu u každého požadavku.

Závěry: bezpečnost jako imitace

Výzkum odhalil systémové problémy ve vývoji státních IT řešení:

  • Absence základní bezpečnosti: Ukládání klíčů v kódu a ignorování kontroly oprávnění – fatální chyby.
  • Kosmetické opravy: Nahrazení XOR za AES bez refaktoringu architektury problém nevyřeší.
  • Rozsah hrozby: Zranitelnosti postihují několik regionů, ohroženy jsou údaje milionů školáků.

Takové zranitelnosti otevírají cestu k masovému neoprávněnému přístupu, včetně změn známek a osobních údajů. Odpovědné struktury hrozbu ignorují navzdory důkazům.

Co je důležité

  • Zranitelnost BAC umožňuje jakémukoli uživateli stát se učitelem změnou pouze dvou parametrů v lokálním souboru.
  • Tajné klíče API a šifrování jsou pevně zakódovány v kódu aplikace, což je činí dostupnými po dekompilaci.
  • Odpovědné orgány se omezují na kosmetické opravy, aniž by odstranily kořenové příčiny problémů.
  • Problém postihuje několik regionů, což ukazuje na šablonový přístup k vývoji bez zohlednění bezpečnosti.

— Editorial Team

Advertisement 728x90

Číst dál