abraxas/joomla-levels-apiJoomla 6.1.3 - Alta - Remota - ACL - GET /api/v1/users/levels espone i livelli di visualizzazione
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · joomla-levels-api
Classe: Privilegio residuo Reach: Remoto
Joomla CMS 6.1.3 (0f2d4de) - Open Source Matters
Administrator Users -> Viewing Access Levels richiede core.admin su com_users (LevelController::allowSave e delete). Il webservice Groups fa già lo stesso (GroupsController, 6.1.1). LevelsController non ha override di allowAdd, allowEdit o delete, quindi ApiController lascia passare core.manage più core.create.
Un token API di classe Manager, a cui è concesso core.login.api senza core.admin, può creare livelli di accesso in visualizzazione che l'interfaccia utente vieta.
| ID | nessuna CVE al momento |
| Classe | Privilegio residuo / bypass di autorizzazione |
| Reach | Remoto (token API con core.login.api) |
| CWE | CWE-863 |
| CVSS | Medio: 6.1 CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N |
| Prodotto | Joomla CMS |
| Affetto | 6.1.3 (0f2d4de4729eb951e0878fec98c7990da07915b2) |
| Auth | Token API per Manager (gruppo 6) con core.login.api e com_users manage/create/edit. Nessun core.admin. Il valore predefinito di core.login.api è solo Super User. |
| Licenza | GNU Affero GPL v3.0 |
| Lab | solo 127.0.0.1 |
Usare un token API non-Super-User per cambiare quali gruppi vedono quali pagine. Non diventano Super User solo con questo residuo. Si tratta di controllo della visibilità dei contenuti, non di takeover del sito.
| Privilegio | Metodo / percorso | Tipo | Provato in lab o dedotto |
|---|---|---|---|
| Creare un livello di accesso in visualizzazione | POST /api/index.php/v1/users/levels JSON title, rules (id dei gruppi) | integrità | Provato in lab. HTTP 200, #__viewlevels id=7, titolo poc-level-JOOMLA-LEVELS-API-WITNESS |
| Modificare un livello esistente (lista gruppi / titolo) | PATCH /api/index.php/v1/users/levels/{id} | integrità | Dedotto. Stesso controller, nessun allowEdit. In lab è stato solo creato. |
| Eliminare un livello | DELETE /api/index.php/v1/users/levels/{id} | integrità / disponibilità delle righe ACL | Dedotto. Stesso override mancante. In lab non è stata eseguita la DELETE. |
| Esporre un articolo, modulo o voce di menu riservato ai membri | Nuovo livello o livello modificato le cui rules includono Public / Guest / Registered | ricognizione (visibilità dei contenuti) | Dedotto da #__viewlevels.rules. In lab è stata inserita la riga; non è stato riapplicato l'ACL a un articolo attivo. |
| Nascondere una pagina a Registered, o aggiungere il gruppo dell'attaccante a un livello Special | Stessa PATCH / creazione | integrità | Dedotto. Stesso store. |
| Modificare i gruppi utente dall'API | POST /api/index.php/v1/users/groups | n/d | Provato in lab chiuso. HTTP 403 (GroupsController core.admin) |
| Aprire Users -> Viewing Access Levels nell'amministratore | GET /administrator/index.php?option=com_users&view=levels | n/d | Provato in lab chiuso. HTTP 403 |
| Salvare un livello dall'interfaccia utente | POST ... task=level.save | n/d | Provato in lab chiuso. HTTP 403 (LevelController::allowSave richiede core.admin) |
Colpire l'API con un Manager standard (senza core.login.api) | Bearer token / X-Joomla-Token | n/d | Dedotto chiuso. Il valore predefinito di core.login.api è solo Super User (gruppo 8). Questo lab lo concede prima al gruppo 6. |
| RCE da Super User / installer | n/d | n/d | Chiuso. Il Manager resta Manager. |
Ho fissato joomla/joomla-cms 6.1.3 dopo l'ondata JSST di 2026-07/08. L'API Groups richiede già core.admin. I livelli di visualizzazione passano ancora attraverso ApiController (core.manage più core.create / core.edit / core.delete). L'unica logica extra su LevelsController è la decodifica JSON PATCH di rules.
Sibling Groups corretto:
public function allowAdd($data = [])
{
return $this->app->getIdentity()->authorise('core.admin', $this->option);
}
Interfaccia amministratore:
protected function allowSave($data, $key = 'id')
{
return $this->app->getIdentity()->authorise('core.admin', $this->option)
&& parent::allowSave($data, $key);
}
Vicoli ciechi già registrati: considerare l'API Groups ancora aperta (restituisce 403); colpire l'API come Manager standard senza prima concedere core.login.api (il valore predefinito è solo Super User, stessa configurazione di CVE-2026-71574 / 72531 / 48904); leggere il 403 dell'interfaccia utente come l'intera storia (il residuo è l'API). Teatro: una reverse shell. L'oracolo è API 200 più Groups 403 più UI 403.
Altri residui dello stesso pin: menu items API, media override, articles catid.
python3 joomla-levels-api-Abraxas-Labs.py
oppure
cd lab
./run.sh
Target solo http://127.0.0.1:19520. Immagine joomla:6.1.3-php8.3-apache più mariadb:11.4.
SUCCESS joomla-levels-api api-http=200 level-id=7 groups-api=403 ui-view=403 ui-save=403 JOOMLA-LEVELS-API-WITNESS
Copiare core.admin allowAdd / allowEdit / delete da GroupsController su LevelsController. Mantenere il gate dell'interfaccia amministratore.
0f2d4de4729eb951e0878fec98c7990da07915b2)LevelsController.phpcore.admin (6.1.1) · CVE-2026-71574GNU Affero GPL v3.0. Vedi LICENSE. Solo lab su loopback. Nessuna garanzia.