Security

Have fun with file extension and file upload (cve-2019-16318)

Filename size matter!

Daniele Scanu Settembre, 2020
Have fun with file extension and file upload (cve-2019-16318)
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 è ext4fourth 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:
 
Pimcore asset(s) upload functionality

Il file caricato viene semplicemente reso disponibile nella web-root /nome-file, di seguito un esempio.
 
Asset caricato in Pimcore

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
 
Burp Suite - richiesta di upload in .php e risposta di conferma di upload di un .txt

Infatti, navigando sulla webroot del sito, possiamo ritrovare il file /pimcore.php.txt, come da screenshot qui sotto.
 
Conferma della NON esecuzione del codice PHP

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").
 
Bupr Suite - Upload di un file con un nome di 255 bytes

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`):
Pimcore file caricato e correttamente visualizzato come file PHP

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.
 
Pimcore Remote Code Execution (RCE)
 

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

Security

Articoli in evidenza

Approfondimenti

UNISCITI A NOI. INVIA LA TUA CANDIDATURA

Certimeter Group crede nei valori, nella passione e nella professionalità delle persone.