Il replay attack è un attacco informatico che ha luogo quando un cyber criminale intercetta una comunicazione in transito su una rete e, quindi, procede a reinviarla o ritardarla in modo da impersonare il mittente e spingere il destinatario ad eseguire le istruzioni contenute nel messaggio.
In altri casi, consente al criminal hacker di interporsi nelle comunicazioni tra un server ed un client oppure tra due endpoint per impossessarsi di una credenziale di accesso e autenticazione ad un servizio e riutilizzarla simulando l’identità del mittente.
Indice degli argomenti
Replay attack: la crittografia non basta a mitigarlo
Nel mondo della sicurezza informatica, quotidianamente, chi difende si deve confrontare con nuove tecniche utilizzate dagli attaccanti. Una fra le soluzioni più comuni per mettere al sicuro dati e comunicazioni è la crittografia; essa permette di proteggere sia i dati a riposo che i dati in transito (ad esempio tramite il protocollo HTTPS).
Ma cosa succede se il cyber criminale non ha bisogno di leggere il contenuto del messaggio cifrato per effettuare il proprio attacco? Su questo principio si basa il replay attack.
Per comprendere appieno il funzionamento del replay attack è utile analizzare la classificazione che ne fa OWASP, l’organizzazione non profit che lavora per rendere il software più sicuro e rilascia linee guida e raccomandazioni per verificarne lo stato.
Nello specifico, lo standard de facto per valutare i rischi delle applicazioni è OWASP Top 10; un report steso da un team di esperti di sicurezza a livello globale e aggiornato ad intervalli regolari che sottolinea le principali criticità per la sicurezza delle applicazioni, focalizzandosi sui 10 rischi più importanti.
Il replay attack viene catalogato alla voce:
- A8:2017 – Insecure Deserialization – Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.
L’Insecure deserialization si verifica quando dati non “trustati” sono utilizzati per compromettere un applicazione, generando Denial of Service o permettendo l’esecuzione di codice arbitrario.
Per capire esattamente cosa sia la deserialization, possiamo definirla come l’opposto della serialization, dove essa è il processo di convertire un oggetto in un formato che possa essere archiviato o trasmesso tramite un messaggio, cioè la conversione di una serie di dati binari in una stringa ASCII.
La deserialization è, di conseguenza, il processo che consente di convertire un dato serializzato proveniente da una comunicazione in un oggetto. La safe deserialization è una pratica utilizzata comunemente nello sviluppo dei software. Il problema sorge, ovviamente, quando si procede con la deserializzazione di un input utente non trustato.
Quando l’input può essere modificato dall’utente, ci si trova di fronte ad una deserialization vulnerability, tipicamente sfruttata preparando un payload che contenga RCE (Remote Code Execution) per l’elaboratore bersaglio dell’attacco.
Esempi di insecure deserialization sono i seguenti:
- CVE-2019-6503 – RCE durante la deserializzazione lato server in Chatopera cosin v.3.10.0, tramite upload di un file malevolo preparato ad hoc;
- CVE-2019-9875 – RCE tramite deserializzazione di dati non trustati nel modulo anti CSRF in Sitecore fino alla versione 9.1;
- CVE-2017-9805 – RCE con target qualsiasi server che utilizzi un’applicazione costruita utilizzando il framework Struts e il plugin REST. Questa vulnerabilità è assurta alle cronache nel 2017, sfruttata da cyber criminali durante l’attacco a Equifax, che ha comportato un data breach coinvolgente le informazioni personali di 147,7 milioni di cittadini statunitensi.
I replay attack sono inoltre categorizzati come nella Common Weakness Enumeration come CWE-294 – Authentication Bypass by Capture-replay. Vengono descritti da Mitre come:
- un capture – replay flaw esiste quando il design del software permette ad un attaccante di sniffare il traffico di rete e bypassare l’autenticazione, riproducendolo sul server target con lo stesso effetto del messaggio originale;
- gli attacchi capture – replay sono comuni e possono essere difficili da contenere senza l’utilizzo della crittografia. Sono un sottoinsieme di network injection attacks che si basano sull’osservazione di comandi precedentemente inviati, li modificano se necessario, e li inviano nuovamente al server target.
Le difficoltà di contenimento di un replay attack
La difficoltà di contenimento di questo tipo di attacchi è da ricercarsi nel fatto che l’attaccante non ha bisogno di decifrare il dato in transito per replicarlo ed inviarlo al target.
Supponiamo che il cyber criminale riesca ad intercettare una serie di password con hash su una comunicazione non cifrata client/server; potrebbe procedere, in seconda istanza, inviando direttamente l’hash sniffato al server di autenticazione, ottenendo l’accesso consentito da tale credenziale.
È importante osservare, inoltre, che i replay attack non sono limitati solamente a quanto riguarda internet. Dove è presente una comunicazione tra due endpoint, è generalmente possibile tentare un tale tipo di attacco. Pensiamo, ad esempio, a quando apriamo la nostra automobile da qualche metro di distanza: un cyber criminale potrebbe intercettare il dato inviato dal radiocomando e replicarlo, quindi, per sbloccare l’automezzo in un secondo momento.
Paul Syverson, nel whitepaper “A Taxonomy of Replay Attacks”, propone una struttura per classificare gli attacchi replay, sottolineando il fatto che sia necessario considerare sia l’origine del messaggio che la destinazione, in quanto entrambe possono essere sfruttate.
La classificazione in base all’origine del messaggio si basa sul processo in corso, ed è possibile classificare attacchi esterni o interni al processo.
Gli attacchi esterni sfruttano gli elementi raccolti durante una comunicazione nell’esecuzione di una comunicazione differente. Un esempio è, richiamandoci a quanto detto in precedenza, il caso dello sniffing della comunicazione tra un’automobile e il radiocomando per sbloccare le portiere; una volta ottenuto il messaggio di interesse, è possibile sfruttarlo in un secondo momento per lo scopo prefissato.
Gli attacchi interni utilizzano, invece, elementi raccolti durante la comunicazione per modificare il messaggio che verrà recapitato al destinatario. Si tratta del tipico attacco Man in the Middle, in cui un attaccante “dirotta” il traffico tra due elaboratori attraverso il proprio sistema, in modo da poter alterare ed eventualmente accedere alle informazioni scambiate.
La classificazione in base alla destinazione del messaggio si focalizza sul destinatario del messaggio, in base a quale fosse l’originario destinatario.
Nello specifico abbiamo deflections (deviazioni), in cui la comunicazione originale viene diretta dall’attaccante ad un destinatario diverso rispetto a quello definito da chi ha iniziato la trasmissione. Si sottocategorizzano in reflections (riflessioni), in cui il messaggio è rispedito al mittente, e deflections verso un destinatario non incluso nella catena di comunicazione originaria.
Abbiamo quindi i cosiddetti straight replays, in cui il destinatario definito dal mittente riceve la comunicazione dopo che la stessa è stata intercettata, e modificata, dall’attaccante.
Mitigare il rischio di un attacco
Visto che i replay attack costituiscono un serio rischio per la sicurezza, cosa può fare direttamente l’utente per mitigarli o impedirli? La risposta è: nulla. Solamente i produttori di software possono fare sì che questo tipo di attacco non abbia successo.
Quali misure dovrebbero quindi mettere in campo?
L’unica architettura che possa fornire qualche tipo di garanzia è quella che non permette di accettare oggetti serializzati da fonti non attendibili.
Se ciò non fosse possibile, OWASP raccomanda di:
- implementare controlli di integrità come digital signatures;
- applicare controlli rigorosi durante la deserializzazione e prima della creazione di un oggetto, in base alle caratteristiche del software;
- Isolare ed eseguire codice che esegue deserializzazione in ambienti con privilegi limitati;
- registrare le eccezioni e gli errori durante le procedure di deserializzazione, come ad esempio quando l’incoming type non è del tipo previsto;
- limitazione e monitoraggio alla connettività di rete in entrata ed in uscita per i containers o il server che eseguono deserializzazione;
- monitoraggio e alert nel caso in cui un utente esegua costantemente deserializzazione.
