Kolizja nazw domen (, także ) – sytuacja, w której w publicznym DNS pojawia się nazwa domenowa identyczna z nazwą używaną w wewnętrznej sieci organizacji. W części przypadków zapytanie, które powinno zostać rozwiązane przez serwer wewnętrzny, trafia wówczas do publicznego DNS, a użytkownik może zostać skierowany do niezamierzonego zasobu lub otrzymać komunikat o błędzie.

Przyczyny Prywatne przestrzenie nazw Wiele organizacji stosuje w sieciach wewnętrznych własne przestrzenie nazw. Najczęstsze rozwiązania to oparcie takiej przestrzeni na prywatnej domenie najwyższego poziomu, nieistniejącej w publicznym DNS, oraz stosowanie list przeszukiwania (search list), pozwalających użytkownikom wpisywać nazwy skrócone, do których system samodzielnie dopisuje przyrostek. Typowym źródłem pierwszego przypadku są instalacje usługi katalogowej Active Directory skonfigurowane z użyciem przyrostka, który w chwili wdrożenia nie był domeną najwyższego poziomu.

Praktyka ta była stosowana od lat 90. XX wieku, przy założeniu, że lista domen najwyższego poziomu pozostanie niezmienna. Założenie to bywało zawodne już wcześniej: gdy zarejestrowano domenę .cs dla Czechosłowacji, w wielu uczelniach nazwy kończące się na cs – używane dotąd jako skrót wydziałów informatyki – stały się pełnymi nazwami domenowymi z publicznego DNS. Microsoft od lat odradza stosowanie prywatnych domen najwyższego poziomu w dokumentacji Active Directory.

Zawodne okazało się również założenie, że bezpieczne są domeny o ograniczonej dostępności. Przyrostek .ad, będący domeną krajową Andory, bywał przyjmowany jako przestrzeń wewnętrzna ze względu na zbieżność z potocznym skrótem nazwy Active Directory oraz na obowiązujące wówczas wymaganie wykazania się andorskim znakiem towarowym przy rejestracji. Wymaganie to nie stanowiło jednak realnej przeszkody – w 2024 roku badacz bezpieczeństwa uzyskał taką domenę za 160 dolarów, powierzając załatwienie formalności związanych ze znakiem towarowym pośrednikowi za kolejne 500.

Program nowych domen najwyższego poziomu Skala zjawiska wzrosła wraz z uruchomionym przez ICANN programem nowych domen najwyższego poziomu, w ramach którego od 2013 roku delegowano setki nowych przyrostków. Nazwy dotąd bezpieczne w użyciu wewnętrznym stały się nazwami rzeczywistymi, możliwymi do zarejestrowania przez dowolny podmiot.

Wśród delegowanych w latach 2013–2015 domen najwyższego poziomu znalazły się przyrostki odpowiadające typowym konwencjom nazewnictwa w sieciach firmowych, m.in. .network, .management, .services, .support, .business, .company, .systems, .computer, .technology i .software.

Mechanizm wycieku Do wycieku zapytania nie dochodzi automatycznie. Częstą przyczyną jest sytuacja, w której komputer kieruje zapytania do publicznego serwera DNS zamiast do serwera nazw organizacji – wskutek własnej konfiguracji albo ustawień otrzymanych z serwera DHCP. Zaleceniem ICANN jest w takim wypadku przestawienie systemu tak, by odpytywał wyłącznie serwer wewnętrzny. Wyciek następuje również wtedy, gdy urządzenie opuszcza sieć organizacji, na przykład przy pracy zdalnej.

Wynik zależy ponadto od konfiguracji listy przeszukiwania oraz od kolejności, w jakiej system rozwiązuje nazwy niepełne; reguły te różnią się między systemami operacyjnymi, a nawet między wersjami tego samego oprogramowania, co utrudnia przewidywanie wycieków. ICANN zwraca uwagę, że rozdzielenie przestrzeni prywatnej i publicznej nigdy nie bywa tak szczelne, jak zakładają administratorzy.

Zanim odpowiadająca nazwie domena najwyższego poziomu zostanie delegowana, wyciekające zapytania trafiają do głównych serwerów DNS i wracają z odpowiedzią o nieistnieniu domeny (NXDOMAIN). Serwery te od dawna obsługują znaczne ilości takiego ruchu, czemu poświęcono odrębną opinię komitetu doradczego ICANN do spraw bezpieczeństwa i stabilności. Problem ujawnia się dopiero w chwili, gdy zamiast odpowiedzi o nieistnieniu domeny zapytanie zaczyna otrzymywać odpowiedź rzeczywistą.

Przeciwdziałanie W lutym 2014 roku firma JAS Global Advisors, działająca na zlecenie ICANN, opublikowała raport Mitigating the Risk of DNS Namespace Collisions, zawierający zalecenia dotyczące ograniczenia ryzyka. Na jego podstawie ICANN przyjęła w sierpniu 2014 roku dokument Name Collision Occurrence Management Framework.

Kluczowym mechanizmem przewidzianym w tych ramach jest kontrolowane przerwanie (controlled interruption). Operator domeny najwyższego poziomu delegowanej po 18 sierpnia 2014 roku przez 90 dni odpowiada na zapytania o nieistniejące nazwy specjalnym adresem 127.0.53.53, należącym do zakresu adresów pętli zwrotnej (loopback). Adres ten nie kieruje ruchu w żadne miejsce, lecz pojawia się w dziennikach systemowych, sygnalizując administratorowi problem z konfiguracją; końcówka „53” stanowi wskazówkę mnemotechniczną, odwołującą się do portu 53 wykorzystywanego przez DNS. Oprócz adresu operator umieszcza w strefie rekordy MX i SRV wskazujące na nazwę your-dns-needs-immediate-attention oraz rekord TXT odsyłający do materiałów informacyjnych ICANN. Obowiązek ten nie dotyczy domen krajowych, których operatorzy mogą zastosować kontrolowane przerwanie dobrowolnie.

Ramy nakładają na operatorów rejestrów także obowiązek reagowania na zgłoszenia kolizji w ciągu dwóch godzin przez pierwsze dwa lata od delegacji domeny. Delegację przyrostków .corp, .home i .mail, uznanych za wykorzystywane w sieciach prywatnych na zbyt dużą skalę, odroczono bezterminowo.

Docelowym rozwiązaniem zalecanym przez ICANN jest rezygnacja z prywatnych domen najwyższego poziomu na rzecz przestrzeni nazw opartej na publicznym DNS oraz posługiwanie się wyłącznie pełnymi nazwami domenowymi, bez list przeszukiwania.

Według raportu końcowego JAS Global Advisors od pierwszej delegacji w październiku 2013 roku do ICANN wpłynęło mniej niż 30 zgłoszeń kolizji powodujących zakłócenia.

Wykorzystanie w atakach Kolizja nazw ma znaczenie nie tylko dla poprawności działania usług, ale również dla bezpieczeństwa. Jeżeli nazwa używana wewnętrznie przez organizację zostanie zarejestrowana w publicznym DNS przez osobę trzecią, może ona przejąć kierowany do niej ruch i przeprowadzić atak typu man in the middle. Mechanizm ten leży u podstaw nadużyć protokołu WPAD, określanych jako BadWPAD, w których przejęcie domeny odpowiadającej przyrostkowi DNS organizacji pozwala narzucić stacjom roboczym konfigurację serwera pośredniczącego (proxy).

Skalę zjawiska próbował zmierzyć w 2024 roku Philippe Caturegli z firmy Seralys, wyszukując w internecie certyfikaty podpisane samodzielnie, odwołujące się do nazw w przyrostkach typowych dla sieci firmowych. Odnalazł ponad 9 tysięcy takich nazw, przy czym około jedna piąta spośród znalezionych w domenach .ad, .cloud i .group pozostawała niezarejestrowana.

Po zarejestrowaniu jednej z nich – memrtcc.ad, odpowiadającej ośrodkowi analitycznemu policji w Memphis – badacz zaczął otrzymywać zgłoszenia uwierzytelniające od setek komputerów z systemem Windows, zawierające nazwy użytkowników i skróty haseł funkcjonariuszy korzystających z laptopów w radiowozach; problem potwierdził urząd miasta. Zarejestrowana przez tego samego badacza domena wpad.ad odnotowała w ciągu tygodnia ponad 140 tysięcy prób połączenia ze strony komputerów poszukujących wewnętrznych serwerów.

Odrębnym wariantem problemu jest sytuacja, w której organizacja używa wewnętrznie domeny zarejestrowanej w publicznym DNS, ale innej niż domena podstawowa – po to, by utrudnić rozpoznanie infrastruktury wewnętrznej. Wygaśnięcie rejestracji takiej domeny pomocniczej może pozostać niezauważone, ponieważ wewnętrzne serwery DNS nadal rozwiązują ją poprawnie. Zagrożenie ujawnia się dopiero wtedy, gdy część stacji korzysta z publicznych serwerów DNS.

Przypisy

Linki zewnętrzne Atak z wykorzystaniem kolizji DNS – nagranie wystąpienia Adama Ziai podczas konferencji Lightning Sekurak Hacking Party, zorganizowanej w 2020 roku przez serwis Sekurak

Kategoria:Domain Name System Kategoria:Cyberataki Kategoria:Bezpieczeństwo sieciowe Kategoria:Bezpieczeństwo komputerowe