È di pochi giorni fa l'allarme lanciato da US-CERT (United States Computer Emergency Readiness Team) riguardo a un tipo di attacco attivo contro sistemi informatici basati su Linux; tale attacco sfrutta chiavi SSH compromesse per accedere a una macchina. Successivamente mediante l'uso di un exploit locale si guadagna i privilegi di superutente e si installa un rootkit denominato Phalanx2, il cui scopo è ricercare altre chiavi SSH da inviare all'attaccante, che potrà utilizzarle per accedere a nuovi sistemi.
SSH e la crittografia asimmetrica
Per poter comprendere come funziona questo attacco e quali sistemi siano realmente vulnerabili ad esso, è necessaria qualche piccola premessa che spieghi lo scopo di SSH e l'utilizzo della crittografica asimmetrica, o crittografia a chiave pubblica, per l'autenticazione a server SSH.
SSH (Secure SHell) è un protocollo pensato per risolvere il problema delle trasmissioni in chiaro durante la fase di autenticazione e trasferimento dati tra due host; fornisce servizi di shell remota e trasmissione dati esattamente come altri protocolli meno sicuri (telnet, ftp, ...) ma, a differenza di questi, garantisce confidenzialità offrendo un tunnel cifrato mediante un algoritmo crittografico. In pratica, se tutto funziona nel modo giusto, un client SSH può connettersi a un server SSH e tutti i dati scambiati fra le due macchine sono inaccessibili ad utenti non autorizzati; nello scenario più semplice, il client si autentica al server inserendo username e password, che vengono trasmessi protetti dalla crittografia e il server, dopo aver verificato le credenziali, concede o meno l'accesso. Tuttavia esistono metodi di autenticazione che non richiedono l'inserimento di una password, ma che si basano su concetti differenti: in particolare l'autenticazione a chiave pubblica fa uso della crittografia asimmetrica per consentire o negare l'accesso alle risorse protette.
La crittografia asimmetrica, contrapposta alla crittografia simmetrica, prevede l'uso di due chiavi distinte per ogni entità in gioco: una chiave pubblica e una chiave privata. Nella crittografia simmetrica vi è una sola chiave, segreta ma nota a entrambi gli attori della comunicazione, che viene utilizzata per cifrare e per decifrare il traffico; nella crittografia asimmetrica, invece, solo la chiave privata è tenuta segreta, e viene utilizzata per decrittare i dati crittati con la corrispettiva chiave pubblica. Ogni entità è quindi dotata di una coppia di chiavi, una per cifrare e una per decifrare.
Autenticazione a chiave pubblica
Abbiamo detto che SSH supporta una modalità di autenticazione basata sulla crittografia asimmetrica, denominata autenticazione a chiave pubblica. Il concetto che viene sfruttato è quello della firma digitale: un dato crittato (firmato) con una chiave privata può essere correttamente decifrato disponendo della chiave pubblica relativa; in questo modo si può verificare la firma, ossia la legittimità della sorgente dati, essendo che solo l'entità in questione può essere in possesso della propria chiave privata, e quindi solo essa può avere cifrato quel dato. La firma digitale non utilizza quindi la crittografia asimmetrica per proteggere in modo sicuro il traffico, bensì per autenticare un soggetto.
L'autenticazione a chiave pubblica nel contesto di SSH funziona nel seguente modo: un server SSH dispone di un file con un elenco di chiavi pubbliche relativo ad altrettanti client che devono avere libero accesso alla macchina; ognuno di questi client, nel momento in cui vuole collegarsi al server di cui sopra, utilizzerà la propria chiave privata per autenticarsi mediante firma digitale; il server controllerà la legittimità del client verificando la firma con la chiave pubblica recuperata dal file descritto in precedenza.
Debian e le chiavi compromesse
Ora dovrebbe essere abbastanza chiaro cosa si intende con chiave SSH: un numero intero molto grande che viene utilizzato per cifrare o decifrare dati. Queste chiavi vengono create attraverso degli algoritmi denominati pseudo-random number generator (PRNG), che creano le chiavi dopo un processo di inizializzazione che fa uso di un seme pseudo-casuale (cioè creato attraverso un algoritmo deterministico, ma con le medesime proprietà di un numero casuale); in pratica, gran parte della forza delle chiavi crittografiche dipende da questa proprietà di casualità del seme. Cosa succederebbe se la casualità venisse a mancare per una debolezza algoritmica? Semplicemente, le chiavi generate non sarebbero più da considerarsi sicure, perchè facilmente duplicabili, annullando di fatto la loro utilità in termini di garanzia di segretezza o autenticità.
Un problema di questo tipo si è avuto nel codice di OpenSSL nella sua versione per le distribuzioni Linux Debian e derivate (tra cui Ubuntu, quindi): una modifica effettuata a settembre 2006 ha indebolito l'algoritmo PRNG di OpenSSL, utilizzato per creare varie chiavi crittografiche, tra cui quelle di SSH. Tale modifica ha portato ad utilizzare solo l'identificativo di processo (pid) come valore "casuale" per la generazione del seme; dato che sui sistemi Linux, di default, il massimo valore del pid è 32768, il numero di valori utilizzati per il seme del PRNG è relativamente molto piccolo. Dati architettura, tipo e dimensione della chiave SSH da creare, infatti, vi saranno solo 32767 possibili risultati, ricreabili deterministicamente partendo dai diversi valori del pid; creare tutte le chiavi possibili, anche se si trattasse di chiavi di grandi dimensioni (1024, 2048, 4096 bit) richiederebbe poche ore, annullando quindi tutta la sicurezza offerta da una crittografia che sfruttasse queste stesse chiavi.
Il 13 maggio 2008 sul sito Debian appare un advisory che avverte della questione, e invita ad aggiornare il pacchetto OpenSSL, il cui aggiornamento corregge ovviamente il problema; tuttavia, tutte le chiavi generate su sistemi Debian-based con le versioni di OpenSSL dalla 0.9.8c-1 alla 0.9.8c-4etch3 (per etch) o alla 0.9.8g-9 (per sid e lenny), ossia tra settembre 2006 e maggio 2008, sono considerate compromesse. Il giorno successivo un altro advisory avverte che viene messo a disposizione dell'utenza un tool per controllare le proprie chiavi SSH e correggere definitivamente i problemi che possono essere derivati dal difetto di OpenSSL, rigenerando le chiavi compromesse e negando l'accesso a sistemi che ne fanno uso per autenticarsi.
Tuttavia, cosa succede nei sistemi che non hanno seguito questo aggiornamento? Server SSH che mantengono, nel proprio file di chiavi pubbliche autorizzate, alcune chiavi compromesse? Ovviamente tali server sono da considerarsi vulnerabili, perchè chiunque abbia generato le chiavi deboli di cui abbiamo discusso finora può autenticarsi correttamente mediante autenticazione a chiave pubblica. Questo è esattamente il problema sollevato da US-CERT.
Il problema e la sua soluzione
Dunque, le macchine Linux (qualunque distribuzione) che offrono un servizio di server SSH all'esterno configurato con l'autenticazione a chiave pubblica e che non sono state aggiornate individuando chiavi compromesse e eliminandole o sostituendole con nuove chiavi sicure, sono vulnerabili ad attacchi basati sui principi descritti precedentemente in questo articolo: chiavi private fasulle possono essere create e utilizzate per autenticarsi a server SSH che danno accesso a soggetti con chiave pubblica compromessa. Una volta ottenuto l'accesso, chiaramente la parte più difficile del lavoro, è possibile guadagnare i privilegi di root sfruttando un exploit locale; nel caso specifico sollevato da US-CERT, l'azione successiva è installare un rootkit denominato phalanx2, il cui scopo è recuperare altre chiavi SSH dalla macchina ed inviarle all'attaccante, che potrà quindi sfruttarle per tentare l'accesso ad altri sistemi similmente configurati.
Come capire se la propria macchina ha subito questo attacco, ossia, come rilevare la presenza di phalanx2 nel proprio sistema? Il rootkit in questione crea una directory in /etc chiamata khubd.p2 non visibile listando i file con un semplice ls, ma a cui si può accedere tramite il classico comando cd; inoltre possono essere presenti file relativi all'attacco in /dev/shm.
Come agire se si è subito un attacco di questo tipo? Disabilitare l'autenticazione a chiave pubblica, verificare la presenza di chiavi compromesse e avvertire i possessori delle chiavi che è avvenuta una possibile compromissione sono le tre azioni fondamentali indicate da US-CERT.
Conclusioni
Il problema sollevato da US-CERT non deve far scattare allarmismi sulla vulnerabilità dei sistemi informatici basati su Linux: la vulnerabilità sfruttata in questo tipo di attacco è infatti limitata a server SSH configurati per accettare autenticazione a chiave pubblica automatizzata, e l'attacco in sè richiede la conoscenza di almeno una chiave privata impropria per essere portato a termine. Se tale chiave venisse rubata (come supposto da US-CERT), sarebbe chiaramente una violazione del paradigma della crittografia asimmetrica, in cui la chiave privata deve rimanere segreta - in pratica sarebbe come gridare allo scandalo da vulnerabilità tecnica se qualcuno rubasse una password e così facendo riuscisse ad accedere a un sistema protetto da password; se tale chiave è compromessa, cioè è predicibile in quanto generata da OpenSSL su un sistema Debian-based tra settembre 2006 e maggio 2008, il problema diventa semplicemente una questione di mantenere aggiornato il sistema, dato che da maggio 2008 stesso sono disponibili tool per individuare chiavi compromesse e, ovviamente, generarne di nuove non compromesse. Insomma, vale sempre il detto "La sicurezza è un processo, non un prodotto".
