9 октября 2026Команда Сарнас

Захват доменов Google через компрометацию ccTLD-регистраторов

Google раскрыла серию захватов своих доменов в национальных зонах .gh, .sl и .as — и атака шла не через сервисы компании, а через компрометацию ccTLD-реестров, что позволило злоумышленникам менять DNS-записи и получать валидные TLS-сертификаты. Разбираем, как устроена цепочка «реестр — регистратор — регистрант», почему взлом реестра даёт контроль над всей зоной и какие меры — от мониторинга Certificate Transparency до записей CAA — действительно помогают владельцам доменов.

В конце 2024 года Google раскрыла серию захватов своих доменов в национальных доменах верхнего уровня. Атака шла не через взлом самих сервисов Google, а через реестры ccTLD: злоумышленники получали доступ к административным операциям с доменами и меняли авторитетные DNS-записи. Чтобы понять, как такое вообще возможно и почему защита оказалась частичной, нужно разобрать цепочку «реестр — регистратор — регистрант», протокол EPP, механику трансфера и то, как устроены WHOIS и RDAP.

Что произошло

Атаки затронули домены в ccTLD .gh (Гана), .sl (Сьерра-Леоне) и .as (Американское Самоа). Злоумышленники изменяли авторитетные DNS-записи, что позволило направлять домены .GH, .SL и .AS на контролируемую ими инфраструктуру и получать действительные TLS-сертификаты для этих доменов. Это дало возможность выдавать себя за легитимные бренды и показывать посетителям произвольный контент с затронутых доменов.

Google заблокировала несанкционированные сертификаты для своих ресурсов в Chrome через CRLSets и работала с центрами сертификации для их отзыва. Анализ журналов Certificate Transparency выявил дополнительные организации, включая ведущие мировые бренды и популярные онлайн-сервисы, предположительно пострадавшие от тех же атак; Google превентивно заблокировала эти сертификаты в Chrome.

Почему полноту списка пострадавших гарантировать нельзя

Google не может гарантировать, что анализ выявил все затронутые домены, из-за сложности DNS-перехватов. Второе ограничение — охват защиты: CRLSets покрывает только пользователей Chrome, поэтому вмешательства Chrome не защищают надёжно пользователей других браузеров. Пользователям Chrome при этом не нужно предпринимать никаких действий.

Владельцам доменов рекомендуется мониторить журналы CT по всему портфелю доменов, включая припаркованные, и публиковать ограничительные записи CAA. Такой мониторинг позволяет практически мгновенно узнавать о выпуске сертификатов, поскольку сведения о любом сертификате, которому по умолчанию доверяет Chrome, должны публиковаться в открытых журналах CT.

Что дают записи CAA

Записи DNS типа CAA позволяют владельцам доменов указывать, каким центрам сертификации разрешено выпускать сертификаты. Такая запись не может предотвратить выпуск сертификата в момент активного перехвата управления DNS, но служит важным средством защиты после восстановления контроля над DNS и способна полностью предотвратить некоторые атаки, использующие уязвимости маршрутизации или протокола HTTP.

Отдельный эффект связан с кэшированием проверки: центрам сертификации разрешено кэшировать и повторно использовать результаты проверки контроля над доменом (DCV) для последующего выпуска сертификатов. Поэтому восстановление строгой политики CAA, особенно ограничивающей выпуск конкретными авторизованными учётными записями и методами проверки, не позволит злоумышленнику воспользоваться кэшированным статусом проверки для выпуска новых сертификатов после прекращения перехвата.

Кто за что отвечает при регистрации домена

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

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

EPP: зачем нужен и почему через него угоняют домены

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

Обмен идёт XML-сообщениями по SSL/TLS, обычно на порту 700. Почти вся функциональность EPP становится доступной только после аутентификации на EPP-сервере. EPP-серверы — один из наиболее критических элементов инфраструктуры в мире доменов, поэтому компрометация учётных данных регистратора даёт доступ к административным операциям с доменами, а через взлом реестра можно получить контроль над каждым доменом в его зоне.

Команды EPP

Протокол определяет команду <login>, которая устанавливает сессию с сервером EPP в ответ на приветствие сервера; она должна быть отправлена до любой другой команды. Команда <logout> завершает сессию и должна быть представлена как пустой элемент без дочерних элементов; при успешной обработке сервер отвечает без <resData> и завершает текущую сессию.

Пять команд преобразования объектов:

<create> создаёт экземпляр объекта на неопределённый срок или на конкретный период действия;
<delete> удаляет экземпляр существующего объекта;
<renew> продлевает срок действия существующего объекта;
<transfer> управляет сменой спонсирующего клиента объекта;
<update> изменяет данные существующего объекта.

При успешной обработке <create> и <delete> сервер может ответить элементом <resData> с объектно-зависимыми дочерними элементами.

Сессия EPP и аутентификация

Команда <login> помимо стандартных элементов содержит: <clID> — назначенный сервером идентификатор клиента; <pw> — открытый текстовый пароль клиента (значение чувствительно к регистру); необязательный <newPW> — новый пароль для последующих <login>; <options> с <version> (версия протокола) и <lang> (язык текстовых ответов); <svcs> с одним или более <objURI> (namespace URI объектов для управления в сессии) и необязательным <svcExtension>.

Значения <version> и <lang> должны точно совпадать с одним из значений, представленных в приветствии EPP. Идентификатор клиента и начальный пароль должны быть созданы на сервере до того, как клиент сможет успешно завершить <login>, и доставлены клиенту внеполосным методом, защищающим их от случайного раскрытия. При успешной обработке сервер отвечает без <resData> и создаёт и поддерживает новую сессию.

Механизм аутентификации EPP похож на PLAIN SASL из RFC 4616, но EPP не требует идентификатора авторизации уровня сессии, а идентификатор пользователя и пароль разделены на отдельные XML-элементы. PLAIN SASL передаёт идентификаторы и пароль как одну строку, разделённую символами ASCII NUL, тогда как EPP использует объединённый идентификатор авторизации и аутентификации и пароль, предоставляемые как отдельные XML-элементы. Дополнительные схемы идентификации и авторизации должны обеспечиваться на других уровнях протокола для более надёжных служб безопасности.

Формат ответа и атомарность команд

Ответ строится из одного или нескольких элементов <result>. У <result> есть атрибут code — четырёхзначное десятичное число, описывающее успех или неуспех команды, и дочерний элемент <msg> с человекочитаемым описанием; язык описания задаётся необязательным атрибутом lang, по умолчанию "en". Дополнительно может быть ноль или более <value>, указывающих предоставленный клиентом элемент или другую информацию, вызвавшую ошибку сервера, и ноль или более <extValue> для дополнительной диагностики.

Команды EPP атомарны: команда либо полностью успешна, либо полностью неуспешна, а результаты успеха и неуспеха не должны смешиваться. Поэтому при успешной обработке команды должен возвращаться только один <result>, а при неуспешной может возвращаться несколько <result> для документирования условий отказа.

Как работает transfer

authInfo служит подтверждением права на операцию трансфера. В команде <transfer> она передаётся как необязательный элемент <domain:authInfo>, содержащий <domain:pw>; атрибут roid указывает registrant или contact, если пароль относится к ним, а не к самому домену. Если authInfo не предоставлена или неверна, серверная политика решает, отклонить команду или вернуть информацию. В схеме authInfo может присутствовать в <info> и в <chg> команды <update>.

Команда <transfer> управляет сменой спонсирующего клиента; клиент задаёт действие атрибутом op: request — запросить передачу, cancel — отменить запрос, approve — одобрить, reject — отклонить. Для доменов команда обязана содержать <domain:transfer> с <domain:name> (полное имя домена) и необязательным <domain:period> — число единиц, добавляемых к сроку регистрации при завершении передачи; period используется только при запросе и игнорируется в остальных случаях.

Получив запрос, сервер обязан уведомить текущего спонсирующего клиента: либо поставить служебное сообщение в очередь для выборки командой <poll>, либо сообщить вне протокола. Текущий спонсирующий клиент может явно одобрить запрос командой <transfer> с op="approve" или отклонить с op="reject". Сервер может сам одобрить или отклонить запросы, по которым клиент не отреагировал за фиксированное время; срок ожидания и поведение по умолчанию определяются локально и должны быть задокументированы в профиле сервера.

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

Статус трансфера и ограничения доступа

Клиент узнаёт статус ожидающих и завершённых transfer-запросов через команду <transfer> с op="query". При успешной обработке сервер обязан вернуть <resData> с дочерним элементом, определяющим пространство имён объекта, а его дочерние элементы должны включать идентификатор объекта, статус переноса, идентификатор клиента-инициатора, дату и время запроса, идентификатор уполномоченного клиента, дату и время ожидаемого действия, а также опциональную дату/время изменения срока действия объекта. Элемент <domain:trDate> — опциональный, содержит дату и время последнего успешного переноса домена и не должен предоставляться, если домен никогда не переносился.

Статус трансфера считается чувствительной информацией, поэтому объектные отображения должны ограничивать запросы трансфера авторизованными клиентами, например требуя авторизационную информацию. Команду <renew> рекомендуется ограничивать спонсирующим клиентом, а команду <poll> — авторизованными клиентами с постановкой сообщений в очередь и ограничением доступа к очереди на по-клиентской основе.

Политика ICANN: роли и обязанности

Registrar of Record обязан подтвердить намерение владельца, уведомив его о поступившем от реестра уведомлении о трансфере. Gaining Registrar отвечает за проверку запросов владельца на перевод домена между регистраторами. Передача команды "transfer" сама по себе является заявлением Gaining Registrar о том, что требуемая авторизация получена от Transfer Contact в авторитетной Whois-базе.

Право одобрить или отклонить трансфер принадлежит Administrative Contact и Registered Name Holder, указанным в Whois Losing Registrar или реестра; при споре приоритет у Registered Name Holder.

FOA и требования к форме запроса

FOA существует в двух вариантах: «Initial Authorization for Registrar Transfer» — её использует Gaining Registrar для запроса авторизации у Transfer Contact, и «Confirmation of Registrar Transfer Request» — её использует Registrar of Record для запроса подтверждения.

FOA должна быть сообщена на английском языке, и любой спор, возникающий из запроса на трансфер, ведётся на английском; регистраторы могут использовать дополнительные языки, но несут ответственность за точность и полноту перевода. Регистратор не должен добавлять никакой дополнительной информации в FOA, используемую для получения согласия Transfer Contact. FOA должна быть отправлена Registrar of Record Registered Name Holder как можно скорее, но не позднее 24 часов после получения запроса на трансфер от Registry Operator.

Основания для отказа в трансфере

Обязательный отказ предусмотрен при: ожидающемся разбирательстве UDRP , о котором регистратору сообщили; судебном приказе компетентного суда; ожидающемся споре по предыдущему трансферу в рамках Transfer Dispute Resolution Policy; разбирательстве URS или приостановке URS, о которых регистратору сообщили; а также если регистратор установил 60-дневную блокировку трансфера после Change of Registrant , и владелец домена не отказался от этой блокировки заранее.

Отказ допустим при разумном споре о личности владельца домена или административного контакта; при неоплате за предыдущий период регистрации (с обязательным переводом домена в статус Registrar Hold до отказа); при явном возражении уполномоченного Transfer Contact; если трансфер запрошен в течение 60 дней с даты создания домена; и если домен находится в пределах 60 дней после трансфера.

При этом Registrar of Record не может отказать только из-за подозрения, что Gaining Registrar не получил подтверждение: политика прямо запрещает такой отказ и устанавливает презумпцию получения и аутентификации запроса. Отсутствие ответа от владельца домена или административного контакта также не является основанием для отказа, как и статус Registrar Lock, если владельцу предоставлена разумная возможность снять блокировку до запроса на трансфер.

Документы и канал TEAC

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

TEAC создаётся для срочных коммуникаций, связанных с трансферами. Сообщения, отправленные по каналу TEAC, должны порождать неавтоматизированный ответ человека-представителя Gaining Registrar, причём отвечающий должен быть способен и уполномочен расследовать и решать срочные вопросы трансфера. Ответ требуется в течение 4 часов с момента первоначального запроса, хотя окончательное разрешение инцидента может занять больше времени.

Change of Registrant

Change of Registrant — это Material Change (существенное изменение) любого из следующих данных: имени, организации или email-адреса Prior Registrant, либо email-адреса административного контакта, если email Prior Registrant отсутствует. Material Change — это изменение, не являющееся исправлением опечатки; к нему относятся: изменение имени или организации Registered Name Holder, которое не выглядит просто исправлением опечатки; любое изменение имени или организации, сопровождаемое сменой адреса или телефона; любое изменение email-адреса Registered Name Holder.

Регистратор обязан обработать смену в течение одного дня с момента получения подтверждений от Prior Registrant и New Registrant, а также уведомить обе стороны до или в течение одного дня после завершения смены. После смены регистратор обязан наложить 60-дневную блокировку межрегистраторского переноса, но может разрешить Registered Name Holder отказаться от неё до запроса на смену.

На снятие статуса ClientTransferProhibited накладывается ограничение: если регистратор применяет этот EPP-статус для 60-дневной блокировки, он должен также заблокировать домен так, чтобы Registered Name Holder не мог снять блокировку. При этом регистратор может, но не обязан устанавливать ограничения на снятие блокировки, например снимать только через пять рабочих дней или после утвердительного ответа Prior Registrant по email.

WHOIS и RDAP

WHOIS — основанный на TCP протокол запросов и ответов, содержимое передаётся в удобочитаемом для человека формате. Сервер слушает TCP-порт 43, клиент отправляет текстовый запрос, сервер отвечает текстовым содержимым; все запросы завершаются ASCII CR, затем ASCII LF. Ответ может содержать более одной строки, поэтому наличие ASCII CR или ASCII LF не означает конец ответа; сервер закрывает соединение, как только вывод завершён, и именно закрытое TCP-соединение служит клиенту признаком того, что ответ получен.

У протокола нет положений для сильной безопасности: отсутствуют механизмы контроля доступа, целостности и конфиденциальности, поэтому службы на основе WHOIS следует использовать только для несекретной информации, предназначенной для всеобщего доступа. WHOIS также не интернационализирован и не имеет механизма указания используемого набора символов, что негативно влияет на совместимость и полезность протокола.

RDAP — это протокол доступа к регистрационным данным, использующий HTTP. При пустом результате RDAP-сервер возвращает 404 (Not Found), при невозможности выдать информацию по политическим причинам — код из диапазона 4xx, при неинтерпретируемом запросе — 400 (Bad Request), при превышении лимитов — 429 (Too Many Requests), и клиент должен снизить частоту запросов и учесть заголовок Retry-After. Для кросс-доменных запросов из браузера рекомендуется заголовок Access-Control-Allow-Origin, значение "*" подходит для публичных ресурсов; использование Access-Control-Allow-Credentials не рекомендуется. Перенаправление на другой сервер выполняется через поле Location.

Как клиент находит авторитетный RDAP-сервер

bootstrapping нужен потому, что единого RDAP-сервера для всех доменов нет: у каждой зоны свой авторитетный сервис, и клиент должен сначала определить, куда именно отправлять запрос. Порядок этого поиска описан в RFC 7484.

Авторитетный сервис регистрационных данных домена находится сопоставлением меток (label-wise longest match) целевого доменного имени со значениями в массивах записей реестра IANA Bootstrap Service Registry for Domain Name Space. Сопоставление идёт по меткам справа налево; если самый длинный совпавший результат даёт несколько записей, они считаются эквивалентными.

Например, запрос для a.b.example.com совпадает с записью com, и базовый URL берётся из второго элемента массива — массива базовых RDAP URL, действительных для этой записи. Если запрос совпадает и с com, и с example.com, применяется самое длинное совпадение, и клиент использует запись example.com. А при наличии записей com и goodexample.com запрос для example.com совпадёт только с com, поскольку сопоставление идёт по меткам. Клиент выбирает один из базовых URL из массива, затем к базовому URL добавляется сегмент, определённый в RFC 7482, чтобы завершить запрос. Базовые RDAP URL должны иметь завершающий символ "/", так как они конкатенируются с различными сегментами. Запись для корня доменного пространства задаётся как "".

Что из этого следует на практике

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

Защита на стороне браузера ограничена: CRLSets охватывает только Chrome, и Google прямо признаёт, что не гарантирует выявление всех затронутых доменов. Записи CAA не мешают выпуску сертификата при активном перехвате DNS, но предотвращают получение новых сертификатов по кэшированной проверке после восстановления контроля — именно поэтому их публикация имеет смысл как пост-инцидентная мера.

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