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