Exploit log4shell: “vecchio” a chi?

0

Che lavoriate o no nella cybersecurity, ricorderete sicuramente quei mesi alla fine del 2021 in cui, improvvisamente, non si parlava d’altro che di log4shell, vulnerabilità di criticità 10.0 che ha messo in subbuglio il mondo dell’IT a ogni livello organizzativo. Come spesso accade in questi casi, la copertura mediatica delle vulnerabilità tende a esaurirsi drasticamente poche settimane dopo la disclosure.

Ciò che ci si aspetta è che, dopo questo genere di notizie, segua una campagna di patching intensiva e profusa nella maggior parte delle aziende e infrastrutture ovunque nel mondo. E’ anche comprensibile che tutto questo naturale seguirsi di eventi non sia perfetto, o perchè la notizia (strano ma vero) non è giunta a tutti, o perchè pur essendo arrivata all’attenzione delle persone giuste, per qualsiasi motivo, non si è intervenuti per mitigare e patchare.

Secondo un report joint Cybersecurity Advisory (CSA) di alcuni giorni fa, risulta, infatti, che log4shell sia ancora un problema e che sia ancora attivamente utilizzata per violare aziende che abbiano server VMware Horizon® e Unified Access Gateway (UAG) non ancora patchati.

A complicare le cose vi è il fatto che patchare il vettore di ingresso iniziale non ha alcun effetto su eventuale malware che nel frattempo si è insediato nell’infrastruttura, il quale potrà continuare a funzionare se non fermato e rilevato da altri strumenti di sicurezza.

Nello stesso report si legge:

In one confirmed compromise, these APT actors were able to move laterally inside the network, gain access to a disaster recovery network, and collect and exfiltrate sensitive data.

In una compromissione confermata, attori [malevoli] APT sono stati in grado di muoversi lateralmente nella rete, ottenere accesso alla rete di disaster recovery, raccogliere ed esfiltrare dati sensibili.

Dal momento che non si fa riferimento a un’azienda specifica, non è chiaro se tale compromissione si è espletata per lungo tempo dopo il patching iniziale o se tutto si è consumato nei primi giorni, prima di patching e incident response.

Risulta però evidente che, anche a seguito di patching e mitigazione, cosa che tra l’altro non appare essere scontata nemmeno adesso a 6 mesi dalla prima disclosure, devono anche seguire sempre i necessari audit o rebuild completi. Blindare la porta di casa è infatti utile, si, ma non sufficiente se il ladro è già dentro, nascosto dentro un armadio.

E Log4shell non è un caso isolato: secondo F-secure, nel 2021, il 61% delle vulnerabilità riportate a livello aziendale era stata annunciata prima del 2016.

A meno che tale trend non sia cambiato drasticamente, la conclusione a cui portano questi dati è che la maggior parte delle vulnerabilità di cui ormai non si parla più da anni è ancora in uso e che esistono in giro ancora troppi sistemi esposti su Internet ma dimenticati a se stessi.

Appassionato di Linux e della cultura open-source da vent’anni, continuo a fare del mio meglio per diffondere tale filosofia e soprattutto condividere la conoscenza.

C’è sempre qualcuno da qualche parte nel mondo che sta avendo un problema che tu hai già risolto e, condividendo la soluzione, puoi fare la differenza.

Se quel qualcuno sei tu, chiedi pure alla community. La trovi ovunque, ad esempio su reddit.com/r/italyinformatica, reddit.com/r/fedora, reddit.com/r/debian, reddit.com/r/ubuntu, reddit.com/r/archlinux, reddit.com/r/linux, sui forum specifici delle distro oppure sulle loro wiki.

Perchè nessun problema andrebbe risolto più di una volta.

[https://it.linkedin.com/in/john-toscano]

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *