subdomain takeover

Subdomain takeover to przejęcie przez atakującego kontroli nad subdomeną cudzej domeny ^[1]. Zwykle dochodzi do niego, gdy subdomena ma w DNS rekord CNAME, ale żaden host nie serwuje dla niej treści, bo usługę dopiero zakładano albo już ją usunięto ^[1]. Atakujący rejestruje wtedy tę samą nazwę u tego samego dostawcy i od tej chwili publikuje własne treści pod adresem ofiary. Microsoft nazywa takie osierocone wpisy „dangling DNS” i ocenia to zagrożenie jako częste i poważne w organizacjach, które często tworzą i usuwają zasoby ^[2].

Jak działa

Podatność powstaje na styku dwóch systemów: strefy DNS właściciela domeny i konta u dostawcy hostingu, platformy SaaS albo CDN. Rekord CNAME mówi przeglądarce, żeby po treść dla blog.example.com szła do usługi dostawcy. Dostawca decyduje, które konto obsługuje tę nazwę. Jeśli konto zniknęło, a rekord został, nazwa jest wolna do zajęcia.

MDN opisuje dwa momenty, w których to się zdarza ^[1]:

• przy uruchamianiu — atakujący zakłada wirtualny host dla subdomeny szybciej niż jej właściciel, jeśli dostawca nie sprawdza, kto naprawdę jest właścicielem nazwy;
• przy wygaszaniu — właściciel usuwa wirtualny host, ale zostawia wpis DNS wskazujący na dostawcę, więc atakujący zakłada tam własny host i przejmuje subdomenę.

Scenariusz opisany przez Microsoft ma trzy etapy: utworzenie zasobu i rekordu CNAME, usunięcie zasobu bez usunięcia rekordu, a potem przejęcie, w którym atakujący wykrywa osieroconą subdomenę powszechnie dostępnymi narzędziami i zakłada zasób o tej samej nazwie ^[2]. Pokazuje to schemat poniżej.

RYS. 1Subdomain takeover po wygaszeniu usługi

Odmiany

Najczęściej opisywany jest rekord CNAME, który według Microsoftu jest na to zagrożenie szczególnie podatny ^[2]. Nie jest jednak jedyny.

GitHub zdecydowanie odradza rekordy wieloznaczne typu *.example.com, bo stwarzają natychmiastowe ryzyko przejęcia: nawet po weryfikacji domeny głównej atakujący może zająć subdomenę objętą takim rekordem ^[3]. Ten sam dokument wymienia sytuacje, w których przejęcie staje się możliwe: usunięcie repozytorium, obniżenie planu rozliczeniowego albo każda inna zmiana, która odłącza domenę, gdy ta pozostaje skonfigurowana i niezweryfikowana ^[3].

Subdomain takeover należy odróżnić od ataku przejęcie DNS (DNS hijacking). W przejęciu DNS atakujący zmienia rekordy albo serwery nazw. Przy subdomain takeover rekordy są nietknięte i poprawne, zmienia się tylko to, kto kontroluje usługę, na którą wskazują.

W WordPressie

Typowe miejsca zostawiania osieroconych rekordów wokół WordPressa to środowisko testowe (staging) postawione u innego dostawcy, stary hosting po migracji, blog w usłudze zewnętrznej, sklep albo landing page na platformie SaaS. Po likwidacji takiej instalacji wpis DNS często zostaje, bo zmienia go inna osoba niż ta, która kasuje serwer.

Skutki zależą od tego, jak ustawione są ciasteczka. Dokumentacja WordPressa opisuje stałą COOKIE_DOMAIN, którą można ustawić dla nietypowych konfiguracji domen, na przykład tak, by ciasteczka WordPressa nie były wysyłane z żądaniami do subdomeny z treścią statyczną ^[4]. Ciasteczka ograniczone do jednej nazwy hosta nie trafią na przejętą subdomenę. Ciasteczka ustawione dla całej domeny trafią. Właściwe flagi ciasteczek (cookie flags) nie pomogą, jeśli sama domena ciasteczka obejmuje przejęty host.

// wp-config.php: ciasteczka tylko dla głównej nazwy witryny
define( 'COOKIE_DOMAIN', 'www.example.com' );

Zagrożenia i skutki

MDN wymienia jako skutki odczyt ciasteczek ustawionych w domenie głównej, XSS (Cross-Site Scripting) i obejście CSP (Content Security Policy), co pozwala przechwycić chronione informacje, w tym dane logowania, albo podać użytkownikom złośliwe treści ^[1]. Microsoft uzupełnia listę ^[2]:

• utrata kontroli nad treścią subdomeny i szkody wizerunkowe;
• zbieranie ciasteczek od odwiedzających, także tych oznaczonych jako bezpieczne, bo atakujący może na przejętej subdomenie uzyskać ważny certyfikat SSL/TLS;
• kampanie typu phishing na wiarygodnie wyglądających adresach, a przy rekordach MX także odbieranie poczty;
• dalsze ataki, takie jak XSS, CSRF (Cross-Site Request Forgery) i obejście CORS.

Certyfikat nie jest więc zabezpieczeniem. Microsoft wskazuje wprost, że przekonanie, iż certyfikaty SSL chronią przed przejęciem, jest błędne ^[2].

Jak się bronić

MDN zaleca stałą kolejność działań: przy uruchamianiu najpierw zająć wirtualny host, a rekordy DNS utworzyć na końcu; przy wygaszaniu najpierw usunąć rekordy DNS ^[1]. Druga rada to spis wszystkich domen organizacji i ich dostawców, aktualizowany przy każdej zmianie ^[1]. Taki spis jest podstawą, na której opiera się zarządzanie powierzchnią ataku (attack surface management).

Microsoft zaleca dodanie punktu „usuń wpis DNS” do obowiązkowej listy kontrolnej przy wycofywaniu usługi, regularny przegląd rekordów pod kątem tego, czy zasoby docelowe istnieją i należą do organizacji, oraz katalog punktów końcowych z przypisanymi właścicielami ^[2]. Po wykryciu osieroconego rekordu trzeba go usunąć albo skierować na własny zasób i sprawdzić, czy nie doszło do naruszenia ^[2].

Pomaga też weryfikacja domeny u dostawcy. GitHub wymaga utrzymania rekordu TXT, by domena pozostała zweryfikowana ^[3]. W usłudze Azure App Service rekord TXT z identyfikatorem weryfikacyjnym sprawia, że żadna inna subskrypcja nie może zweryfikować ani przejąć domeny ^[2].

Historia i przykłady

Sekurak opisał 4 maja 2020 roku błąd w serwisie Roblox, który zaczął się od subdomain takeover: subdomena devrel.roblox.com wskazywała na porzuconą usługę, w której można było podpiąć domenę do własnego projektu ^[5]. Ciasteczka logowania były ustawione dla całej domeny, więc trafiały także na przejętą subdomenę, co umożliwiało przejęcie kont ^[5]. Zgłoszenie trafiło do programu bug bounty ^[5]. Przypadek dobrze ilustruje, jak zakres ciasteczek decyduje o tym, czy przejęta subdomena kończy się tylko podmianą treści, czy przejęciem kont.