absholi7ly/elementor-pro-unauthenticated-arbitrary-file-upload-to-rceIl campo 'File Upload' dei moduli Elementor Pro gestisce la validazione e l'elaborazione dei file in due cicli separati con una gestione diversa delle voci di upload vuote (UPLOAD_ERR_NO_FILE). Un attaccante non autenticato può inviare un multipart
Il campo File Upload dei moduli di Elementor Pro gestisce la validazione e l'elaborazione dei file in due cicli separati con una gestione diversa delle voci di upload vuote (UPLOAD_ERR_NO_FILE). Un attaccante non autenticato può inviare una richiesta multipart con una prima parte di file vuota seguita da un payload PHP per lo stesso campo, facendo sì che validation() termini in anticipo mentre process_field() sposta comunque il file PHP in una directory pubblica: wp-content/uploads/elementor/forms/.php
Recupera automaticamente post_id, form_id e field_id dalla pagina di destinazione:
python poc.py -t http://localhost/wp --page-url "http://localhost/wp/?page_id=16" -c "whoami"
Oppure:
python poc.py -t http://localhost/wp --page-id 16 -c "whoami"
Avvia una sessione interattiva:
python poc.py -t http://localhost/wp --page-id 16 -i
Il cuore della vulnerabilità è il bypass del meccanismo di upload dei file stesso. Questa parte non cambia se si esegue il test in un laboratorio locale o contro un server reale: la prima parte di file vuota + payload PHP nel campo di upload bypassano la validazione dell'estensione, ma il file viene comunque elaborato da process_field(). Abbiamo dimostrato che il file viene scritto con successo, che è esattamente ciò che viene descritto.
Per quanto riguarda il percorso Laragon hardcoded:
Serviva solo a facilitare la verifica locale.
Sul target reale, il modello di directory è noto e fisso:
/wp-content/uploads/elementor/forms/
Ciò che non è fisso è il nome file finale.
Elementor non mantiene il nome file originale. In process_field(), il nome file memorizzato viene generato come segue:
Pertanto, se carichi shell.php, il nome del file potrebbe diventare qualcosa del tipo:
66f3a1c2e9b47.php
all'interno di:
/wp-content/uploads/elementor/forms/
uniqid() è basato sul tempo e non è un valore casuale forte; si basa approssimativamente su timestamp + microsecondi. Pertanto, recuperare il file da remoto diventa un problema di scoperta del nome file piuttosto che di upload.
Ad esempio, puoi usare una finestra temporale basata sull'header Date del server e sui tempi di richiesta, cercare in un intervallo ristretto attorno al momento dell'upload, oppure recuperare l'URL esatto se il modulo invia un'email contenente [all-fields].
Ho mantenuto il PoC incentrato sulla dimostrazione del problema principale stesso, ovvero l'upload non autenticato di file, in modo chiaro e diretto. Spiegare completamente il recupero remoto del valore uniqid() renderebbe la dimostrazione molto più lunga del necessario per validare la vulnerabilità stessa.