RECOVER_YOUR_DATA_info: quando una tabella MySQL è sintomo di un hackeraggio o di una richiesta di riscatto

Un caso reale gestito dal nostro team: un file .env finito per errore nella cartella pubblica, un database MySQL raggiungibile da Internet e un bot che in pochi secondi ha copiato e cancellato i dati di un portale editoriale. Ecco come lo abbiamo individuato, contenuto e risolto, e cosa insegna a chi gestisce siti in produzione.

Aprire la cartella di un database MySQL e trovare, al posto delle tabelle del sito, una sola tabella chiamata RECOVER_YOUR_DATA_info è una delle esperienze più spiacevoli per chi gestisce un sito. Il nome è esplicito: i dati non ci sono più e qualcuno chiede un riscatto per restituirli. È quello che è successo pochi giorni fa a un nostro cliente, un portale editoriale con centinaia di migliaia di contenuti, che ci ha contattati allarmato alle 11:40 di un normale venerdì mattina.

In questo articolo raccontiamo come è andata, senza nomi né dettagli che permettano di identificare il sito, perché questo tipo di attacco è molto più comune di quanto si pensi e nasce quasi sempre da una svista banale. Vedremo cosa significa quella tabella, come lavorano i bot che la creano, quali errori hanno reso possibile l’attacco e quali regole adottare su nginx, MySQL e backup per non trovarsi nella stessa situazione.

Cosa significa la tabella RECOVER_YOUR_DATA_info

La tabella RECOVER_YOUR_DATA_info, insieme alle sue varianti come README_TO_RECOVER, WARNING o PLEASE_READ_ME, è la firma di una famiglia di attacchi automatici rivolti ai database MySQL e MariaDB esposti su Internet. Non si tratta di un ransomware classico, che cifra i file del server: qui l’attaccante entra nel database con credenziali valide, scarica il contenuto, cancella le tabelle e lascia una tabella con un messaggio. Di solito il messaggio contiene un indirizzo di un portafoglio bitcoin, un importo, un contatto email e una scadenza oltre la quale i dati verrebbero “pubblicati” o “distrutti”.

Nel nostro caso la cartella del database, sul disco del server, si presentava così:

[root@server nomedb]# ls -al
drwxr-x--- 2 mysql mysql  4096 Nov  6 11:40 .
-rw-r----- 1 mysql mysql    65 Sep  6  2022 db.opt
-rw-r----- 1 mysql mysql  8566 Nov  6 11:40 RECOVER_YOUR_DATA_info.frm
-rw-r----- 1 mysql mysql 98304 Nov  6 11:41 RECOVER_YOUR_DATA_info.ibd

Tutte le tabelle di WordPress erano sparite. Restavano solo il file di configurazione del database e la tabella con la richiesta di riscatto.

È importante sapere una cosa: pagare non garantisce nulla. Questi attacchi sono condotti da script automatici che colpiscono migliaia di server: spesso i dati non vengono nemmeno conservati, o vengono venduti comunque. Il nostro consiglio è sempre lo stesso: non pagare, non contattare gli attaccanti, conservare le prove e ripristinare da un backup affidabile.

Come funziona l’attacco: tre ingredienti

Perché un attacco di questo tipo vada a segno servono tre condizioni. Basta toglierne una per fermarlo.

1. Il database è raggiungibile da Internet. MySQL resta in ascolto sulla porta 3306 su tutte le interfacce di rete e nessun firewall ne limita l’accesso.
2. Esiste un utente del database che può collegarsi da qualsiasi indirizzo, il classico utente@'%'.
3. L’attaccante conosce la password di quell’utente, perché l’ha indovinata con un attacco a forza bruta o, molto più spesso, perché l’ha letta in un file di configurazione esposto per errore.

Il nostro caso li aveva tutti e tre. I primi due erano una configurazione storica del server, ereditata da una precedente gestione, con un database aperto verso l’esterno per comodità di sviluppo. Il terzo è nato il giorno prima, da un gesto di pochi secondi.

La ricostruzione: un file .env nel posto sbagliato

Il sito usa una struttura moderna per WordPress, con le credenziali e le chiavi segrete in un file .env. È la stessa convenzione di Laravel, Symfony, Node.js e di tante altre piattaforme. Il file contiene in chiaro tutto ciò che serve per far funzionare il sito: nome utente e password del database, chiavi e salt di WordPress, credenziali SMTP, token di servizi esterni e chiavi di licenza. Proprio per questo deve stare fuori dalla cartella pubblica, cioè quella che il web server mostra ai visitatori.

Analizzando i log e la cronologia dei comandi sul server, abbiamo ricostruito questa sequenza:

• Giorno 1, ore 8:34. Durante un intervento manuale sul sito, il file .env viene copiato dentro la cartella pubblica web/, probabilmente per una prova o per risolvere al volo un problema di configurazione. Da quel momento il file è scaricabile da chiunque conosca l’indirizzo /.env.
• Giorno 1, dalle 17:52. I primi bot di scansione trovano e scaricano il file. Sul dominio principale il CDN bloccava la richiesta, ma interrogando il server direttamente per indirizzo IP, cioè saltando il CDN, il file veniva servito lo stesso. In più la cache HTTP ne aveva memorizzato una copia: anche cancellando il file, l’avrebbe continuato a servire per ore.
• Giorno 2, ore 11:34. Un primo indirizzo tenta l’accesso a MySQL con i dati presi dal file. Nei log compaiono tentativi con nomi utente come SECURE_AUTH_KEY=: è la firma inconfondibile di uno script che legge un file .env riga per riga e prova ogni valore come credenziale.
• Giorno 2, ore 11:40. Da un secondo indirizzo l’accesso riesce. In meno di un minuto l’attaccante esegue un dump completo delle tabelle principali (centinaia di megabyte), le cancella e crea la tabella RECOVER_YOUR_DATA_info.

Ventisette ore tra l’errore e l’attacco. Per un bot è un tempo lunghissimo: su un altro sito dello stesso server, dove era stato commesso lo stesso errore, il file .env risultava già scaricato oltre cento volte.

Come abbiamo individuato il problema in pochi minuti

Il cliente ci ha scritto pochi istanti dopo essersi accorto del problema e il nostro reparto sistemistico ha risposto in pochi secondi. In situazioni del genere la tempestività conta quanto la competenza: ogni minuto con le credenziali compromesse ancora valide è un minuto in cui l’attaccante può tornare a colpire altri database dello stesso server.

Il primo passo è stato capire da dove e con quale utente era entrato l’attaccante. Il registro degli errori di MySQL mostra solo i tentativi falliti, ma il slow query log, attivo per l’analisi delle prestazioni, ha registrato le query più pesanti dell’attacco. Il dump delle tabelle più grandi ha superato la soglia di tempo, e così sono finiti nel log anche l’indirizzo IP e l’utente usato:

# User@Host: utente_db[utente_db] @ [xxx.xxx.xxx.xxx]
# Query_time: 10.954655  Rows_sent: 3743338  Bytes_sent: 514566486
SELECT /*!40001 SQL_NO_CACHE */ * FROM `wp_postmeta`;
...
DROP TABLE IF EXISTS `nomedb`.`wp_postmeta`;

La sintassi SELECT /*!40001 SQL_NO_CACHE */ * è quella generata da mysqldump: conferma che i dati non sono stati solo cancellati, ma prima copiati. Per il cliente è un’informazione decisiva, perché fa scattare gli obblighi previsti dal GDPR in caso di violazione di dati personali.

Da lì è stato semplice risalire alla causa. Una volta noto l’utente del database, abbiamo cercato i file che contenevano la sua password, e un controllo sui log di accesso del web server ha mostrato le richieste a /.env con risposta 200:

find /var/www -name ".env*" -not -path "*/vendor/*"
grep -E '"GET /[^ ]*\.env[ ?]' access.log | grep '" 200 '

A quel punto mancava solo il “come”: la cronologia dei comandi dell’utente di sistema del sito riportava, nero su bianco, il cp .env web/.env del giorno precedente.

Il contenimento: credenziali, cache e ripristino

Identificata la causa, abbiamo eseguito in pochi minuti le operazioni di contenimento, nell’ordine giusto:

1. Rimozione dei file .env dalle cartelle pubbliche, su entrambi i siti coinvolti. I file non sono stati cancellati ma spostati in una cartella riservata, perché sono prove utili per la relazione tecnica e per un’eventuale segnalazione.
2. Cambio delle password del database per tutti gli utenti esposti e per tutti gli host da cui potevano collegarsi, con l’aggiornamento immediato della configurazione dei siti e una verifica dell’accesso con le nuove credenziali.
3. Pulizia della cache HTTP, che conservava ancora una copia del file .env e l’avrebbe servita anche dopo la rimozione. È un dettaglio che molti trascurano: con Varnish, una cache nginx o un CDN, cancellare un file non basta, bisogna invalidare anche le copie in cache.
4. Ripristino del database dal backup esterno, verifica dell’integrità e rimessa in produzione del sito.
5. Controllo degli altri database dello stesso server e delle sessioni attive, per escludere altri accessi in corso.

Il sito è tornato online in tempi brevissimi, con tutti i contenuti. Senza un backup esterno, il cliente si sarebbe trovato davanti a una scelta impossibile: pagare un riscatto senza garanzie o ricostruire da zero anni di contenuti.

Il file .env in produzione: una svista frequente

Quello che è successo in questo caso non è un’eccezione. Il file .env esposto è una delle cause più comuni di compromissione dei siti moderni, per diversi motivi:

• durante il debug in produzione si è tentati di copiare il file “dove serve” per fare una prova veloce, e poi ci si dimentica di toglierlo;
• in alcuni framework la radice del progetto e la cartella pubblica coincidono, oppure il web server punta per errore alla cartella sbagliata;
• i deploy manuali via FTP o rsync caricano tutto il progetto, file nascosti compresi;
• i file di esempio, come .env.example, .env.production e .env.bak, vengono lasciati nella cartella pubblica con dentro credenziali vere.

Dall’altra parte ci sono bot che non dormono mai. Basta guardare i log di accesso di qualsiasi sito per trovare, ogni giorno, decine di richieste a /.env, /.env.bak, /api/.env, /.git/config, /wp-config.php.bak, e tentativi di path traversal come /?file=../../.env. Questi scanner provano tutto, su tutti gli indirizzi IP, continuamente: è solo questione di tempo prima che trovino un file lasciato lì.

Proteggere i file .env con nginx

La regola d’oro è semplice: il file .env non deve mai trovarsi nella cartella pubblica. Siccome però l’errore umano è sempre possibile, serve una seconda linea di difesa sul web server che impedisca di servire file nascosti anche quando finiscono dove non dovrebbero.

Su nginx basta una regola da inserire in ogni blocco server:

# Blocca file e cartelle nascosti (.env, .git, .htpasswd, ...)
# ma lascia passare le verifiche di Let's Encrypt
location ~ /\.(?!well-known) {
    deny all;
    return 404;
}

# Blocca file di configurazione e backup lasciati per errore
location ~* \.(env|ini|log|sql|bak|old|orig|save|swp|dist)$ {
    deny all;
    return 404;
}

Usare return 404 invece del classico 403 non dà agli scanner la conferma che il file esiste. Ci sono poi tre aspetti che il nostro caso ha messo bene in evidenza.

1. Il blocco server di default. Il CDN proteggeva il dominio, ma il server rispondeva anche alle richieste dirette sull’indirizzo IP, e lì la regola di protezione non c’era. Ogni server nginx dovrebbe avere un blocco di default che chiude le richieste senza un nome di dominio valido:

server {
    listen 80 default_server;
    listen 443 ssl default_server;
    server_name _;
    ssl_reject_handshake on;   # nginx 1.19.4+
    return 444;
}

2. La cache. Se davanti al sito ci sono Varnish, una cache di nginx o un CDN, un file sensibile servito anche una sola volta può restare in cache per ore. Dopo un incidente vanno invalidate anche le cache, e le regole di blocco vanno applicate sul server di origine, prima della cache.

3. La verifica. Dopo ogni modifica è utile controllare dall’esterno, sia sul dominio sia sull’IP:

curl -s -o /dev/null -w "%{http_code}\n" https://www.esempio.it/.env
curl -sk -o /dev/null -w "%{http_code}\n" https://IP_DEL_SERVER/.env

La risposta attesa è 404 o 444, mai 200.

MySQL non deve essere raggiungibile da Internet

Anche con le credenziali in mano, l’attaccante non sarebbe entrato se il database avesse accettato connessioni solo dal server stesso. Nella grande maggioranza dei siti web, il database e l’applicazione girano sulla stessa macchina o nella stessa rete privata: non c’è nessun motivo per esporre la porta 3306 al mondo.

• Ascolto solo in locale. In my.cnf, impostare bind-address = 127.0.0.1 oppure l’indirizzo della rete privata.
• Firewall. Se un accesso remoto serve davvero, per un gestionale o un ufficio, la porta va aperta solo agli indirizzi IP autorizzati, mai a tutti.
• Utenti legati all’host. Preferire utente@'localhost' o utente@'10.0.0.%' a utente@'%'. Un utente con host % accetta connessioni da qualsiasi indirizzo del pianeta.
• Niente root da remoto. L’utente root di MySQL non dovrebbe mai poter accedere dall’esterno. Nei log di questo server c’erano decine di migliaia di tentativi a forza bruta proprio su root.
• Privilegi minimi. L’utente del sito non ha bisogno dei privilegi di amministrazione. Separare utenti diversi per siti diversi limita i danni: qui gli altri database dello stesso server sono rimasti integri proprio perché ogni sito aveva il proprio utente.

Per verificare rapidamente la situazione bastano due comandi:

ss -ltnp | grep 3306
mysql -e "SELECT user, host FROM mysql.user WHERE host NOT IN ('localhost','127.0.0.1','::1');"

Se il primo mostra MySQL in ascolto su 0.0.0.0 o [::] e il secondo restituisce utenti con host %, il database è potenzialmente esposto.

Il backup esterno: l’unica vera assicurazione

In questo incidente il backup ha fatto la differenza tra un disservizio di breve durata e la perdita di anni di lavoro editoriale. Ma non basta “avere un backup”: deve avere alcune caratteristiche precise.

• Esterno al server. Un backup sullo stesso server, o su un disco montato in modo permanente, può essere cancellato dallo stesso attaccante. Il backup deve stare su un sistema separato, come uno storage remoto, un object storage o un altro datacenter.
• Non modificabile da chi attacca il sito. Le credenziali per cancellare i backup non devono essere presenti sul server di produzione. Dove possibile, conviene usare il versioning o il blocco in sola scrittura (immutability) dello storage.
• Frequente e conservato a lungo. Per un sito editoriale o un e-commerce, un dump giornaliero del database è il minimo. Con i binary log attivi si può arrivare al ripristino puntuale (point-in-time recovery) fino a pochi istanti prima dell’attacco. Conservare più giorni o settimane permette di tornare indietro anche quando una compromissione viene scoperta in ritardo.
• Testato. Un backup che non è mai stato ripristinato è solo una speranza. Le prove di ripristino periodiche sono l’unico modo per sapere quanto tempo serve davvero per tornare online.

È la regola 3-2-1, sempre attuale: tre copie dei dati, su due supporti diversi, di cui una fuori sede.

Dopo il ripristino: le cose da non dimenticare

Rimettere online il sito non chiude l’incidente. Ci sono altri passaggi importanti:

• Cambiare tutti i segreti presenti nel file esposto, non solo la password del database: chiavi e salt di WordPress (questo disconnette tutti gli utenti), credenziali SMTP, chiavi API di servizi esterni, token del CDN e licenze. Chi ha scaricato il file ha in mano tutto.
• Valutare gli obblighi GDPR. Se il database conteneva dati personali come utenti registrati, iscritti alla newsletter o email nei commenti, la copia dei dati è una violazione di dati personali. Il titolare del trattamento deve valutare la notifica al Garante entro 72 ore dalla scoperta. Una relazione tecnica con orari, modalità e dati coinvolti è la base per questa valutazione.
• Cercare altre esposizioni. Se un file è finito nella cartella pubblica una volta, può essere successo anche altrove: altri siti dello stesso server, vecchie release di deploy, cartelle di backup.
• Chiudere le porte rimaste aperte. Firewall, utenti del database e regole nginx vanno sistemati subito, non “appena possibile”.

Checklist: come evitare la tabella RECOVER_YOUR_DATA_info

1. Il file .env sta fuori dalla cartella pubblica e non viene mai copiato in produzione “per prova”.
2. nginx blocca file nascosti e file di configurazione su tutti i virtual host, compreso il blocco di default per le richieste dirette all’IP.
3. MySQL è in ascolto solo su localhost o sulla rete privata, e la porta 3306 è chiusa verso Internet.
4. Nessun utente del database ha host % senza un reale motivo, e root non è accessibile da remoto.
5. Ogni sito ha il proprio utente del database, con i privilegi minimi.
6. Esiste un backup esterno, frequente, non cancellabile dal server di produzione e testato.
7. Dopo una modifica di sicurezza si verifica dall’esterno, con curl, che i file sensibili non siano raggiungibili.
8. In caso di incidente si conservano le prove, si cambiano tutti i segreti e si valutano gli obblighi GDPR.

Conclusioni

La tabella RECOVER_YOUR_DATA_info non è il risultato di un attacco sofisticato. È il prodotto di bot automatici che sfruttano errori comuni: un file di configurazione lasciato nel posto sbagliato e un database aperto su Internet. Bastano poche ore perché questi errori vengano trovati e sfruttati.

La buona notizia è che le contromisure sono semplici e alla portata di qualsiasi infrastruttura: poche righe di configurazione su nginx, un database che ascolta solo in locale, un backup esterno ben fatto. A queste si aggiunge un elemento meno tecnico ma altrettanto decisivo: poter contare su un’assistenza sistemistica che risponde subito. In questo caso, il fatto di aver preso in carico la richiesta del cliente in pochi secondi ci ha permesso di identificare la causa, cambiare le credenziali, ripulire la cache e riportare il sito in produzione nel giro di pochi minuti, prima che lo stesso errore venisse sfruttato anche sugli altri siti del server.

Se gestisci siti WordPress, e-commerce o applicazioni con un database MySQL e vuoi sapere se la tua infrastruttura è esposta a questo tipo di attacco, contattaci: un audit dei file pubblici, delle porte aperte e della strategia di backup richiede poco tempo e può evitarti di trovare, una mattina qualsiasi, una tabella che chiede un riscatto al posto del tuo sito.