ИИ напишет код, но кто защитит домены?

Автор: Yajin

31 октября сайты более десятка DeFi-проектов были взломаны один за другим. Один из пострадавших проектов, Kintsu, опубликовал в X[1] сообщение, что его домен, приобретённый через Vercel, был перехвачен на уровне регистратора. В этом заявлении есть два ключевых термина: Vercel и регистратор. Начнём с Vercel.

Vercel — это платформа для развёртывания веб-сайтов. Разработчики отправляют написанный код, а она отвечает за сборку и запуск сайта, после чего доставляет веб-страницы пользователям через серверы, распределённые по всему миру. Vercel также является компанией, стоящей за фреймворком для фронтенда Next.js[2], который очень популярен среди разработчиков, и большинство упомянутых в этот раз проектов размещают свои веб-страницы на Vercel. Помимо хостинга сайтов, Vercel также продаёт домены, позволяя пользователям приобретать домены и управлять настройками DNS из одной панели.

Судя по найденным нами данным, код этих проектов, размещённый на Vercel, не был изменён; изменилось то, куда указывает домен.

Этот инцидент заслуживает внимания каждого поставщика прикладных сервисов, особенно сервисов цифровых активов. За последние два года стал популярен вайб-кодинг (разработка с помощью ИИ на основе описаний) — подход, при котором требования описываются на естественном языке, а программу пишет ИИ. Это значительно снижает порог разработки приложений: ИИ пишет код, вы отправляете его на платформы развёртывания вроде Vercel, Netlify или Cloudflare для запуска в один клик, покупаете домен на платформе — и через несколько минут у вас есть приличный сайт.

Порог снизился, но базовые принципы не стали проще. Многие не знают, где зарегистрирован их домен, кто может изменить, куда он указывает, и какие ключи нужны для изменений. Vercel — лишь один тип платформ; эти вопросы относятся ко всем способам развёртывания в один клик. Цель этой статьи — как можно проще разъяснить эти вопросы.

01 Как браузер находит сайт по URL

Теперь посмотрим, что Kintsu называл «регистратором». Чтобы понять, что делает регистратор, сначала нужно разобраться, как находится URL. Можно представить веб-сайт как магазин. Доменное имя — это название магазина, например example.com; IP-адрес сервера — это номер дома. Пользователи запоминают только название магазина, поэтому кто-то должен переводить название магазина в номер дома, и этот процесс перевода называется «разрешением домена».

В процессе перевода участвуют три роли.

Реестр доменных имён действует как центральное регистрационное бюро. У каждого типа суффикса свой реестр, например .com, .xyz, .finance и т. д. Реестр помнит только одно: где находится «справочная» для определённого доменного имени.

Регистратор выступает посредником, выполняющим поручения пользователей. Обычные люди не могут напрямую обратиться в реестр для регистрации; они должны пройти через регистратора, чтобы купить домен, продлить его или изменить регистрационную информацию. Пользователи могут указать в панели регистратора, какая «справочная» отвечает за их домен.

Сервер имён — это «справочная». У него есть таблица, в которой указано, какое название магазина соответствует какому номеру дома. Каждая строка этой таблицы называется записью разрешения. Когда говорят о «смене разрешения», имеют в виду изменение этой таблицы на сервере имён.

После того как пользователь вводит URL в браузере, браузер сначала спрашивает центральный реестр: где справочная для этого магазина? Затем спрашивает справочную: какой номер дома? Наконец, находит магазин по номеру дома и открывает веб-страницу.

Браузер сначала спрашивает реестр, затем сервер имён и наконец находит магазин по номеру дома.

Итак, если кто-то хочет заманить клиентов в свой поддельный магазин, есть два метода. Первый — пойти в справочную и изменить номер дома в таблице. Второй более скрытный: пойти к регистратору и полностью заменить справочную, зарегистрированную для этого магазина, на свою, а затем записать поддельный номер дома в новой справочной. При использовании второго метода владелец магазина проверяет исходную справочную, и в таблице ничего не изменилось, но клиенты уже уведены.

Два метода: изменить таблицу в справочной или полностью заменить справочную на контролируемую злоумышленником.

02 Кто управляет доменом, купленным в один клик

Поняв реестр, регистратора и сервер имён, мы можем вернуться к платформам развёртывания, таким как Vercel. Платформы развёртывания отвечают за запуск написанных программ в сети. Чтобы упростить жизнь пользователям, многие платформы интегрировали покупку доменов и управление DNS в свою панель, позволяя пользователям взаимодействовать только с платформой от покупки домена до запуска сайта.

Однако за платформой по-прежнему присутствуют все упомянутые ранее роли. Некоторые платформы сами являются регистраторами, другие действуют от имени пользователей, обращаясь к регистраторам; Vercel относится ко второй категории. Мы проверили домен Kintsu, и регистратором, указанным в реестре, является Name.com, а не сам Vercel.

Такой комплексный подход очень удобен, но недостаток в том, что пользователи часто не знают, что у их домена есть регистратор, и вряд ли заботятся о безопасности на уровне регистратора. В панели и интерфейсе Vercel[3] можно изменить сервер имён, а также получить код авторизации для переноса домена. Иными словами, тот, кто владеет учётной записью платформы или правами её интерфейса, потенциально может изменить, куда указывает домен, или даже перенести его.

Многие проекты тщательно проверяют свой код и контракты, но их домены находятся под одной учётной записью, за которой никто не следит, и при возникновении проблем они не знают, к кому обратиться.

В эпоху ИИ «один клик» становится «без единого клика». Инструмент командной строки Vercel[4] теперь поддерживает сценарии и ИИ-ассистентов для покупки и продления доменов без участия человека. Vercel также предоставляет интерфейс MCP для ИИ-ассистентов (стандартный способ вызова внешних инструментов ИИ-ассистентами) с 28 инструментами, связанными с доменами и DNS[5]. Это означает, что когда разработчик говорит ИИ: «Помоги запустить сайт и настроить домен», ИИ может сам выполнить покупку домена и изменение разрешения.

Разработчики экономят не только клики, но и возможность понять эти процессы: под какой учётной записью куплен домен, какой регистратор за ним стоит и кто может его изменить — всё это, скорее всего, никогда не попадётся им на глаза.

Одной фразой ИИ выполнил покупку домена и настройку разрешения для разработчика.

03 Где злоумышленник внёс изменения

Согласно публичным отчётам[6], 31 октября число атакованных сайтов выросло до более чем десятка. Помимо Kintsu, пострадали DeFi-проекты StonkFun, Pickle, Echelon, Origami, Fluxbeam, Stakepoint, SupSwap, Longbow, SHPRD и ApeX DeFi.

Информация о регистрации доменов публична, и любой может её запросить. Мы проверили домены 11 из этих проектов и обнаружили, что у всех регистратором является Name.com, причём у 7 из них 31 октября в реестре были изменения. По состоянию на 18:00 по пекинскому времени 31-го числа 5 доменов всё ещё указывали на серверы злоумышленников.

Злоумышленники использовали оба упомянутых метода. У pickle.finance[7] и stakepoint.app на сервере имён Vercel всё ещё есть таблица с адресом сервера Vercel, что указывает на то, что их исходная справочная должна была находиться на Vercel; однако их справочная, зарегистрированная в реестре, была изменена на сервер имён Name.com около 1:00 UTC 31-го числа, а новый IP-адрес — 31.56.52.52.

В другом случае fluxbeam.xyz, supswap.xyz и apexdefi.xyz изначально имели справочные на Name.com, и регистрация в реестре не менялась с февраля или мая этого года, однако таблица в справочной теперь также указывает IP-адрес 31.56.52.52, что говорит о том, что сама таблица была изменена. Этот адрес зарегистрирован на компанию Snowcore[8], а диапазон IP зарегистрирован в Нидерландах и не связан с Vercel.

URL разных проектов были направлены на один и тот же адрес, контролируемый злоумышленником.

Что касается остальных доменов, некоторые были возвращены на обычные серверы, некоторые перешли на других поставщиков услуг, а другие находятся в процессе переноса домена, что указывает на попытки команд проектов восстановить контроль.

Оба метода объединяет одно: они требуют внесения изменений на стороне регистратора. Получили ли злоумышленники разрешения от самого Name.com, от интеграции между Vercel и Name.com или от учётных записей отдельных проектов, из публичных данных неясно. На момент нашего запроса ни Vercel, ни Name.com публично не комментировали ситуацию.

Kintsu упомянул в своём объявлении, что исправление задерживается, что может быть связано с кэшированием. DNS-серверы по всему миру кэшируют информацию о справочных на некоторое время, обычно около часа. После того как команда проекта вернёт регистрацию, компьютеры некоторых пользователей могут всё ещё использовать старый ответ, продолжая направляться в поддельный магазин. Это наше предположение, и оно не подтверждено.

04 Ключи — это не только пароли

Как упоминалось ранее, до сих пор не установлено, где злоумышленники получили разрешения на стороне регистратора. Независимо от точки входа, возможность изменить домен в конечном счёте сводится к определённому ключу. Говоря о ключах, многие думают о паролях учётных записей и кодах подтверждения. Те, кто использует ИИ для написания программ и автоматизации развёртывания, на самом деле имеют ещё один тип ключей: токены доступа.

Токены — это строки символов, которые позволяют программам вызывать интерфейсы платформы от имени пользователей без паролей и кодов подтверждения. Например, в Vercel при создании токена необходимо выбрать набор разрешений[9]: можно управлять только одним проектом, всеми проектами команды или выбрать «вся учётная запись» для получения полных прав. Также нужно выбрать срок действия; после истечения срока токен автоматически становится недействительным. Чем больше выбранный набор, тем больше потенциальный ущерб при утечке токена.

Способов утечки токенов больше, чем многие думают:

• Запись в код или файлы конфигурации. Если токен записан в код, отправлен в публичный репозиторий или упакован во фронтенд, его может увидеть кто угодно.

• Передача ИИ-ассистенту по программированию. Ассистент читает файлы конфигурации в проекте или напрямую получает токены, вставленные пользователем в диалог, чтобы помочь с развёртыванием. Ассистент, подключённый к платформе развёртывания через MCP, имеет полномочия изменять доменные имена и разрешения. Эта информация будет отправлена вместе с диалогом, и если ассистент прочитает веб-страницу или документ, которые были подменены, его могут побудить выполнить операции, которые не следовало выполнять.

• Через прокси-сервер. Некоторые пользователи ради экономии или удобства не вызывают интерфейс поставщика ИИ напрямую, а используют сторонний прокси-сервер. Весь контент диалога проходит через него, и если в нём есть токены, оператор прокси-сервера может их ясно увидеть.

• Доступ к различным плагинам и интеграциям. Каждый раз при интеграции стороннего сервиса появляется ещё одно место для хранения ключей.

Токены, способные изменять доменные имена, могут утечь из этих мест.

Следует отметить, что точка входа этого инцидента ещё не установлена; мы не утверждаем, что причиной стала утечка токенов; скорее, в современном мире, где ИИ всё чаще пишет программы, токены, способные изменять серверы доменных имён и записи разрешения, заслуживают такой же серьёзной защиты, как и приватные ключи.

05 Почему взлом сайтов, связанных с активами, особенно опасен

При взломе обычных сайтов пользователи могут раскрыть свои пароли на поддельных страницах. Для сервисов, связанных с активами, таких как биржи, кошельки, платёжные учреждения и DeFi-приложения, последствия взлома домена часто более прямые: каждое действие пользователя на поддельной странице может привести к реальной потере активов.

Особенно это касается цифровых активов. Когда пользователи нажимают «Авторизовать», «Обменять» или «Застейкать» на веб-странице DeFi, страница отправляет транзакцию в кошелёк, и пользователь подтверждает её в кошельке. То, что отправляет страница, часто непонятно многим пользователям, и они могут доверять только самому URL. Взломанный URL может отправить транзакцию, которая авторизует токены злоумышленнику; после подписания злоумышленник может перевести средства в любой момент. После завершения перевода в блокчейне вернуть средства практически невозможно.

То же касается платёжных учреждений. Когда пользователи вводят номер карты и код подтверждения на платёжной странице или платят по отображаемому адресу получателя, если поддельная страница изменит информацию о получателе, деньги окажутся у злоумышленника. Доменное имя, страница и процесс, которые видит пользователь, идентичны обычным, поэтому обнаружить подмену сложно.

На мой взгляд, фокус внимания к безопасности в эпоху ИИ должен сместиться. Поскольку всё больше кода пишется ИИ, команды сосредотачивают усилия на проверке кода и аудите контрактов, что не неправильно, но пользователи по-прежнему проходят через реестры, регистраторов, серверы доменных имён и платформы развёртывания, чтобы попасть на сайт. Этот путь также является частью безопасности, и именно на этих этапах ИИ делает больше всего работы, а люди понимают меньше всего.

Какими бы надёжными ни были бэкенд-системы и контракты, если хотя бы одно звено этого пути будет взломано, пользователи отдадут свои активы на поддельной странице.

06 Рекомендации для поставщиков прикладных сервисов и сервисов цифровых активов

Выясните, кто владеет доменным именем. Проверьте, у какого регистратора зарегистрирован ваш домен, где находится сервер доменных имён и кто управляет связанными учётными записями. Даже для доменов, купленных в один клик на платформе, следует знать, кто за этим стоит.

Заблокируйте доменное имя. Включите блокировку переноса у регистратора, чтобы предотвратить произвольный перенос домена. Важные проекты могут подать заявку на блокировку в реестре, требующую ручной проверки личности при изменении ключевой информации, такой как адрес маршрутизации.

Защитите учётные записи и токены. Используйте аппаратные ключи безопасности для многофакторной аутентификации учётных записей. Токены должны иметь только минимально необходимые разрешения и срок действия. Токены не следует записывать в код, вставлять в диалоги с ИИ или передавать через неизвестные прокси-серверы. Неиспользуемые токены следует своевременно удалять.

Выдайте ИИ-ассистенту отдельный ключ. Разрешая ИИ-ассистенту помогать с развёртыванием, создайте для него отдельный токен, предоставив только разрешения, необходимые для текущего проекта, и установите более короткий срок действия. Такие операции, как покупка домена, изменение серверов доменных имён и перенос доменов, должны подтверждаться человеком, а не выполняться ИИ автоматически.

Отслеживайте изменения. Любое изменение серверов доменных имён, записей разрешения или статуса домена должно вызывать оповещение. Для включения HTTPS на поддельных сайтах злоумышленникам обычно требуется получить новый сертификат для этого домена, а публично выданные сертификаты имеют открытые записи; мониторинг этих записей может помочь рано обнаружить аномалии.

Заранее подготовьте планы действий в чрезвычайных ситуациях. Продумайте, как немедленно уведомить пользователей, если с доменом что-то пойдёт не так, и как найти реальную службу поддержки регистратора. Kintsu пожаловался в объявлении, что служба поддержки — всего лишь робот. В таких ситуациях наличие заранее подготовленных каналов связи с людьми может определить скорость снижения потерь.

07 Чем проще запуск, тем важнее знать, у кого ключи

ИИ упростил написание кода, а также запуск, покупку доменов и настройку разрешений. Порог входа снизился, но ответственность осталась прежней. Когда пользователи вводят URL, они доверяют всему пути за этим URL, а также всем людям и программам, владеющим ключами.

Эти этапы часто невидимы и редко обдумываются, но в глазах пользователей они являются частью сервиса, как и код, написанный поставщиком. Если какое-либо звено выйдет из строя, пользователи возложат ответственность на поставщика.

По мере того как инструменты делают за нас всё больше, понимаем ли мы по-прежнему ясно, какие ключи мы передали?