6 октября команда Chrome Secure Web and Networking рассказала в блоге Google об угоне доменов в национальных зонах .gh (Гана), .sl (Сьерра-Леоне) и .as (Американское Самоа). Атакующие взломали не Google, а сами реестры этих ccTLD, поменяли авторитативные DNS-записи и выпустили HTTPS-сертификаты на несколько доменов Google и на домены других организаций. На русском новость вышла на opennet.
Под угрозой оказался любой домен в .gh, .sl и .as. Если у вашей компании есть региональный домен в одной из этих зон, даже припаркованный, его стоит проверить прямо сейчас.
Как получили сертификаты: подмена DNS и проверка домена
Схема простая. Удостоверяющий центр перед выдачей сертификата проверяет, что вы управляете доменом (domain control validation, DCV): через DNS-запись или файл на сайте. Когда NS-записи домена указывают на серверы атакующих, все эти проверки уходят к ним, и они их спокойно проходят. Поэтому Google считает, что сами УЦ, которые выдали эти сертификаты, ничего не нарушили.
По словам Google, кроме нескольких его собственных доменов, от атак пострадали крупные мировые бренды и популярные онлайн-сервисы.
Что сделал Chrome: CRLSets, отзыв и логи CT
Для доменов Google Chrome сразу заблокировал поддельные сертификаты через CRLSets, это его собственный список отозванных сертификатов, который браузер получает с обновлениями. Вместе с УЦ, которые их выпустили, Google добился отзыва, чтобы защитить и тех, кто сидит не в Chrome.
Потом в логах Certificate Transparency (CT) нашлись другие организации, которые, судя по всему, пострадали от тех же атак. Их сертификаты Chrome тоже заблокировал на опережение, а владельцев, до кого смогли достучаться, Google предупредил. Пользователям Chrome ничего делать не нужно.
Что делать владельцу домена: мониторинг CT
Google прямо пишет, что надеяться на браузер не стоит: при угоне DNS нельзя гарантировать, что найдены все затронутые домены, а блокировка в Chrome не защищает людей с другими браузерами. Первый совет: постоянно следить за логами CT по всем своим доменам. Любой сертификат, которому Chrome доверяет по умолчанию, обязан попасть в публичные CT-логи, так что мониторинг CT почти сразу покажет новый сертификат на ваш домен.
Следить надо за всем набором доменов, включая припаркованные и региональные. Если у вас домен в .gh, .sl или .as, посмотрите последние записи в CT на предмет неожиданных сертификатов. Быстро глянуть можно через crt.sh:
curl -s 'https://crt.sh/?q=example.gh&output=json' | jq -r '.[] | [.not_before, .issuer_name, .name_value] | @tsv' | sort -r | head -20
Записи CAA с привязкой к ACME-аккаунту
Второй совет: опубликовать строгие записи CAA, где перечислены УЦ, которым можно выпускать сертификаты на домен. Во время самого угона CAA не спасёт, ведь DNS в руках атакующих. Зато она важна после того, как контроль над DNS вернули: УЦ могут кешировать пройденную проверку домена и выдавать по ней новые сертификаты. Строгая CAA, особенно с привязкой к конкретному аккаунту и способу проверки по RFC 8657, не даст атакующему выпустить что-то ещё по старой проверке.
Например, если сертификаты выпускает только Let’s Encrypt через ваш ACME-аккаунт и только через DNS-проверку, записи могут выглядеть так (номер аккаунта свой):
example.gh. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456789; validationmethods=dns-01" example.gh. IN CAA 0 issuewild ";" example.gh. IN CAA 0 iodef "mailto:security@example.gh"
В дальнейшем Google собирается через Chrome Root Program и дальше сокращать срок жизни сертификатов и время, которое УЦ может использовать старую проверку домена.
В итоге атакующие взломали реестры трёх национальных зон, подменили DNS и честно прошли проверку домена у УЦ. Chrome заблокировал найденные сертификаты через CRLSets, а УЦ их отозвали, но Google не гарантирует, что найдено всё. Для своих доменов надёжнее всего мониторинг CT и строгие записи CAA с accounturi.
