(...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-ransomware-outbreak-/6952574.html «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>.
signature.asc
Description: PGP signature
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
