En 1993, los criptógrafos lo denominaron "el ataque más sencillo que existe": tomar un mensaje válido, esperar y volver a enviarlo. Nadie construye una bóveda esperando que la clave se reutilice.
Pero eso fue precisamente lo que ocurrió cuando Ethereum y Ethereum Classic se separaron: la misma transacción firmada, transmitida en dos cadenas, movió fondos reales dos veces. Sin hackeo, sin robo de contraseña, sin enlaces de phishing.
Un ataque recurrente que hace lo que siempre ha hecho, utilizando la legitimidad como arma.
Únase a UEEx
Experimente la plataforma líder mundial de gestión de patrimonio digital
¿Qué es un ataque de repetición (ataque de repetición)?
Un ataque de repetición es un tipo de violación de seguridad de red en la que un atacante intercepta transmisiones de datos válidas y las reutiliza o reenvía maliciosamente para engañar a un sistema.
A diferencia de los ataques que alteran o falsifican datos, un ataque de repetición simplemente retransmite información capturada previamente, como credenciales de inicio de sesión, tokens de autenticación o solicitudes de transacción, para engañar a un sistema y hacerle creer que está recibiendo un comando nuevo y legítimo.
Nota bondadosa: Un ataque de repetición (ataque de repetición) puede ocurrir en la misma cadena o en una cadena cruzada.
¿Cuál es la diferencia entre un ataque de repetición en la misma cadena y un ataque de repetición en cadenas cruzadas?
Un ataque de repetición en la misma cadena se produce dentro de una misma cadena de bloques: la misma transacción o mensaje firmado se envía varias veces a la misma red.
El mecanismo nonce evita esto en las transacciones estándar de Ethereum; una vez que se consume un nonce (número de un solo uso), la misma transacción es rechazada.
Los ataques de repetición entre cadenas se producen entre dos cadenas de bloques que comparten formatos de dirección y lógica de firma, generalmente después de una bifurcación dura (hard fork).
El nonce (número de un solo uso) no es útil en este caso, ya que ambas cadenas gestionan los nonces de forma independiente. Una transacción con nonce 5 en Ethereum y otra con nonce 5 en Ethereum Classic son registros distintos en sistemas diferentes, pero los datos de la transacción firmada son idénticos.
El identificador de cadena de EIP-155 es la solución específica para la repetición entre cadenas. Para la verificación de firmas de contratos inteligentes, el separador de dominio de EIP-712 admite variantes tanto dentro de la misma cadena como entre cadenas.
Únase a UEEx
Experimente la plataforma líder mundial de gestión de patrimonio digital
Cuándo ocurrieron realmente los ataques de repetición: tres casos documentados
Los ataques de repetición en blockchain no son teóricos. Han provocado pérdidas financieras documentadas en múltiples ocasiones.
La bifurcación Ethereum/Ethereum Classic — 2016
Cuando la red Ethereum se bifurcó en Ethereum (ETH) y Ethereum Classic (ETC) tras el hackeo de la DAO, todas las transacciones firmadas antes de la bifurcación fueron válidas en ambas cadenas.
Las dos cadenas compartían espacios de direcciones, formatos de transacción y lógica de verificación de firmas idénticos.
Una transacción firmada por cualquier monedero era simultáneamente una transacción válida tanto en ETH como en ETC.
Las plataformas de intercambio que gestionaban fondos de usuarios de ETH y ETC se convirtieron inmediatamente en objetivos.
Los atacantes interceptaron transacciones válidas de retiro de ETH y las reprodujeron en la cadena de ETC, agotando así los saldos de ETC que los usuarios no tenían intención de tocar.
Más de 40,000 ETC fueron retirados de las plataformas de intercambio en el período posterior a la bifurcación, antes de que se implementara de forma generalizada la protección contra ataques de repetición.
Este acontecimiento impulsó directamente la creación de la EIP-155.
La fusión de Ethereum — 2022
Cuando Ethereum pasó de Prueba de Trabajo a Prueba de Participación (La Fusión), se creó una cadena bifurcada llamada Ethereum. PoW (ETHW) fue creada.
En cuestión de días, un atacante explotó el contrato entre cadenas Omni Bridge, que no tenía protección específica contra la repetición de transacciones para ETHW, y repitió transacciones que transfirieron 200 ETHW desde el contrato puente.
Como parte del ataque, el atacante utilizó datos de precios del oráculo de la red principal de ETH en la cadena ETHW, donde estaban desactualizados y eran manipulables.
El robo de tokens de Optimism OP — 2022
En un incidente de repetición entre cadenas, se robaron 20 millones de dólares en tokens OP de Optimism durante una secuencia de transacciones multifirma en disputa.
El ataque explotó la brecha entre los contextos de las cadenas L1 (Ethereum) y L2 (Optimism), donde la reproducción de un mensaje firmado específico en la cadena incorrecta movió tokens sin autorización.
No se trata de incidentes aislados. Representan un patrón documentado: cada vez que una nueva bifurcación o implementación de capa 2 crea dos entornos que comparten formatos de dirección o firma sin una vinculación específica de la cadena, existe riesgo de repetición de ataques.
Piensa en la última vez que se lanzó una nueva cadena que compartía tu dirección de Ethereum. ¿Verificaste si tus autorizaciones firmadas existentes eran válidas en esa nueva cadena? ¿Verificaste que el esquema de firma de tu billetera incluyera EIP-155? La mayoría no lo hizo. La mayoría no tuvo problemas. Pero quienes sí los tuvieron perdieron fondos reales, y ninguno lo esperaba.
EIP-155: La solución que siguió a la bifurcación de 2016
La EIP-155, presentada por el cofundador de Ethereum, Vitalik Buterin, en 2016, fue creada específicamente para evitar que las transacciones se reproduzcan en cadenas bifurcadas.
La solución era sencilla en principio: incorporar el identificador único de la cadena (chainId) en la firma de cada transacción.
Antes de EIP-155, una firma de transacción abarcaba seis campos de datos: nonce, precio del gas, límite de gas, dirección del destinatario, valor y datos.
La firma era válida en cualquier cadena compatible con EVM que utilizara la misma lógica de verificación, ya que ninguno de esos campos identificaba a qué cadena específica estaba destinada la transacción.
Tras la EIP-155, las transacciones incluyen tres campos adicionales en el hash de la firma: chainId y dos valores de marcador de posición vacíos.
Una transacción firmada por Mainnet de Ethereum (chainId = 1) no es una firma válida en Optimism (chainId = 10), Polygon (chainId = 137) ni en ninguna otra cadena EVM.
El nodo que recibe la transacción compara el chainId con el suyo propio y rechaza cualquier discrepancia.
Este único cambio redujo significativamente los ataques de repetición entre cadenas para las transacciones estándar.
La limitación importante: EIP-155 solo protege las transacciones de Ethereum sin procesar.
No protege las firmas a nivel de aplicación, es decir, los mensajes firmados que los contratos inteligentes verifican internamente mediante la función ecrecover.
Un contrato que valida firmas fuera de la cadena sin comprobar el ID de la cadena sigue siendo vulnerable a ataques de repetición, incluso si EIP-155 se implementa completamente a nivel de transacción. Ahí es donde entra en juego EIP-712.
El nonce: cómo evita la repetición en la misma cadena.
El nonce (número de un solo uso) es el mecanismo que impide los ataques de repetición dentro de la misma cadena de bloques. Cada cuenta de Ethereum mantiene un contador que comienza en 0 y se incrementa en 1 con cada transacción enviada.
Cuando envías una transacción con nonce = 5, la red solo la acepta si el nonce de tu cuenta actual es exactamente 5.
Una vez procesado, el nonce de su cuenta se convierte en 6, y cualquier intento de reproducir la transacción nonce-5 falla porque la red ahora espera un nonce 6.
Por eso no se puede enviar la misma transacción de Ethereum dos veces en la misma cadena: el nonce lo impide. El problema, según el análisis de Gate.io de marzo de 2026, radica en que un nonce por sí solo impide la repetición dentro de la misma cadena, pero no la repetición entre cadenas, ya que cada cadena mantiene un conteo de nonce independiente.
El valor nonce de tu cuenta en la red principal de Ethereum y el valor nonce de tu cuenta en Ethereum Classic se rastrean de forma independiente.
Una transacción con nonce = 5 en Ethereum también podría tener nonce = 5 en Ethereum Classic si se ha realizado el mismo número de transacciones en ambas cadenas. EIP-155 soluciona este problema al incorporar el chainId a la firma digital.
Únase a UEEx
Experimente la plataforma líder mundial de gestión de patrimonio digital
La EIP-155 solucionó los ataques de repetición a nivel de transacción. No ayuda con la verificación de firmas de contratos inteligentes.
Cuando un contrato inteligente utiliza ecrecover para validar una firma fuera de la cadena, está verificando un mensaje, no una transacción. La protección chainId de EIP-155 se aplica a la transacción de Ethereum que contiene el mensaje, no al contenido del mensaje en sí.
Si un desarrollador crea un contrato que valida firmas sin incluir el chainId, la dirección del contrato y el nonce en los datos firmados, cualquiera que intercepte esas firmas podrá reproducirlas.
La norma EIP-712 (Firma de Datos Estructurados Tipados) aborda esta cuestión. Define una forma estándar de estructurar los mensajes firmados que incluye un separador de dominio, un hash que incorpora el ID de la cadena, la dirección del contrato de verificación y el nombre y la versión del contrato.
Una firma creada bajo EIP-712 está vinculada a un contrato específico en una dirección específica en una cadena específica.
No se puede reproducir en una cadena diferente o en un contrato diferente, incluso si el código de bytes es idéntico.
Para desarrolladores: antes de implementar cualquier contrato que verifique firmas fuera de la cadena, asegúrese de que su esquema de firma incluya los tres elementos: nonce (evita la reutilización del mismo mensaje), chainId (evita la repetición entre cadenas) y dirección del contrato (evita la repetición entre contratos). La biblioteca ECDSA de OpenZeppelin, versión 4.7.3 y posteriores, implementa correctamente los tres elementos.
Sistemas y protocolos vulnerables a ataques de repetición
Sistema/Protocolo de destino
Por qué es vulnerable
Ejemplos comunes y fallos
Conexiones inalámbricas
La transmisión al aire libre facilita la interceptación y el reenvío de datos.
Wi-Fi obsoleto (WEP/WPA débil) sin secuenciación de paquetes; dispositivos Bluetooth sin validación de nonce o emparejamiento de sesión.
Protocolos criptográficos
Se basa en claves estáticas o carece de comprobaciones de vigencia que tengan en cuenta el contexto.
Kerberos u OAuth cuando los tokens de sesión o las credenciales carecen de marcas de tiempo y reglas de caducidad estrictas.
Internet de los objetos (IO)
Prioriza el funcionamiento de bajo consumo y la comodidad por encima de la seguridad robusta.
Cerraduras y cámaras inteligentes que utilizan protocolos IoT (MQTT, CoAP) sin protección integrada contra ataques de repetición debido a la limitada capacidad de procesamiento.
Sistemas de pago
Vulnerable si las transacciones carecen de códigos de autenticación dinámicos y de un solo uso.
Tarjetas sin contacto antiguas y terminales de punto de venta que carecen de criptogramas EMV o tokens por transacción.
1. Validación de marcas de tiempo y monitorización de registros
Los ataques de repetición suelen reutilizar datos sin modificar su marca de tiempo original.
Al supervisar y validar las marcas de tiempo, los sistemas pueden detectar cuándo los mensajes se retrasan inesperadamente o se encuentran fuera de un intervalo de tiempo aceptable.
Implementar controles de validez estrictos basados en el tiempo para tokens, transacciones y llamadas API.
Marcar los mensajes que parecen estar retrasados o procesados fuera de la duración normal de la sesión.
Cruzar los registros del sistema para identificar solicitudes con marcas de tiempo idénticas que aparecen más de una vez.
2. Detección de mensajes duplicados
Una característica distintiva de los ataques de repetición es la repetición de mensajes o paquetes idénticos.
Los sistemas deberían supervisar este tipo de patrones, especialmente en áreas críticas como la autenticación, las transacciones financieras y la gestión de sesiones.
Utilice hash o huellas dactilares para detectar paquetes o solicitudes duplicados.
Compare los datos entrantes con las entradas procesadas recientemente para verificar si hay contenido repetido.
Registre e investigue tokens de sesión repetidos, llamadas API o cargas útiles cifradas.
3. Seguimiento de números de secuencia y valores aleatorios (nonce)
Los sistemas seguros suelen basarse en números de secuencia o nonces (números de un solo uso) para rastrear y validar la unicidad de los datos.
Los mensajes que se reproducen suelen reutilizar el mismo número de secuencia o nonce, lo cual puede ser señalado.
Mantenga una memoria a corto plazo (caché o base de datos) de los nonces o números de secuencia utilizados recientemente.
Eliminar o registrar solicitudes que contengan valores reutilizados.
Alerta sobre tokens de sesión o identificadores de solicitud que ya han sido procesados.
4. Detección de anomalías de comportamiento
Los ataques de repetición no siempre son duplicados técnicos; a veces, el contexto del comportamiento puede revelar la amenaza.
Por ejemplo, un usuario que realiza exactamente la misma transacción dos veces en cuestión de segundos podría resultar sospechoso.
Supervisar el comportamiento del usuario y crear perfiles de referencia para la actividad normal.
Marcar patrones anormales como acciones repetidas de alta frecuencia, solicitudes idénticas desde diferentes IP o múltiples inicios de sesión utilizando el mismo token.
Integrar sistemas de detección de anomalías que puedan aprender y adaptarse a patrones de tráfico típicos.
5. Análisis del tráfico de red
Las herramientas de detección avanzadas pueden analizar el tráfico de red en tiempo real para buscar patrones sospechosos, especialmente en entornos inalámbricos o de IoT donde los ataques de repetición son comunes.
Utilice sistemas de detección de intrusiones (IDS) o sistemas de prevención de intrusiones inalámbricas (WIPS) para detectar retransmisiones de paquetes sospechosos.
Analice los encabezados de paquetes en busca de identificadores reutilizados, nonces o parámetros de cifrado.
Esté atento a las cargas útiles cifradas repetitivas que no varían entre sesiones.
6. Análisis del token de sesión y del registro de autenticación
Los ataques de repetición suelen implicar la reutilización de tokens de autenticación. Los sistemas deben auditar y analizar los registros de emisión y uso de tokens para identificar aquellos que parecen reutilizarse o usarse indebidamente.
Realice un seguimiento de la duración de los tokens de sesión y la información de IP/dispositivo asociada.
Registra los intentos de reutilizar credenciales de autenticación vencidas o ya consumidas.
Investigar los intentos de inicio de sesión que reutilizan encabezados, metadatos o detalles de la sesión.
¿Cuál es la diferencia entre un ataque de repetición y un ataque MITM?
Un ataque de repetición implica capturar y reenviar datos válidos para engañar a un sistema, mientras que un ataque de intermediario (MitM) intercepta y altera activamente la comunicación entre dos partes en tiempo real.
¿Cuáles son los tipos más comunes de paquetes capturados en un ataque de repetición?
Los tipos más comunes de paquetes capturados en un ataque de repetición incluyen solicitudes de autenticación, tokens de sesión, mensajes de transacción y comandos de control utilizados en comunicaciones inalámbricas o de red.
¿Cómo previene TLS un ataque de repetición?
TLS evita ataques de repetición mediante el uso de claves de sesión únicas, números de secuencia y códigos de autenticación de mensajes (MAC) para garantizar que cada mensaje sea nuevo y no pueda reenviarse ni modificarse sin detección.
¿Qué es un ataque de repetición de Kerberos?
Un ataque de repetición de Kerberos ocurre cuando un atacante captura y reenvía un mensaje de autenticación Kerberos válido para engañar al sistema y que conceda acceso no autorizado sin volver a autenticarse.
Únase a UEEx
Experimente la plataforma líder mundial de gestión de patrimonio digital
Los ataques de repetición pueden parecer sencillos, pero su impacto puede ser grave, desde el acceso no autorizado hasta pérdidas financieras e interrupciones del servicio.
Es fundamental reconocer los sistemas vulnerables, comprender cómo funcionan estos ataques y aplicar defensas por capas como nonces, marcas de tiempo y cifrado.
A medida que las amenazas continúan apuntando a los puntos débiles de los procesos de verificación, la detección temprana y la prevención se vuelven fundamentales.
Reforzar los sistemas contra los ataques de repetición no se trata solo de protección; se trata de garantizar la confianza, la integridad de los datos y un servicio consistente en entornos digitales donde la seguridad no puede verse comprometida.
Akindele T. Francis es una redactora de contenido versátil con amplia experiencia en diversos sectores. Especializada en publicaciones de blog, contenido web, páginas de servicios, textos de venta atractivos, etc., Akindele ha colaborado con numerosas agencias para ofrecer material escrito atractivo y eficaz. Con una atención al detalle y una pasión por crear narrativas impactantes, Akindele supera constantemente las expectativas de sus clientes, impulsando resultados y mejorando el mensaje de marca en diversas plataformas.
Renuncia de responsabilidad:Este artículo tiene fines exclusivamente informativos y no debe considerarse asesoramiento comercial ni de inversión. Nada de lo aquí contenido debe interpretarse como asesoramiento financiero, legal o fiscal. Operar o invertir en criptomonedas conlleva un riesgo considerable de pérdida financiera. Siempre realice la debida diligencia antes de tomar cualquier decisión comercial o de inversión.
