Безопасность поддоменов отеля: Скрытые угрозы и способы защиты

Случай, произошедший с одним из наших клиентов, побудил нас к глубокому изучению этой темы. IT-менеджер бутик-отеля в Стамбуле думал, что они находятся в полной безопасности после того, как перевели свой основной сайт за Cloudflare. Однако через несколько недель активировался поддельный сайт бронирования, использующий в точности реальный IP-адрес сервера отеля. Как это случилось?

Ответ был прост: поддомен "mail.oteladi.com" указывал напрямую на старый почтовый сервер, не настроенный с Cloudflare. И этот IP-адрес был открыт для всех.

Поддомен (субдомен) — это префикс, добавляемый перед основным доменом. "www.oteladi.com" — это поддомен; "rezervasyon.oteladi.com" — тоже. Отели обычно создают десятки поддоменов за годы: сайт кампании, созданный для одного сезона, старый движок бронирования, тестовая среда, корпоративная почтовая инфраструктура и многое другое.

Часть этих поддоменов со временем забывается. Записи DNS не удаляются, они продолжают указывать на старые серверы. И эти забытые адреса могут стать золотой жилой для мошенников.

Сервисы CDN (Content Delivery Network), такие как Cloudflare, добавляют защитный слой перед веб-сайтами. Благодаря этому реальный IP-адрес сервера скрывается. Однако эта защита действует только для записей, настроенных через Cloudflare.

Поддомен вроде "mail.oteladi.com" для трафика SMTP (электронная почта) вынужден указывать напрямую на IP сервера. Протокол электронной почты не может быть направлен через Cloudflare. Эта ситуация означает, что если кто-то изучит поддомен «mail» с помощью простого DNS-запроса, он легко найдет реальный IP.

В ходе наших исследований мы обнаружили такие открытые записи поддоменов у более чем 75% изученных турецких отелей. Часть из них была адресами старой инфраструктуры, не использовавшейся годами, но они все еще были доступны. Для получения дополнительной информации о связи между SSL-сертификатами и поддоменами прочтите нашу статью sahte-ssl-sertifika-tespiti-rehberi.

Термин "Dangling DNS" (висячий DNS) описывает ситуацию, когда запись DNS все еще существует, но сервер или сервис, на который она указывает, больше не активен. Эта ситуация представляет собой распространенную, но часто незамеченную угрозу в гостиничном секторе.

Отель много лет назад заключил договор со сторонним движком бронирования. Для этого движка был создан поддомен "rezervasyon.oteladi.com" и направлен на сервер этой компании. В последующие годы движок был изменен, открыт новый поддомен для нового провайдера; однако старая запись DNS осталась на месте, так как никто о ней не вспомнил.

В этот момент могут возникнуть три сценария. В первом сценарии сторонняя компания закрылась, и этот IP-адрес был назначен другому клиенту. Новый владелец IP может направить трафик, приходящий на адрес "rezervasyon.oteladi.com", на свой сервер. Во втором сценарии провайдер прекратил обслуживание, но запись доменного имени все еще указывает на них. В третьем сценарии злоумышленник, купив этот IP-адрес, может создать фишинговый сайт через поддомен, используя репутацию отеля.

Некоторые отели размещают рекламные материалы или старый контент блога в сервисах облачного хранения, таких как AWS S3, Azure Blob или Google Cloud Storage. Для этих сервисов настроены поддомены вроде "cdn.oteladi.com" или "media.oteladi.com", однако при окончании контракта бакет (bucket) хранилища удаляется.

Если при удалении бакета запись DNS не удалена, любой, кто может создать новый бакет с тем же именем, что и удаленный, может захватить этот поддомен. Это называется "subdomain takeover" (захват поддомена), и в наших исследованиях это ситуация, время от времени встречающаяся на сайтах турецких отелей.

Поддомены, созданные во время интеграции с SaaS-сервисами, такими как программное обеспечение для управления бронированием, менеджер каналов или программа лояльности клиентов, могут остаться бесхозными после окончания договора на обслуживание. Адреса вроде "loyalty.oteladi.com" или "crm.oteladi.com" могут оставаться в записях DNS в течение месяцев или даже лет.

Поддомены вроде "mail.", "smtp.", "imap.", "webmail." указывают на почтовую инфраструктуру. Они всегда оставляют реальный IP открытым. Эксперты отрасли особенно подчеркивают, что управление записями DNS этих поддоменов должно осуществляться осторожно.

Поддомены вроде "summer2022.", "kampanya.", "rez.", "booking." могли быть открыты для старых проектов и забыты. Эти адреса могли быть проиндексированы поисковыми системами и оставаться привязанными напрямую к серверу.

Поддомены вроде "dev.", "test.", "staging.", "beta." являются наиболее опасными с точки зрения безопасности. Потому что эти среды обычно работают с неполной конфигурацией безопасности и могут иметь доступ к производственным базам данных.

Поддомены вроде "admin.", "panel.", "cpanel.", "wp-admin." могут указывать напрямую на панели доступа. При неправильной конфигурации они и раскрывают IP, и становятся целью атак brute force (перебор паролей).

Когда мошенник или злоумышленник хочет узнать реальный IP-адрес отеля, он выполняет следующие шаги:

1. DNS enumeration (перечисление DNS): С помощью инструментов перебора DNS пробует распространенные поддомены, такие как «www», «mail», «ftp», «admin».
2. Логи Certificate Transparency: Через crt.sh просматривает все сертификаты, выданные для этого домена, перечисляя используемые поддомены.
3. Веб-архив: Ищет старые записи DNS в Wayback Machine и подобных архивах.
4. Обратный запрос IP: Перечисляет все сайты, размещенные на этом IP до Cloudflare.

Эти четыре шага завершаются за несколько минут и в большинстве случаев позволяют добраться до реального IP. Вы можете найти более подробную информацию о методах, используемых мошенниками для обхода защитного слоя Cloudflare, в нашей статье otel-domain-guvenligi-typosquatting.

Первый и самый критический шаг — собрать воедино все имеющиеся у вас записи DNS. Мы видим, что многие отели не знают собственного списка поддоменов. Экспортируйте все записи A, CNAME и MX из вашей панели управления DNS.

Удалите записи DNS для неиспользуемых поддоменов, таких как старый сайт кампании, старая инфраструктура CRM, старая интеграция электронной коммерции. Это и закроет уязвимость, и упростит управление доменным именем.

По возможности направляйте поддомены, которые вы продолжаете использовать (кроме панели управления), через прокси Cloudflare. Таким образом, реальный IP-адрес останется скрытым.

Разрешите доступ к поддоменам управления, таким как "admin." или "cpanel.", только с определенных IP-адресов. Это предотвратит атаки brute force и попытки несанкционированного доступа.

Хотя бы раз в месяц проверяйте все имеющиеся у вас поддомены с помощью инструментов сканирования. У вас будет шанс на раннее обнаружение при появлении новой уязвимости.

В одном курортном отеле на побережье Эгейского моря, который мы изучали, все еще был активен поддомен, принадлежащий старому движку бронирования, выведенному из эксплуатации два года назад. Тот, кто добирался до реального IP-адреса отеля через этот поддомен, мог обнаружить и другие сервисы, размещенные на том же IP. Когда мы проинформировали отель, менеджеры совершенно не знали об этом поддомене.

Что такое захват поддомена (subdomain takeover) и почему он представляет риск для моего отеля? Захват поддомена — это захват злоумышленниками поддомена, запись DNS которого существует, но сам сервис уже не активен. Злоумышленник может создать аккаунт на платформе удаленного сервиса и направить запись DNS на свой сервер. В этом случае поддомен, несущий репутацию отеля, может быть использован как фишинговый сайт.

Как я могу узнать, сколько у меня поддоменов? Вы можете экспортировать все записи из своей панели управления DNS (cPanel, Cloudflare, Route53). Также, выполнив поиск по своему доменному имени через crt.sh, вы можете увидеть сертификаты, принадлежащие всем поддоменам, зарегистрированным в логах CT. Сочетание этих двух методов обеспечивает наиболее полную инвентаризацию.

Разве я не могу перевести поддомены электронной почты за прокси Cloudflare? Нет, трафик электронной почты SMTP не может быть направлен через прокси Cloudflare. По этой причине поддомены вроде "mail.", "smtp." всегда раскрывают реальный IP. В качестве решения рекомендуется перенести почтовую инфраструктуру на отдельный IP или облачный почтовый сервис.

Не будет ли вредным удаление записей DNS старых поддоменов? Нет, наоборот, это полезно. Удаление записи DNS неиспользуемых поддоменов устраняет риск безопасности. Если вы не уверены, поступает ли все еще трафик на этот адрес, проанализируйте тип записи перед удалением записи DNS; затем вы сможете смело ее убрать.

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