Сигурност на хотелските поддомейни: Скрити заплахи и начини за защита

Случай, станал с един наш клиент, ни накара да проучим тази тема в дълбочина. IT мениджърът на бутиков хотел в Истанбул смятал, че са напълно защитени, след като са поставили основния си сайт зад Cloudflare. Въпреки това, няколко седмици по-късно се активирал фалшив сайт за резервации, използващ точно истинския IP адрес на сървъра на хотела. Как се беше случило това?

Отговорът беше прост: поддомейнът „mail.oteladi.com“ сочеше директно към стария имейл сървър, който не беше конфигуриран с Cloudflare. И този IP адрес беше публично достъпен за всички.

Поддомейнът (subdomain) е префикс, добавен пред основния домейн. „www.oteladi.com“ е поддомейн; „rezervasyon.oteladi.com“ също. Хотелите обикновено създават десетки поддомейни през годините: сайт за кампания за един сезон, стар модул за резервации, тестова среда, корпоративна имейл инфраструктура и много други.

Част от тези поддомейни се забравят с времето. DNS записите не се изтриват, те продължават да сочат към стари сървъри. И тези забравени адреси могат да бъдат златна мина за измамниците.

Cloudflare и подобни CDN (Мрежа за доставка на съдържание) услуги добавят защитен слой пред уебсайтовете. По този начин истинският IP на сървъра се скрива. Тази защита обаче е валидна само за записи, конфигурирани чрез Cloudflare.

Поддомейн като „mail.oteladi.com“ трябва да сочи директно към IP адреса на сървъра за SMTP (имейл) трафик. Имейл протоколът не може да бъде насочен през Cloudflare. Това означава, че ако някой проучи поддомейна „mail“ с просто DNS запитване, може лесно да открие истинския IP.

В нашите проучвания открихме такива отворени записи на поддомейни в повече от седемдесет и пет процента от изследваните турски хотели. Някои от тях бяха адреси на стара инфраструктура, неизползвани от години, но все още достъпни. За повече информация относно връзката между SSL сертификатите и поддомейните прочетете нашата статия sahte-ssl-sertifika-tespiti-rehberi.

Терминът „Dangling 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 записът не бъде изтрит при изтриване на bucket-а, всеки, който може да създаде нов bucket със същото име като изтрития, може да превземе този поддомейн. Това се нарича „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 изброяване): Изпробва често срещани поддомейни като „www“, „mail“, „ftp“, „admin“ с инструменти за brute-force DNS
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 и защо представлява риск за моя хотел? Subdomain takeover е превземането от нападатели на поддомейн, чийто DNS запис съществува, но вече не е активен. Нападателят може да насочи DNS записа към собствения си сървър, като отвори акаунт в платформата на изтритата услуга. В този случай поддомейнът, носещ репутацията на хотела, може да бъде използван като фишинг сайт.

Как мога да разбера колко поддомейна имам? Можете да експортирате всички записи от вашия DNS панел за управление (cPanel, Cloudflare, Route53). Освен това можете да видите сертификатите, принадлежащи на всички поддомейни, регистрирани в CT логовете, като потърсите името на вашия домейн чрез crt.sh. Комбинацията от тези два метода осигурява най-изчерпателния опис.

Не мога ли да поставя имейл поддомейните зад проксито на Cloudflare? Не, SMTP имейл трафикът не може да бъде насочен през проксито на Cloudflare. Поради тази причина поддомейни като „mail.“, „smtp.“ винаги разкриват истинския IP. За решение се препоръчва преместване на имейл инфраструктурата към отделен IP или облачна имейл услуга.

Няма ли да е вредно да изтрия DNS записите на стари поддомейни? Не, напротив, полезно е. Изтриването на DNS записа на неизползвани поддомейни елиминира риска за сигурността. Ако не сте сигурни дали все още идва трафик към този адрес, анализирайте типа запис, преди да изтриете DNS записа; след това можете безопасно да го премахнете.

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