Trend che emergono dall’analisi dell’attacco malware con WP GDPR Compliance: studio delle compromissioni
Estratto di articolo tradotto [qui l’originale in inglese] autorizzato da Wordfence che detiene il copyright dei testi.
Nel corso dei giorni seguenti la compromissione del plugin il team Wordfence ha continuato a seguire coloro che cercavano di sfruttare questo nuovo vettore di attacco. Oggi condividiamo i risultati di questa ricerca estesa. Questo post è di natura tecnica e sarà utile per difensori della rete, sviluppatori e ricercatori della sicurezza.
Se hai un sito WordPress e si utilizza questo plug-in, è necessario eseguire l’aggiornamento alla versione più recente che corregge la vulnerabilità o rimuovere la versione precedente del plug-in. La versione più recente di WP GDPR Compliance è la versione 1.4.3.
Due exploit notevoli
I dati raccolti dalle scansioni di malware, attività firewall e report di pulizia del sito hanno rivelato due tipi principali di exploit in atto. Il primo caso riguarda la modifica delle impostazioni di registrazione dell’utente. Il secondo caso, rilevato e registrato dalla nuova regola del firewall per questa vulnerabilità, inietta azioni maligne pianificate che devono essere eseguite da WP-Cron. Gli esempi che abbiamo visto di entrambi i tipi di attacco hanno fatto uso di script backdoor chiamati wp-cache.php, anche se il contenuto di questi file backdoor differisce tra i due metodi.
Accesso amministratore tramite impostazioni modificate
Gli attacchi più comuni sfruttano direttamente la possibilità di modificare impostazioni arbitrarie sui siti interessati. Abilitando la registrazione di nuovi utenti e modificando il ruolo predefinito dei nuovi utenti in Amministratore, gli autori di attacchi possono semplicemente creare un nuovo utente privilegiato, quindi accedere e intraprendere qualsiasi azione sul sito appena compromesso.
È interessante notare che i tentativi automatici di eseguire questa attività stanno anche invertendo le modifiche alle impostazioni in corso. La seguente schermata contiene le voci del registro di accesso pertinenti per uno di questi attacchi.
In questo registro, prima vediamo una richiesta GET alla home page del sito. Questa prima richiesta è necessaria per produrre la nonce “ajaxSecurity” richiesta dal plugin per eseguire azioni AJAX. Successivamente, vengono fatte due richieste POST a /wp-admin/admin-ajax.php. I dati memorizzati negli organismi POST non sono presenti nei log di accesso, tuttavia nel corso della nostra ricerca siamo stati in grado di acquisire campioni di questi dati. Le prime due richieste AJAX contengono i seguenti dati:
action = wpgdprc_process_action & data = { “type”:”save_setting”,”aggiungere”: true “opzione”,:”users_can_register”,”valore”:”1″MM non copiare il testo altrui} & security= [redacted]
action = wpgdprc_process_action & data = { “type”:”save_setting”,”add”: false,”option”:”default_role”,”valore”:”administrator”} & security= [redacted]
Nella prima azione, vediamo l’autore dell’attacco che abilita l’opzione users_can_register, che aggiunge funzionalità alla pagina wp-login.php di un sito che consente agli utenti di creare nuovi account. Successivamente, l’opzione default_role è impostata su “amministratore“, il che significa che qualsiasi nuovo utente registrato sul sito riceve automaticamente l’accesso amministrativo completo.
Gli elementi successivi nel log di accesso mostrano l’attaccante che effettua una richiesta POST a /wp-login.php?action=register e il successivo reindirizzamento alla casella di dialogo”Registrazione completata. Per favore controlla la tua email “.
Infine, vengono fatte altre due richieste AJAX, contenenti le seguenti istruzioni:
action = wpgdprc_process_action & data = { “type”:”save_setting”,”add”: true “option”,:”users_can_register”,”value”:”0″} & security= [redacted]
action = wpgdprc_process_action & data = { “type”:”save_setting”,”add”: false,”option”:”default_role”,”value”:”subscriber”} & security= [redacted]
Qui possiamo vedere l’autore dell’attacco che inverte effettivamente le modifiche alla configurazione che hanno consentito loro di creare un account amministratore, disattivando la registrazione dell’utente e impostando il ruolo utente predefinito su “subscriber“. Ciò serve ad impedire agli altri aggressori di creare i propri account di amministratore, oltre a ridurre la probabilità che l’amministratore di un sito noterà il problema. Chiude la porta dietro l’aggressore.
Diverse ore dopo la creazione del nuovo utente, l’utente malintenzionato accede al suo nuovo account amministratore e può iniziare l’installazione di ulteriori backdoor. Nei nostri esempi di casi, abbiamo visto gli aggressori caricare un robusto webshell PHP in un file chiamato wp-cache.php. L’immagine sotto è uno screenshot dell’interfaccia utente della shell.
Con un file manager, un emulatore di terminale e funzioni di eval PHP, uno script come questo su un sito può consentire a un utente malintenzionato di distribuire ulteriori payload a piacimento.
Installazione backdoor tramite Injected Cron
Il secondo tipo di exploit che stiamo vedendo è meno semplice e più difficile da identificare a colpo d’occhio. Inserendo azioni dannose nella pianificazione WP-Cron di un sito, questi aggressori sono in grado di installare una backdoor persistente che può sostituirsi se rimossa. Mentre una serie di azioni dannose può essere memorizzata ed eseguita tramite WP-Cron, i casi che abbiamo visto finora si basano sulla presenza di un altro popolare plug-in di WordPress, WooCommerce.
La seguente riga contiene una porzione di un corpo di richiesta AJAX bloccato dal firewall di Wordfence per tentare di inserire un’attività WP-Cron dannosa:
“woocommerce_plugin_background_installer”:{“[redacted]”:{“schedule”:”hourly”,”args”:[“2mb-autocode”,{“repo-slug”:”2mb-autocode”}],”interval”:3600}}
Questa attività cron tenta di utilizzare l’azione woocommerce_plugin_background_installer integrata di WooCommerce per installare il plug-in Autocode da 2 MB, che consente l’inserimento di codice PHP arbitrario in tutti i post di un sito. Il codice da iniettare è archiviato da 2MB Autocode come opzione nel database, quindi il passo successivo è modificare quell’impostazione utilizzando la stessa vulnerabilità:
{“type”:”save_setting”,”option”:”2mb_autocode_topstring”,”value”:”[malicious_php]”}
Il segnaposto [malicious_php] nell’esempio precedente contiene uno script backdoor PHP che esegue le seguenti azioni in sequenza:
- Riceve l’input codificato memorizzato nella richiesta dell’aggressore come un’intestazione “HTTP_X_AUTH”, che dichiara le posizioni utilizzate nei seguenti passaggi.
- Fa una richiesta a http: // pornmam [.] Com / wp.php
- Decodifica la risposta e salva la backdoor PHP risultante come wp-cache.php
- Include il file principale /wp-admin/includes/file.php
- Disattiva ed elimina il plug-in di Autodesche da 2 MB
- Cancella l’evento WP-Cron associato all’attacco
- Elimina l’opzione 2mb_autocode_topstring contenente questo codice.
Mentre lo script backdoor visto in questi casi condivide il nome wp-cache.php con altri metodi, i contenuti sono molto diversi. Invece di una shell Web autonoma, questo script contiene alcune funzioni di decodifica e una certa sintassi di esecuzione, ma nessuno del carico utile eseguito viene memorizzato nel file. Invece, il carico utile da decodificare ed eseguire viene memorizzato come variabile POST o in un cookie.
Senza richieste catturate a questo script, non possiamo sapere esattamente quale sia il comportamento previsto. Tuttavia, data la natura della sceneggiatura e la sua eventuale chiamata a eval (), ci si può aspettare che qualsiasi codice arbitrario possa essere eseguito attraverso questa backdoor.
Ancora nessun obiettivo esplicitato
Nella maggior parte delle infezioni, ci saranno uno o più metodi attivi per portare un valore di qualche tipo all’attaccante. Indipendentemente dal fatto che un sito infetto pubblichi email di spam, che ospitano una truffa di phishing o qualsiasi altra monetizzazione diretta o indiretta, spesso c’è un obiettivo chiaro identificato come parte del processo di triage. Tuttavia, nonostante il rapido verificarsi di questi casi identificati, finora la nostra ricerca ha generato solo script backdoor sui siti interessati da questo problema. Nessun payload “end stage” è stato ancora associato a questi attacchi.
Questo comportamento può significare un numero di cose diverse. È possibile che questi aggressori stiano accumulando gli host infetti per essere confezionati e venduti all’ingrosso a un altro attore che ha le proprie intenzioni. C’è anche la possibilità che questi attaccanti abbiano in mente i propri obiettivi, ma non hanno ancora avviato quella fase dell’attacco. In entrambi i casi, i siti interessati da questi attacchi dovrebbero immediatamente lavorare per identificare e rimuovere eventuali backdoor presenti.
Indicatori di compromissione
La seguente sezione contiene una serie di IOC (Indicators of Compromise) che possono essere utilizzati per assistere nell’identificazione e triaging di casi simili a quelli in questo report. Tieni presente che qualsiasi metodo comune può essere modificato dall’attore malevolo in qualsiasi momento, specialmente se un maggior numero di aggressori inizia a sfruttare questa vulnerabilità.
La maggior parte degli indirizzi IP di attacco prevalenti
Metodo di creazione dell’amministratore:
109.234.39.250
109.234.37.214
Metodo Cron Injection
46.39.65.176
195.123.213.91
Domini in uscita acceduti
pornmam[.]com
Hash di malware
Metodo di creazione dell’amministratore Backdoor
MD5: b6eba59622630b18235ba2d0ce4fcb65
SHA1: 577293e035cce3083f2fc68f684e014bf100faf3
Cron Injection Method Backdoor
MD5: c62180f0d626d92e29e83778605dd8be
SHA1: 83d9688605a948943b05df5c548bea6e1a7fe8da
Indicatori del database
La presenza di account non autorizzati nella tabella utenti del tuo sito, inclusi ma non limitati ai seguenti esempi:
t2trollherten
t3trollherten
Una voce nella tabella delle option_name che inizia con 2mb_autocode (Se non usato intenzionalmente)
L’opzione default_role è impostata su un valore diverso da “subscriber” a meno che non sia intenzionale.
L’opzione users_can_register attivata involontariamente.
Plugin installati
Autocode da 2 MB (se non utilizzato intenzionalmente)
Conclusione
La nostra speranza è che i dettagli rivelati da questa ricerca possano essere utilizzati per aiutare altri che lavorano nell’ambito sicurezza a monitorare e prevenire questi exploit. Tuttavia, gli attacchi osservati per la prima volta in seguito a una divulgazione di sicurezza impattante possono essere considerevolmente diversi da quelli osservati nelle settimane e nei mesi successivi. Data la portata della vulnerabilità in questione, è probabile che in futuro si vedranno più metodi di attacco unici e sofisticati nella loro natura.
Come sempre, sottolineiamo l’importanza di eseguire aggiornamenti regolari dei plug-in per evitare che questi attacchi possano aver successo in un primo momento. Il plug-in Wordfence notifica automaticamente agli amministratori i plug-in obsoleti al fine di facilitare una rapida risposta a potenziali vulnerabilità.
Scritto da Mikey Veenstra con i contributi di Stephen Rees-Carter e Marco Wotschka. A cura di Mark Maunder.
Hai un problema di sicurezza? Richiedi un preventivo
Se vuoi condividere la tua esperienza sul caso, commenta sotto.
Articolo apparso per la prima volta in www.fedegrafia.com il 13/11/2018, la notizia può essere condivisa attraverso link con attribuzione all’autore. Non può in ogni caso essere copiato senza autorizzazione.
Lascia un commento