Blocca la vulnerabilità della libreria Java Apache Log4j con un'architettura zero trust

Partecipa al nostro webinar di mercoledì 15 dicembre, in cui gli esperti di Zscaler ThreatLabZ forniranno indicazioni sulle ultime novità relative alla vulnerabilità Apache CVE-2021-44228 e sulle strategie da adottare per mitigare l'impatto delle vulnerabilità future.

Recently, a zero-day vulnerability (CVE-2021-44228) was discovered in the popular Apache Log4j logging library, which could allow an attacker full remote code execution. There is evidence that this vulnerability is being exploited in the wild. This logging library is commonly used by enterprise apps and cloud services, with many enterprise deployments supporting private apps. Apache has since released a security update, and provided recommended configurations for earlier versions that mitigates the vulnerability's impact, and we strongly encourage all IT admins to update their software immediately if you haven’t already done so.

Zscaler ha confermato che la vulnerabilità CVE-2021-44228 non ha avuto alcun impatto sui suoi servizi. Per ulteriori dettagli tecnici su questa vulnerabilità, è possibile leggere questo post di ThreatLabZ. Se temi di aver subito danni, esegui un'analisi gratuita della superficie di attacco Internet, per verificare se hai una superficie di attacco esterna che utilizza Apache.

Data l'adozione su larga scala di Apache Struts e di altre soluzioni correlate, questa vulnerabilità potrebbe avere conseguenze per i mesi e potenzialmente per gli anni a venire, con gang di ransomware e criminali informatici che potrebbero sfruttarla e causare danni incalcolabili. Sfortunatamente, questo tipo di scoperta non è una novità e, come Heartbleed e Shellshock prima di essa, evidenzia i molti rischi presenti nel nostro mondo digitale e interconnesso.

Inoltre, se si dipende da VPN e firewall per la protezione dell'azienda, le probabilità di subire danni sono maggiori rispetto a quelle che si registrano con una vera architettura di rete zero trust. Innanzitutto, vediamo perché l'utilizzo di firewall e VPN comporta un rischio significativo quando su un'app interna viene utilizzata una versione vulnerabile di Apache:

• Le soluzioni di sicurezza di rete legacy pubblicano le app su Internet affinché gli utenti possano accedervi; in questo modo, le app sono individuabili anche dagli aggressori, i quali, utilizzando degli strumenti disponibili gratuitamente, come Shodan, possono attaccarle.
• Firewall e VPN collocano gli utenti sulla rete per consentire loro di accedere alle applicazioni. A un aggressore o a un utente compromesso basta soltanto guadagnare un punto di ingresso iniziale, che può essere ottenuto sfruttando una vulnerabilità; dopodiché, è possibile muoversi lateralmente all'interno dell'azienda e distribuire ransomware o rubare dati. L'accesso alle app non dovrebbe mai richiedere l'accesso alla rete.
• Molto è stato detto su come la pandemia abbia accelerato il nostro passaggio collettivo al lavoro ibrido, e a questo proposito bisogna sottolineare che, oltre a rappresentare dei rischi, i firewall e le VPN sono anche lenti, obsoleti e complicano l'accesso alle app private per i dipendenti in remoto. Perché quindi utilizzare tecnologie rischiose che offrono un'esperienza utente scadente?

Detto questo, quanti di voi fanno ancora uso di firewall e VPN? È giunto il momento di sviluppare un piano per i prossimi 3, 6 o 9 mesi, e questo è un processo che non può avvenire da un giorno all'altro, ma è uno dei passi più importanti per ridurre al minimo il rischio aziendale.

4 semplici passaggi per ridurre i rischi con un'architettura zero trust:

Sono tante le parole che sono state spese per descrivere i vantaggi dello zero trust rispetto agli approcci tradizionali, ma facciamo un riepilogo utilizzando la vulnerabilità di Apache come riferimento.

In questo caso, i ricercatori di Alibaba Cloud hanno scoperto una vulnerabilità 0-day, che significa che, senza un aggiornamento di sicurezza di emergenza, tutti i clienti che utilizzano una versione vulnerabile sono a rischio. Inoltre, questa vulnerabilità consente l'esecuzione completa di codice da remoto, e fornisce l'accesso completo da amministratore al servizio Apache e a tutti i dati al suo interno. Ma per sfruttare questa vulnerabilità, gli aggressori devono prima individuare l'app. Per impedire agli aggressori di riuscirci, bisogna assicurarsi di rispettare le condizioni riportate di seguito.

1. Ridurre al minimo la superficie di attacco e rendere le app invisibili: l'adozione di un'architettura zero trust, come Zero Trust Exchange di Zscaler e, in particolare, di Zscaler Private Access (ZPA), consente di rendere tutte le app interne completamente invisibili a Internet. Se nascoste dietro a una piattaforma zero trust, gli aggressori non sono in grado di individuarle e sfruttarle, e in questo modo è possibile tenere al sicuro anche le versioni vulnerabili di Apache da questa e da vulnerabilità future, un'impresa impossibile con VPN e firewall legacy.
    

2. Assicurarsi che solo gli utenti autorizzati possano accedere alle app: la sicurezza informatica è più efficace quando si basa su una difesa a più livelli, come parte di una piattaforma integrata. Oltre a rendere invisibili le app vulnerabili, Zscaler consente solo agli utenti autorizzati di accedere alle app autorizzate attraverso policy, in base all'identità immutabile dei principali fornitori, come Azure AD, Okta, Duo o Ping. Se un aggressore non è autorizzato ad accedere a un'app vulnerabile, gli verrà impedito di farlo.
   
   Qualora quest'ultimo riesca a stabilire un punto di ingresso all'interno di una rete aziendale, sfruttando la vulnerabilità di Apache o altri mezzi, tenterà inevitabilmente di avanzare muovendosi lateralmente per compromettere altri sistemi, installare ransomware ed esfiltrare i dati. È dunque necessario:
    

3. Impedire il movimento laterale con la microsegmentazione da utente ad app e da applicazione ad applicazione: ZPA separa l'accesso alle applicazioni dall'accesso alla rete, collegando direttamente gli utenti alle risorse attraverso un tunnel inverso, che non colloca mai gli utenti sulla rete. Se per accedere alle app non è necessario accedere alla rete, si previene qualsiasi potenziale diffusione laterale di un'infezione, anche nei casi in cui viene stabilito un punto di ingresso iniziale. Inoltre, Zero Trust Exchange estende la stessa policy zero trust ai carichi di lavoro su cloud pubblico attraverso Zscaler Workload Segmentation, bloccando così il movimento laterale all'interno di un data center o di un ambiente cloud. In entrambi i casi, la piattaforma Zscaler impedisce che un singolo server infetto venga utilizzato per compromettere l'intera azienda.
    
4. Ispezionare sia il traffico in entrata che quello in uscita. Visibilità e monitoraggio sono i capisaldi dello zero trust. Ispezionando tutto il traffico, sia quello criptato che non, è possibile bloccare la compromissione iniziale, e cioè la fase in cui gli aggressori tentano di ottenere l'accesso al tuo ambiente, e interrompere le attività di post-exploitation, come la comunicazione con i server di comando e controllo o l'esfiltrazione dei dati. La soluzione zero trust Zscaler Internet Access (ZIA) è dotata di entrambe queste funzionalità. La funzionalità di protezione dalle minacce avanzate di Zscaler Internet Access ispeziona sia il traffico da Internet a server, che quello da server a Internet, alla ricerca di indicatori di compromissione associati a exploit noti e contribuendo a bloccare, rilevare e mitigare gli attacchi.

Per proteggere le aziende dalle vulnerabilità 0-day non si può più fare affidamento su firewall e VPN, ma è necessario adottare una vera architettura zero trust con Zero Trust Exchange di Zscaler.

Richiedi oggi stesso una dimostrazione personalizzata di Zero Trust Exchange e inizia il tuo percorso di trasformazione.

Esegui un'analisi gratuita della superficie di attacco Internet, e scopri se hai superfici di attacco esterne che utilizzano Apache.

Partecipa al nostro webinar mercoledì 15 dicembre, per ulteriori dettagli e consigli degli esperti sulla vulnerabilità di Apache.