Replay Attack - Timestamp, Nonce e Kerberos#
Un Replay Attack avviene quando un attaccante cattura un messaggio autenticato valido (token JWT, pacchetto Kerberos, credenziali di rete) e lo ritrasmette identico verso il server per ottenere lo stesso accesso, senza dover decifrare o modificare nulla. Il principio e' semplice: se il server non ha modo di distinguere il messaggio originale da una copia, accettera' entrambi.
Meccanismo dell'attacco#
Il Replay Attack non richiede di decifrare il messaggio intercettato: il server accetta il pacchetto perche' la firma o il token al suo interno e' autentico. E' la versione digitale di registrare il codice di un citofono e riproporlo per aprire il cancello.
Il termine "replay" arriva dal mondo audio/video: come premere Play su un registratore, l'attaccante riproduce esattamente la stessa comunicazione. In football americano si chiama "instant replay" la moviola che ritrasmette l'azione identica. In security: l'attaccante ha registrato il pacchetto di autenticazione e lo "ritrasmette" al server come se lo stesse mandando in quel momento.
Variante: credential replay -- le credenziali catturate vengono riutilizzate per un nuovo login. Diverso dal Session Hijacking: nel replay non si ruba una sessione gia' attiva, si riusa un messaggio intero per avviarne una nuova.
Scenario con Kerberos: l'attaccante cattura un TGT (Ticket Granting Ticket) -- un blob cifrato con firma, timestamp e identita' dell'utente. Non lo decifra. Lo rimanda al Key Distribution Center tale e quale. Senza timestamp di scadenza, il KDC verificherebbe solo la firma -- valida -- e concederebbe l'accesso. Il timestamp previene esattamente questo.
Difese#
Le difese al Replay Attack si basano tutte sullo stesso principio: rendere ogni messaggio unico e verificabilmente recente.
Timestamp -- ogni messaggio include l'ora di creazione. Se il server riceve un messaggio con timestamp vecchio di piu' di X secondi (tipicamente 5 minuti), lo rifiuta. Un messaggio intercettato ieri non potra' mai essere ritrasmesso con successo.
Nonce (Number Used Once) -- token monouso generato dal server e incluso nella richiesta. Il server tiene un registro dei nonce gia' utilizzati: una seconda richiesta con lo stesso nonce viene scartata immediatamente, indipendentemente dall'eta' del messaggio.
Sequence Number -- numeri progressivi su ogni pacchetto di sessione. Un pacchetto con numero gia' visto o fuori sequenza viene scartato. Questo meccanismo e' alla base di TLS e IPSec.
HMAC con Timestamp -- il timestamp viene incluso nel payload prima di calcolare l'HMAC. Poiche' il timestamp cambia ad ogni richiesta, l'HMAC stesso e' unico: un replay del messaggio originale produce lo stesso HMAC ma con un timestamp che il server riconosca come scaduto.
Kerberos e la sincronizzazione dell'orologio#
Kerberos usa timestamp come difesa primaria contro il replay. Ogni ticket include il momento di emissione e una scadenza: il KDC (Key Distribution Center) accetta solo ticket con timestamp entro 5 minuti dall'orario corrente del server.
Questa scelta ha una conseguenza operativa importante: se il clock drift tra client e KDC supera 5 minuti, i ticket vengono rifiutati e gli utenti non possono autenticarsi. Per questo NTP (Network Time Protocol) e' considerato un requisito di sicurezza in ambienti Active Directory, non solo una convenienza operativa.
Il KDC tiene anche un registro dei nonce (sequence di autenticazione) gia' visti nella finestra temporale attiva, bloccando anche replay esatti dello stesso ticket.
JWT e il ciclo di vita breve#
Un access token JWT rubato puo' essere riusato (replayed) fino alla sua scadenza naturale. Per minimizzare la finestra di vulnerabilita', i JWT hanno tipicamente una vita di 15 minuti. Il refresh token -- con vita piu' lunga -- permette di ottenere nuovi access token senza che l'utente si riautentichi ogni quarto d'ora.
La refresh token rotation chiude il vettore del replay a lungo termine: ogni volta che un refresh token viene usato per emettere un nuovo access token, il vecchio refresh token viene invalidato. Se un attaccante tenta di riusare un refresh token gia' consumato, il sistema puo' rilevare l'anomalia e revocare l'intera sessione.
| Contromisura | Come funziona | Dove si usa |
|---|---|---|
| Timestamp | rifiuta messaggi troppo vecchi | Kerberos, API HMAC |
| Nonce | token monouso, registrato lato server | OAuth, SAML, Kerberos |
| Sequence Number | scarta pacchetti gia' visti | TLS, IPSec, TCP |
| HMAC con Timestamp | firma cambia ad ogni richiesta | Webhook Stripe/GitHub |
| JWT breve + rotation | finestra di replay ridotta | API REST, SPA |
Dev parallel: In un'API PHP/Node, l'autenticazione HMAC-SHA256 delle webhook (Stripe, GitHub) include sempre un timestamp nel payload firmato. Stripe rifiuta webhook piu' vecchi di 5 minuti (
Stripe-Signatureheader contienet=<timestamp>). Questo e' esattamente il meccanismo timestamp per prevenire replay: un attaccante che cattura il webhook non puo' ritrasmettere la stessa richiesta dopo 5 minuti perche' il server la rifiutera'.
Dev parallel: JWT senza refresh token rotation: se il refresh token viene rubato, l'attaccante puo' generare nuovi access token indefinitamente -- un replay a lungo termine. La soluzione e' la refresh token rotation implementata lato server (tabella dei token emessi, invalidazione automatica al riuso) piu' una revocation list per i casi di breach rilevato.
