3. The Internet Threat Model (Modello di minaccia Internet)

3. The Internet Threat Model (Modello di minaccia Internet)

Un THREAT MODEL (modello di minaccia) descrive le capacità che si assume un attaccante possa schierare contro una risorsa. Dovrebbe contenere informazioni quali le risorse disponibili a un attaccante in termini di informazione, capacità di calcolo e controllo del sistema. Lo scopo di un modello di minaccia è duplice. Primo, vogliamo identificare le minacce di cui ci preoccupiamo. Secondo, vogliamo escludere esplicitamente dal perimetro alcune minacce. Quasi ogni sistema di sicurezza è vulnerabile a un attaccante sufficientemente determinato e dotato di risorse.

L’ambiente Internet ha un modello di minaccia abbastanza ben compreso. In generale, assumiamo che i sistemi finali che partecipano a uno scambio di protocollo non siano stati essi stessi compromessi. Proteggersi da un attacco quando uno dei sistemi finali è stato compromesso è straordinariamente difficile. È tuttavia possibile progettare protocolli che riducano al minimo l’entità del danno in tali circostanze.

Per contrasto, assumiamo che l’attaccante abbia un controllo quasi completo del canale di comunicazione sul quale i sistemi finali comunicano. Ciò significa che l’attaccante può leggere qualsiasi PDU (Protocol Data Unit, unità dati di protocollo) sulla rete e rimuovere, modificare o iniettare in modo non rilevabile pacchetti falsificati sul cavo. Ciò include la capacità di generare pacchetti che sembrano provenire da una macchina attendibile. Pertanto, anche se il sistema finale con cui desiderate comunicare è di per sé sicuro, l’ambiente Internet non fornisce alcuna garanzia che i pacchetti che dichiarano di provenire da quel sistema lo siano in effetti.

È importante rendersi conto che il significato di una PDU è diverso a livelli diversi. A livello IP, una PDU significa un pacchetto IP. A livello TCP, significa un segmento TCP. A livello applicativo, significa qualche tipo di PDU applicativa. Ad esempio, a livello di posta elettronica può significare un messaggio RFC 822 o un singolo comando SMTP. A livello HTTP, può significare una richiesta o una risposta.

3.1. Limited Threat Models (Modelli di minaccia limitati)

Come abbiamo detto, un attaccante dotato di risorse e determinato può controllare l’intero canale di comunicazione. Tuttavia, un gran numero di attacchi può essere montato da un attaccante con minori risorse. Vari attacchi noti al momento possono essere montati da un attaccante con controllo limitato della rete. Ad esempio, gli attacchi di sniffing delle password possono essere montati da un attaccante che può solo leggere pacchetti arbitrari. Ciò è in genere indicato come ATTACCO PASSIVO (PASSIVE ATTACK) [INTAUTH].

Per contrasto, l’attacco di indovinare il numero di sequenza di Morris [SEQNUM] può essere montato da un attaccante che può scrivere ma non leggere pacchetti arbitrari. Qualsiasi attacco che richiede all’attaccante di scrivere sulla rete è noto come ATTACCO ATTIVO (ACTIVE ATTACK).

Pertanto, un modo utile di organizzare gli attacchi è dividerli in base alle capacità richieste per montare l’attacco. Il resto di questa sezione descrive queste categorie e fornisce alcuni esempi di ciascuna categoria.

3.2. Passive Attacks (Attacchi passivi)

In un attacco passivo, l’attaccante legge i pacchetti dalla rete ma non li scrive. Il modo più semplice per montare tale attacco è semplicemente trovarsi sulla stessa LAN della vittima. Nelle configurazioni LAN più comuni, inclusi Ethernet, 802.3 e FDDI, qualsiasi macchina sul cavo può leggere tutto il traffico destinato a qualsiasi altra macchina sulla stessa LAN. Si noti che gli hub commutati rendono questo tipo di sniffing sostanzialmente più difficile, poiché il traffico destinato a una macchina va solo al segmento di rete su cui si trova quella macchina.

Allo stesso modo, un attaccante che ha il controllo di un host nel percorso di comunicazione tra due macchine vittime è in grado di montare un attacco passivo sulle loro comunicazioni. È anche possibile compromettere l’infrastruttura di instradamento per organizzare specificamente che il traffico passi attraverso una macchina compromessa. Ciò può coinvolgere un attacco attivo all’infrastruttura di instradamento per facilitare un attacco passivo su una macchina vittima.

I canali di comunicazione wireless meritano considerazione speciale, soprattutto con la recente e crescente popolarità delle LAN wireless, come quelle che usano 802.11. Poiché i dati sono semplicemente trasmessi su frequenze radio ben note, l’attaccante deve solo essere in grado di ricevere quelle trasmissioni. Tali canali sono particolarmente vulnerabili agli attacchi passivi. Sebbene molti di questi canali includano protezione crittografica, spesso è di qualità così scarsa da essere quasi inutile [WEP].

In generale, l’obiettivo di un attacco passivo è ottenere informazioni che mittente e destinatario preferirebbero mantenere private. Queste informazioni private possono includere credenziali utili nel mondo elettronico e/o password o credenziali utili nel mondo esterno, come informazioni commerciali riservate.

3.2.1. Confidentiality Violations (Violazioni della riservatezza)

L’esempio classico di attacco passivo è intercettare dal cavo dati intrinsecamente privati. Ad esempio, nonostante la larga disponibilità di SSL, molte transazioni con carta di credito attraversano ancora Internet in chiaro. Un attaccante potrebbe intercettare tale messaggio e recuperare il numero della carta di credito, che può poi essere usato per transazioni fraudolente. Inoltre, informazioni commerciali riservate sono routinariamente trasmesse sulla rete in chiaro nella posta elettronica.

3.2.2. Password Sniffing (Intercettazione di password)

Un altro esempio di attacco passivo è l’INTERCETTAZIONE DI PASSWORD (PASSWORD SNIFFING). L’intercettazione di password è mirata all’ottenimento di uso non autorizzato delle risorse. Molti protocolli, inclusi [TELNET], [POP] e [NNTP], usano una password condivisa per autenticare il client al server. Spesso, questa password è trasmessa dal client al server in chiaro sul canale di comunicazione. Un attaccante che può leggere questo traffico può quindi catturare la password e RIPRODURLA (REPLAY). In altre parole, l’attaccante può avviare una connessione al server e fingersi il client e accedere usando la password catturata.

Si noti che sebbene la fase di login dell’attacco sia attiva, la fase effettiva di cattura della password è passiva. Inoltre, a meno che il server non controlli l’indirizzo di origine delle connessioni, la fase di login non richiede alcun controllo speciale della rete.

3.2.3. Offline Cryptographic Attacks (Attacchi crittografici offline)

Molti protocolli crittografici sono soggetti ad ATTACCHI OFFLINE (OFFLINE ATTACKS). In tale protocollo, l’attaccante recupera dati che sono stati elaborati usando la chiave segreta della vittima e poi monta un attacco crittanalitico su quella chiave. Le password costituiscono un bersaglio particolarmente vulnerabile perché tipicamente hanno entropia bassa. Vari protocolli popolari di challenge-response basati su password sono vulnerabili ad ATTACCO A DIZIONARIO (DICTIONARY ATTACK). L’attaccante cattura una coppia challenge-response e poi prova voci da un elenco di parole comuni (come un file dizionario) finché non trova una password che produce la risposta corretta.

Un attacco simile può essere montato su una rete locale quando si usa NIS. La password Unix è cifrata con una funzione unidirezionale, ma esistono strumenti per violare tali password cifrate [KLEIN]. Quando si usa NIS, la password cifrata è trasmessa sulla rete locale e un attaccante può quindi intercettarla e attaccarla.

Storicamente, è stato anche possibile sfruttare piccole vulnerabilità del sistema operativo per recuperare il file delle password con un attacco attivo. Queste vulnerabilità possono poi essere usate come trampolino per un account reale usando le suddette tecniche offline di recupero password. Così combiniamo un attacco attivo di basso livello con un attacco passivo offline.

3.3. Active Attacks (Attacchi attivi)

Quando un attacco comporta la scrittura di dati sulla rete, ci riferiamo a esso come ATTACCO ATTIVO (ACTIVE ATTACK). Quando IP è usato senza IPsec, non c’è autenticazione per l’indirizzo del mittente. Di conseguenza, è semplice per un attaccante creare un pacchetto con un indirizzo sorgente di sua scelta. Ci riferiamo a ciò come ATTACCO DI SPOOFING (SPOOFING ATTACK).

In certe circostanze, un tale pacchetto può essere filtrato dalla rete. Ad esempio, molti firewall a filtro di pacchetti scartano tutti i pacchetti con indirizzi sorgente sulla rete INTERNA che arrivano sull’interfaccia ESTERNA. Si noti, tuttavia, che ciò non fornisce protezione contro un attaccante che è dentro il firewall. In generale, i progettisti dovrebbero assumere che gli attaccanti possano falsificare pacchetti.

Tuttavia, la capacità di falsificare pacchetti non va di pari passo con la capacità di ricevere pacchetti arbitrari. In effetti, esistono attacchi attivi che comportano l’invio di pacchetti falsificati ma non la ricezione delle risposte. Ci riferiamo a questi come ATTACCHI CIECI (BLIND ATTACKS).

Si noti che non tutti gli attacchi attivi richiedono la falsificazione degli indirizzi. Ad esempio, l’attacco di negazione del servizio TCP SYN [TCPSYN] può essere montato con successo senza mascherare l’indirizzo del mittente. Tuttavia, è pratica comune mascherare il proprio indirizzo per nascondere la propria identità se un attacco viene scoperto.

Ogni protocollo è suscettibile ad attacchi attivi specifici, ma l’esperienza mostra che vari schemi comuni di attacco possono essere adattati a un dato protocollo. Le sezioni seguenti descrivono vari di questi schemi e danno esempi specifici applicati a protocolli noti.

3.3.1. Replay Attacks (Attacchi di replay)

In un ATTACCO DI REPLAY (REPLAY ATTACK), l’attaccante registra una sequenza di messaggi dal cavo e li riproduce alla parte che li aveva originariamente ricevuti. Si noti che l’attaccante non deve essere in grado di comprendere i messaggi. Deve solo catturarli e ritrasmetterli.

Ad esempio, considerate il caso in cui un messaggio S/MIME è usato per richiedere un servizio, come un acquisto con carta di credito o un’operazione borsistica. Un attaccante potrebbe desiderare che il servizio sia eseguito due volte, se solo per creare disagio alla vittima. Potrebbe catturare il messaggio e riprodurlo, anche se non può leggerlo, causando l’esecuzione della transazione due volte.

3.3.2. Message Insertion (Inserimento di messaggi)

In un attacco di INSERIMENTO DI MESSAGGIO (MESSAGE INSERTION), l’attaccante falsifica un messaggio con un insieme scelto di proprietà e lo inietta nella rete. Spesso questo messaggio avrà un indirizzo sorgente falsificato per mascherare l’identità dell’attaccante.

Ad esempio, un attacco di negazione del servizio può essere montato inserendo una serie di pacchetti TCP SYN spuri diretti verso l’host bersaglio. L’host bersaglio risponde con il proprio SYN e alloca strutture dati del kernel per la nuova connessione. L’attaccante non completa mai il handshake a tre vie, quindi gli endpoint di connessione allocati restano lì occupando memoria del kernel. Le implementazioni tipiche dello stack TCP consentono solo un numero limitato di connessioni in questo stato "semi-aperto" e quando questo limite è raggiunto, non possono essere avviate altre connessioni, nemmeno da host legittimi. Si noti che questo attacco è un attacco cieco, poiché l’attaccante non deve elaborare i SYN della vittima.

3.3.3. Message Deletion (Cancellazione di messaggi)

In un attacco di CANCELLAZIONE DI MESSAGGIO (MESSAGE DELETION), l’attaccante rimuove un messaggio dal cavo. L’attacco di indovinare il numero di sequenza di Morris [SEQNUM] spesso richiede che sia eseguito un attacco di cancellazione di messaggio con successo. In questo attacco cieco, l’host il cui indirizzo viene falsificato riceverà un pacchetto TCP SYN spurio dall’host attaccato. La ricezione di questo SYN genera un RST, che abbatterebbe la connessione illegittima. Per impedire a questo host di inviare un RST così che l’attacco possa essere portato a termine con successo, Morris descrive di sommergere questo host per creare overflow di coda tali che il pacchetto SYN sia perso e quindi mai a cui rispondere.

3.3.4. Message Modification (Modifica di messaggi)

In un attacco di MODIFICA DI MESSAGGIO (MESSAGE MODIFICATION), l’attaccante rimuove un messaggio dal cavo, lo modifica e lo reinietta nella rete. Questo tipo di attacco è particolarmente utile se l’attaccante vuole inviare parte dei dati nel messaggio ma anche cambiarne parte.

Considerate il caso in cui l’attaccante vuole attaccare un ordine di merci effettuato su Internet. Non ha il numero di carta di credito della vittima, quindi aspetta che la vittima piazzi l’ordine e poi sostituisce l’indirizzo di consegna (e possibilmente la descrizione delle merci) con il proprio. Si noti che questo attacco particolare è noto come attacco CUT-AND-PASTE (taglia-e-incolla), poiché l’attaccante taglia il numero di carta di credito dal messaggio originale e lo incolla nel nuovo messaggio.

Un altro esempio interessante di attacco taglia-e-incolla è fornito da [IPSPPROB]. Se IPsec ESP è usato senza alcun MAC, è possibile per l’attaccante leggere traffico cifrato per una vittima sulla stessa macchina. L’attaccante attacca un’intestazione IP corrispondente a una porta che controlla al pacchetto IP cifrato. Quando il pacchetto è ricevuto dall’host, sarà automaticamente decifrato e inoltrato alla porta dell’attaccante. Tecniche simili possono essere usate per montare un attacco di dirottamento di sessione (session hijacking). Entrambi questi attacchi possono essere evitati usando sempre l’autenticazione dei messaggi quando si usa la crittografia. Si noti che questo attacco funziona solo se (1) non è usato alcun controllo MAC, poiché questo attacco genera pacchetti danneggiati (2) è usata una SA host-to-host, poiché una SA user-to-user risulterebbe in un’incoerenza tra la porta associata alla SA e la porta di destinazione. Se la macchina ricevente è single-user, questo attacco è impraticabile.

3.3.5. Man-In-The-Middle (Uomo nel mezzo)

Un attacco MAN-IN-THE-MIDDLE (uomo nel mezzo) combina le tecniche sopra in una forma speciale: l’attaccante soverte il flusso di comunicazione per fingersi il mittente verso il destinatario e il destinatario verso il mittente:

Cosa pensano Alice e Bob: Alice <----------------------------------------------> Bob

Cosa sta succedendo: Alice <----------------> Attacker <----------------> Bob

Questo differisce fondamentalmente dalle forme di attacco sopra perché attacca l’identità delle parti comunicanti, piuttosto che il flusso di dati stesso. Di conseguenza, molte tecniche che forniscono integrità del flusso di comunicazione sono insufficienti a proteggere dagli attacchi man-in-the-middle.

Gli attacchi man-in-the-middle sono possibili ogni volta che a un protocollo manca l’AUTENTICAZIONE TRA ENTITÀ PARI (PEER ENTITY AUTHENTICATION). Ad esempio, se un attaccante può dirottare la connessione TCP del client durante il handshake TCP (forse rispondendo al SYN del client prima del server), allora l’attaccante può aprire un’altra connessione al server e iniziare un attacco man-in-the-middle. È anche banale montare attacchi man-in-the-middle su reti locali tramite ARP spoofing: l’attaccante falsifica un ARP con l’indirizzo IP della vittima e il proprio indirizzo MAC. Strumenti per montare questo tipo di attacco sono prontamente disponibili.

Si noti che è necessario autenticare solo un lato della transazione per prevenire attacchi man-in-the-middle. In tale situazione i pari possono stabilire un’associazione in cui solo un pari è autenticato. In un tale sistema, un attaccante può avviare un’associazione fingendosi il pari non autenticato ma non può trasmettere o accedere ai dati inviati su una connessione legittima. Questa è una situazione accettabile in contesti come l’e-commerce Web dove solo il server deve essere autenticato (o il client è autenticato indipendentemente tramite qualche meccanismo non crittografico come un numero di carta di credito).

3.4. Topological Issues (Questioni topologiche)

In pratica, l’assunzione che sia ugualmente facile per un attaccante leggere e generare tutti i pacchetti è falsa, poiché Internet non è completamente connessa. Ciò ha due implicazioni principali.

3.5. On-path versus off-path (Sul percorso rispetto a fuori percorso)

Affinché un datagramma sia trasmesso da un host a un altro, deve in genere attraversare un insieme di collegamenti e gateway intermedi. Tali gateway possono naturalmente leggere, modificare o rimuovere qualsiasi datagramma trasmesso lungo quel percorso. Ciò rende molto più facile montare una vasta gamma di attacchi se si è sul percorso (on-path).

Gli host fuori percorso (off-path) possono, naturalmente, trasmettere datagrammi arbitrari che sembrano provenire da qualsiasi host ma non possono necessariamente ricevere datagrammi destinati ad altri host. Pertanto, se un attacco dipende dalla capacità di ricevere dati, gli host off-path devono prima sovertire la topologia per collocarsi sul percorso. Ciò non è affatto impossibile ma non è necessariamente banale.

I progettisti di protocolli applicativi NON DEVONO assumere che tutti gli attaccanti saranno off-path. Dove possibile, i protocolli DOVREBBERO essere progettati per resistere ad attaccanti che hanno controllo completo della rete. Tuttavia, ci si attende che i progettisti diano maggior peso agli attacchi che possono essere montati da attaccanti off-path così come da quelli on-path.

3.6. Link-local (Collegamento locale)

Un caso specializzato di on-path è trovarsi sullo stesso collegamento. In alcune situazioni, è desiderabile distinguere tra host che sono sulla rete locale e quelli che non lo sono. La tecnica standard per questo è verificare il valore IP TTL [IP]. Poiché il TTL deve essere decrementato da ogni inoltro, un protocollo può richiedere che il TTL sia impostato a 255 e che tutti i ricevitori verifichino il TTL. Un ricevitore ha quindi qualche motivo di credere che i pacchetti conformi provengano dallo stesso collegamento. Si noti che questa tecnica deve essere usata con cautela in presenza di sistemi di tunneling, poiché tali sistemi possono far passare pacchetti senza decrementare il TTL.