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.

Di recente, nella popolare libreria per la gestione dei log Apache Log4j è stata trovata una vulnerabilità 0-day (CVE-2021-44228) che potrebbe consentire l'esecuzione completa di codice da remoto da parte di utenti malintenzionati. Ci sono prove che questa vulnerabilità venga di fatto sfruttata. Questa libreria per la gestione dei log viene comunemente utilizzata dalle app aziendali e dai servizi cloud, e molte distribuzioni aziendali supportano app private. Apache ha pubblicato un aggiornamento di sicurezza e ha fornito consigli su come configurare le versioni precedenti per mitigare l'impatto della vulnerabilità. Incoraggiamo tutti gli amministratori IT che non lo hanno ancora fatto, ad aggiornare immediatamente il proprio software.

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.