Saltar al contenido principal

Ataques de repetición - Reutilización de datos capturados

Lectura de 2 min aprox.

Un ataque de repetición (replay attack) es una técnica de ataque que intenta el acceso no autorizado interceptando datos de comunicación legítimos y reenviándolos tal cual. Su característica distintiva es que el atacante no necesita descifrar el cifrado; el ataque tiene éxito simplemente con «grabar y reproducir» datos legítimamente autenticados. A menudo se ejecuta en combinación con un ataque de intermediario, y cualquier comunicación puede convertirse en objetivo, incluidos tokens de autenticación, solicitudes de API y datos de transacciones financieras. Aunque el principio es simple, es un ataque problemático que no puede prevenirse solo con el cifrado en tránsito sin las contramedidas adecuadas.

Cómo funciona el ataque

1. Interceptar
Capturar la comunicación legítima
2. Almacenar
Registrar los datos tal cual
3. Reenviar
Enviar datos idénticos al servidor
4. Aceptar
El servidor lo confunde con algo legítimo

El punto crucial es que el atacante no necesita entender el contenido de los datos. Incluso los datos cifrados, si se reenvían tal cual, serán procesados por el servidor como una solicitud legítima. El cifrado mediante TLS evita la interceptación, pero no puede impedir la reutilización de datos capturados dentro de una sesión legítima.

La diferencia con el secuestro de sesión

Los ataques de repetición y el secuestro de sesión se confunden con facilidad, pero sus mecanismos de ataque difieren.

Ataque de repetición
  • Reenvía datos de comunicación anteriores
  • Funciona aunque la sesión original haya terminado
  • No se necesita modificar los datos
  • Contramedidas: nonces, marcas de tiempo
Secuestro de sesión
  • Toma el control de una sesión activa
  • Solo es efectivo mientras la sesión es válida
  • Requiere robar el ID de sesión
  • Contramedidas: prevención de fijación de sesión, reautenticación

Técnicas de contramedida

Las contramedidas contra los ataques de repetición se reducen a introducir mecanismos que «hagan que los mismos datos no puedan usarse dos veces».

NonceIncluir en la solicitud un valor aleatorio utilizable una sola vez, y que el servidor registre los nonces usados y rechace su reutilizaciónMarca de tiempoIncluir la hora actual en la solicitud y rechazar las solicitudes antiguas que superen un periodo establecido (p. ej., 5 minutos)Desafío-respuestaEl servidor envía un desafío diferente cada vez y el cliente devuelve una respuesta basada en él. Las respuestas anteriores no pueden reutilizarseNúmero de secuenciaAsignar números secuenciales a las comunicaciones y detectar y rechazar números duplicados o fuera de orden

Por qué FIDO/WebAuthn resiste los ataques de repetición

El protocolo FIDO/WebAuthn incorpora la resistencia a los ataques de repetición desde la fase de diseño. Cada vez que se realiza la autenticación, el servidor genera un desafío aleatorio y el cliente firma ese desafío con su clave privada. Como la firma incluye el valor del desafío, el origen (el dominio de conexión) y el valor del contador del autenticador, reenviar una firma anterior se rechaza de inmediato por la discrepancia del desafío. Es importante reforzar todo el flujo de autenticación en combinación con las contramedidas contra el secuestro de sesión y las defensas contra el robo de tokens de sesión.

Caducidad de tickets de Kerberos

El protocolo de autenticación Kerberos, ampliamente utilizado en entornos de Active Directory, también incorpora contramedidas contra los ataques de repetición. Al ticket de autenticación (TGT) se le asigna un periodo de caducidad (10 horas por defecto), y los tickets caducados son rechazados. Además, cada solicitud incluye una marca de tiempo, y el servidor verifica que la diferencia horaria entre el servidor y el cliente sea inferior a 5 minutos. Este requisito de sincronización horaria es también la razón por la que operar un servidor NTP se considera imprescindible en un entorno Kerberos.

Los ataques de repetición son una técnica clásica, pero con el aumento de los dispositivos IoT y las comunicaciones por API, todavía existen muchos sistemas con contramedidas insuficientes. Combinarlos con la introducción de la autenticación de dos factores permite reforzar aún más la solidez de la autenticación.libros especializados en seguridad de redes (Amazon) son recomendables para estudiar en profundidad las contramedidas a nivel de protocolo.

Términos relacionados

¿Te resultó útil este artículo?

XHatena