ronf98/cve-2024-11972-pocCVE-2024-11972 in Hunk Companion <1.9.0 consente a utenti non autenticati di sfruttare endpoint REST API insicuri e installare plugin vulnerabili, rischiando RCE, SQLi, XSS e backdoor.
CVE-2024-11972 è una vulnerabilità critica nel plugin WordPress Hunk Companion nelle versioni precedenti alla 1.9.0. Questa falla consente ad attaccanti non autenticati di sfruttare endpoint API REST non adeguatamente autorizzati, permettendo loro di installare e attivare plugin dal repository WordPress.org, inclusi quelli obsoleti o con vulnerabilità note. Sfruttare questa vulnerabilità può portare a gravi rischi per la sicurezza, come esecuzione di codice remoto, SQL injection, XSS o backdoor amministrative.
Un esempio comune di abuso di questa vulnerabilità è con il plugin WP Query Console. Una volta installato utilizzando questo exploit, il plugin fornisce un'interfaccia console all'interno di WordPress dove gli utenti possono eseguire query SQL sul database del sito, consentendo il furto di dati, la creazione di backdoor e il completo compromesso del database.
Librerie Python necessarie -> argparse, requests, urljoin
options:
-h, --help show this help message and exit
-u URL, --url URL Base URL of the WordPress site (default: http://localhost/wordpress/).
-p PLUGIN, --plugin PLUGIN
Plugin name to install (default: classic-editor).
<insert wordpress URL> -p <insert plugin name>L'endpoint vulnerabile, /wp-json/hc/v1/themehunk-import, è stato inizialmente identificato da Daniel Rodriguez durante un'analisi dei log di accesso come parte di un'indagine in corso.
Utilizzando queste informazioni possiamo esaminare il codice sorgente dell'endpoint di importazione.
All'interno del file /import/core/class-installation.php possiamo vedere la seguente riga:
204 | $temp_file = download_url('https://downloads.wordpress.org/plugin/'.$slug.'.zip');
La classe HUNK_COMPANION_SITES_BUILDER_SETUP gestisce l'installazione e l'attivazione di plugin e temi WordPress, gestendo sia i tipi gratuiti che premium in base ai parametri di input.
Controlla dinamicamente se un plugin o un tema è installato o attivo, scarica e decomprime i file necessari se mancanti, e li attiva utilizzando le funzioni core di WordPress.
Questa funzionalità hardcoded permette al plugin di scaricare qualsiasi plugin dal repository WordPress, anche quelli rimossi o discontinuati, dando agli attaccanti l'opportunità di sfruttare plugin vulnerabili per l'exploit.
Per approfondire il problema, possiamo esaminare /import/app/app.php,
confrontiamo le diverse correzioni introdotte nelle versioni 1.8.0 | 1.8.7 | 1.9.0 poiché ciascuna ha introdotto un ulteriore livello di sicurezza:
register_rest_route( 'hc/v1', 'themehunk-import', array(
'methods' => 'POST',
'callback' => array( $this, 'tp_install' ),
'permission_callback' => '__return_true',
) );
Il permission_callback restituisce sempre true, questo permette a qualsiasi utente o attore non autenticato di accedere all'endpoint tramite una richiesta POST.
Poiché non esiste alcun tipo di verifica Nonce o alcun processo di autenticazione, un attaccante potrebbe bypassare le autorizzazioni necessarie e installare direttamente il plugin desiderato.
Nella versione 1.8.7, sono stati introdotti diversi miglioramenti di sicurezza per affrontare le falle presenti nelle versioni precedenti,
ma l'endpoint /hc/v1/themehunk-import e l'implementazione complessiva presentano ancora significative falle:
public function register_routes() {
register_rest_route( 'hc/v1', 'themehunk-import', array(
'methods' => 'POST',
'callback' => array( $this, 'tp_install' ),
'permission_callback' => function () {
// Check if the user is logged in
if ( ! is_user_logged_in() ) {
return new WP_REST_Response( 'Unauthorized: User not logged in', 401 );
}
// Debug: Log the user role and capabilities to see what they have
$current_user = wp_get_current_user();
// error_log( 'Current user: ' . $current_user->user_login );
// error_log( 'User roles: ' . implode( ', ', $current_user->roles ) );
// error_log( 'User capabilities: ' . print_r( $current_user->allcaps, true ) );
// Ensure the user has the 'install_plugins' capability
if ( ! current_user_can( 'install_plugins' ) ) {
return new WP_REST_Response( 'Unauthorized: Insufficient capabilities', 401 );
}
// Get the nonce from the request header
$nonce = $request->get_header('X-WP-Nonce');
// Verify the nonce
if ( ! wp_verify_nonce( $nonce, 'hc_import_nonce' ) ) {
return new WP_REST_Response( 'Unauthorized: Invalid nonce', 401 );
}
return true; // Permission granted
Mentre questa versione include controlli per assicurarsi che l'utente sia autenticato (is_user_logged_in()) e verifica che abbia le capacità appropriate (current_user_can('install_plugins')), inviando una risposta 401 Unauthorized in caso contrario, trascura ancora il problema principale che rimane irrisolto.
La logica di callback di WordPress per quanto riguarda permission_callback viene valutata in questo modo:
Ciò significa che una risposta corretta sarebbe una delle seguenti - true | false | WP_Error.
Il problema deriva dal fatto che il WP_REST_Response restituito non è un booleano né un WP_Error, poiché WordPress non lo interpreta come un rifiuto (false) né come un errore (WP_Error(), potrebbe implicitamente accettarlo e concedere l'accesso a un utente non autenticato, non risolvendo sostanzialmente il problema principale.
La versione 1.9.0 ha risolto con successo il problema, rendendo la vulnerabilità non più sfruttabile:
public function register_routes() {
register_rest_route( 'hc/v1', 'themehunk-import', array(
'methods' => 'POST',
'callback' => array( $this, 'tp_install' ),
'permission_callback' => function () {
// Check if the user is logged in
if ( ! is_user_logged_in() ) {
return false;
}
// Debug: Log the user role and capabilities to see what they have
$current_user = wp_get_current_user();
// error_log( 'Current user: ' . $current_user->user_login );
// error_log( 'User roles: ' . implode( ', ', $current_user->roles ) );
// error_log( 'User capabilities: ' . print_r( $current_user->allcaps, true ) );
// Ensure the user has the 'install_plugins' capability
if ( ! current_user_can( 'install_plugins' ) ) {
return false;
}
// Get the nonce from the request header
$nonce = $request->get_header('X-WP-Nonce');
// Verify the nonce
if ( ! wp_verify_nonce( $nonce, 'hc_import_nonce' ) ) {
return false;
}
return true; // Permission granted
In questa versione, possiamo vedere che viene restituito un valore false appropriato se l'utente non è autenticato o non ha le autorizzazioni corrette, assicurando che permission_callback neghi correttamente l'accesso non autorizzato, rendendo l'exploit non più valido.