sarpantkeltiek/cve-2024-37010Exploit per CVE-2024-37010: accedere allo storage esterno di un altro utente e movimento laterale
Exploit per CVE-2024-37010: accesso allo storage esterno di altri utenti e movimento laterale:
https://www.cert.ssi.gouv.fr/avis/CERTFR-2024-AVI-0753/
https://owncloud.com/security-advisories/insecure-direct-object-reference-in-external-storage
Owncloud trasforma un server in un cloud per archiviare file, come Google Drive. Ciò consente, ad esempio, alle aziende di fornire un cloud per i dipendenti, senza che sia gestito da terze parti.
Se gli amministratori lo hanno configurato in questo modo, gli utenti possono anche collegare storage esterni, come altri cloud, FTP o Google Drive, per centralizzare i file su un unico cloud e semplificare così la vita degli utenti.
Una volta creato il nostro storage esterno, possiamo aggiornare questo modulo per modificare, ad esempio, il campo "Nome cartella". Quando il modulo viene aggiornato, viene inviata una richiesta con l'intero modulo in formato JSON. In questo modulo, il campo 'ID', essendo un intero, è l'identificatore del nostro storage esterno, generato dal server quando abbiamo creato lo storage.
Immaginiamo che un altro utente su Owncloud, ad esempio l'amministratore, abbia anche uno storage esterno, con ID "18".
Ora, ripetiamo la richiesta di aggiornamento del modulo come utente "normal_user", senza privilegi speciali, ma cambiamo l'ID in 18, lo storage esterno dell'amministratore.
![[images/req.png]](images/req.png)
Una volta inviata la richiesta, il server restituisce un errore 404 (4) e ci informa di non aver trovato alcuno storage con l'ID specificato (5).
Tuttavia, quando accediamo all'account amministratore, ecco cosa vediamo:
![[pwned_article.png]](images/pwned_article.png)
Lo storage dell'amministratore è stato aggiornato.
Se accediamo di nuovo come "normal_user", possiamo vedere che ora abbiamo accesso a "storage_pwned", lo storage dell'amministratore.
![[access.png]](images/access.png)
L'utente A è riuscito ad aggiornare lo storage dell'utente B e a riottenere i diritti di accesso ad esso. Ricordiamo che l'utente A NON deve modificare l'host durante la richiesta di aggiornamento, per non rompere la configurazione dell'utente B e poi poter accedere ai file di quest'ultimo.
Ecco il codice utilizzato per aggiornare lo storage esterno.
![[Pasted image 20241016114714.png]](images/2.png)
Innanzitutto, possiamo vedere che non c'è alcuna verifica dei diritti dell'utente che ha appena effettuato la richiesta. Il codice non controlla che lo storage appartenga all'utente che effettua la richiesta. Questo spiega perché "normal_user" ha potuto aggiornare lo storage dell'amministratore.
In secondo luogo, possiamo vedere che ad ogni aggiornamento, il codice aggiunge l'utente che ha appena effettuato la richiesta agli utenti autorizzati a connettersi allo storage, spiegando così perché "normal_user" ha ottenuto magicamente l'accesso allo storage dell'amministratore dopo l'aggiornamento.
In questo esempio, abbiamo visto come sia possibile per un utente ottenere accesso completo allo storage esterno di un altro utente e quindi accedere ai suoi file personali. Questo rende già la vulnerabilità piuttosto critica.
A questo punto, come potete vedere, questo IDOR (Insecure Direct Object Reference) è già una vulnerabilità importante. Ma proviamo a continuare a sfruttarla per aumentare l'impatto che potrebbe avere.
Per fare ciò, comprendiamo il processo di autenticazione eseguito dal server Owncloud per lo storage esterno al fine di recuperare i file. Per i sistemi di autenticazione di base che utilizzano una semplice coppia login/password, il server cloud si limiterà a
![[Pasted image 20241017162909.png]](images/20241017162909.png)
Ora, immaginiamo che un attaccante riesca ad aggiornare questa configurazione cambiando l'host con un indirizzo che controlla. Ciò significa che il server Owncloud ora invierà le credenziali a questo nuovo indirizzo, controllato dall'attaccante.
![[Pasted image 20241017163143.png]](images/20241017163143.png)
Questo è esattamente ciò che possiamo fare grazie alla nostra vulnerabilità.
Quando ripetiamo la richiesta di aggiornamento specificando l'ID dello storage di un altro utente, dobbiamo solo cambiare l'host specificando, ad esempio, il nostro collaborator Burp.
![[Pasted image 20241017163326.png]](images/20241017163326.png)
In questo modo, quando l'utente si riconnette, il server Owncloud tenta di autenticarsi presso il nostro collaborator inviandogli le credenziali dell'utente.
![[Pasted image 20241017163644.png]](images/20241017163644.png)
Magicamente, il collaborator riceve la richiesta di autenticazione dal server Owncloud con le credenziali codificate in Base64.
![[Pasted image 20241017163945.png]](images/20241017163945.png)
Abbiamo appena recuperato le credenziali in chiaro dello storage esterno dell'amministratore.
Per l'autenticazione sullo storage esterno, puoi utilizzare le tue credenziali Owncloud per accedere, se ad esempio usi la stessa password. Quando si richiede un aggiornamento dello storage esterno, puoi specificare "password::sessioncredentials" nel campo "authMechanism".
Il server Owncloud salverà quindi le nostre credenziali in chiaro al prossimo accesso e le trasferirà al nostro dispositivo di storage esterno per l'autenticazione.
Quindi potete immaginare...
Ciò significa che un attaccante può anche attivare questo meccanismo per lo storage esterno di un altro utente e quindi trasferire le credenziali in chiaro della sessione Owncloud della vittima a un host che controlla, come abbiamo appena fatto.
CVE-2024-37010 permette quindi a un attaccante con un account su un server Owncloud di:
