E’ attualmente in corso un attacco ransomware su molti dispositivi di storage QNAP: come dichiarato in una nota https://www.qnap.com/en/security-news/2022/descriptions-and-explanations-of-the-qts-quts-hero-recommended-version-feature, dalla società QNAP stessa, l’attacco è stato eseguito sfruttando una vulnerabilità 0-day presente all’interno del software QTS e QuTS Hero, vulnerabilità poi risolta con un aggiornamento rilasciato il 13 Gennaio 2022 (QSA-21-57: https://www.qnap.com/en/security-advisory/qsa-21-57).
L’attacco comporta la cifratura di tutti i files contenuti all’interno del NAS stesso: i nuovi files, non più utilizzabili, vengono rinominati con estensione .deadbolt.
Ad essere colpiti sono tutti quei NAS, non aggiornati all’ultima patch, pubblicamente esposti su Internet: a fronte di circa 200’000 NAS QNAP raggiungibili da Internet (https://www.shodan.io/search?query=ssl%3A%22QNAP+NAS%22), risultano ad oggi oltre 1300 NAS cifrati con ransomware Deadbolt (https://www.shodan.io/search?query=http.title%3ADEADBOLT).
Il numero, però, è falsato dall’aggiornamento QNAP QSA-21-57, convertito in “Recommended Version” il 27 Gennaio 2022 e diventato quindi “auto-installante” per quei sistemi con la feature “auto-update” abilitata. L’aggiornamento ha infatti modificato la pagina iniziale con la richiesta di riscatto sostituendola con quella “originale”. Rimuovendo inoltre il ransomware, l’aggiornamento ha reso più complesso ripristinare i files a fronte del pagamento della richiesta di riscatto: il metodo di decifratura, infatti, sfrutta proprio l’eseguibile del ransomware stesso per eseguire il ripristino dei files.
Tutti i clienti colpiti da questo ransomware, quando provano a raggiungere da Web la pagina di login del proprio QNap, si trovano davanti la seguente pagina:
Qui è riportata la richiesta di riscatto con l’importo (0.03 BTC) e l’indirizzo del Wallet Bitcoin al quale inviare il pagamento, univoco per ogni vittima.
Questa è la grande novità di questo ransomware: non più un “contatto email” da utilizzare per avere maggiori informazioni o dal quale ricevere la chiave di decifratura nel caso si effettuasse il pagamento del riscatto, bensì unicamente un indirizzo Bitcoin sul quale procedere al pagamento.
Una volta effettuato il pagamento, l’attaccante esegue una nuova transazione bitcoin (diretta allo stesso indirizzo del wallet) con un importo di pochi centesimi e contenente, in uno specifico campo della transazione, la chiave di decifratura ottenuta. Cliccando sul link “more information” presente nella pagina index.html, vengono mostrati ulteriori dettagli:
Come si legge nel comunicato, la chiave di 32 caratteri viene inserita all’interno del campo OP_RETURN contenuto in una nuova transazione eseguita verso lo stesso wallet Bitcoin, immediatamente dopo la ricezione del riscatto da 0.03 BTC. Per comodità, l’attaccante mette anche il link al sito Blockchain Explorer con il riferimento alla transazione “da monitorare” per poter leggere la chiave ottenuta.
Analisi OSINT condotte dal SOC Team di Swascan hanno evidenziato come l’ottenimento della chiave, a fronte del pagamento di 0.03BTC, sia in realtà quasi istantaneo, ad indicare come probabilmente l’attaccante abbia automatizzato mediante script l’invio della decryption key corretta abbinata al corretto indirizzo wallet BTC:
Tornando alla index.html, si può notare come in fondo alla pagina sia presente anche un link ”Important message for QNAP” che, se cliccato, mostra il seguente avviso:
Il DEADBOLT Team, come si firma nel comunicato, si rivolge direttamente alla società QNAP offrendo “due diverse opzioni” per mitigare la vulnerabilità: la prima prevede un pagamento di 5 BTC a fronte del quale verrà inviato, all’indirizzo [email protected], i dettagli sulla vulnerabilità 0-day sfruttata. La seconda opzione, invece, consente di ricevere, con una spesa di 50 BTC, la “master key” utilizzabile per decodificare TUTTI i clienti cifrati da ransomware Deadbolt.
Inserendo quindi la corretta “private key” (ottenuta con un pagamento di 0.03 BTC) o la corretta “master key” (ottenuta con un pagamento di 50 BTC) all’interno dell’apposito spazio presente in fondo alla pagina index.html, viene avviato automaticamente il processo di decryption dei files:
Processo che, una volta terminato, ripristina automaticamente la pagina index.html “originale” permettendo all’utente di potersi loggare nuovamente ed accedere a tutti i propri files.
Ma come funziona nel dettaglio questo ransomware?
Come anticipato, l’attacco sfrutta una vulnerabilità del software QTS per riuscire a caricare, all’interno del path HDA_ROOT/update_pkg/ del NAS Qnap esposto, il file SDDPd.bin, il cui contenuto è il seguente:
Questo file, una volta eseguito, procede con la rinomina della pagina “index.html” originale (contenente la form di login al QNap) col nome “index.html.bak“, e successivamente la creazione di una nuova pagina “index.html” a partire dal codice in Base64 presente all’interno del file .bin stesso (mostrato in riga 4, ma omesso per brevità).
La nuova pagina index.html, dunque, diventa la seguente:
Nel dettaglio, la pagina intercetta il metodo utilizzato per richiamare la pagina index.html stessa: nel caso di una GET, mostra il codice HTML creato a partire dal codice in Base64 mostrato nella riga 75 (anche questo omesso per brevità) e corrispondente alla pagina con la richiesta di riscatto già mostrata in precedenza.
Nel caso in cui, invece, venisse eseguita una POST sulla pagina index.html, a seconda della “action” specificata (“decrypt” o “status”), la pagina avvierebbe il processo di decrypt (nel caso appunto di action “decrypt”) o mostrerebbe lo stato di avanzamento della decryption (nel caso di action “status”).
Nel caso di decrypt, il codice verifica inizialmente la lunghezza della chiave inserita:
Nel caso in cui la chiave non fosse esattamente di 32 caratteri, il codice terminerebbe mostrando l’avviso “invalid key len”.
In caso contrario, verrebbe creato un file, all’interno della directory /tmp, denominato “k-” seguito da un numero randomico di 5 cifre (es: k-15734).
All’interno di questo file viene quindi inserito l’hex della chiave da 32 caratteri inserita in precedenza, per poi calcolarne lo SHA256 (inserendo il risultato all’interno della variabile “SUM”) e rimuovendo infine il file $K creato:
Essendo la funzione di hashing “unidirezionale”, non è possibile in alcun modo risalire, a partire dall’HASH della chiave, alla chiave originale inserita.
Ecco perché l’attaccante si può permettere di scrivere l’hash delle due chiavi (privata e master) all’interno del codice stesso della pagina index.html, ed usarlo per un confronto con l’hash della chiave ricavato ed inserito nella variabile SUM:
Nel caso in cui il confronto avesse successo, verrebbe avviato il tool di decryption (che altri non è che il ransomware stesso usato per cifrare tutti i dati e presente all’interno del path /mnt/HDA_ROOT/ con un nome randomico di 5 cifre, richiamabile mediante la variabile ${TOOL}), con la direttiva “-d” (probabilmente per “decryption”) seguita dalla chiave da 32 caratteri (private o master) e dal path della cartella contenente i files da decifrare ($CRYPTDIR, corrispondente a “/share”).
Nel caso in cui, invece, la chiave fosse sbagliata, la pagina mostrerebbe l’errore wrong key e nessuna azione di decryption verrebbe avviata.
L’unico modo per eseguire la decifratura di tutti i files, quindi, è quello di inserire una delle due chiavi da 32 caratteri in grado di poter eseguire il processo di decryption.
Processo che, una volta avviato, può essere “monitorato” dalla pagina index.html stessa mediante la action “status” collegata alla POST della pagina stessa:
Il codice su mostrato verifica continuamente la presenza del file /tmp/deadbolt.finish (salvato nella variabile $FINISH_FILENAME): tale file viene creato solo al termine dell’esecuzione del processo di decryption ed indica proprio la buona riuscita dell’azione di de-cifratura. Oltre a quello viene monitorato anche il file /tmp/deadbolt.pid, contenente il Process ID dell’eseguibile lanciato e necessario per verificare la corretta esecuzione del processo stesso. Per tener traccia del numero dei files decifrati, viene infine letto il file /tmp/deadbolt.status, il cui valore viene mostrato, durante la decryption, all’interno della pagina index.html:
Terminato il processo di decryption, viene ripristinata la pagina index.html “originale” (copiata all’inizio del processo) e l’utente sarà nuovamente in grado di procedere con la login ed accedere così ai propri files.
Anche prima di procedere alla decryption, è possibile però accedere al NAS digitando nel browser il percorso http://IP_NAS:Porta_NAS/cgi-bin/ : una volta acceduto, sarà possibile visualizzare l’elenco dei files cifrati (tutti con estensione .deadbolt) ma non sarà possibile procedere alla decryption dall’interfaccia “standard” del QNap.
Da notare come l’aggiornamento del QNap, se eseguito dopo aver subito l’infezione ransomware ma prima di aver avviato il processo di decryption, porti alla cancellazione del ransomware e al ripristino del solo file index.html originale… lasciando però inalterati i files cifrati che, senza più il tool di decryption installato, possono essere recuperati solo “manualmente” (lanciando il ransomware, recuperato magari da un altro NAS infetto, da shell con parametro “-d” e con la chiave di decifratura corretta).
Ma come è possibile proteggersi da questo ransomware?
Il primo step è ovviamente quello di tenere aggiornato sempre il software all’ultima patch disponibile emessa dal vendor: generalmente, ad ogni aggiornamento vengono chiuse vulnerabilità che, se sfruttate, potrebbero permettere all’attaccante di accedere remotamente al NAS ed eseguire codice malevolo.
Il consiglio principale è quello poi di non esporre un NAS direttamente su Internet: se assolutamente necessario per garantire l’accesso da utenti esterni alla propria rete, è possibile creare una VPN ed instaurare così una rete “privata” in grado di permettere l’accesso ai dati contenuti nel NAS.
Fondamentale è anche configurare (e testare il corretto funzionamento di) un sistema di backup “offline” (non esposto su Internet) in grado di garantire il ripristino in tempi brevi di eventuali dati non più disponibili nel caso di infezioni sul sistema NAS principale.
