m3m0o/portabilis-ieducar-user-type-privilege-escalationProva di concetto per lo sfruttamento della vulnerabilità descritta in CVE-2025-11554, che riguarda la possibilità di un'escalation dei privilegi tramite richieste arbitrarie all'endpoint di modifica dei tipi di utente nel software i-Educar.
Prova di concetto per lo sfruttamento della vulnerabilità descritta in CVE-2025-11554, che riguarda la possibilità di un'escalata di privilegi durante richieste arbitrarie agli endpoint dei tipi utente nel software i-Educar.
Gli utenti senza i privilegi necessari per modificare i tipi utente possono modificare le autorizzazioni dei tipi utente registrati tramite una richiesta arbitraria all'endpoint responsabile di questa azione. Ciò consente agli utenti con privilegi bassi di aumentare i propri privilegi concedendo autorizzazioni massime al tipo utente a cui sono associati, compromettendo tutte le sezioni dell'applicazione.
Per dimostrare la vulnerabilità, simuleremo un percorso di attacco che potrebbe essere utilizzato in uno scenario di sfruttamento reale. Innanzitutto, abbiamo l'utente Usuário sem Privilégios, associato al tipo utente Baixíssimo.
Il tipo utente Baixíssimo non ha privilegi associati e gli viene assegnato il livello di accesso più basso, Biblioteca, che ha il livello 8.
Ai fini di questa dimostrazione, possiamo vedere che le autorizzazioni per la modifica dei tipi utente sono disabilitate per questo ruolo, il che significa che gli utenti associati ad esso non dovrebbero essere in grado di visualizzare, creare/modificare o eliminare i tipi utente.
Dopo aver effettuato l'accesso come Usuário sem Privilégios, possiamo confermare che non sono assegnate autorizzazioni, poiché nessuna sezione è disponibile per lui.
Il primo passo nel processo di escalata dei privilegi è identificare il tipo utente assegnato all'utente. In varie risposte alle richieste che restituiscono documenti HTML renderizzati dall'applicazione, queste informazioni si trovano nella variabile dataLayer, situata all'interno del primo elemento script del documento. Possiamo verificare queste informazioni accedendo alla pagina iniziale dell'applicazione, ad esempio. In questa dimostrazione, Burp Suite verrà utilizzato per l'analisi e la manipolazione delle richieste.
Dopo aver identificato il tipo utente associato all'utente corrente, il passo successivo è determinare il suo identificativo memorizzato nel database. Per raggiungere questo obiettivo, si deve utilizzare l'endpoint /usuarios/tipos/<cod_tipo_usuario>. Poiché gli identificativi dei tipi utente sono numerici e sequenziali, è possibile enumerare tutti i tipi utente memorizzati finché non si trova quello associato all'utente corrente.
Il tipo utente identificato da 1, ad esempio, è il tipo utente amministrativo, Administrador, per impostazione predefinita.
Nella risposta dell'applicazione, possiamo vedere le autorizzazioni associate al tipo utente nell'oggetto processes. Ogni sezione specifica è identificata da un identificativo numerico univoco, e il livello di accesso del tipo utente a quella sezione è determinato dai numeri 0, 1, 2, o 3:
Possiamo osservare che il tipo utente amministrativo ha livello di accesso 3 per tutte le sezioni.
Quando si richiede il tipo utente con identificativo 2, vediamo che corrisponde al tipo utente associato all'utente corrente. Questo tipo utente ha un livello di accesso 0 per tutte le sezioni.
Con tutto questo in mente, possiamo procedere con l'escalata dei privilegi. Per farlo, una richiesta POST deve essere inviata allo stesso endpoint, contenente l'identificativo del tipo utente corrispondente all'identificativo del tipo utente associato all'utente corrente. Il corpo della richiesta deve includere i parametri _method, name, level, description, e processes. Non tutti i valori richiesti sono immediatamente comprensibili, ma poiché si tratta di un progetto open-source, la struttura corretta della richiesta potrebbe essere facilmente scoperta tramite revisione del codice o test manuali su un'istanza locale.
Nella richiesta seguente, modifichiamo il livello di accesso per tutte le sezioni al massimo accesso (3) e cambiamo il tipo utente da Biblioteca a Poli-institucional (parametro level impostato al valore 1).** Ciò significa che l'utente otterrebbe accesso a tutte le istituzioni registrate, non solo a quella associata durante la sua creazione.
Dopo questo, ricaricando la pagina iniziale, possiamo confermare che l'utente precedentemente senza privilegi ora ha tutti i privilegi disponibili nel contesto dell'applicazione, concessi arbitrariamente.
Le rotte per gli endpoint vulnerabili si trovano nel file routes/web.php.
I metodi vulnerabili utilizzati da queste rotte si trovano nel file app/Http/Controllers/AccessLevelController.php. Questi metodi non eseguono un controllo delle autorizzazioni sull'utente richiedente prima di eseguire le azioni richieste sui tipi utente.
Questo software è utilizzato come soluzione di gestione scolastica in varie istituzioni pubbliche. Ogni istanza contiene potenzialmente vari tipi di informazioni sensibili sugli utenti e sugli studenti registrati, come documenti di identificazione e cartelle cliniche (condizioni mediche). In uno scenario in cui un utente malintenzionato con privilegi bassi o un account controllato da un attaccante sfrutta questa vulnerabilità, la riservatezza, l'integrità e la disponibilità di questi record sarebbero a rischio. Una rapida valutazione della sicurezza del progetto rivelerebbe questa debolezza.
