(...segue) ma torniamo "a bomba" a un paio di passaggi nell'articolo:
380° <g...@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_source=share&utm_medium=web2x&context=3 [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>.
signature.asc
Description: PGP signature
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
