Le vulnerabilità di Log4j sono qui per restare: sei preparato?

La diffusa vulnerabilità apparsa per la prima volta in Apache Log4j nel 2021 continuerà ad essere sfruttato, potenzialmente anche in modi peggiori di quelli che abbiamo visto fino ad oggi. L'aspetto più preoccupante di queste minacce è che ci sono buone possibilità che continuino a essere sfruttate per mesi o anni nel futuro.

Il comitato di revisione della sicurezza informatica del Dipartimento per la sicurezza interna ha debuttato nel 2021 e nel 2022 ha pubblicato il suo relazione inaugurale sulla sicurezza (PDF). In esso, il consiglio di amministrazione ha definito Log4j una "vulnerabilità endemica", principalmente perché non esiste un "elenco clienti" completo per Log4j, rendendo il tenere il passo con le vulnerabilità un compito quasi impossibile. Un dipartimento del gabinetto federale ha persino impiegato 33,000 ore per la sua risposta Log4j.

E molte organizzazioni e soluzioni di sicurezza sul mercato non riescono a identificare la differenza tra sfruttabilità e vulnerabilità, lasciando agli aggressori l'opportunità di svolgere attività dannose.

Sfruttabilità contro vulnerabilità

Uno dei problemi chiave con la sicurezza informatica oggi è comprendere la differenza tra le vulnerabilità e la loro gravità. Quando si tratta di misurare la sfruttabilità rispetto a una vulnerabilità, c'è una grande differenza tra il fatto che una minaccia alla sicurezza sia sfruttabile all'interno dell'azienda o se sia semplicemente "vulnerabile" e non possa ostacolare l'azienda o raggiungere una risorsa critica. I team di sicurezza passano troppo tempo a non capire la differenza tra i due e a correggere ogni vulnerabilità man mano che si presenta, invece di dare la priorità a quelle sfruttabili.

Ogni azienda ha migliaia di vulnerabilità ed esposizioni comuni (CVE), molte delle quali ottengono un punteggio elevato nel Common Vulnerability Scoring System (CVSS), quindi è impossibile risolverle tutte. Per combattere questo, la speranza è che gli strumenti di gestione delle vulnerabilità basati sul rischio (RBVM) lo facciano semplificare la definizione delle priorità chiarendo ciò che è sfruttabile.

Tuttavia, gli approcci di prioritizzazione della sicurezza che combinano i punteggi CVSS con le informazioni sulle minacce RBVM non forniscono risultati ottimali. Anche dopo aver filtrato e osservato solo ciò che è sfruttabile in natura, i team di sicurezza hanno ancora troppo da gestire perché l'elenco è lungo e ingestibile. E solo perché un CVE non ha un exploit oggi non significa che non ne avrà uno la prossima settimana.

In risposta, le aziende hanno aggiunto l'IA predittiva del rischio, che può aiutare gli utenti a capire se un CVE potrebbe essere sfruttato in futuro. Questo non è ancora abbastanza e porta a troppi problemi da risolvere. Migliaia di vulnerabilità mostreranno ancora di avere un exploit, ma molte avranno altre serie di condizioni che devono essere soddisfatte per sfruttare effettivamente il problema.

Ad esempio, con Log4j, è necessario identificare i seguenti parametri:

• Esiste la libreria vulnerabile Log4j?
• È caricato da un'applicazione Java in esecuzione?
• La ricerca JNDI è abilitata?
• Java è in ascolto di connessioni remote ed esiste una connessione per altre macchine?

Se le condizioni e i parametri non sono soddisfatti, la vulnerabilità non è critica e non dovrebbe essere prioritaria. E anche se una vulnerabilità potrebbe essere sfruttabile su una macchina, e allora? Quella macchina è estremamente critica o forse non è collegata ad alcuna risorsa critica o sensibile?

È anche possibile che la macchina non sia importante ma può consentire a un utente malintenzionato di continuare verso risorse critiche in modi più furtivi. In altre parole, il contesto è fondamentale: questa vulnerabilità è su un potenziale percorso di attacco alla risorsa critica? È sufficiente eliminare una vulnerabilità in un punto di strozzatura (un'intersezione di più percorsi di attacco) per impedire al percorso di attacco di raggiungere una risorsa critica?

I team di sicurezza odiano i processi di vulnerabilità e le loro soluzioni, perché ci sono sempre più vulnerabilità: nessuno potrà mai cancellare completamente la lavagna. Ma se possono concentrarsi su ciò che può creare danno ad un bene critico, possono capire meglio da dove cominciare.

Lotta contro le vulnerabilità di Log4j

La buona notizia è che una corretta gestione delle vulnerabilità può aiutare a ridurre e correggere l'esposizione agli attacchi incentrati su Log4j identificando dove esiste il rischio di potenziale sfruttamento.

La gestione delle vulnerabilità è un aspetto importante della sicurezza informatica ed è necessaria per garantire la sicurezza e l'integrità dei sistemi e dei dati. Tuttavia, non è un processo perfetto e le vulnerabilità possono ancora essere presenti nei sistemi nonostante i migliori sforzi per identificarle e mitigarle. È importante rivedere e aggiornare regolarmente i processi e le strategie di gestione delle vulnerabilità per garantire che siano efficaci e che le vulnerabilità vengano affrontate in modo tempestivo.

Il focus della gestione delle vulnerabilità non dovrebbe essere solo sulle vulnerabilità stesse, ma anche sul potenziale rischio di sfruttamento. È importante identificare i punti in cui un utente malintenzionato potrebbe aver ottenuto l'accesso alla rete, nonché i percorsi che potrebbe intraprendere per compromettere le risorse critiche. Il modo più efficiente ed economico per mitigare i rischi di una particolare vulnerabilità è identificare le connessioni tra vulnerabilità, configurazioni errate e comportamento degli utenti che potrebbero essere sfruttate da un utente malintenzionato e affrontare in modo proattivo questi problemi prima che la vulnerabilità venga sfruttata. Questo può aiutare a interrompere l'attacco e prevenire danni al sistema.

Dovresti anche fare quanto segue:

• Patch: Identifica tutti i tuoi prodotti vulnerabili a Log4j. Questo può essere fatto manualmente o utilizzando scanner open source. Se viene rilasciata una patch pertinente per uno dei tuoi prodotti vulnerabili, correggi il sistema il prima possibile.
• Soluzione: Nelle versioni Log4j 2.10.0 e successive, nella riga Java CMD, impostare quanto segue: log4j2.formatMsgNoLookups=true
• Bloccare: Se possibile, aggiungi una regola al firewall dell'applicazione Web per bloccare: "jndi:"

La sicurezza perfetta è un'impresa irraggiungibile, quindi non ha senso rendere perfetto il nemico del bene. Concentrati invece sulla definizione delle priorità e sul blocco di potenziali percorsi di attacco che migliorano continuamente il livello di sicurezza. Identificare ed essere realistici su ciò che è effettivamente vulnerabile rispetto a ciò che è sfruttabile può aiutare a farlo, poiché consentirà la capacità di incanalare strategicamente le risorse verso le aree critiche che contano di più.

• Distribuzione di contenuti basati su SEO e PR. Ricevi amplificazione oggi.
• Platoblockchain. Web3 Metaverse Intelligence. Conoscenza amplificata. Accedi qui.
• Fonte: https://www.darkreading.com/attacks-breaches/log4j-vulnerabilities-are-here-to-stay-are-you-prepared-