Una delle funzionalità più critiche da implementare dal punto di vista della sicurezza, e una delle più sfruttate durante gli attacchi informatici, è senza dubbio il file upload. Esistono molte tecniche che si possono utilizzare per ottenere la compromissione del servizio tramite il file upload, ma quella trovata in Pimcore è una delle più interessanti.
In questo articolo descriviamo come è stato possibile ottenere l'esecuzione di codice remoto (RCE) tramite file upload, sfruttando la lunghezza massima dei nomi dei file. La vulnerabilità individuata ci è valsa il CVE 2019-16318.
Gestione dei file in Unix/Linux
Nei sistemi operativi Unix-like, uno dei filesystem più utilizzati è
ext4 o
fourth extended filesystem. Come in ogni filesystem, i file sono gestiti in un certo modo e devono rispettare determinati criteri, come ad esempio i caratteri consentiti all'interno del nome del file o la
lunghezza del nome del file. In ext4, la lunghezza di un file è
limitata ad un massimo di 255 bytes, come è possibile osservare anche su questa
tabella riassuntiva.
Questo è senz'altro un particolare molto interessante, da tenere in considerazione nei penetration test, soprattutto se si va a testare una funzionalità correlata alla gestione dei file, come il file upload. Chi ha
smanettato su
Hack The Box, avrà già visto in passato questa particolarità dei file su una delle macchine proposte dalla piattaforma, se non vi è capitato di farlo, andate a vedere la macchina di nome "Falafel" 😉.
Pimcore file upload
Nel pannello di amministrazione di Pimcore, è presente una funzionalità che permette al gestore del sito di caricare file o immagini sotto forma di assets:
Il file caricato viene semplicemente reso disponibile nella web-root /nome-file
, di seguito un esempio.
Andando ad esaminare più nel dettaglio la richiesta tramite Burp Suite, possiamo notare che il caricamento non è altro che un semplice file upload. La prima cosa che ci viene spontaneo fare è provare a caricare una web shell in PHP, ma Pimcore è furbo e non lo permette, anzi, il suo comportamento è molto particolare perché il file viene caricato ma, alla nostra estensione .php,
viene aggiunta l'estensione .txt
Infatti, navigando sulla webroot del sito, possiamo ritrovare il file /pimcore.php.txt
, come da screenshot qui sotto.
Sostanzialmente l'estensione del file è stata modificata da .php a .txt e la configurazione di default del web server non prevede l'esecuzione di file con questa estesione. Ci siamo quindi chiesti se fosse in qualche modo possibile "troncare" l'estensione .txt e la risposta è stata: sì, grazie alla gestione dei file nel filesystem e alla lunghezza massima di un nome di file.
Successivamente abbiamo provato a usare file con un nome di lunghezza 255 bytes che finisse con .php, in modo che non ci fosse più spazio per l'estensione .txt
inserita dalla web application.
Per generare il nome del file abbiamo usato il comando: (printf "%0.sA" {1..251} && echo ".php"
).
Come è possibile notare nell'immagine sotto, il file è stato caricato correttamente, ma tra gli assets appare come
file di tipo PHP. Questo avviene perchè se Pimcore riuscisse ad appendere l'estensione `.txt`, la lunghezza del nome del file passerebbe da 255 bytes a 259 bytes,
dimensione non ammessa da ext4. Il risultato è che Pimcore salva ugualmente il file mantenendo solo i primi 255 caratteri (scartando di conseguenza l'odioso `.txt`):
Infatti, provando ad accedere all'url `
/A*251.php?cmd=id
`,
abbiamo ottenuto la nostra fantastica web shell con la quale possiamo eseguire comandi sul sistema remoto.
Timeline
Data |
Cosa |
18 marzo 2019 |
La vulnerabilità è stata scoperta. |
19 marzo 2019 |
La vulnerabilità è stata segnalata al team di Pimcore. |
19 marzo 2019 |
Pimcore rilascia la patch. |
15 luglio 2019 |
SNYK rende pubblica la vulnerabilità. |
Conclusioni
La issue è stata riportata agli sviluppatori di Pimcore, che hanno prontamente fixato. In contemporanea è stata effettuata anche la disclosure tramite il canale ufficiale di Snyk che si occupa della gestione delle issues di sicurezza dei pacchetti appartenenti a Composer di cui Pimcore fa parte. Snyk, dopo una verifica, ha inserito la vulnerabilità all'interno del loro database facendoci assegnare il CVE-2019-16318.
Che dire, la combinazione di PHP con le particolarità dei sistemi operativi a volte può farci davvero emozionare!
Riferimenti