Vulnerabilità Heartbleed: Rischi all'interno della rete

2 maggio 2014
Oliver Tavakoli
Chief Technology Officer
Vulnerabilità Heartbleed: Rischi all'interno della rete

Si è parlato molto dell'impatto globale di Heartbleed. Prima ci sono state tutte le descrizioni di Heartbleed, la mia preferita era quella di xkcd. Poi abbiamo visto avvertire che avremmo dovuto cambiare la nostra password sui siti web pubblici. A questo è seguito un avviso secondo cui, poiché le chiavi private dei certificati potrebbero essere recuperate sfruttando Heartbleed, dovremmo cambiare le nostre password ora, aspettare che i siti web cambino i loro certificati e poi cambiare di nuovo le nostre password.

Ciò che ha ricevuto molta meno attenzione è il fatto che molti dei prodotti aziendali comuni (ad esempio, router, firewall, proxy web) all'interno della nostra infrastruttura sono anch'essi suscettibili di Heartbleed. I bollettini di Cisco, Juniper Networks e Blue Coat indicano un uso diffuso di OpenSSL, il software in cui è presente il bug Heartbleed, in questi prodotti. Anche i sistemi di controllo industriale di aziende come Siemens presentano questa vulnerabilità, di cui ha scritto recentemente Arik Hesseldahl su Re/code.net. Inoltre, a differenza dei siti web pubblici, molti dei quali sono già stati sottoposti ad aggiornamenti per risolvere il bug, la disponibilità e la distribuzione delle patch per tutti i sistemi infrastrutturali vi colpirà in modi inaspettati, tra cui la necessità di aggiornare il software a versioni più recenti di quelle che probabilmente state utilizzando, richiedendo cicli di test prima di poterlo distribuire.

Come funziona il bug Heartbleed
Come funziona il bug Heartbleed xkcd

Valutazione della vulnerabilità Heartbleed nelle reti interne

Per cominciare, se gli indirizzi IP utilizzati per la gestione di router, firewall e altri sistemi di infrastruttura sono raggiungibili da Internet senza un accesso VPN (considerato una cattiva pratica di sicurezza), dovreste essere molto preoccupati e dovreste già aver rimosso l'accesso diretto o patchato il vostro sistema. Supponendo che gli indirizzi IP di gestione siano accessibili solo dall'interno della rete, lo scenario peggiore è il seguente:

  1. Un aggressore si introduce nella rete tramite un malware o un'altra forma di attacco;
  2. L'aggressore effettua una ricognizione e trova le interfacce di gestione dei sistemi dell'infrastruttura;
  3. L'attaccante sfrutta la presenza di Heartbleed in questi sistemi infrastrutturali per leggere la memoria dei sistemi, recuperando le credenziali amministrative utilizzate di recente per accedere al sistema e, eventualmente, anche la chiave privata del certificato che protegge la connessione; \
  4. L'attaccante utilizza le credenziali rubate per accedere e riconfigurare il sistema o, nel caso in cui non si tratti solo di credenziali dell'account locale, per accedere ad altre risorse non correlate.

Valutazione del rischio di vulnerabilità Heartbleed passo dopo passo

Fase 1: Assumere un compromesso

Accettateil fatto che può succedere a voi; le organizzazioni subiscono continuamente violazioni malware , quindi dobbiamo presumere che sia già successo o che possa succedere.

Fase 2: implementare una soluzione di rilevamento delle minacce

Si spera che abbiate una soluzione di sicurezza in grado di rilevare le scansioni eseguite nella fase di ricognizione di un attacco mirato. Se non ce l'avete, ve ne proponiamo una da valutare e implementare.

Fase 3: Protezione dagli exploit interni di Heartbleed

Un aggressore che si trovi all'interno della vostra rete e utilizzi Heartbleed per accedere al vostro sistema infrastrutturale è ovviamente molto preoccupante. Sarebbe fantastico se aveste una soluzione di sicurezza in grado di individuare tali attacchi all'interno della vostra rete. Se non ce l'avete, saremo lieti di fornirvene una da valutare e implementare ;-) Sebbene la maggior parte dei recenti articoli di stampa si sia concentrata sul furto di chiavi private, la perdita della chiave privata risulta essere meno minacciosa in una rete aziendale.

Per utilizzare la chiave privata, l'aggressore deve ascoltare le altre connessioni allo stesso sistema o deve essere in grado di impersonare il sistema. Ai tempi degli hub, quando l'Ethernet era davvero un mezzo condiviso, ascoltare il traffico di un'altra macchina era semplice come mettere la scheda di interfaccia di rete in modalità "promiscua". Con gli switch, invece, si vede solo il traffico trasmesso, multi-cast o destinato alla propria macchina.

Il metodo classico di impersonificazione è quello dei trucchi ARP e funziona solo sulla subnet in cui si trova l'host dell'attaccante. Se le interfacce di gestione dei sistemi si trovano su una subnet separata, spesso addirittura su una VLAN separata, l'impersonificazione ARP non funziona. Quindi, anche se l'attaccante può accedere alla chiave privata del sistema, sfruttare la disponibilità della chiave privata non è così semplice come sembrerebbe. Questo è in netto contrasto con il problema che i siti web pubblici hanno con Heartbleed: non possono presumere che il traffico non possa essere snobbato a monte e con tutti i trucchi DNS in circolazione, non possono nemmeno presumere che qualcuno non sia in grado di impersonarli con successo.

Passo 4: Gestire le credenziali e la sicurezza dell'identità

È qui che si scatena la vera ansia. Se avete seguito le migliori pratiche di sicurezza e avete integrato l'autenticazione amministrativa sui vostri sistemi di infrastruttura con un'infrastruttura standard di gestione delle identità (ad esempio, Active Directory), le credenziali rubate saranno probabilmente le chiavi del regno. Possono essere utilizzate per accedere al sistema stesso o a praticamente tutto ciò a cui possono accedere gli amministratori di sistema.

Identificazione della superficie di attacco Heartbleed nelle reti interne

Potreste applicare le patch a tutti i router, gli switch e i firewall, ma dimenticarvi di applicare le patch a una stampante in un luogo oscuro che ha la stessa integrazione di autenticazione della vostra infrastruttura più importante.

È solo questione di tempo - anzi, probabilmente sta già accadendo - prima di vedere attacchi mirati che utilizzano Heartbleed come una delle armi dell'arsenale degli aggressori per acquisire le credenziali degli account chiave e usarle per arrivare ai gioielli della corona.

In altre parole, Heartbleed è un problema tanto all'interno quanto all'esterno.

DOMANDE FREQUENTI

Che cos'è l'Heartbleed (CVE-2014-0160)?

Heartbleed è un bug di sicurezza nella libreria OpenSSL, che consente agli aggressori di leggere dati sensibili dalla memoria di un server.

Quali sono le misure da adottare per applicare una patch a Heartbleed nei sistemi interni?

Per correggere Heartbleed, le organizzazioni devono aggiornare le librerie OpenSSL all'ultima versione che risolve il bug. Inoltre, devono revocare e riemettere i certificati SSL/TLS e reimpostare le password, se necessario, per assicurarsi che non siano in uso credenziali compromesse.

In che modo gli aggressori sfruttano Heartbleed nelle reti interne?

Gli aggressori sfruttano Heartbleed inviando richieste modificate a un server vulnerabile, che risponde con dati sensibili dalla sua memoria. Questi possono includere nomi utente, password, chiavi private e altre informazioni riservate.

In che modo le soluzioni di sicurezza possono contribuire a mitigare i rischi di Heartbleed?

Le soluzioni di sicurezza come i sistemi di rilevamento delle intrusioni (IDS), i firewall e gli strumenti di gestione delle vulnerabilità possono aiutare a rilevare e bloccare gli exploit Heartbleed. Aggiornamenti e patch regolari di queste soluzioni sono essenziali per proteggersi dalle vulnerabilità note.

Ci sono stati incidenti recenti che hanno coinvolto gli exploit di Heartbleed?

Sebbene Heartbleed sia stato il più importante nel 2014, si verificano ancora incidenti occasionali quando i sistemi rimangono senza patch. Il monitoraggio regolare degli avvisi di sicurezza e dei rapporti sugli incidenti aiuta a rimanere informati sugli exploit recenti.

Come possono le organizzazioni rilevare le vulnerabilità di Heartbleed all'interno della propria rete?

Le organizzazioni possono rilevare le vulnerabilità di Heartbleed utilizzando scanner di vulnerabilità e strumenti progettati per verificare la presenza del bug Heartbleed nei loro sistemi. Sono efficaci anche le verifiche periodiche e le valutazioni automatizzate della sicurezza.

Quali sono i rischi di non affrontare Heartbleed nei sistemi interni?

Il mancato intervento su Heartbleed rende i sistemi interni vulnerabili alle violazioni dei dati, agli accessi non autorizzati e alla potenziale perdita di informazioni sensibili. Ciò può comportare perdite finanziarie, danni alla reputazione e problemi di conformità.

Quali tipi di infrastrutture sono più a rischio di Heartbleed?

I server e i dispositivi che eseguono versioni vulnerabili di OpenSSL sono i più a rischio. Si tratta di server Web, server di posta elettronica e qualsiasi dispositivo collegato in rete che utilizzi le versioni di OpenSSL interessate.

In che modo le soluzioni di sicurezza possono contribuire a mitigare i rischi di Heartbleed?

Gli impatti a lungo termine includono una maggiore consapevolezza della necessità di aggiornamenti regolari della sicurezza e di migliori pratiche di sicurezza. Le organizzazioni possono anche implementare controlli più severi e programmi di gestione delle vulnerabilità più rigorosi.

Quali sono le best practice che possono prevenire gli exploit di Heartbleed nelle reti interne?

Le migliori pratiche includono l'aggiornamento di OpenSSL, la scansione regolare delle vulnerabilità, l'implementazione di forti controlli di accesso e la formazione del personale sull'igiene della sicurezza. Sono fondamentali anche regolari controlli di sicurezza e piani di risposta agli incidenti.