Metti la sicurezza al primo posto: non permettere al tuo server SQL di attaccarti con ransomware

I truffatori hanno poche possibilità per intrufolarsi nel tuo sistema.

Potrebbero mettere in atto un hacking spietato sfruttando vulnerabilità ed exploit per aggirare i controlli di sicurezza e portare i tuoi server a eseguire software che non dovrebbero eseguire.

Oppure potrebbero trovare un modo per accedere ai tuoi server senza alcun raggiro utilizzando un’entrata e comandi di sistema ufficiali.

Sarebbe un po’ come prendere un taxi invece di una macchina rubata per andare a fare una rapina in banca. Non è un qualcosa di criminale e la presenza di eventuali telecamere per il riconoscimento targhe lungo la strada non rappresenterebbe un problema.

Come i lettori fedeli già sapranno, al momento uno dei veicoli più popolari per i truffatori che si servono di malware è Windows RDP, acronimo di Remote Desktop Protocol.

Purtroppo negli ultimi anni abbiamo parlato diverse volte dei problemi di sicurezza dei server RDP che consentono ai truffatori di accedere alla tua rete come se fossero reali amministratori di sistema…

… che invece di sistemare le cose le distruggono e poi chiedono soldi per risolvere i danni.

Il protocollo RDP non è comunque l’unico modo in voga fra i truffatori per sferrare attacchi.

Recentemente abbiamo pubblicato una ricerca sugli honeypot focalizzata sugli attacchi SSH, dove SSH sta per Secure Shell, un sistema di accesso remoto largamente utilizzato su Linux e Unix, più di quanto lo sia RDP su Windows.

(SSH è popolare anche sui server Windows, ma non come sui cugini Unix, dove è adottato con una percentuale pari quasi al 100%.)

La nostra ricerca offre un’immagine chiara di quanta energia i criminali informatici siano pronti a investire per entrare nella tua rete sfruttando metodi eccezionali.

L’uso di strumenti legittimi per accessi illegali non solo apre la criminalità informatica a un gruppo molto più numeroso di truffatori, ma aggira anche il rischio di rilevamento di exploit e di crash del server.

Sfortunatamente i truffatori non si accontentano semplicemente di utilizzare SSH e RDP come strumenti di attacco generici.

Esistono altri servizi online, compresi alcuni che non ci si aspetterebbe, che sono utili quanto un prompt dei comandi se solo si riuscisse a connettersi a essi fin dall’inizio.

Un server MySQL non sicuro, oltre a rappresentare la strada per la violazione di dati, è inoltre un’alternativa davvero efficace, sebbene non ortodossa, a RDP e SSH per eseguire software da remoto.

Ecco un esempio eloquente rilevato di recente da un honeypot di SophosLabs che ascoltava sulla porta TCP 3306, la porta di accesso predefinito per MySQL.

Il server usato come esca fingeva di essere un’istanza non sicura di MySQL che gli hacker potevano trovare, esplorare e a cui era possibile connettersi.

Gli honeypot attirano deliberatamente gli hacker per tenere traccia delle tecniche di attacco che i truffatori stanno usando in un particolare momento, ma ovviamente entro certi limiti in quanto gli honeypot non devono consentire ai truffatori di causare danni reali.

Gli operatori che gestiscono gli honeypot devono prestare molta attenzione in modo da essere parte della soluzione e non rischiare di diventare parte del problema. Se cerchi di attirare spammer con un presunto computer zombie pronto a distruggere email indesiderate, devi allontanarti abbastanza in modo da consentire ai truffatori di realizzare il messaggio che vogliono inviare, aggiungere gli allegati che vogliono diffondere e rivelare quante persone vogliono raggiungere.

Non devi però permettere che questi messaggi sospetti vengano inviati, altrimenti offrirai ai truffatori un servizio di spam gratuito.

Nell’attacco basato su SQL rilevato da SophosLabs, i truffatori hanno tentato di trasformare il server MySQL dell’honeypot in un robot di esecuzione codice da remoto utilizzando una sequenza come questa:

1. Connettiti al server.
2. Prova a indovinare le credenziali di un utente non autorizzato ed esegui il login.
3. Crea una tabella di database dall’aria innocente e aggiungi un record di testo consistente in testo che sia effettivamente un file eseguibile su Windows con valori esadecimali.
4. Decodifica i dati esadecimali e salvali come un file locale denominato cna12.dll. (Una DLL è un tipo di programma speciale di Windows pensato per essere caricato da un’applicazione già in esecuzione per aggiungere ulteriori funzionalità.)
5. Istruisci il server per caricare la nuova DLL come plugin MySQL conosciuto come Funzione definita dall’utente (User Defined Function, UDF).
6. Chiama una funzione nel nuovo plugin per prendere ed eseguire un malware utilizzando HTTP.

In parole povere, i truffatori hanno usato MySQL come uno zombie di esecuzione codice da remoto generico grazie al sistema di plugin UDF ufficiale di MySQL che consente a funzionalità aggiuntive di essere attirate nel server in fase di esecuzione.

L’attacco non era particolarmente sofisticato in quanto i truffatori non notarono che l’honeypot stava eseguendo Linux e caricarono codice eseguibile specifico per la versione Windows di MySQL.

Tuttavia, se il server avesse eseguito Windows, il download HTTP al punto 6 sopra…

… avrebbe consentito al ransomware noto come GandCrab di infiltrarsi con facilità.

Per un’analisi dettagliata delle tecniche utilizzate durante l’attacco e per gli indicatori di compromissione (IoCs) che puoi utilizzare per cercare analisi simili sui tuoi server, leggi l’analisi tecnica sul nostro sito gemello Sophos News.

Cosa fare?

Secondo il buon senso non dovresti essere vulnerabile a questo tipo di attacco.

Il massiccio attacco globale sferrato dal virus SQL Slammer nel 2003 dovrebbe averci insegnato a proteggere i nostri server SQL dai pericoli di Internet e il potenziale di abuso della funzionalità UDF di MySQL è stato ben documentato già da molto tempo.

Tuttavia, il fatto che ci ritroviamo ancora a bloccare tentativi automatizzati e basilari di irruzione attraverso porte SQL con connessione Internet ci ricorda che stiamo continuando a commettere gli stessi errori.

Ecco dunque cosa fare:

• Assicurati che non sia possibile accedere ai tuoi server SQL direttamente da Internet. Se non fosse così, dovrebbe trattarsi quasi sicuramente di un errore. Non è un errore? Allora è davvero una cattiva idea, devi trovare un altro modo per accedere ai server da remoto. Prendi in considerazione di utilizzare una VPN oppure SSH come prima modalità per l’accesso e insisti sulla 2FA per tutti gli utenti.
• Scegli password appropriate. L’attacco descritto qui non può essere portato a termine da un utente non autenticato, perciò non correre rischi con password deboli. Anche se è possibile accedere al tuo server solo internamente, non vuoi di certo che chiunque possa eseguire il login con facilità, soprattutto come utente con privilegi.
• Verifica le tue impostazioni di controllo di accesso MySQL. Solo gli utenti con diritti di INSERT nel database principale di MySQL possono caricare nuove UDF e, in questo modo, chiunque voglia preparare un attacco ha già abbastanza potere per fare tantissime altre cose negative. (Sarebbe bello se esistesse un’opzione per disattivare le UDF se non vengono mai usate, ma non riusciamo a trovare un modo per farlo. L’unico trucco che conosciamo per bloccare il caricamento di UDF è creare la propria versione collegata staticamente di mysqld dal codice sorgente.)
• Prendi in considerazione i penetration test. Probabilmente conosci già tutte le strategie difensive elencate finora, ma vale la pena controllare che tu le abbia applicate correttamente. Errori possono capitare, ma se non ci presti la giusta attenzione lo farà sicuramente qualcun altro.

Metti la sicurezza al primo posto: corri ai ripari e controlla che tutte le porte di accesso siano state impostate correttamente.