
WordPress 7.1.1 corregge la catena Click2Shell fino all'esecuzione remota di codice
WordPress 7.1.1 corregge Click2Shell, una falla che concatenava un clic di un amministratore fino a una shell remota sui siti che eseguono un tema vulnerabile.
WordPress 7.1.1 ha corretto una vulnerabilità che poteva permettere a un singolo clic di un amministratore autenticato di trasformarsi in una shell remota funzionante sul server, secondo un'analisi pubblicata da Patchstack. La falla, chiamata Click2Shell, è stata segnalata in modo responsabile da Paulos Yibelo di pwn.ai e chiusa nella release di WordPress del 17 settembre, con il resoconto di Patchstack a cura del ricercatore di sicurezza Chazz Wolcott pubblicato il 18 settembre. Patchstack dichiara che i propri clienti sono protetti dalla vulnerabilità e raccomanda a tutti gli altri di aggiornare immediatamente WordPress all'ultima versione disponibile.
Il bug è meno un singolo errore e più una catena. Patchstack lo descrive come un Cross-Site Request Forgery (CSRF, un trucco che fa inviare al browser autenticato della vittima una richiesta che la vittima non aveva mai intenzione di fare) combinato con una selector injection (caratteri extra inseriti nel codice che cerca gli elementi di una pagina, così che ne trovi uno diverso da quello previsto). Nessuna delle due debolezze è drammatica da sola. Concatenate, trasformano un singolo clic in codice in esecuzione sul server del sito.
Il meccanismo risiede nel modo in cui WordPress gestisce i temi. Gli amministratori possono visualizzare in anteprima o installare un tema direttamente dal catalogo WordPress.org all'interno del pannello di amministrazione, e quel flusso porta nell'URL lo slug del tema, il suo breve nome identificativo. Secondo Patchstack, lo stesso valore viene poi letto due volte da due parti diverse del codice, e le due non concordano su come trattarlo. Lato server, l'API dei Temi di WordPress.org sanifica il valore e rimuove i caratteri extra, così una stringa costruita ad arte come twentytwenty"]> si riduce di nuovo a twentytwenty nel momento in cui l'API risponde. Lato front end, il JavaScript di wp-admin prende lo stesso valore grezzo e lo inserisce direttamente in una stringa selettore jQuery, senza alcuna sanificazione. jQuery è una libreria JavaScript molto usata che aiuta le pagine web a trovare e modificare elementi. Questa discordanza è l'intera vulnerabilità: uno slug appositamente costruito può convincere la pagina che chi la sta guardando ha cliccato Installa su un tema completamente diverso.
Da sola, un'installazione silenziosa di un tema inattivo non è un grande rischio. Come osserva Patchstack, senza essere attivato in WordPress un tema o plugin inattivo è essenzialmente inerte. C'è un momento in cui un tema inattivo viene eseguito, ed è quando viene visualizzato in anteprima nel Customizer di WordPress. La catena completa costruita da pwn.ai usava un tema reale del catalogo, Mobile Repair Zone 2.5.4, come secondo stadio. Prima l'URL costruito ad arte installa il tema, poi un link successivo carica il Customizer con Mobile Repair Zone attivo. Questo fa sì che il file functions.php del tema venga eseguito e registri i suoi hook, incluso un gestore AJAX che accettava un URL di download di un plugin senza alcun controllo di nonce (un nonce è un codice monouso che prova che una richiesta proviene dalla tua sessione) e senza alcun controllo di permessi di alcun tipo. Passare a quell'azione un URL che punta a un file ZIP controllato dall'attaccante significa che WordPress tratta l'archivio malevolo come un normale plugin, lo scarica e lo esegue sul server. È questo il passaggio che cambia l'esito da un tema inattivo che appare a un attaccante che tiene in mano una shell funzionante.
Patchstack è esplicito sul fatto che non si tratta di un attacco drive-by, e la distinzione conta. Leggere in sequenza "nessun account attaccante necessario" e "esecuzione remota di codice" può far sembrare che qualsiasi visitatore possa attivarlo, ma l'attaccante deve far caricare a un amministratore del sito un URL costruito ad arte. Un visitatore normale non può attivarlo, e nemmeno un account con più privilegi come un Autore o un Editore. Ci sono due percorsi. Il primo è un attacco di phishing mirato contro uno specifico amministratore che è autenticato e interagisce con il link malevolo. Il secondo è un'iniezione XSS (Cross-Site Scripting, una falla che permette a un attaccante di inserire il proprio codice in una pagina, dove viene eseguito nel browser di chiunque la guardi) già presente sul sito, che fa partire la richiesta automaticamente quando un amministratore guarda la pagina. Quel secondo percorso presuppone che l'attaccante avesse già un punto d'appoggio, il che significa che qualche altro componente doveva essere vulnerabile all'XSS fin dall'inizio, e Click2Shell sarebbe solo uno dei vari modi per sfruttarlo. Il risultato completo di esecuzione remota di codice dipende anche dal fatto che il sito bersaglio sia in grado di installare un tema vulnerabile. Dove non è possibile installare nuovi temi, per esempio quando DISALLOW_FILE_MODS è abilitato, l'iniezione potrebbe comunque verificarsi, ma il suo impatto non si estende all'installazione di nuovi temi o plugin sul sito.
WordPress 7.1.1 chiude il problema in due mosse. Limita il selettore vulnerabile ai veri elementi .theme nel documento, e fa passare lo slug attraverso $.escapeSelector() prima che il valore entri nella stringa del selettore. I dati ora vengono trattati come testo letterale e non come dati strutturali, quindi non possono più cliccare pulsanti da soli. Il punto più ampio di Patchstack è che la lezione riguarda meno questo singolo selettore e più la forma del bug: quando un parametro URL viene elaborato sia sul back end sia sul front end, deve essere sanificato su entrambi i lati, e quel pattern può comparire ovunque due parti diverse di codice analizzino lo stesso input in modo indipendente.
Per i proprietari di siti, il consiglio pratico è lo stesso della maggior parte delle correzioni di WordPress. Gli aggiornamenti del core sono il punto in cui arriva questa patch, e un aggiornamento rimandato è una finestra che resta aperta. Dove il lavoro quotidiano di applicare le patch è la parte difficile, AEU Hosting, il nostro servizio di hosting WordPress gestito, mantiene aggiornato il livello della piattaforma WordPress per i siti che gestisce, e i dettagli sono esposti su albhosting.eu. Anche l'abitudine nella scelta dei temi conta: un tema inutilizzato che resta installato è una cosa in più che può essere fatta eseguire.
Click2Shell illustra anche perché le etichette di gravità possono ingannare. Due debolezze che verrebbero entrambe liquidate con una scrollata di spalle, una richiesta che il browser non avrebbe dovuto inviare e una stringa che avrebbe dovuto essere sottoposta a escape, diventano una shell lato server quando vengono combinate, e per nessuna delle due metà è richiesto un account attaccante. La lettura onesta del resoconto di Patchstack è che l'exploit era reale, la correzione è pubblicata, e la precondizione è umana: un amministratore deve cliccare, oppure qualcos'altro sul sito deve già servire codice iniettato.
Come Proteggerti
- Accedi alla dashboard di WordPress, apri la schermata Aggiornamenti e assicurati di avere la versione più recente di WordPress, la 7.1.1 o successiva.
- Non cliccare mai un link che riguarda il tuo sito e che arriva via email o messaggio, anche se sembra provenire da un collega o dalla tua azienda di hosting; apri invece il tuo sito digitando tu stesso il suo indirizzo.
- Chiedi a chi mantiene il tuo sito, o al tuo fornitore di hosting, di attivare gli aggiornamenti automatici di WordPress, così le correzioni di sicurezza arrivano senza che nessuno debba ricordarsene.
- Elimina qualsiasi tema o plugin che non stai usando attivamente, perché un tema installato ma inutilizzato può comunque essere attivato senza che tu te ne accorga.
- Installa temi e plugin solo dal catalogo ufficiale di WordPress, non da link che ti vengono inviati o da siti di download sconosciuti.
- Se qualcuno ti dice che il tuo sito gli ha inviato un link strano o inaspettato, contatta subito il tuo fornitore di hosting così può controllare.
I Termini Spiegati
- CSRF (Cross-Site Request Forgery) Un trucco che fa inviare al tuo browser, già autenticato, una richiesta a un sito di cui ti fidi, senza che tu lo voglia fare.
- remote code execution Quando un attaccante riesce a far girare un proprio programma sul tuo server, il che di fatto gli consegna il controllo del server.
- sanitize Pulire le informazioni che entrano in un sito web rimuovendo o neutralizzando i caratteri che un computer potrebbe altrimenti leggere come istruzioni.
- selector injection Inserire caratteri extra nella parte del codice di una pagina che cerca quale elemento deve essere modificato, così che ne modifichi un altro.
- jQuery Una parte di JavaScript molto usata che aiuta una pagina web a trovare e modificare alcune sue parti.
- nonce Un codice di sicurezza monouso allegato a una richiesta per dimostrare che proviene davvero dalla tua sessione sul sito.
- XSS (Cross-Site Scripting) Una falla che permette a un attaccante di inserire un proprio codice in una pagina, così che venga eseguito nel browser di chiunque guardi quella pagina.
- slug Il nome breve che identifica un tema o un plugin in un indirizzo web.