Hanno lasciato in giro la chiave del server VMware ESXi. E i cybercriminali ne hanno approfittato
... un sistema digitale sempre più prezioso per la vita sociale ha bisogno di una difesa più efficace e proattiva di quella che per ora viene garantita da tante organizzazioni informatiche troppo disattente, troppo lente ad aggiornare i software, troppo fissate sul risparmio dei costi piuttosto che sulla sicurezza dei loro utenti. https://lucadebiase.nova100.ilsole24ore.com/2023/02/05/hanno-lasciato-in-gir... A.
/"Ci si domanda peraltro anche se i responsabili di centri informatici che non hanno aggiornato le difese contro vulnerabilità note dei loro sistemi per due anni possano essere al sicuro da azioni legali contro di loro."/ Temo che l'unica notizia possibile che si possa dare su una vicenda del genere sia appunto la frase conclusiva dell'articolo citato. Credo peraltro che sia emblematico di come di questa vicenda ne abbiano (stra)parlato i media nazionali ma, qui su Nexa, vi sia stato solo un post. Giustamente, peraltro, visto che si tratta di una (a mio modesto parere) *NON NOTIZIA*. MP Il 06/02/23 09:43, Antonio ha scritto:
... un sistema digitale sempre più prezioso per la vita sociale ha bisogno di una difesa più efficace e proattiva di quella che per ora viene garantita da tante organizzazioni informatiche troppo disattente, troppo lente ad aggiornare i software, troppo fissate sul risparmio dei costi piuttosto che sulla sicurezza dei loro utenti.
https://lucadebiase.nova100.ilsole24ore.com/2023/02/05/hanno-lasciato-in-gir...
A. _______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
-- Michele Pinassi - Responsabile Cybersecurity Ufficio esercizio e tecnologie - CSIRT Università degli Studi di Siena irt@unisi.it
...
Credo peraltro che sia emblematico di come di questa vicenda ne abbiano (stra)parlato i media nazionali ma, qui su Nexa, vi sia stato solo un post. Giustamente, peraltro, visto che si tratta di una (a mio modesto parere) *NON NOTIZIA*.
Io invece sono convinto che delle /non notizie/, delle /fake news tecnologiche/ bisogna parlarne anche qui, per tutta una serie di motivi. Intanto una premessa. Come e da dove arriva una notizia? Succede qualcosa in Italia o nel mondo? Pochi minuti dopo le agenzie di stampa (ANSA, ma non solo) /battono la notizia/. A seguire arrivano i giornali online, poi i social, le televisioni e infine giornali/riviste/periodici cartacei. L'ordine più variare leggermente (a volte i social anticipano o Amadeus che /entra/ nel telegiornale per l'annuncio in diretta del superospite sanremese). Il /giro/ funziona più o meno allo stesso modo anche con notizie che invece richiederebbero qualche approfondimento in più prima di essere date in pasto all'opinione pubblica. Ma si sa, per i titolisti sempre in cerca di scoop, il tempo e i click sono importanti, e così vai con "massiccio attacco hacker", "hacker attaccano migliaia di server", "attacco hacker in tutto il mondo". Nella società dello spettacolo, dell'intrattenimento, dell'esserci sempre e comunque, la veridicità e i dettagli di una notizia non sono assolutamente rilevanti. Bisogna titolare, parlare, cianciare, gazzarrare come cornacchie. Proprio per questo diventa importante discuterne in posti come questi, fuori da social, da televisioni. Lontani da un insopportabile (almeno per me) presenzialismo di certi /esperti/ televisivi. Antonio
E allora parliamone, perché se c'è un aspetto della vicenda che merita essere discusso è come nasce una (non) notizia come questa e di come, soprattutto, Agenzie nazionali deputate alla cybersecurity rilanciano e amplificano una (non) vicenda, solleticando (inutili) allarmismi. Secondo me è questo l'aspetto meritevole di essere affrontato qui, nell'ottica di comprendere quale ruolo ha e avrà ACN nel panorama cyber nazionale, al di là delle "mission istituzionali" definite nei decreti. Qualche spunto: https://www.matricedigitale.it/editoriali/attacco-hacker-in-corso-ai-media-i... https://www.open.online/2023/02/05/attacco-hacker-italia-5-feb-2023/ https://web.archive.org/web/20230206131914/https://www.governo.it/it/articol... MP Il 07/02/23 20:27, Antonio ha scritto:
...
Credo peraltro che sia emblematico di come di questa vicenda ne abbiano (stra)parlato i media nazionali ma, qui su Nexa, vi sia stato solo un post. Giustamente, peraltro, visto che si tratta di una (a mio modesto parere) *NON NOTIZIA*.
Io invece sono convinto che delle /non notizie/, delle /fake news tecnologiche/ bisogna parlarne anche qui, per tutta una serie di motivi. Intanto una premessa. Come e da dove arriva una notizia? [...] Proprio per questo diventa importante discuterne in posti come questi, fuori da social, da televisioni. Lontani da un insopportabile (almeno per me) presenzialismo di certi /esperti/ televisivi.
Antonio
-- Michele Pinassi Responsabile Sicurezza Informatica - Telefonia di Ateneo Ufficio Esercizio e tecnologie - Università degli Studi di Siena tel: 0577.(23)5000 - helpdesk@unisi.it PGP/GPG key fingerprint 6EC4 9905 84F5 1537 9AB6 33E7 14FC 37E5 3C24 B98E
On mer, 2023-02-08 at 08:26 +0100, Michele Pinassi wrote:
E allora parliamone, perché se c'è un aspetto della vicenda che merita essere discusso è come nasce una (non) notizia come questa e di come, soprattutto, Agenzie nazionali deputate alla cybersecurity rilanciano e amplificano una (non) vicenda, solleticando (inutili) allarmismi.
Secondo me è questo l'aspetto meritevole di essere affrontato qui, nell'ottica di comprendere quale ruolo ha e avrà ACN nel panorama cyber nazionale, al di là delle "mission istituzionali" definite nei decreti.
Qualche spunto:
https://www.matricedigitale.it/editoriali/attacco-hacker-in-corso-ai-media-i... https://www.open.online/2023/02/05/attacco-hacker-italia-5-feb-2023/ https://web.archive.org/web/20230206131914/https://www.governo.it/it/articol...
Chiedo scusa per l'autocitazione ed i toni da polemista di questo articolo https://medium.com/@calamarim/cassandra-crossing-cybersicurezza-generali-e-f... ma mi pare che sia necessario citare un campione anche di dibattito, riguardo alla situazione italiana ed alle istituzioni, un po' più realista e realisticamente allarmistico, non solo pompieristico e tranquillizzante come quello degli articolo più "ufficiali" Marco
MP
Il 07/02/23 20:27, Antonio ha scritto:
...
Credo peraltro che sia emblematico di come di questa vicenda ne abbiano (stra)parlato i media nazionali ma, qui su Nexa, vi sia stato solo un post. Giustamente, peraltro, visto che si tratta di una (a mio modesto parere) *NON NOTIZIA*.
Io invece sono convinto che delle /non notizie/, delle /fake news tecnologiche/ bisogna parlarne anche qui, per tutta una serie di motivi. Intanto una premessa. Come e da dove arriva una notizia? [...] Proprio per questo diventa importante discuterne in posti come questi, fuori da social, da televisioni. Lontani da un insopportabile (almeno per me) presenzialismo di certi /esperti/ televisivi.
Antonio
L'idea di un GSPR è condivisibile, soprattutto considerando quando -ad esempio- la sicurezza "fisica" sul lavoro è da anni un fattore rilevante nelle Aziende e PA. Ore di corsi obbligatori su illuminazione, sedute, postazioni di lavoro e scrivanie. Zero per i rischi cyber, anche se il GDPR, seppur non in modo così esplicito, prevede. Zero, quando si parla di PA, anche sulle MMSPA, dove nella migliore delle ipotesi "la sicurezza informatica è solo una inutile scocciatura". IMHO è, ancora una volta una questione culturale, prima che politica e tecnica. Ne sento parlare da anni, ormai, e penso che siamo tutti concordi su questo. La sfida è cambiare questa percezione distorta e tossica, sfidando anche i media mainstream che sembrano proprio non voler capire, a cui fanno eco anche soggetti istituzionali. MP Il Mer 8 Feb 2023, 10:09 Marco A. Calamari <marcoc_maillist@marcoc.it> ha scritto:
On mer, 2023-02-08 at 08:26 +0100, Michele Pinassi wrote:
E allora parliamone, perché se c'è un aspetto della vicenda che merita essere discusso è come nasce una (non) notizia come questa e di come, soprattutto, Agenzie nazionali deputate alla cybersecurity rilanciano e amplificano una (non) vicenda, solleticando (inutili) allarmismi.
Secondo me è questo l'aspetto meritevole di essere affrontato qui, nell'ottica di comprendere quale ruolo ha e avrà ACN nel panorama cyber nazionale, al di là delle "mission istituzionali" definite nei decreti.
Qualche spunto:
https://www.matricedigitale.it/editoriali/attacco-hacker-in-corso-ai-media-i... https://www.open.online/2023/02/05/attacco-hacker-italia-5-feb-2023/
https://web.archive.org/web/20230206131914/https://www.governo.it/it/articol...
Chiedo scusa per l'autocitazione ed i toni da polemista di questo articolo
https://medium.com/@calamarim/cassandra-crossing-cybersicurezza-generali-e-f...
ma mi pare che sia necessario citare un campione anche di dibattito, riguardo alla situazione italiana ed alle istituzioni, un po' più realista e realisticamente allarmistico, non solo pompieristico e tranquillizzante come quello degli articolo più "ufficiali"
Marco
MP
Il 07/02/23 20:27, Antonio ha scritto:
...
Credo peraltro che sia emblematico di come di questa vicenda ne
abbiano (stra)parlato i media nazionali ma, qui su Nexa, vi sia stato solo un post. Giustamente, peraltro, visto che si tratta di una (a mio modesto parere) *NON NOTIZIA*.
Io invece sono convinto che delle /non notizie/, delle /fake news tecnologiche/ bisogna parlarne anche qui, per tutta una serie di motivi. Intanto una premessa. Come e da dove arriva una notizia? [...] Proprio per questo diventa importante discuterne in posti come questi, fuori da social, da televisioni. Lontani da un insopportabile (almeno per me) presenzialismo di certi /esperti/ televisivi.
Antonio
Buongiorno, Michele Pinassi <michele.pinassi@unisi.it> writes:
E allora parliamone,
sì parliamone, perché la vicenda è complessa e in realtà la "non notizia" evidenzia un sacco di cose _molto_ problematiche
perché se c'è un aspetto della vicenda che merita essere discusso è come nasce una (non) notizia come questa
il problema nasce dal fatto che alcuni giornalisti troppo zelanti di scoop (è quello che gli chiedono i loro datori di lavoro, fanno *esattamente* quello per cui sono pagati) confezionano notizie un tanto al chilo, in qualche caso sfruttando anche la situazione contingente per arrivare a suggerire che "ha stato Putin", perché fa più scena però dietro la (non) notizia - ma solo perché spesso confezionata malissimo - in realtà di fatti ce ne sono diversi e piuttosto interessanti, soprattutto se **potessimo** analizzare informazioni che invece ci sono assolutamente precluse... dopotutto è /solo/ una questione di cibersicurezza nazionale, quindi cosa pretendiamo?!?
e di come, soprattutto, Agenzie nazionali deputate alla cybersecurity rilanciano e amplificano una (non) vicenda, solleticando (inutili) allarmismi.
il comunicato del 4 Febbraio del CSIRT è questo: https://www.csirt.gov.it/contenuti/rilevato-lo-sfruttamento-massivo-della-cv... --8<---------------cut here---------------start------------->8--- [...] È stato recentemente rilevato lo sfruttamento massivo, ai fini del rilascio di ransomware, della vulnerabilità CVE-2021–21974 trattata da questo CSIRT nell'alert AL03/210224/CSIRT-ITA. Sulla relativa campagna il Computer Emergency Response Team Francese (CERT-FR) ha pubblicato un security advisory, disponibile nella sezione riferimenti, in cui si evidenziano i relativi dettagli. Dalle analisi effettuate la campagna risulta indirizzata anche verso soggetti nazionali. Qualora sfruttata, tale vulnerabilità, con score CVSS v3 pari a 8.8, di tipo “heap buffer overflow” e relativa alla componente OpenSLP – con riferimento ai prodotti VMware ESXi e Cloud Foundation (ESXi) – potrebbe consentire l’esecuzione di comandi arbitrari (RCE) sui dispositivi target. Per eventuali ulteriori approfondimenti si consiglia di consultare il security advisory, disponibile nella sezione Riferimenti. --8<---------------cut here---------------end--------------->8--- Cosa c'è di inutilmente allarmistico? [...]
Qualche spunto:
https://www.matricedigitale.it/editoriali/attacco-hacker-in-corso-ai-media-i...
--8<---------------cut here---------------start------------->8--- Nel corso di una domenica tranquilla, le redazioni sono state sconvolte da una notizia allarmistica: massiccio attacco hacker in Italia. [...] [...] Queste le indiscrezioni della prima ore che hanno mobilitato redazioni di giornali e tg nel dare una notizia a ridosso del blocco di Tim, creando disagi ad un milione di utenti che hanno associato il fail informatico del gestore telefonico all’attacco in corso su suggerimento dei media che non hanno distinto i due casi. --8<---------------cut here---------------end--------------->8--- Beh a parziale giustificazione dei giornalisti c'è il fatto che il "blocco di TIM" è avvenuto nella stessa finestra temporale degli attacchi a VMware ESXi: una sfortunata coincidenza? --8<---------------cut here---------------start------------->8--- [...] Immaginarsi l’italiano medio che non sa installare un software sul pc e che al tg delle 20 gli viene detto di aggiornare il suo VmWare. Il messaggio che gli arriva è quello di un attacco hacker catastrofico in corso. Se questo non è procurato allarme, allora cos’è? --8<---------------cut here---------------end--------------->8--- Ci manca solo di buttarla in vacca con il "procurato allarme": perché prendersela col "giornalista medio" che deve parlare all'"italiano medio" di informatica senza che i due sappiano "installare un software su un PC" (e anche su smartphone) e figurarsi se hanno idea di cosa sia VMware ESXi? :-O --8<---------------cut here---------------start------------->8--- [...] Quello che non torna è invece la notizia dell’attacco informatico in corso su larga scala ed è qui che è parso a tutti evidente la mano di ACN o di un suo interno che ha diffuso la notizia a pochi fidati che hanno generato il caos. La prova di questa tesi sta proprio nel fatto che tutti i media hanno citato ACN come se fosse la promotrice della notizia dell’allarme in corso su larga scala. --8<---------------cut here---------------end--------------->8--- Dietrologia? C'è la mano di ACN dietro l'allarmismo? ...e chi lo saprà mai: i giornalisti hanno canali che noi umani... :-O BTW, ecco il comunicato di ACN: https://www.acn.gov.it/notizie/contenuti/rilevato-lo-sfruttamento-massivo-de... --8<---------------cut here---------------start------------->8--- [...] il calo di connessione non è stato invece quantificato e soprattutto non può collegato all’esiguo numero di server compromessi come ha spiegato Odisseus. --8<---------------cut here---------------end--------------->8--- NetBlocks lo quantifica, perdita del 74% della connettività italiana: https://twitter.com/netblocks/status/1622227650386214913?s=20 --8<---------------cut here---------------start------------->8--- Confirmed: #Italy is in the midst of a major internet outage with high impact to leading operator Telecom Italia; real-time network data show national connectivity at 26% of ordinary levels; incident ongoing 📉 #TIMDown --8<---------------cut here---------------end--------------->8---
https://www.open.online/2023/02/05/attacco-hacker-italia-5-feb-2023/
--8<---------------cut here---------------start------------->8--- Domani mattina alle 9 il sottosegretario Alfredo Mantovano, autorità delegata per la cybersicurezza, incontrerà a Palazzo Chigi il direttore di ACN, Roberto Baldoni, e la direttrice del DIS-Dipartimento informazione e sicurezza, Elisabetta Belloni, per fare un primo bilancio dei danni provocati dagli attacchi --8<---------------cut here---------------end--------------->8--- Il "bilancio dei danni provocati" se lo sono tenuti per loro?
https://web.archive.org/web/20230206131914/https://www.governo.it/it/articol...
--8<---------------cut here---------------start------------->8--- [...] in Italia nessuna Istituzione o azienda primaria che opera in settori critici per la sicurezza nazionale è stata colpita. --8<---------------cut here---------------end--------------->8--- OK, quindi nessun allarme: giusto? --8<---------------cut here---------------start------------->8--- [...] Per fare una analogia con l’ambito sanitario, è accaduto come se a febbraio 2021 un virus particolarmente aggressivo avesse iniziato a circolare, le autorità sanitarie avessero sollecitato le persone fragili a una opportuna prevenzione, e a distanza di tempo siano emersi i danni alla salute per chi a quella prevenzione non avesse ottemperato. --8<---------------cut here---------------end--------------->8--- eh certo, non poteva non mancare la "traduzione" in termini di salute pubblica del problema della vulnerabilità di VMware ESXi! --8<---------------cut here---------------start------------->8--- [...] Il Governo, dando seguito a quanto previsto dal DL n. 82/2021, adotterà tempestivamente un DPCM per raccordare il fondamentale lavoro di prevenzione delle Regioni con ACN. Nel contempo la stessa Agenzia istituzionalizzerà un tavolo di interlocuzione periodica con tutte le strutture pubbliche e private che erogano servizi critici per la Nazione, a cominciare dai Ministeri e dagli istituti di credito e assicurativi. --8<---------------cut here---------------end--------------->8--- ma sì: un DPCM e un tavolo di interlocuzione non si negano a nessun governo che si rispetti! [...] (segue...) -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
(...continua) Il miglior report che sono riuscito a trovare è quello di Julien Levrard di OVH: https://blog.ovhcloud.com/ransomware-targeting-vmware-esxi/ «Ransomware targeting VMware ESXi» --8<---------------cut here---------------start------------->8--- [...] These attacks are detected globally. According to experts from the ecosystem as well as authorities, the malware is probably using CVE-2021-21974 as compromission vector. Investigation are still ongoing to confirm those assumptions. [...] In addition to the recovery procedure described earlier, we noted that the encryption process is only impacting a small amount of data within the file. Depending of your VM OS and file system type, you might be able to recover data with data revery tools, at least partially. [...] So far we identified the following behavior: * The compromission vector is confirmed to use a OpenSLP vulnerability that might be CVE-2021-21974 (still to be confirmed). The logs actually show the user dcui as involved in the compromission process. * Encryption is using a public key deployed by the malware in /tmp/public.pem * The encryption process is specifically targeting virtual machines files (“.vmdk”, “.vmx”, “.vmxf”, “.vmsd”, “.vmsn”, “.vswp”, “.vmss”, “.nvram”,”*.vmem”) * The malware tries to shutdown virtual machines by killing the VMX process to unlock the files. This function is not systematically working as expected resulting in files remaining locked. * The malware creates argsfile to store arguments passed to the encrypt binary (number of MB to skip, number of MB in encryption block, file size) * No data exfiltration occurred. --8<---------------cut here---------------end--------------->8--- Perché report del genere non sono redatti dalle istituzioni preposte, tipo il CSIRT?!? Non è ancora definitivamente certo che il vettore di attacco sia il servizio CVE-2021-21974 datato 4 Gennaio 2021? ...è /quasi/ certo https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21974 --8<---------------cut here---------------start------------->8--- OpenSLP as used in ESXi (7.0 before ESXi70U1c-17325551, 6.7 before ESXi670-202102401-SG, 6.5 before ESXi650-202102101-SG) has a heap-overflow vulnerability. A malicious actor residing within the same network segment as ESXi who has access to port 427 may be able to trigger the heap-overflow issue in OpenSLP service resulting in remote code execution. --8<---------------cut here---------------end--------------->8--- OpenSLP [1] è un servizio che implementa "Service Location Protocol (SLP)", il cui repository ufficiale Git è su GitHub [2] sin dal 13 Settembre 2019 [3] **ma** sulle pagine web [1] tutto fa ancora riferimento a SourceForge, mailing list comprese (i cui archivi si fermano al 2019). Il fatto che CVE-2021-21974 dica "OpenSLP as used in ESXi" indica molto probabilmente che la versione OpenSLP usata da VMware è stata modificata e il sorgente non è disponibile in formato sorgente (possono farlo perché è BSD), infatti nel CVE non è indicata nessuna patch al sorgente, contrariamente a quanto accade con il software "open source". Una ricerca alle issues registrate su GitHub [4] pare confermare che la versione ufficiale del software non abbia quel problema di heap-overflow... o non l'abbiano mai identificata e risolta. Lunedì 6 VMware emette un suo comunicato in merito: https://blogs.vmware.com/security/2023/02/83330.html «VMware Security Response Center (vSRC) Response to ‘ESXiArgs’ Ransomware Attacks» --8<---------------cut here---------------start------------->8--- [...] VMware has not found evidence that suggests an unknown vulnerability (0-day) is being used to propagate the ransomware used in these recent attacks. Most reports state that End of General Support (EOGS) and/or significantly out-of-date products are being targeted with known vulnerabilities which were previously addressed and disclosed in VMware Security Advisories (VMSAs). [...] With this in mind, we are advising customers to upgrade to the latest available supported releases of vSphere components to address currently known vulnerabilities. In addition, VMware has recommended disabling the OpenSLP service in ESXi. In 2021, ESXi 7.0 U2c and ESXi 8.0 GA began shipping with the service disabled by default. --8<---------------cut here---------------end--------------->8--- OK tutto chiaro no? L'attacco ransomware (a volte) è andato a buon fine perché non sono stati applicati gli aggiornamenti per tempo. Tutto risolto allora? Beh, il ransomware almeno è visibile ma chi chi lo sa in questi due anni (e per quanto prima?) altri "enti" sono stati in grado di portare a termine attacchi di tipo hyperjacking [5] senza essere stati scoperti, semplicemente limitandosi a spiare o a compromettere le "build chains" del software compilato da macchine virtuali sotto VMware ESXi? saluti, 380° [1] http://www.openslp.org/ [2] https://github.com/openslp-org/openslp [3] https://sourceforge.net/p/openslp/mailman/message/36762757/ [4] https://github.com/openslp-org/openslp/issues?q=is%3Aissue [5] https://en.wikipedia.org/wiki/Hyperjacking P.S.: a volte ho l'impressione che, in relazione a notizie come queste, si "dipinga" la situazione IT italiana con tinte molto più fosche rispetto a /paradisi/ tecologici esteri, tuttavia se si lascia da parte il pregiudizio si scopre che nell"universo IT" siamo davvero tutti nella stessa barca: https://www.voanews.com/a/us-state-court-system-us-eu-universities-hit-by-ra... «US State Court System, US, EU Universities Hit by Ransomware Outbreak» -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
...
P.S.: a volte ho l'impressione che, in relazione a notizie come queste, si "dipinga" la situazione IT italiana con tinte molto più fosche rispetto a /paradisi/ tecologici esteri Grazie Giovanni, hai riportato tanti link a cui ero giunto pure io e che quindi non ripeterò. Ma a me piacciono le cronistorie, così ne indicherò altri :) 3 febbraio 2023, sono le 14:37 e su Twitter, Arnaud de Bermingham di Scaleway lancia l'allarme: "If you're using ESXi 6.x, update IMMEDIATELY, a cryptolock is rolling out fast!" [1] Ore 15:01, su un forum appare il messaggio ricevuto dagli attaccati: "We hacked your company successfully All files have been stolen and encrypted by us If you want to restore files or avoid file leaks, please send <b>2.0781</b> bitcoins to the wallet" [2] Il forum si riempie presto di messaggi e alle 19:11, appena 4 ore dopo, ecco: "ATTENTION TO WHOSE FILES WERE CRYPTED BY THIS ATTACK. CLICK HERE TO READ THE TUTORIAL ON HOW TO DECRYPT YOUR AFFECTED VMDK FILES" [3] Problema rientrato? Macché. 04 febbraio 2023 ore 22:23 esce l'alert di ACN, 32 ORE dopo l'inizio dell'attacco !!! Il resto è storia.
Ma alla fine, un dubbio rimane. Quanti saranno state le /vittime/ dell'attacco? Eccoli qua: 3805 indirizzi IP di cui 22 italiani [5]. A. [1] https://twitter.com/a_bermingham/status/1621503163584118790 [2] https://www.bleepingcomputer.com/forums/t/782193/esxi-ransomware-help-and-su... [3] https://www.bleepingcomputer.com/forums/t/782193/esxi-ransomware-help-and-su... [4] https://www.csirt.gov.it/contenuti/rilevato-lo-sfruttamento-massivo-della-cv... [5] https://gist.github.com/cablej/bdc2ee2c84915d0b68eec9d4d4747e19
On mer, 2023-02-08 at 17:54 +0100, Antonio wrote:
...
P.S.: a volte ho l'impressione che, in relazione a notizie come queste, si "dipinga" la situazione IT italiana con tinte molto più fosche rispetto a /paradisi/ tecologici esteri Grazie Giovanni, hai riportato tanti link a cui ero giunto pure io e che quindi non ripeterò.
...
Ma alla fine, un dubbio rimane. Quanti saranno state le /vittime/ dell'attacco? Eccoli qua: 3805 indirizzi IP di cui 22 italiani [5].
Vabbe, avranno usato Shodan per contare gli IP con la porta di default del servizio aperta. Ma a quanti server corrispondono, ed a quante macchine virtuali corrispondono? Sennò come si può stimare l'entità del rischio/danno? E sopratutto. Chi sono i 22 italiani ....?
Buongiorno, (that's why I love Lista Nexa!) grazie Antonio per i link, davvero preziosi, specialmente il Gist! "Marco A. Calamari" <marcoc_maillist@marcoc.it> writes:
On mer, 2023-02-08 at 17:54 +0100, Antonio wrote:
[...]
Ma alla fine, un dubbio rimane. Quanti saranno state le /vittime/ dell'attacco? Eccoli qua: 3805 indirizzi IP di cui 22 italiani [5].
Vabbe, avranno usato Shodan per contare gli IP con la porta di default del servizio aperta.
Non credo abbiano usato solo quel tipo di scansione perché la tabella in CSV allegata al gist [5] indica anche (Bitcoin wallet) "address", che non è un'informazione che si può ricavare scansionando gli IP: --8<---------------cut here---------------start------------->8--- ip,address,city,country,country_code,port,dns_names,reverse_dns 78.46.39.83,1HTZ1dKiwWQKBHT3QaAkypPBngaK4z76PB,,Germany,DE,443,[],[esxi] 78.46.86.170,16oEskLDvAKHa7u6PASJUijCsRgjMFD3Ff,,Germany,DE,443,[lara.smart1.eu],[lara.smart1.eu] 78.46.72.169,1HjigJrc711d2rYy8PM9GHJua3pqUxUYT9,,Germany,DE,443,[static.169.72.46.78.clients.your-server.de],[static.169.72.46.78.clients.your-server.de] [...] --8<---------------cut here---------------end--------------->8--- (estratto da https://gist.githubusercontent.com/cablej/bdc2ee2c84915d0b68eec9d4d4747e19/r...) Il Gist (pubblicato da Jack Cable [6] fondatore di Ransomwhere [7]) dice: «A list of ESXi victims Censys, published by Ransomwhere» Censys [8] è un servizio di map scanning globale che fornisce ai propri clienti servizi per consultare la "mappa di tutto su Internet": --8<---------------cut here---------------start------------->8--- The Leading Internet Intelligence Platform for Threat Hunting and Exposure Management. Censys empowers security teams with the most comprehensive, accurate, and up-to-date map of the internet to defend attack surfaces and hunt for threats. [...] Censys Search leads the industry in internet scanning capabilities to provide the largest, most comprehensive dataset of internet intelligence available. [...] The foundation of the Censys Platform is our data. Founded by the creators of ZMap, Censys’ proprietary map of the internet offers the most coverage, fastest discovery, and the deepest insights available. [...] Censys has the widest breadth and depth of internet scanning data available. We scan the top 137 ports and the top 1440 ports in the cloud on a daily basis, while refreshing all known services within a 24 hour time frame. [...] Censys provides a rich understanding of everything on the internet, enabling security teams to understand asset connections, current configurations, and discovered threat details. Additionally, security teams get access to the potential impacts of each risk and recommended steps for remediation. [...] Censys provides the most comprehensive and accurate relationship of things on the internet. Through our advanced attribution engine, seed data is exposed to show connected assets, which are then enriched with contextual data for even deeper visibility. --8<---------------cut here---------------end--------------->8--- Censys usa ZMap [9] come "motore", il software libero che ha letteralmente cambiato il modo di fare net-scanning: --8<---------------cut here---------------start------------->8--- ZMap is capable scanning the entire public IPv4 address space in under 45 minutes. With a 10gigE connection and PF_RING, ZMap can scan the IPv4 address space in under 5 minutes. --8<---------------cut here---------------end--------------->8--- (da https://github.com/zmap/zmap) Inoltre, Censys collabora con Stanford pubblicando due (degli attuali tre) dataset liberamente disponibili su "Stanford Internet Research Data Repository": https://scans.io/ Quindi Ransomwhere (via Jack Cable) ha usato i servizi Censys per estrarre la tabella Come hanno fatto a raccogliere i dati su questo ransomware è descritto in questo post di Censys (bingo! trovato l'articolo più interessante in assoluto in merito a questo attacco): https://censys.io/esxwhy-a-look-at-esxiargs-ransomware/ «ESXWhy: A Look at ESXiArgs Ransomware» --8<---------------cut here---------------start------------->8--- Executive Summary * A ransomware campaign targeting VMWare ESXi servers began in early Februrary, 2023. The ransomware, dubbed ESXiArgs, peaked in infections on February 3, with Censys observing 3,551 infected hosts. * Typically, ransomware takes hosts offline and leaves few artifacts visible to the public Internet. ESXiArgs ransomware, however, presents ransom notes to the Internet, making them visible to Censys’ passive scanners. * Bitcoin wallet addresses are posted on the ransom pages, allowing us to track payments associated with this ransomware. * France, US, Germany, Canada, and other countries have seen attacks, with many occurring in France, particularly against hosts on French cloud provider OVH. --8<---------------cut here---------------end--------------->8--- Quindi a quanto pare Censys ha dei "passive scanners" [9]... facendo scaping (lo scraping è passivo?!? :-D ) delle "ransom notes" pubblicate dagli attaccanti su Internet. In fondo all'articolo è pubblicato l'URL della query al database Censys: https://search.censys.io/search?resource=hosts&sort=RELEVANCE&per_page=25&vi... Per facilità di lettura, il testo della query è: --8<---------------cut here---------------start------------->8--- services.http.response.body: "How to Restore Your Files" and services.http.response.html_title:"How to Restore Your Files" --8<---------------cut here---------------end--------------->8--- Adesso quella query restituisce 1,510 hosts, perché man mano le pagine con la richiesta di riscatto stanno sparendo ...sottolineo: non ho scritto che i server sono stati ripristinati (sono liberi da backdoors), ho scritto che le pagine con la richiesta di riscatto stanno pian piano sparendo, probabilmente perché sono state "applicate le patch" Riusciranno i nostri eroi a garantirsi che le proprie macchine con su VMware ESXi siano prive di backdoors? :-O
Ma a quanti server corrispondono, ed a quante macchine virtuali corrispondono?
Credo che ci sia una e una sola "ransom note" per server fisico (bare metal) con VMware ESXi compromesso... le macchine virtuali potrebbero essere anche centinaia per ciascun nodo fisico
Sennò come si può stimare l'entità del rischio/danno?
Da fuori l'entità del rischio è **inestimabile**, quindi anche del danno: (giustamente) solo i proprietari dei server sanno cosa ci gira dentro
E sopratutto. Chi sono i 22 italiani ....?
Nel CVS del Gist [5] ci sono tutti gli IP dei 22 (non ho contato) server italiani, pare che nessuno sia istituzionale per fortuna (continua...) Saluti, 380° [5] https://gist.github.com/cablej/bdc2ee2c84915d0b68eec9d4d4747e19 [6] https://en.wikipedia.org/wiki/Jack_Cable_(software_developer) [7] https://ransomwhe.re/ [8] https://censys.io/ [9] https://en.wikipedia.org/wiki/ZMap_(software) [10] un "passive scanner" non interagisce con il sistema monitorato inviando un pacchetto IP o richiedendo una risposta ad un pacchetto IP [...] -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
(...segue) ma torniamo "a bomba" a un paio di passaggi nell'articolo: 380° <g380@biscuolo.net> writes: [...]
https://censys.io/esxwhy-a-look-at-esxiargs-ransomware/
«ESXWhy: A Look at ESXiArgs Ransomware»
--8<---------------cut here---------------start------------->8--- [...] Per the VMWare advisory, to execute such an attack, the actor must have access to a system that resides within the same network segment as ESXi and have access to port 427. This raises the question: how was that initial access gained if local network access is needed to exploit? --8<---------------cut here---------------end--------------->8--- Interessantissima (quanto tecnica) domanda, perché i dettagli contano molto; in questo caso la riposta potrebbe essere: e se avessero compromesso una delle VM ospitate e usato quella per fare "tunneling" verso l'host? [1]. Mi pare comunque strano perché sull'host come minimo dovrebbe esserci un Firewall che impedisce traffico dalle VM --8<---------------cut here---------------start------------->8--- Oddly enough, not every compromised server was running the SLP service, although some were. Below are two screenshots showing the output of snmpnetstat against two separate compromised servers, which display processes listening on the network. One shows an SLP service running, the other does not. --8<---------------cut here---------------end--------------->8--- (l'articolo poi riporta due screenshots coi risultati dello scan) Effettivamente /pare/ che uno degli host compromessi non avesse il servizio SLP (quello bacato, responsabile del heap-overflow che consente il successo dell'attacco) attivo, almeno non sulla porta di default del servizio... o almeno non nel momento in cui è stato eseguito il comando SNMP, magari il sysadmin ha spento il demone prima dello scan (ma dopo i ransomware) :-) Comunque /pare/ ci siano alcuni "segnali" che ancora non consentono di stabilire con certezza quale sia stato esattamente il vettore di attacco utilizzato. Mah?!? Ultima nota: spiace un po' leggere --8<---------------cut here---------------start------------->8--- Perhaps not surprisingly, we observed that French cloud hosting provider OVH is by far the most affected autonomous system, with just over 1,700 infected hosts during the 6-day time period we studied. --8<---------------cut here---------------end--------------->8--- Chi non fosse del settore potrebbe pensare che in OVH siano degli sprovveduti, senza sapere che OVH - come altri, tipo Hetzner, dove ci sono altri server compromessi - affitta server fisici (bare metal) sui quali i clienti possono decidere di installare il sistema operativo che preferiscono [2], VMware ESXi compreso. Saluti, 380° [...] [1] https://www.reddit.com/r/sysadmin/comments/10tbmve/comment/j77g7rc/?utm_sour... [2] https://www.ovhcloud.com/it/bare-metal/os/ -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
...
Chi non fosse del settore potrebbe pensare che in OVH siano degli sprovveduti, senza sapere che OVH - come altri, tipo Hetzner, dove ci sono altri server compromessi - affitta server fisici (bare metal) sui quali i clienti possono decidere di installare il sistema operativo che preferiscono [2], VMware ESXi compreso. E le responsabilità ricadono sul cliente, come espressamente indicato nelle Condizioni Particolari di Servizio [1]:
"Per quanto riguarda le installazioni ESXi su risorse Cliente dedicate (Server Host), OVHcloud informa il Cliente come indicato sopra. Il Cliente è interamente responsabile degli aggiornamenti minori (patch) di ESXi e li gestisce direttamente. A questo proposito, OVHcloud incoraggia il Cliente a verificare regolarmente gli aggiornamenti disponibili presso l'editor VMware. A questo scopo, il Cliente può utilizzare il VUM (Virtual Update Manager) di VMware. OVHcloud declina qualsiasi responsabilità in caso di malfunzionamento del Servizio a seguito degli aggiornamenti dell'Hypervisor installati dal Cliente. Allo stesso modo, il Cliente si assume la piena responsabilità della mancata applicazione degli aggiornamenti dell'Hypervisor. A. [1] https://storage.gra.cloud.ovh.net/v1/AUTH_325716a587c64897acbef9a4a4726e38/c... (pag. 6)
...
Credo che ci sia una e una sola "ransom note" per server fisico (bare metal) con VMware ESXi compromesso... le macchine virtuali potrebbero essere anche centinaia per ciascun nodo fisico ... e ad ogni macchina virtuale potrebbero puntare decine di siti (Name-Based Virtual Host). Un modo, tutto sommato semplice, di controllare se in quei server è /ospitato/ qualche sito web potrebbe essere il /reverse IP lookup/. Lo farei io ma in questo momento mi trovo sprovvisto dell'elenco dei 350 milioni di domini attualmente registrati [1] ;)
A. https://www.verisign.com/assets/domain-name-report-Q32022.pdf
Beh, il ransomware almeno è visibile ma chi chi lo sa in questi due anni (e per quanto prima?) altri "enti" sono stati in grado di portare a termine attacchi di tipo hyperjacking [5] senza essere stati scoperti, semplicemente limitandosi a spiare o a compromettere le "build chains" del software compilato da macchine virtuali sotto VMware ESXi?
Ma che domande fai 380°? È ovvio che è successo decine di volte? Per ogni violazione tanto maldestra da farsi scoprire, ne avvengono decine prima. Ma tanto faranno tutti finta che basti aggiornare e riavviare tutto. Come hanno fatto con log4shell. Giacomo Il 8 Febbraio 2023 15:12:40 UTC, "380°" <g380@biscuolo.net> ha scritto:
(...continua)
Il miglior report che sono riuscito a trovare è quello di Julien Levrard di OVH:
https://blog.ovhcloud.com/ransomware-targeting-vmware-esxi/
«Ransomware targeting VMware ESXi»
--8<---------------cut here---------------start------------->8---
[...] These attacks are detected globally. According to experts from the ecosystem as well as authorities, the malware is probably using CVE-2021-21974 as compromission vector. Investigation are still ongoing to confirm those assumptions.
[...] In addition to the recovery procedure described earlier, we noted that the encryption process is only impacting a small amount of data within the file. Depending of your VM OS and file system type, you might be able to recover data with data revery tools, at least partially.
[...] So far we identified the following behavior:
* The compromission vector is confirmed to use a OpenSLP vulnerability that might be CVE-2021-21974 (still to be confirmed). The logs actually show the user dcui as involved in the compromission process.
* Encryption is using a public key deployed by the malware in /tmp/public.pem
* The encryption process is specifically targeting virtual machines files (“.vmdk”, “.vmx”, “.vmxf”, “.vmsd”, “.vmsn”, “.vswp”, “.vmss”, “.nvram”,”*.vmem”)
* The malware tries to shutdown virtual machines by killing the VMX process to unlock the files. This function is not systematically working as expected resulting in files remaining locked.
* The malware creates argsfile to store arguments passed to the encrypt binary (number of MB to skip, number of MB in encryption block, file size)
* No data exfiltration occurred.
--8<---------------cut here---------------end--------------->8---
Perché report del genere non sono redatti dalle istituzioni preposte, tipo il CSIRT?!?
Non è ancora definitivamente certo che il vettore di attacco sia il servizio CVE-2021-21974 datato 4 Gennaio 2021? ...è /quasi/ certo
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21974
--8<---------------cut here---------------start------------->8---
OpenSLP as used in ESXi (7.0 before ESXi70U1c-17325551, 6.7 before ESXi670-202102401-SG, 6.5 before ESXi650-202102101-SG) has a heap-overflow vulnerability. A malicious actor residing within the same network segment as ESXi who has access to port 427 may be able to trigger the heap-overflow issue in OpenSLP service resulting in remote code execution.
--8<---------------cut here---------------end--------------->8---
OpenSLP [1] è un servizio che implementa "Service Location Protocol (SLP)", il cui repository ufficiale Git è su GitHub [2] sin dal 13 Settembre 2019 [3] **ma** sulle pagine web [1] tutto fa ancora riferimento a SourceForge, mailing list comprese (i cui archivi si fermano al 2019).
Il fatto che CVE-2021-21974 dica "OpenSLP as used in ESXi" indica molto probabilmente che la versione OpenSLP usata da VMware è stata modificata e il sorgente non è disponibile in formato sorgente (possono farlo perché è BSD), infatti nel CVE non è indicata nessuna patch al sorgente, contrariamente a quanto accade con il software "open source". Una ricerca alle issues registrate su GitHub [4] pare confermare che la versione ufficiale del software non abbia quel problema di heap-overflow... o non l'abbiano mai identificata e risolta.
Lunedì 6 VMware emette un suo comunicato in merito:
https://blogs.vmware.com/security/2023/02/83330.html
«VMware Security Response Center (vSRC) Response to ‘ESXiArgs’ Ransomware Attacks»
--8<---------------cut here---------------start------------->8---
[...] VMware has not found evidence that suggests an unknown vulnerability (0-day) is being used to propagate the ransomware used in these recent attacks. Most reports state that End of General Support (EOGS) and/or significantly out-of-date products are being targeted with known vulnerabilities which were previously addressed and disclosed in VMware Security Advisories (VMSAs).
[...] With this in mind, we are advising customers to upgrade to the latest available supported releases of vSphere components to address currently known vulnerabilities. In addition, VMware has recommended disabling the OpenSLP service in ESXi. In 2021, ESXi 7.0 U2c and ESXi 8.0 GA began shipping with the service disabled by default.
--8<---------------cut here---------------end--------------->8---
OK tutto chiaro no? L'attacco ransomware (a volte) è andato a buon fine perché non sono stati applicati gli aggiornamenti per tempo.
Tutto risolto allora?
Beh, il ransomware almeno è visibile ma chi chi lo sa in questi due anni (e per quanto prima?) altri "enti" sono stati in grado di portare a termine attacchi di tipo hyperjacking [5] senza essere stati scoperti, semplicemente limitandosi a spiare o a compromettere le "build chains" del software compilato da macchine virtuali sotto VMware ESXi?
saluti, 380°
[2] https://github.com/openslp-org/openslp
[3] https://sourceforge.net/p/openslp/mailman/message/36762757/
[4] https://github.com/openslp-org/openslp/issues?q=is%3Aissue
[5] https://en.wikipedia.org/wiki/Hyperjacking
P.S.: a volte ho l'impressione che, in relazione a notizie come queste, si "dipinga" la situazione IT italiana con tinte molto più fosche rispetto a /paradisi/ tecologici esteri, tuttavia se si lascia da parte il pregiudizio si scopre che nell"universo IT" siamo davvero tutti nella stessa barca: https://www.voanews.com/a/us-state-court-system-us-eu-universities-hit-by-ra...
«US State Court System, US, EU Universities Hit by Ransomware Outbreak»
-- 380° (Giovanni Biscuolo public alter ego)
«Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché»
Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
Buongionro, un piccolo passo indietro e /di lato/ 380° <g380@biscuolo.net> writes: [...]
NetBlocks lo quantifica, perdita del 74% della connettività italiana:
https://twitter.com/netblocks/status/1622227650386214913?s=20
--8<---------------cut here---------------start------------->8---
Confirmed: #Italy is in the midst of a major internet outage with high impact to leading operator Telecom Italia; real-time network data show national connectivity at 26% of ordinary levels; incident ongoing 📉 #TIMDown
--8<---------------cut here---------------end--------------->8---
quindi il 5 Febbraio c'è stata quella perdita di connettività, in contemporanea agli attacchi ransomware a VMware, ma è solo una coincidenza: giusto? Matteo G. Flora dice: https://twitter.com/lastknight/status/1622283570013241344?s=20 --8<---------------cut here---------------start------------->8--- [...] non è il problema segnalato con ESXi, semplicemente è stato palesemente un problema di un carrier, legato alla connettività BGP che infatti dava una pletora di errori. Questi errori, come abbiamo imparato dal down di Facebook, non sono quasi mai creati da attacchi, ma da configurazioni errate. Oltretutto c'entra nulla con VmWare (sarebbe come dire, ho un problema di iOs, è impazzita una mietitrebbia: c'entra una minchia). --8<---------------cut here---------------end--------------->8--- Esiste un report ufficiale che dica che quel problema è dipeso da una errata configurazione BGP?!? Io non lo trovo. @TonyAlligatour risponde a Flora: (https://twitter.com/TonyAlligatour/status/1622524731202105345?s=20) --8<---------------cut here---------------start------------->8--- i router BGP non altro che dei dispositivi è come tali possono essere virtualizzati anche su ESXi, se qualcuno ha sfruttato la vulnerabilità di ESXi. potrebbe aver preso il controllo di questi dispositivi è configurarli al suo piacimento [...] sembra incredibile, ma è unico modo per collegare un bug di sicurezza su ESXi con problemi di traffico intercontinentale --8<---------------cut here---------------end--------------->8--- Quindi domando di nuovo: HA stata una sfortuita coincidenza? Perché non esiste un "CSIRT", un ente cyberquaicos, che fornisca report chiari ed esaustivi su incidenti come questo BGP hijacking?!? Sarà mica una cosa seria, questa: la connettività italiana è calata del 74% per diverse ore di Domenica 5 e siamo qui a /speculare/ su cosa è successo?!? [...] saluti, 380° -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
participants (5)
-
380° -
Antonio -
Giacomo Tesio -
Marco A. Calamari -
Michele Pinassi