Gli hacktivisti di LulzSec violano i sistemi dell'ospedale San Raffaele di Milano: cronaca di una giornata di smentite e attacchi

venerdì 22 maggio 2020

Tornano a colpire gli hacktivisti del gruppo italiano LulzSec, affiliati alla rete di Anonymous: ieri 21 Maggio hanno pubblicato su Twitter un estratto dei dati contenuti nei database dell'Ospedale San Raffaele di Milano. Con il tweet LulzSec, oltre a rivendicare pubblicamente l'azione, attacca frontalmente il San Raffaele sulla questione sicurezza dei dati: l'accesso ai sistemi ha consentito al gruppo di mettere le mani sui dati di migliaia di utenti, compresi infermieri e pazienti, con password in chiaro. In dettaglio hanno ottenuto 2400 indirizzi email del personale sanitario con tanto di password in chiaro e i dati (nom, cognome, codice fiscale, nazionalità, comune di residenza) di 600 pazienti. Inoltre la decisione di rendere pubblico il breach consegue al fatto che l'Ospedale non ha comunicato il breach al Garante Privacy entro le 72 ore previste dal GDPR, ma neppure agli utenti riguardati dall'esposizione dei dati.

Dal primo tweet, pubblicato alle 9.28 di ieri mattina, il gruppo di hacktivisti ha iniziato una vera e propria escalation, sfidando apertamente l'Ospedale che, ad ora, pare non avere ancora effettuato nessuna notifica come previsto da legge: inizia un turbinio di tweet contenti ulteriori prove del breach. In mezzo finisce pure il noto virologo Roberto Burioni, dipendente del San Raffaele: LulzSec ha messo le mani anche sulla sua password in chiaro, ma il gruppo ha voluto ribadire quanto quella password sia il più classico esempio di password debole da non usare mai.
Gli screenshot pubblicati da LulzSec mostrano come, nei fatti, i dati del San Raffaele siano conservati senza neppure i minimi requisiti di sicurezza, quindi in aperta violazione del GDPR: il breach dovrebbe essere avvenuto a fine Marzo, ma il gruppo non ha voluto pubblicare prima i dati coerentemente a quanto deciso a inizio pandemia, quando LulzSec e Anonymous Italia avevano annunciato la sospensione di tutti gli attacchi per rispetto allo stato di emergenza.

Tra i dati pubblicati risultano, oltre a screenshot dei database, anche molti file .csv che contengono informazioni sensibili come dati e i codici fiscali di chi si è presentato all'accettazione, oltre alle password e altri dati riferiti a medici e infermieri.

Dal silenzio, alla negazione all'ammissione
Quel che ha colpito immediatamente è stato l'assoluto silenzio del San Raffaele, ma anche il poco risalto dato dalla stampa all'evento, nonostante si tratti di un grave breach che ha di nuovo ribadito come in Italia ci sia un totale disinteresse sulla questione sicurezza dei dati. Il silenzio ha colpito ancora di più perchè LulzSec ha già effettuato simili operazioni: nel Dicembre 2018 avevano già colpito diverse ASL italiane (Viterbo, Rieti, Caserta) e l'Ospedale San Giovanni di Roma. Dal 2018 ad oggi pare non esserci stato alcun avanzamento.

La direzione del San Raffaele, dopo il silenzio, ha inviato ad alcune testate giornalistiche un breve comunicato stampa, comunicato del quale non c'è traccia sul sito ufficiale:

"La situazione a cui si fa riferimento, riportata da fonte non attendibile, si riferisce a un tentativo di intrusione avvenuto mesi fa che non ha comportato l’accesso ad alcun dato sensibile. I nominativi di molti operatori sono pubblici per ragioni di servizio e le informazioni pubblicate sono relative a un’applicazione dedicata alla formazione online dismessa da anni con utenze e password di accesso altrettanto obsolete e dismesse. La direzione dell’Ospedale è già in contatto con gli organi competenti per fornire ogni utile chiarimenti"

LulzSec, appena letta la smentita ripubblicata da alcuni giornali online, ha iniziato a pubblicare nuovi dati contestando la definizione di dati sensibili: accedere ai database non è accedere a dati sensibili?

Ma questa appassionante storia non finisce qui: il primo comunicato del San Raffaele viene modificato con l'aggiunta di una frase che, infine, ammette la violazione dei sistemi negata in precedenza. La frase aggiunta è questa: "le informazioni pubblicate sono relative a un’applicazione dedicata alla formazione online dismessa da anni con utenze e password di accesso altrettanto obsolete e dismesse”

Insomma, alla fine l'accesso ai sistemi c'è stato e LulzSec commenta a pioggia criticando punto punto il comunicato della direzione. Per ribadire che "sono una fonte attendibile" pubblicano i dati dell'intranet dell'Ospedale, altri file .csv e uno screenshot che dimostra come il gruppo sia riuscito a creare ben 3 utenti su 3 diverse macchine.

Riguardo poi alla datazione dei database, se già non è buona prassi conservare dati in chiaro, ancora meno lo è conservare dei dati obsoleti in chiaro, oltretutto che il GDPR vieta apertamente la conservazione di dati ritenuti obsoleti perchè non più utili per alcuna finalità: questi andrebbero distrutti.

eBay analizza i computer dei visitatori in cerca di porte aperte per programmi di accesso remoto
lunedì 25 maggio 2020
La notizia ha dell'incredibile e serpeggia nel web da qualche giorno. Prima un report specifico, poi i test dei tecnici della testata online BleepingComputer quindi la conferma: eBay, in tutti i propri domini, esegue una verifica sul computer di ogni utente alla prima visita in cerca di porte aperte per individuare applicazioni di accesso remoto o di supporto remoto. Un "port scanning" come spesso ne effettuano i cyber attaccanti in cerca di porte aperte da sfruttare per accedere alle macchine egli utenti.

La versione integrale del report pubblicato dai tecnici di Nullsweep e disponibile qui, conferma inequivocabilmente il port scanning effettuato da eBay.

Il port scanning: come funziona la verifica di eBay
Questa scansione cerca porte aperte dal lato client e verifica la presenza dei più diffusi software per l'amministrazione remota dei sistemi Windows. Un software di questo tipo, se installato ed eseguito, apre una o anche più porte in ingresso sulla macchina, per gestire le richieste di connessione da parte di terzi.

La scansione avviene tramite codice JavaScript rinominato check.js (consultabile qui per gli appassionati), la cui presenza è stata confermata anche nella versione italiana del sito: verifica in dettaglio, quali porte sul sistema, associabili alla presenza di programmi di accesso remoto, sono aperte. Il controllo viene effettuato direttamente in locale sull'IP 127.0.0.1 tramite lo script caricato dal browser: un sistema che consente di superare eventuali firewall. I software di accesso remoto che vengono cercati da Ebay sono Windows Remote Desktop, VNC, TeamViewer, Ammy Admin, AnyDesk e altri... mentre sono ben 14 le porte sulle quali ebay esegue questo tipo di verifica.

Alla ricerca delle porte aperte e delle app in esecuzione

In particolare vengono verificate le seguenti porte: 5900, 5901, 5902, 5903 (VNC), 3389 (Windows Remote Desktop), 5950 (Aeroadmin), 5931 (Ammyy), 5939, 6039, 5944, 6040 (TeamViewer), 5279 (Anyplace Control), 7070 (AnyDesk) e 63333.

Sull'IP vengono inviate vere e proprie richieste di connessione: se il JavaScript riceve una risposta significa che l'app per la gestione da remoto è in esecuzione. Sembrano essere al riparo soltanto gli utenti Linux: i ricercatori di Nullsweep, tra i primi a diffondere la notizia, hanno verificato che l'attività di port scanning non si avvia su terminali Linux.

La madre di tutte le domande: perchè?
E' ovvio è naturale chiedersi perchè eBay stia procedendo ad analisi di questo tipo. Non c'è, fino ad ora, una posizione ufficiale e anche la redazione di BleepingComputer fa sapere di avere tentato un contattato, ma di non aver ricevuto alcuna risposta per adesso.

Si può solo supporre quindi: una delle prime possibilità è che questa verifica sia una forma di difesa. eBay infatti potrebbe eseguire il port scanning per individuare quei client compromessi che sono usati spesso per effettuare acquisti fraudolenti. Ed è assolutamente una possibilità credibile: nel 2016 furono pubblicati centinaia di report che denunciavano il problema dell'uso di computer controllati tramite TeamViewer per effettuare acquisti fraudolenti su Ebay. Gli attaccanti sfruttavano il fatto che moltissimi utenti usano i cookie per accedere automaticamente al sito, quindi da remoto gli attaccanti sono riusciti ad accedere ad Ebay ed effettuare acquisti.

Insomma il problema è reale, ma è innegabile che questa tipologia di verifica, anche se eseguita a scopo difensivo, sia estremamente invadente per gli utenti e, probabilmente, pochissimi di questi accetterebbero di buon grado un port scanning, qualora ne fossero stati informati. Restiamo in attesa di una posizione ufficiale da parte di eBay.

E' stato individuato un nuovo ransomware, rinominato [F]Unicorn, che sta colpendo esclusivamente utenti italiani: l'attacco inizia con una email che sembra inviata dalla Federazione Ordini farmacisti italiani e cerca di convincere gli utenti a scaricare la versione beta dell'app Immuni, scelta dal governo italiano per il contact tracing dei contagi Covid.

La campagna di attacco è stata individuata dal CERT e dall'Agenzia per l'Italia Digitale, segnalata poi tramite specifico alert. Un campione delle email fake è visibile sotto:

Fonte: Dottomarc.it

Il CERT-AgID ha analizzato non solo il ransomware, ma anche le tecniche di ingegneria sociale usate dagli attaccanti per convincere le vittime a scaricare e installare il ransomware. L'email parla del rilascio di una versione beta dell'app Immuni riservata a medici, farmacisti, enti coinvolti nella sanità pubblica, università e centri di ricerca ecc... che
Per rendere ancora più credibile l'email, gli attaccanti non solo impersonano la Federazione degli Ordini dei Famacisti, ma hanno anche registrato un sito web il cui nome dominio è estremamente simile a quello legittimo della Federazione: quello legittimo è fofi.it, mentre quello registrato dagli attaccanti sostituisce la "i" finale con una "l" rendendo molto difficile il riconoscimento del sito fake.

Se un utente scarica l'eseguibile indicato in email, visualizza anzitutto una dashboard fake contenente informazioni riguardanti i contagi: i dati sembrano raccolti dal Center for System Scienze and Engineering della Johns Hopkins University.

Fonte: bleepingcomputer.com

Mentre l'utente è impegnato a visualizzare la mappa, dettagliatissima e carica di dati, il ransomware si attiva e [F]Unicorn avvia la criptazione del sistema. Stando all'analisi del CERT-AgID, il malware esegue verifiche sulle cartelle Desktop, Link, Contatti, Documenti, Download, Foto, Musica, OneDrive, Giochi Salvati, Preferiti, Ricerche, Video in cerca dei seguenti formati file da criptare:

.Txt, .jar, .exe, .dat, .contact, .settings, .doc, .docx, .xls, .xlsx, .ppt, .pptx, .odt, .jpg, .png, .csv,. py, .sql, .mdb, .sln, .php, .asp, .aspx, .html, .htm, .xml, .psd, .pdf, .dll, .c, .cs, .mp3, .mp4, .f3d, .dwg, .cpp, .zip, .rar, .mov, .rtf, .bmp, .mkv, .avi, .apk, .lnk, .iso, .7-zip, .ace, .arj, .bz2, .cab, .gzip, .lzh, .tar, .uue, .xz, .z, .001, .mpeg, .mp3, .mpg, .core, .crproj, .pdb, .ico, .pas , .db, .torrent

Sotto, un esempio di file criptati

Fonte: bleepingcomputer.com

Solo al termine della criptazione l'utente realizza di aver subito l'infezione ransomware, quando visualizza una nota di riscatto scritta in italiano nella quale si richiedono 300 euro di riscatto entro 3 giorni, pena l'irrecuperabilità dei dati. Sotto è visualizzabile la stramba richiesta di riscatto:

Ad ora non esistono tool in grado di decriptare questo ransomware, ma le analisi del CERT-AgID sembrano aver rilevato che [F]Unicorn invii la password per i file criptati in chiaro: analizzando i log del traffico dovrebbe quindi essere recuperabile.

E' molto probabile che l'attaccante sia un novizio che ha copiato codice ransomware pre esistente, in dettaglio il ransomware Hidden Tear. Non sarebbe comunque la prima volta: anche FTCode, altro ransomware che vide una distribuzione specifica contro l'Italia pochi mesi fa, aveva lo stesso bug nella prima versione, inviando in chiaro la chiave necessaria alla criptazione.

Inoltre l'email di contatto indicata nel riscatto sembra non essere valida, quindi non è possibile inviare agli attaccanti alcuna prova di effettuato pagamento: un altro motivo per non pagare il riscatto.

Chi avesse subito questa infezione può valutare di contattare il nostro servizio di decriptazione ransomware decryptolocker.it: avviseremo non appena sarà disponibile una soluzione per questa infezione.

Aggiornamento:
Il sito web fake non risulta più raggiungibile dal 25 Maggio scorso, spiega lo CSIRT: la campagna di diffusione può quindi ritenersi conclusa.