La IA puede escribir código, pero ¿quién custodia los dominios?

Autor: Yajin

El 31 de octubre, los sitios web de más de una docena de proyectos DeFi fueron secuestrados sucesivamente. Uno de los proyectos afectados, Kintsu, publicó en X[1] que su dominio, adquirido a través de Vercel, fue secuestrado a nivel de registrador. En esta declaración hay dos términos clave: uno es Vercel y el otro es registrador. Empecemos por Vercel.

Vercel es una plataforma de despliegue de sitios web. Los desarrolladores envían su código escrito y la plataforma se encarga de compilarlo y lanzar el sitio, para luego entregar las páginas web a los usuarios mediante servidores distribuidos por todo el mundo. Vercel es también la empresa detrás del framework front-end Next.js[2], muy popular entre los desarrolladores, y la mayoría de los proyectos mencionados en esta ocasión tienen sus páginas web alojadas en Vercel. Además de alojar sitios web, Vercel también vende dominios, permitiendo a los usuarios comprar dominios y gestionar la configuración DNS desde el mismo panel.

Según los datos que encontramos, el código de estos proyectos alojado en Vercel no fue alterado; lo que se modificó fue a dónde apuntaba el dominio.

Este incidente merece la atención de todos los proveedores de servicios de aplicaciones, especialmente los de activos digitales. En los últimos dos años, el vibe coding se ha popularizado: consiste en describir los requisitos en lenguaje natural y dejar que la IA escriba el programa. Esto reduce enormemente el umbral para desarrollar aplicaciones: con la IA escribiendo el código, enviándolo a plataformas de despliegue como Vercel, Netlify o Cloudflare para un lanzamiento con un clic, y comprando un dominio en la plataforma, se puede tener un sitio web decente en pocos minutos.

Aunque el umbral se ha reducido, los principios subyacentes no se han vuelto más simples. Muchas personas no saben dónde está registrado su dominio, quién puede modificar su apuntamiento y qué claves se necesitan para hacerlo. Vercel es solo un tipo de plataforma; estos problemas se aplican a todos los métodos de despliegue con un clic. Este artículo pretende aclarar estas cuestiones de la manera más sencilla posible.

01 Cómo se localiza una URL

Veamos ahora a qué se refería Kintsu con "registrador". Para entender qué hace un registrador, primero debemos ver cómo se localiza una URL. Podemos pensar en un sitio web como una tienda. El nombre de dominio es el nombre de la tienda, como ejemplo.com; la dirección IP del servidor es el número de la calle. Los usuarios solo recuerdan el nombre de la tienda, por lo que alguien debe traducir el nombre de la tienda al número de la calle, y este proceso de traducción se llama "resolución de dominio".

El proceso de traducción implica tres roles.

El registro actúa como una oficina central de registro. Cada tipo de sufijo tiene su propio registro, como .com, .xyz, .finance, etc. El registro solo recuerda una cosa: dónde se encuentra el "lugar de consulta" de un determinado nombre de dominio.

El registrador actúa como intermediario que hace los trámites por los usuarios. La gente común no puede ir directamente al registro para registrar; debe pasar por un registrador para comprar un dominio, renovarlo o modificar la información de registro. Los usuarios pueden especificar qué "lugar de consulta" es responsable de su dominio en el panel del registrador.

El servidor de nombres es el "lugar de consulta". Tiene una tabla que indica qué nombre de tienda corresponde a qué número de calle. Cada fila de esta tabla se llama registro de resolución. Cuando hablamos de "cambiar la resolución", nos referimos a cambiar esta tabla en el servidor de nombres.

Después de que un usuario introduce una URL en el navegador, el navegador primero pregunta al registro central: ¿dónde está el lugar de consulta de esta tienda? Luego pregunta al lugar de consulta: ¿cuál es el número de la calle? Finalmente, encuentra la tienda según el número de la calle y abre la página web.

El navegador primero pregunta al registro, luego al servidor de nombres y finalmente encuentra la tienda por el número de la calle.

Entonces, si alguien quiere engañar a los clientes para que vayan a su tienda falsa, hay dos métodos. El primero es ir al lugar de consulta y cambiar el número de la calle en la tabla. El segundo es más encubierto: ir al registrador y reemplazar por completo el lugar de consulta registrado para esta tienda por uno que controlan, y luego escribir un número de calle falso en el nuevo lugar de consulta. Al usar el segundo método, el dueño de la tienda revisa el lugar de consulta original y nada ha cambiado en la tabla, pero los clientes ya han sido desviados.

Dos métodos: cambiar la tabla en el lugar de consulta o reemplazar el lugar de consulta por completo con uno controlado por el atacante.

02 Quién gestiona el dominio comprado con un clic

Entendiendo el registro, el registrador y el servidor de nombres, ahora podemos volver a las plataformas de despliegue como Vercel. Las plataformas de despliegue son responsables de ejecutar los programas escritos en línea. Para facilitar las cosas a los usuarios, muchas plataformas de despliegue han integrado la compra de dominios y la gestión de DNS en su panel, permitiendo a los usuarios interactuar únicamente con la plataforma desde la compra del dominio hasta el lanzamiento del sitio web.

Sin embargo, detrás de la plataforma, todos los roles mencionados anteriormente siguen presentes. Algunas plataformas son registradores en sí mismas, mientras que otras actúan en nombre de los usuarios para encontrar registradores; Vercel pertenece a esta última categoría. Comprobamos el dominio de Kintsu y el registrador que figura en el registro es Name.com, no el propio Vercel.

Este enfoque "todo en uno" es muy conveniente, pero la desventaja es que los usuarios a menudo no saben que su dominio tiene un registrador y es poco probable que se preocupen por la seguridad a nivel de registrador. En el caso de Vercel, en su panel e interfaz[3], se puede modificar el servidor de nombres y también se puede obtener el código de autorización para transferir el dominio. En otras palabras, quien tenga la cuenta de la plataforma o los permisos de su interfaz podría cambiar el apuntamiento del dominio o incluso transferirlo.

Muchos proyectos revisan rigurosamente su código y contratos, pero sus dominios están bajo una única cuenta que nadie supervisa, y cuando surgen problemas, no saben a quién acudir.

En la era de la IA, "un clic" se está convirtiendo en "cero clics". La herramienta de línea de comandos de Vercel[4] ahora admite que scripts y asistentes de IA compren y renueven dominios sin intervención humana. Vercel también proporciona una interfaz MCP para asistentes de IA (una forma estándar para que los asistentes de IA llamen a herramientas externas), con 28 herramientas relacionadas con dominios y DNS[5]. Esto significa que cuando un desarrollador le dice a la IA: "Ayúdame a lanzar el sitio web y configurar un dominio", la IA puede encargarse de la compra del dominio y los cambios de resolución por él.

Lo que los desarrolladores se ahorran no son solo clics, sino también la oportunidad de entender estos procesos: bajo qué cuenta se compra el dominio, qué registrador hay detrás y quién puede modificarlo, probablemente nunca pasen por sus ojos de principio a fin.

En una frase, la IA ha completado la compra del dominio y la configuración de la resolución para el desarrollador.

03 Dónde realizó cambios el atacante

Según informes públicos[6], el 31 de octubre, el número de sitios web atacados aumentó a más de una docena. Además de Kintsu, hay proyectos DeFi como StonkFun, Pickle, Echelon, Origami, Fluxbeam, Stakepoint, SupSwap, Longbow, SHPRD y ApeX DeFi.

La información de registro de dominios es pública y cualquiera puede consultarla. Comprobamos los dominios de 11 de estos proyectos y descubrimos que todos sus registradores son Name.com, y 7 de ellos tuvieron modificaciones en el registro el 31 de octubre. A las 6 PM hora de Pekín del día 31, 5 dominios seguían apuntando a los servidores de los atacantes.

Los atacantes utilizaron ambos métodos mencionados anteriormente. pickle.finance[7] y stakepoint.app todavía tienen una tabla en el servidor de nombres de Vercel que enumera la dirección del servidor del propio Vercel, lo que indica que su lugar de consulta original debería haber estado en Vercel; sin embargo, su lugar de consulta registrado en el registro se cambió al servidor de nombres de Name.com alrededor de la 1 AM UTC del día 31, con el nuevo número de calle 31.56.52.52.

En otro caso, fluxbeam.xyz, supswap.xyz y apexdefi.xyz originalmente tenían sus lugares de consulta en Name.com, y el registro no ha cambiado desde febrero o mayo de este año, pero la tabla en el lugar de consulta ahora también enumera el número de calle 31.56.52.52, lo que sugiere que la tabla en sí fue alterada. Esta dirección está registrada bajo una empresa llamada Snowcore[8], y el rango de IP está registrado en los Países Bajos, sin relación con Vercel.

Las URL de diferentes proyectos han sido apuntadas a la misma dirección controlada por el atacante.

Para los dominios restantes, algunos han vuelto a servidores normales, otros han cambiado a otros proveedores de servicios y otros están en proceso de transferir el dominio, lo que indica que los equipos de los proyectos están intentando recuperarse.

Ambos métodos tienen algo en común: requieren modificaciones en el lado del registrador. Si los atacantes obtuvieron permisos del propio Name.com, de la integración entre Vercel y Name.com, o de las cuentas individuales de los proyectos, no está claro a partir de los datos públicos. Hasta nuestra consulta, ni Vercel ni Name.com han hecho comentarios públicos.

Kintsu mencionó en su anuncio que la solución se ha retrasado, lo que puede estar relacionado con el almacenamiento en caché. Los servidores DNS de todo el mundo almacenan en caché la información del lugar de consulta durante un período de tiempo, comúnmente alrededor de una hora. Después de que el equipo del proyecto cambie el registro de nuevo, las computadoras de algunos usuarios pueden seguir usando la respuesta antigua y continuar siendo dirigidas a la tienda falsa. Esto es una especulación nuestra y no ha sido confirmado.

04 Las claves son más que contraseñas

Como se mencionó anteriormente, aún no se ha determinado dónde obtuvieron los atacantes los permisos en el lado del registrador. Independientemente de dónde esté el punto de entrada, la capacidad de cambiar un dominio se reduce en última instancia a una determinada clave. Al hablar de claves, muchas personas piensan en contraseñas de cuentas y códigos de verificación. Aquellos que usan IA para escribir programas y automatizar despliegues en realidad tienen otro tipo de clave: los tokens de acceso.

Los tokens son cadenas de caracteres que permiten a los programas llamar a las interfaces de la plataforma en nombre de los usuarios sin necesidad de contraseñas ni códigos de verificación. Por ejemplo, en Vercel, al crear un token, se debe seleccionar un alcance de permisos[9]: puede gestionar solo un proyecto, todos los proyectos de un equipo, o seleccionar "cuenta completa" para obtener permisos totales. También se debe elegir el tiempo de expiración; después de expirar, el token se invalida automáticamente. Cuanto mayor sea el alcance seleccionado, mayor será la pérdida potencial si el token se filtra.

Hay más formas de que los tokens se filtren de lo que mucha gente cree:

• Escritos en código o archivos de configuración. Si un token se escribe en el código, se envía a un repositorio público o se empaqueta en el front-end, cualquiera puede verlo.

• Entregados al asistente de programación de IA. El asistente de programación lee los archivos de configuración del proyecto u obtiene directamente los tokens pegados por el usuario en la conversación para ayudar a los usuarios a desplegar. El asistente conectado a la plataforma de despliegue a través de MCP tiene la autoridad para modificar nombres de dominio y resoluciones. Esta información se enviará con la conversación, y si el asistente lee una página web o documento que ha sido manipulado, puede ser inducido a ejecutar operaciones que no debería realizar.

• A través de una estación de retransmisión. Algunos usuarios, por costo o conveniencia, no llaman directamente a la interfaz del proveedor de IA, sino que utilizan una "estación de retransmisión" de terceros. Todo el contenido de la conversación pasa por la estación de retransmisión, y si se incluyen tokens, el operador de la estación puede verlos claramente.

• Acceso a varios complementos e integraciones. Cada vez que se integra un servicio de terceros, hay otro lugar donde guardar las claves.

Los tokens que pueden cambiar nombres de dominio pueden filtrarse desde estos lugares.

Cabe señalar que el punto de entrada de este incidente no ha sido concluido; no estamos diciendo que haya sido causado por una fuga de tokens; más bien, en el mundo actual donde la IA escribe programas cada vez más, los tokens que pueden modificar servidores de nombres de dominio y registros de resolución merecen ser protegidos tan seriamente como las claves privadas.

05 Por qué el secuestro de sitios web que involucran activos es especialmente peligroso

Cuando los sitios web normales son secuestrados, los usuarios pueden filtrar sus contraseñas de cuenta en páginas falsas. Para los servicios que involucran activos, como exchanges, billeteras, instituciones de pago y aplicaciones DeFi, una vez que el dominio es secuestrado, las consecuencias suelen ser más directas: cada operación que un usuario realiza en una página falsa puede resultar en una pérdida real de activos.

Esto es especialmente cierto para los activos digitales. Cuando los usuarios hacen clic en "Autorizar", "Intercambiar" o "Apostar" en una página web DeFi, la página web envía una transacción a la billetera y el usuario hace clic en confirmar en la billetera. Lo que la página web envía a menudo es incomprensible para muchos usuarios, que solo pueden confiar en la propia URL. Una URL secuestrada puede enviar una transacción que autorice tokens al atacante; una vez firmada, el atacante puede transferir los fondos en cualquier momento. Una vez completada la transferencia en la cadena, es casi imposible recuperarla.

Lo mismo ocurre con las instituciones de pago. Cuando los usuarios introducen su número de tarjeta y código de verificación en una página de pago, o pagan según la dirección de recepción mostrada, si la página falsa cambia la información de recepción, el dinero acabará en manos del atacante. El nombre de dominio, la página y el proceso que ven los usuarios son idénticos a los que encuentran habitualmente, lo que dificulta su detección.

En mi opinión, el enfoque de la atención a la seguridad en la era de la IA debe cambiar. A medida que más código es escrito por IA, los equipos concentran sus esfuerzos de seguridad en revisiones de código y auditorías de contratos, lo cual no está mal, pero los usuarios aún pasan por registros, registradores, servidores de nombres de dominio y plataformas de despliegue para llegar a un sitio web. Esta vía también es parte de la seguridad, y estas etapas son precisamente donde la IA hace más trabajo y donde la gente entiende menos.

No importa cuán ajustados estén los sistemas backend y los contratos, mientras un eslabón de esta vía sea vulnerado, los usuarios entregarán sus activos en una página falsa.

06 Recomendaciones para proveedores de servicios de aplicaciones y de activos digitales

Aclarar quién posee el nombre de dominio. Compruebe con qué registrador está registrado su nombre de dominio, dónde está el servidor de nombres de dominio y quién gestiona las cuentas relacionadas. Incluso para dominios comprados con un clic en una plataforma, debe saber quién está detrás.

Bloquear el nombre de dominio. Active el bloqueo del registrador para evitar que el dominio se transfiera arbitrariamente. Los proyectos importantes pueden solicitar bloqueos de registro, que requieren verificación manual de identidad al modificar información clave como la dirección de enrutamiento.

Proteger cuentas y tokens. Utilice claves de seguridad de hardware para la autenticación multifactor en las cuentas. Los tokens deben tener solo los permisos mínimos necesarios y establecer tiempos de expiración. Los tokens no deben escribirse en el código, pegarse en conversaciones de IA ni pasar por estaciones de retransmisión desconocidas. Los tokens no utilizados deben eliminarse de inmediato.

Dar al asistente de IA una clave separada. Al permitir que el asistente de IA ayude con el despliegue, cree un token separado para él, otorgando solo los permisos necesarios para el proyecto actual y establezca un tiempo de expiración más corto. Operaciones como comprar un dominio, cambiar servidores de nombres de dominio y transferir dominios deben ser confirmadas por una persona, no dejadas a la IA para que las complete automáticamente.

Supervisar los cambios. Cualquier cambio en los servidores de nombres de dominio, registros de resolución o estado del dominio debe activar una alerta. Los atacantes que habilitan HTTPS en sitios web falsos normalmente necesitan solicitar un nuevo certificado para ese dominio, y los certificados emitidos públicamente tienen registros públicos; supervisar estos registros puede ayudar a detectar anomalías temprano.

Preparar planes de emergencia con antelación. Considere cómo notificar a los usuarios de inmediato si algo sale mal con el dominio y cómo encontrar el servicio de atención al cliente real del registrador. Kintsu se quejó en un anuncio de que el servicio de atención al cliente era solo un robot. En tales situaciones, tener canales humanos preparados de antemano puede determinar la velocidad de mitigación de pérdidas.

07 Cuanto más fácil es lanzarse, más necesario es saber quién tiene las claves

La IA ha facilitado la escritura de código, así como el lanzamiento, la compra de nombres de dominio y la configuración de resoluciones. Las barreras se han reducido, pero las responsabilidades no han disminuido. Cuando los usuarios introducen una URL, están confiando en toda la vía detrás de la URL, así como en todas las personas y programas que tienen las claves.

Estas etapas a menudo son invisibles y rara vez se piensa en ellas, pero a los ojos de los usuarios, son parte del servicio al igual que el código escrito por el proveedor de servicios. Si algún eslabón falla, los usuarios responsabilizarán al proveedor de servicios.

A medida que las herramientas hacen más por nosotros, ¿seguimos entendiendo claramente qué claves hemos entregado?