XSS2Shell: una catena pre-autenticazione può trasformare WordPress in una porta d’ingresso al server

Dalla pagina di login al DOM clobbering

I ricercatori di Pwn hanno descritto di recente XSS2Shell, una catena d’attacco critica che parte dalla pagina di accesso di WordPress e non richiede autenticazione iniziale.

L’attacco usa un nome utente inesistente, riflesso nel messaggio d’errore. Il primo filtro applicato da PHP tramite strip_tags() non riconosce come tag validi gli elementi scritti con uno spazio tra il carattere < e il nome:

< area id=ajaxurl>

Il successivo wp_kses_post() interpreta invece la stringa come un elemento HTML valido, trasformandola in contenuto attivo nel DOM.

L’attributo id="ajaxurl" abilita quindi un DOM clobbering: il browser espone l’elemento come proprietà window.ajaxurl, alterando il comportamento previsto dagli script della pagina.

L’abuso di user-profile.js e della REST API

La pagina di login carica anche user-profile.js, utilizzato per la gestione dei reset delle password. Lo script può individuare e attivare automaticamente un pulsante di reset manipolato, senza un clic esplicito dell’amministratore.

La catena sfrutta poi una risposta JSONP della REST API. Il parametro callback accetta punti, consentendo di attraversare catene di proprietà tra finestre del browser. I ricercatori hanno riutilizzato una tecnica resa pubblica per la prima volta nel 2022 per ottenere un clic cross-window nella sessione effettiva di un amministratore autenticato.

Il browser viene portato a una schermata WordPress per l’approvazione delle Application Password. Cookie e nonce della sessione amministrativa permettono di attivare automaticamente il pulsante di approvazione.

Il risultato è una Application Password valida per l’account amministratore.

Dalla credenziale alla possibile esecuzione di codice

WordPress accetta la Application Password tramite autenticazione HTTP Basic sulla REST API. La configurazione CORS riflette l’origine della richiesta e consente gli header Authorization e Content-Type, rendendo possibili chiamate API autenticate cross-origin.

Su installazioni single-site, gli amministratori dispongono normalmente della capability unfiltered_html. JavaScript arbitrario può quindi rimanere nei contenuti pubblicati.

L’attaccante può pubblicare una pagina con codice JavaScript, usarla per caricare un plugin e raggiungere l’esecuzione di codice PHP arbitrario. Nel proof of concept, una risposta JSON ha confermato l’esecuzione con l’identità dell’utente del web server.

L’impatto potenziale comprende:

• compromissione della sessione amministrativa;
• emissione fraudolenta di Application Password;
• pubblicazione di contenuti JavaScript;
• installazione di plugin malevoli;
• Remote Code Execution;
• possibile presa di controllo completa del server.

Il proof of concept non ha lasciato persistenza: i ricercatori hanno revocato la credenziale, eliminato la pagina e rimosso la directory del plugin.

Cosa devono verificare gli amministratori

Non sono stati indicati identificativi CVE né numeri di versione vulnerabili o corretti per WordPress, PHP, browser o componenti coinvolti.

Gli amministratori dovrebbero:

1. aggiornare WordPress alle versioni corrette rese disponibili dal vendor;
2. applicare gli aggiornamenti di sicurezza a WordPress, PHP e componenti installati;
3. revocare Application Password sospette o non necessarie;
4. controllare pagine pubblicate, plugin, directory dei plugin e log della REST API;
5. cercare richieste anomale verso gli endpoint di approvazione delle Application Password;
6. monitorare traffico JSONP e chiamate cross-origin con header Authorization;
7. ridurre i privilegi amministrativi e limitare, quando possibile, l’uso di unfiltered_html.

Le versioni interessate non sono note. Di conseguenza, l’assenza di un comportamento anomalo osservabile non è sufficiente per escludere una compromissione.