Podatność Subdomain Takeover – czym jest i jak jej szukać? – Cyberbezpieczeństwo

Podatność ta, zgodnie z nazwą, polega na przejęciu pojedynczej subdomeny przez osobę niepowołaną. Nie będzie to artykuł o wyczekiwaniu aż komuś wygaśnie domena, ale… zacznijmy od początku uwzględniając także tę opcję.

Ten artykuł możesz także obejrzeć w formie video na Youtube.

Nabycie jakiejś domeny przypisuje domenę jej właścicielowi, a zbycie tej domeny może nastąpić tylko w drodze transferu lub sprzedaży domen. Kupując domenę zazwyczaj kupujemy ją na jakiś okres czasu (rok, dwa, więcej). Przed upływem opłaconego okresu mamy możliwość zdecydować, czy chcemy opłacić kolejny okres korzystania z domeny, czy nie płacimy, a domena ponownie może zostać przez kogoś kupiona.

Okolicznością, o której nie jest ten artykuł, ale która może być pierwszym skojarzeniem z możliwością przejęcia domeny, jest sytuacja, gdzie domena wygasa w określonym terminie, a właściciel nie zdąży na czas przedłużyć jej ważności (opłacić kolejnego okresu). Wtedy możliwe jest wykupienie jej zaraz po terminie wygaśnięcia, a następnie uruchomienie swojej strony, która może np. przypominać oryginał, ale atakować odwiedzających kradnąc hasła lub serwując malware. Skoro wiemy już, czym nie jest subdomain takeover, to wyjaśnimy teraz dokładnie, o co konkretnie chodzi. Zanim będziemy mogli to zrobić, musimy jednak przypomnieć sobie kilka faktów o protokole DNS związanego z obsługą nazw domenowych.

Jeżeli wiesz, jak działa DNS i jakie są typy rekordów DNS, możesz śmiało przejść do sekcji „Przyczyna podatności Subdomain Takeover”

Jak działa DNS

Celem protokołu DNS (Domain Name System) jako rozwiązania jest umożliwienie powiązania adresów IP z domenami. Komputery nie potrzebują domen, ale ludzie, aby wygodniej korzystać z internetu, przypisują adresom IP domeny. Łatwiej jest wpisać w przeglądarce google.com, czy example.com niż zapamiętywać adresy IP. Ilekroć korzystamy z nazwy domenowej – czy to w przeglądarce, czy innym miejscu (skupimy się tu na przeglądarkach, ale mechanizm ten dotyczy także np. połączeń do adresów domenowych wywoływanych z programów i skryptów), to system operacyjny obsługuje tzw. rozwiązanie nazwy DNS, czyli ustalenie, jaki adres IP stoi za daną nazwą DNS. Jeżeli system nie ma tej nazwy zapisanej u siebie (zależnie od systemu może być przechowywana w pliku hosts, czy np. DNS cache), to system skorzysta z zapisanych w swoich zasobach (ustawienia sieciowe Windows, /etc/resolv.conf w Linuxie) adresów serwerów DNS, i odpyta je o nieznaną nazwę domenową. Serwery DNS odpowiedzą pod jaki adres IP powinien się połączyć nasz system, aby trafić do danej domeny. Ale skąd serwery DNS to wiedzą?

Rekordy DNS

Serwery DNS oczywiście muszą gdzieś przechowywać adresy IP powiązane z domenami, ponieważ nie ma możliwości, żeby magicznie je zgadły. Zatem aby być w stanie udzielić odpowiedzi na pytanie „jaki adres IP ma domena X”, serwery DNS utrzymują bazę danych z informacjami, która domena odpowiada któremu adresowi IP… ale nie tylko adresowi IP. Wpisy te nazywamy rekordami DNS.

Rekordy DNS dzielą się na typy, z których każdy przechowuje nieco inny typ informacji o danej domenie. Zatem nie zawsze serwer DNS rozwiązuje domenę tylko na adres IP, bo czasami – może rozwiązać ją także na inną domenę – więcej o tym poniżej:

Rekord typu A

Przechowuje informację o adresie IP powiązanym z domeną – najprostsza i najpopularniejsza sytuacja.

Rekord typu AAAA

Przechowuje informację o adresie IPv6 powiązanym z domeną – podobnie jak powyżej, tylko w innej wersji IP.

Rekord typu CNAME

CNAME, czyli Canonical Name, to rekord, który pozwala na rozwiązanie domeny na inną domenę, a nie adres IP.

Rekord typu MX

MX, czyli Mail eXchanger wskazuje na serwer mailowy. Podobnie jak rekord CNAME, wskazuje on na domenę, a nie adres IP.

Rekord typu NS

NS od „NameServer” wskazuje na główny serwer DNS dla domeny (authoritative DNS) – czyli taki, zawierający rekordy DNS dla danej domeny. Rekord NS także więc zawiera nazwę domenową, a nie adres IP.

Subdomain takeover w większości przypadków występuje na rekordach CNAME, więc to na nich się skupimy. Warto jednak mieć w pamięci, że problem może też dotyczyć rekordów MX i NS. Powyżej opisane rekordy to nie wszystkie typy rekordów DNS, ale z punktu widzenia podatności te przykłady są wystarczające.

Przyczyna podatności Subdomain Takeover

Jak pewnie się domyślasz, problem tkwi w tym, że rekord DNS wskazuje na inną domenę, która z perspektywy obserwatora zewnętrznego może być zupełnie niewidoczna. Wchodząc na cname.luk3.eu, nie widzimy, że „pod spodem” następuje skorzystanie z rekordu CNAME, który to dopiero jest rozwiązywany na adres IP (w tym przypadku nie dojdzie do tego, ponieważ rekord CNAME wskazuje na nieistniejącą domenę). Z punktu widzenia użytkownika przeglądarki czy innego narzędzia do połączenia po HTTP, widzimy tylko problem z połączeniem.

Powyższy przykład to wariant subdomain takeover, gdzie rekord CNAME wskazuje na nieistniejącą domenę pierwszego rzędu (top level domain). Ktoś, kto zarejestrowałby powyższą nieistniejącą domenę .com, przejąłby tym samym zawartość subdomeny cname.luk3.eu.

Cały czas mówiliśmy też o domenach. Subdomena, czyli domena podrzędna, może być dowolnie dodawana przez posiadacza domeny głównej (top level domain, tld), czyli np. posiadacz domeny example.com może tworzyć subdomeny users.example.com, mail.example.com i korzystając np. z panelu zarządzania swoją domeną (dostępne zazwyczaj u sprzedawcy domen) stworzyć odpowiednie rekordy.

CNAME subdomain takeover

Załóżmy, że jesteśmy właścicielem domeny example.com. Chcielibyśmy stworzyć sobie serwis do przechowywania plików, który będzie korzystał z plików hostowanych na domenie files.example.com

Jednak niezbyt mamy pomysł gdzie te pliki przechowywać, ale tak się składa, że mamy gdzieś starą stronę z już zakodowanym systemem sharingu plików. Możemy więc po prostu dodać mojestarepliki.com jako zawartość rekordu CNAME, a wchodząc na files.example.com będziemy normalnie widzieć zawartość tej strony. Nie dojdzie też do żadnego przekierowania – po prostu przy odwiedzeniu serwisu files.example.com DNS najpierw odpowie, że CNAME dla tej domeny to mojestarepliki.com, a potem rozwiąże adres IP domeny mojestarepliki.com i z niego załaduje zawartość strony files.example.com

To bardzo funkcjonalne rozwiązanie – przy pomocy rekordu CNAME możemy po prostu „podpiąć” inną domenę pod naszą. Problem robi się dopiero wtedy, kiedy zapomnimy o tym, że nasza domena mojestarepliki.com jest gdzieś podpięta i np. ją usuniemy.

Wtedy dochodzi do sytuacji, że zostajemy z „wiszącym” rekordem CNAME prowadzącym dokinąd – a raczej, do wolnej domeny możliwej do zajęcia. Może to być też subdomena wolnej domeny, albo subdomena w zewnętrznym serwisie – np. kubełek S3, blog na githubie, czy blog w serwisie wordpress.com.

3rd party providers

Z reguły „podpinanie” domeny z innego naszego serwera nie będzie miało miejsca w praktyce – skoro obydwa należą do nas, możemy po prostu przenieść pliki. Za to dużo bardziej standardowym use-case dla rekordu typu CNAME jest „wpięcie” strony dostawcy usług do naszej infrastruktury – np. serwisu AWS S3, strony Github Pages, innej usługi dostawcy chmurowego itp.

Tworząc konto w tego typu serwisach, zazwyczaj otrzymujemy dostęp do nowo utworzonej usługi w adresie podobnym do poniższych:

mojanazwausługi.nazwaprovidera.com,
lub nazwaprovidera.com/mojanazwauslugi

Czyli utworzona nazwa domenowa jest zmienialna. Chcąc taką usługę osadzić w swojej infrastrukturze, np. nasz nowo utworzony kubełek s3, ustawiamy rekord CNAME na niego. Możemy wtedy np. pod domeną mojepliki.mojadomena.com hostować zawartość kubełka s3, który może mieć np. adres mojkubelek.s3.amazonaws.com (zamienne na s3.amazonaws.com/mojkubelek – AWS zezwala na dwojakie adresowanie kubełków s3)

Jeżeli w przyszłości pozbędziemy się tego kubełka, a mimo to rekord CNAME dalej będzie brzmiał

mojepliki.mojadomena.com in CNAME mojkubelek.s3.amazonaws.com.

to przechodząc pod mojepliki.mojadomena.com, zobaczymy taki komunikat wraz z kodem odpowiedzi 404:

Dlaczego tym razem mimo tego, że domena nie istnieje, otrzymujemy odpowiedź?

Otóż usługi założone w ramach serwisów zewnętrznych dostawców zazwyczaj zrobione są w taki sposób, że jeżeli próbujemy dostać się do nieistniejącej usługi, dostaniemy o tym informację – zazwyczaj w postaci kodu 404 i odpowiedzi wskazującej na to, że usługa o takiej nazwie nie istnieje (czyli prawdopodobnie możemy my taką założyć i w ten sposób wykonać atak subdomain takeover)

Skąd wiadomo, że usługa / domena jest podatna?

Podsumowując, na razie cały proces przedstawia się następująco:

Znajdujemy subdomenę, której odwiedzenie skutkuje kodem odpowiedzi 404
Przy pomocy polecenia dig lub podobnego sprawdzamy, że ta subdomena ma ustawiony rekord CNAME na usługę zewnętrznego dostawcy
Wchodząc na wskazaną w rekordzie CNAME domenę dostajemy ten sam komunikat

W następnym kroku powinniśmy upewnić się, od jakiego dostawcy pochodzi komunikat i czy na pewno istnieje możliwość zarejestrowania u niego domeny o nazwie odpowiadającej opuszczonemu rekordowi CNAME.

W tym celu możemy skorzystać z repozytorium https://github.com/EdOverflow/can-i-take-over-xyz

Zawiera ono popularne „sygnatury” czyli typowe dla danych dostawców informacje o tym, że dana strona nie istnieje, ponieważ nie ma usługi o takiej nazwie (komunikat dla „typowego” błędu 404 ma inną składnię zdania – stąd możliwe jest rozróżnienie).

Ponadto w repozytorium zawarte są też informacje, czy dana domena skojarzona z usługą może zostać przejęta przez rejestrację nowego konta – czasami dostawcy usług generują dla nich losowe nazwy, w związku z czym istnieje nikłe prawdopodobieństwo, że uda nam się zająć np. domenę skojarzoną z nazwą usługi mojlogin-123f32da32-32.dostawcauslug.com.

Automatyzacja

Głównym podejrzanym są wszelkie strony błędu 404 występujace na subdomenach, a jeżeli dodatkowo treść tego błędu odpowiada sygnaturom z powyższego repozytorium – to jest spora szansa, że możliwe jest, że podatność istnieje. Tego typu schemat detekcji daje duży potencjał do automatyzacji – jedyne, czego potrzebujemy to lista subdomen (efektywne znajdowanie subdomen to osobny temat – już wkrótce także go poruszymy) i lista sygnatur z powyższego repozytorium. Dostępne są publicznie narzędzia działające dokładnie zgodnie z tym schematem – ich krótka lista znajduje się poniżej:

Do automatycznego poszukiwania można użyć np. narzędzi:

Impact

Co może zrobić atakujący kontrolując daną subdomenę?

Zaszkodzić reputacji marki, lub jej nadużyć hostując np. fałszywy panel logowania lub dystrybuując malware. Przykładowo, możliwe jest osadzenie strony podobnej do formularza logowania znajdującego się na głównej domenie, ale kradnącego poświadczenia.
Spróbować ataku XSS, jeżeli może już stworzyć swoją stronę w cudzej domenie. Nie jest to trudne – po prostu tworzymy stronę z kodem html takim, jaki jest nam potrzebny, co jest odpowiednikiem xss’a znalezionego w subdomenie jakiejś strony.
A także spróbować niestandardowych, sytuacyjnych ataków. Możliwe może być, zależnie od konfiguracji serwisów leżących w obrębie całej domeny:
- Ominięcie różnego rodzaju whitelist „posiadając” subdomenę
- Odczytać cookie z poziomu strony – jeżeli główna domena wystawia cookie dla *.example.com, to w razie wizyty osoby zalogowanej, cookie zostaną wysłane do „naszej” strony przez przeglądarkę – nie pomoże więc zabezpieczenie ich przy pomocy flagi HTTPOnly
- Ominięcie checków dla pochodzenia (Origin) w przypadku np. postMessage API w Javascript lub referera *.example.com dla CSRF.

Subdomain Takeover w praktyce

Subdomain takeover jest dość proste do znalezienia, co powoduje, że bardzo wiele osób szuka tej podatności. Jeżeli próbujesz znaleźć tę podatność np. w ramach bug bounty, to przygotuj się na to, że:

Albo musisz znajdywać subdomeny (potencjalnych kandydatów do takeover) lepiej niż inni
Albo musisz uruchamiać narzędzia automatyczne ciągle w czasie rzeczywistym i kiedy tylko takeover się pojawi od razu go zajmować / zgłaszać

Z uwagi na fakt, że automatyzacja jest łatwa, wiele osób w ramach bug bounty uruchamia własnej roboty „kombajny” które stosując powyższe metody efektywnie czyszczą cele z tej podatności. Jednak jeżeli jesteś w stanie znaleźć nowe subdomeny w nietypowy, inny niż wszyscy sposób, to koniecznie sprawdź, czy nie są one przypadkiem podatne. Oczywiście, jeżeli chcesz zrobić przegląd własnej infrastruktury lub szukasz tej podatności w ramach np. testu bezpieczeństwa – również jest spora szansa, że taką podatność uda się znaleźć.