Domain Mayday EP05: El secuestro masivo de dominios DeFi en Squarespace en 2024

En julio de 2024, lo más peligroso del sitio web de un proyecto cripto no era un error en el contrato inteligente ni una clave privada filtrada. Era el registrador que controlaba el dominio.

Durante varios días de ese mes, los usuarios que escribían una dirección familiar en su navegador — el sitio oficial de un protocolo de préstamos en el que confiaban, un puente que habían utilizado cien veces — llegaban exactamente donde esperaban, a una página de apariencia completamente normal, y entonces veían cómo sus carteras se vaciaban. Nada había sido hackeado en el sentido habitual. Nadie había descifrado una contraseña ni robado una frase semilla. Los atacantes simplemente habían entrado por la puerta principal del dominio en sí, porque esa puerta había quedado sin cerrar durante una mudanza corporativa que la mayoría de estos proyectos nunca notó.

La mudanza fue la migración de Google Domains a Squarespace. La puerta sin cerrar eran los valores predeterminados de autenticación de Squarespace. Y el resultado fue una oleada coordinada de secuestros de DNS contra proyectos cripto y DeFi que controlaban, en palabras de un investigador, miles de millones de dólares en activos.

Cómo una migración de registrador creó una superficie de ataque masiva

Por lo general, los dominios no se conciben como una flota. Cada uno parece algo individual y privado — tu dirección, tu panel de control, tus registros DNS. Pero los registradores los albergan en conjunto, y cuando la base de clientes completa de un registrador se traslada a otro, todas las cuentas de esa base se mueven con la misma lógica de migración, con los mismos valores predeterminados, al mismo tiempo. Cualquier debilidad que exista en esa lógica no es un error aislado. Es una propiedad de toda la flota.

Eso es lo que convirtió el incidente de 2024 en un evento masivo en lugar de una serie de compromisos individuales desafortunados.

En junio de 2023, Squarespace adquirió aproximadamente 10 millones de nombres de dominio de Google Domains, tras el anuncio de Google de que cerraba su registrador. Durante el año siguiente, Squarespace estuvo migrando usuarios para los aproximadamente 10 millones de nombres de dominio adquiridos en la transacción. Para que la transición pareciera fluida, Squarespace pre-creó cuentas para las personas asociadas a cada dominio migrado, vinculadas a las direcciones de correo electrónico que Google tenía registradas.

Fluida era exactamente el problema. Una migración que no le pide nada al usuario es una migración en la que el usuario no ha demostrado nada — ni su contraseña, ni su identidad, ni el control de su correo. Las cuentas existían, los dominios estaban adjuntos, y lo único que se interponía entre un dominio y quien llegara primero era una pantalla de inicio de sesión que, para estas cuentas migradas, casi no exigía nada.

Los secuestros de julio de 2024

Los ataques comenzaron el 9 de julio y se prolongaron durante los días siguientes. No fueron sutiles. Una oleada de ataques coordinados de secuestro de DNS dirigidos a dominios de criptomonedas de finanzas descentralizadas (DeFi) que usaban el registrador Squarespace, redirigiendo a los visitantes a sitios de phishing que albergaban vaciadores de carteras, según informó BleepingComputer.

El primero en causar revuelo fue uno de los nombres más conocidos en el préstamo DeFi. La empresa de seguridad Blockaid, que investigó el incidente, descubrió que los visitantes de estos sitios eran redirigidos a páginas maliciosas diseñadas para vaciar los fondos de las carteras conectadas. Los sitios falsos no eran imitaciones toscas. Según Blockaid, estas dApps falsas ejecutaban la última versión del kit de vaciado Inferno, diseñado para engañar a los usuarios para que firmaran transacciones que vaciarían sus carteras.

La lista de víctimas confirmadas parecía un recuento del ecosistema. Las entidades secuestradas incluyeron Celer Network, Compound Finance, Pendle Finance y Unstoppable Domains. En el caso de Compound, su dominio principal había sido tomado para mostrar una página de phishing. Celer detectó el intento y recuperó rápidamente sus registros DNS; Pendle experimentó problemas similares y advirtió a sus usuarios que revocaran las aprobaciones de sus carteras.

Lo que estaba en juego — y lo que perdieron los usuarios

La crueldad de un secuestro de dominio radica en que anula todos los hábitos en los que los usuarios aprenden a confiar. Verifica la URL. Asegúrate de que es el sitio real. Busca el icono de candado. Todo ese consejo asume que el dominio aún apunta a donde debe. Cuando el atacante controla el DNS del dominio, la URL es real — es la dirección genuina del proyecto — y se resuelve en el servidor del atacante. El candado está en verde. La barra de direcciones dice la verdad. La página es una trampa.

Por eso los kits de vaciado de carteras como Inferno combinan tan bien con el secuestro de DNS. El vaciador no necesita robar una contraseña; necesita que la víctima conecte una cartera y firme. Y un usuario que llegó al dominio real de su protocolo de préstamos no tiene motivo para dudar antes de aprobar una transacción. El sitio de phishing hereda toda la confianza que el dominio legítimo tardó años en ganarse.

¿Qué tan grave podría haber sido? El número que capturó la dimensión del problema no fue la cantidad de robos confirmados, sino la de proyectos expuestos. El análisis de Blockaid, reportado por Decrypt, fue directo: aproximadamente 228 interfaces de usuario de protocolos DeFi siguen en riesgo, porque todas se encontraban detrás de la misma vulnerabilidad de cuenta migrada. Los secuestros que ocurrieron fueron una muestra. La superficie de ataque era todo el colectivo cripto que había transitado la migración de Google a Squarespace.

Cómo ocurrió: el fallo de autenticación en la migración

El mecanismo, una vez que los investigadores lo reconstruyeron, resultó casi vergonzosamente sencillo — lo que lo hacía peligroso a escala.

Todo parte de dos decisiones de diseño. Primera, Squarespace no verificaba que la persona que iniciaba sesión controlara efectivamente el correo electrónico de la cuenta. Como lo expresaron los investigadores, Squarespace no exige verificación de correo electrónico para las nuevas cuentas creadas con contraseña. Segunda, las cuentas migradas habían sido pre-creadas pero aún no reclamadas — no tenían contraseña establecida. Así que cuando alguien llegaba con el correo correcto, al no haber contraseña en la cuenta, simplemente se le enviaba al flujo de 'crear contraseña para tu nueva cuenta'.

Combina esos dos factores y el ataque se escribe solo. Las direcciones de correo vinculadas a dominios migrados no eran secretas — los contactos administrativos y de titular suelen ser públicos o predecibles. Un atacante que simplemente se registraba en la cuenta primero, usando un correo migrado conocido, antes de que el propietario real iniciara sesión, se marchaba con el control del dominio. Taylor Monahan, directora de producto de MetaMask y una de las investigadoras que diseccionó el incidente, describió el punto ciego con precisión: Squarespace nunca consideró la posibilidad de que un actor malicioso pudiera registrarse en una cuenta usando un correo electrónico asociado a un dominio recientemente migrado antes de que el titular legítimo de ese correo creara la cuenta por sí mismo.

¿Por qué existía la vinculación previa? Por conveniencia. Los investigadores concluyeron que Squarespace asumió que todos los usuarios que migraban desde Google Domains elegirían las opciones de inicio de sesión social — OAuth de Google — en lugar de correo electrónico y contraseña. El sistema vinculaba previamente todos los correos a dominios, independientemente de si la cuenta ya existía, probablemente porque querían que los usuarios pudieran autenticarse con OAuth de Google y acceder de inmediato a todos sus dominios, según explicaron los investigadores a The Register. Pero la vía de correo y contraseña nunca se cerró, y por esa vía nada demostraba el control de la bandeja de entrada.

Hubo un agravante más. Durante la migración, la protección que debería haber detectado esto estaba desactivada: como parte de la transición a Squarespace, la autenticación multifactor fue deshabilitada en las cuentas. Incluso un propietario de dominio que había activado cuidadosamente el MFA en Google Domains llegaba a Squarespace sin ese MFA. Sin contraseña que descifrar, sin segundo factor que eludir, sin correo que interceptar — para una cuenta migrada y sin reclamar, conocer una dirección de correo predecible era toda la historia de autenticación.

Respuesta y mitigación

La comunidad de seguridad cripto actuó más rápido que el registrador. Los investigadores — entre ellos Samczsun, Taylor Monahan y Andrew Mohawk — publicaron el mecanismo, y Blockaid distribuyó listas de interfaces aún vulnerables para que los proyectos pudieran comprobar si estaban expuestos. Los proyectos afectados se apresuraron a reclamar sus cuentas, restablecer los registros DNS y advertir a los usuarios que revocaran las aprobaciones de tokens concedidas a los sitios maliciosos.

El consejo de mitigación inmediata fue el mismo para todos los que aún tenían una cuenta migrada: iniciar sesión y reclamar la cuenta antes de que lo hiciera un atacante, establecer una contraseña única y segura, y — sobre todo — volver a activar la autenticación multifactor, que la migración había eliminado en silencio. Squarespace, por su parte, trabajó para bloquear las cuentas migradas y el flujo de creación de cuentas. Pero la lección estructural superó al parche: un control de seguridad que un proveedor desactiva durante una migración es, durante esa migración, un control que no existe.

Lo que esto enseña sobre la seguridad del registrador y el MFA

Los secuestros de Squarespace no son realmente la historia de la mala configuración de una empresa. Son la historia de dónde reside realmente el control de los dominios, y cuán frágil sigue siendo la capa por encima de la blockchain.

Algunas lecciones se generalizan mucho más allá de julio de 2024:

1. La cuenta del registrador es la verdadera raíz de confianza — no el contrato inteligente. Ninguno de los protocolos afectados tenía un error en el contrato. Su código on-chain estaba bien. Los atacantes se apoderaron del dominio, y el dominio es lo que los usuarios escriben, en lo que confían y a lo que conectan sus carteras. Un proyecto puede ser impecable on-chain y aun así entregar sus usuarios a un atacante si el plano de control de su DNS es débil.

2. El MFA solo es una protección si sobrevive a las migraciones. El doloroso detalle aquí es que el MFA no falló bajo ataque — fue eliminado antes del ataque, como una concesión de comodidad en la migración. Trata el estado del MFA como algo que hay que reverificar después de cada movimiento de cuenta, transferencia o cambio de proveedor, no como algo que se configura una vez y se olvida.

3. "Sin fricciones" es una concesión de seguridad. Cada paso que una migración omite por comodidad del usuario es un paso en el que la identidad queda sin verificar. Las cuentas pre-creadas, los correos vinculados automáticamente y los inicios de sesión sin verificación son toda la fricción que el usuario no sintió — y la fricción es, con mucha frecuencia, lo que mantenía a los atacantes fuera.

4. Los identificadores predecibles son credenciales disfrazadas. El "secreto" que desbloqueó estos dominios era una dirección de correo electrónico que nunca fue secreta. Todo sistema en el que conocer un identificador público otorga control está a una suplantación de identidad de ser comprometido.

5. El radio de daño de un registrador es igual a toda su base de clientes. La seguridad individual del dominio no importa si el comportamiento predeterminado del registrador es débil, porque ese comportamiento predeterminado se aplica a todos a la vez. Dónde vive tu dominio, y cómo ese custodio gestiona la autenticación, es una decisión de seguridad tan trascendente como cualquier otra que tomes on-chain.

El ángulo de Namefi

Los secuestros de 2024 ocurrieron en la brecha entre "quién es realmente el propietario de este dominio" y "quién puede iniciar sesión en la cuenta que lo controla". En el modelo tradicional, esas dos cosas están solo débilmente conectadas: la propiedad es un registro en la base de datos de un registrador, y el acceso a ella está condicionado por la autenticación que ese registrador imponga esa semana — incluyendo en medio de una migración de 10 millones de dominios en la que la puerta estuvo, brevemente, completamente abierta.

Namefi está diseñado para cerrar esa brecha. Al representar la propiedad del dominio como un activo tokenizado on-chain que sigue siendo compatible con DNS, el control se convierte en algo que puedes verificar criptográficamente en lugar de algo que descansa en un correo predecible y en los valores predeterminados de inicio de sesión de un proveedor. La propiedad reside en una cartera que tú controlas, las transferencias son auditables, y la pregunta "¿quién tiene permitido modificar los registros de este dominio?" tiene una respuesta resistente a manipulaciones en lugar de una respuesta de soporte al cliente.

Eso no habría hecho que la migración de Squarespace fuera impecable. Pero cambia el modo de fallo. Un atacante que registra una cuenta con un correo conocido no adquiere por ello la propiedad de un dominio tokenizado — la propiedad no es una fila que una cuenta medio inicializada puede reclamar silenciosamente. El plano de control de un nombre debería ser tan difícil de falsificar como los activos que protege. En julio de 2024, para cientos de proyectos cripto, no lo era. Esa brecha es exactamente la que vale la pena eliminar con ingeniería.

Fuentes y lectura adicional

• Krebs on Security — Researchers: Weak Security Defaults Enabled Squarespace Domains Hijacks
• BleepingComputer — DNS hijacks target crypto platforms registered with Squarespace
• Blockaid — Squarespace Domain Hijacking Incident: Attack Report
• SecurityWeek — Hackers Exploit Flaw in Squarespace Migration to Hijack Domains
• Decrypt — More Than 220 DeFi Protocols Still 'at Risk' From Squarespace DNS Hijack
• The Register — Infoseccers claim Squarespace migration linked to DNS hijackings at Web3 firms
• Socket — Squarespace Domain Hijacks Enabled by Email Address Exploit on Migrated Accounts
• SiliconANGLE — Multiple crypto domains hijacked from Squarespace due to Google Domains migration flaw
• Cybernews — Squarespace crypto domains under DNS attack, lack of MFA to blame
• Hackread — DeFi Hack Alert: Squarespace Domains Vulnerable to DNS Hijacking
• CircleID — Security Lapses Lead to Squarespace Domain Hijacks