W poprzednim wpisie pokazaliśmy przykłady źródeł domen, które mogą generować fałszywe alarmy przy wykrywaniu botnetowych domen DGA. Były to przykłady źródeł niezłośliwych (przynajmniej z zasady). W tej części pokażemy gdzie można napotkać losowe domeny, które mogą zostać wykorzystane do ataków lub świadczyć, że taki atak miał miejsce.

Atak pseudolosowych poddomen – Pseudo Random Subdomain Attack

Atak pseudolosowych poddomen jest atakiem DDoS na serwery nazw danej strefy domenowej. Polega na wysłaniu bardzo dużej liczby zapytań DNS o poddomeny ofiary, co ostatecznie ma spowodować odmowę dostępu dla normalnych zapytań. Poddomeny generowane są <https://blog.secure64.com/?p=377>losowo, więc atak może wyglądać podobnie do działania botnetu DGA. Na przykład, jeśli atakowane są serwery autorytatywne domeny example.com, to zapytania będą podobne do abc4gd5fr7.example.com. Losowość domen przeciwdziała ich cache’owaniu. Przez wykorzystanie otwartych serwerów DNS można dodatkowo wzmocnić atak, ponieważ w przypadku braku odpowiedzi z serwerów autoratywnych dla danej domeny, zapytanie zostanie powtórzone – dla Bind od wersji 8.2 domyślnie wykonywane są dwie rundy odpytywania tych serwerów. Nie jest to duże wzmocnienie w porównaniu z osiąganymi w atakach odbitych, niemniej na pewno ułatwia atakującym osiągnięcie celu.

Tunele DNS

Kolejnym źródłem domen o losowych znakach są tunele DNS, które mogą tworzyć zapytania podobne do tych generowanych przez botnety DGA. Ruch DNS używany jest jako medium do utworzenia osobnego kanału komunikacji. Tunele DNS stosowane są w sieciach, w których nie każdy ruch sieciowy na zewnątrz sieci lokalnej jest dozwolony, np. w korporacyjnych albo hotelowych. Często ruch DNS nie jest w nich blokowany lub monitorowany, co pozwala na użycie go do tworzenia kanałów ukrytych. Dzięki temu można przesyłać dane pomiędzy siecią lokalną a Internetem bez większych ograniczeń i bez zbytniego wzbudzania podejrzeń.
Dane na zewnątrz sieci lokalnej przesyłane są w nazwach domenowych, o które odpytuje klient DNS. Zapytania te są skierowane do kontrolowanej strefy domenowej, dzięki czemu można sterować tunelem. Dane zwrotne umieszczone są w rekordach odpowiedzi, np. TXT lub CNAME. Przykładowy schemat tunelu DNS został umieszczony na rysunku poniżej.

Klient koduje dane do przesłania jako domeny trzeciego i wyższego poziomu strefy example.com. Następnie wysyła zapytanie DNS o rekord CNAME tak zakodowanej domeny do lokalnego serwera nazw (1). Ten działając jako serwer iteratywny odnajduje serwer autorytatywny dla poszukiwanej strefy i przekazuje tam zapytanie (2). Tam tunel się kończy, a przesłane dane są przetwarzane dalej, np. wysyłane jest żądanie GET do zdalnego serwera WWW (3). Odpowiedź otrzymana na to żądanie (4) jest kodowana do postaci rekordu CNAME i jako odpowiedź DNS odsyłana do lokalnego serwera nazw (5). Stamtąd ostatecznie wysyłana jest do klienta (6). Możliwe są także schematy działania tuneli pomijające lokalny serwer nazw, np. wykorzystanie zewnętrznych otwartych serwerów DNS lub praca klienta w trybie iteratywnym i łączenie się bezpośrednio z serwerem autorytatywnym wykorzystywanej strefy. Poniżej zamieszczony jest fragment rzeczywistej wymiany danych przy użyciu tunelu zestawionego przez DNScapy.
W komunikacji wykorzystywane są rekordy TXT i CNAME. Zapytania mają kilku poziomowe nazwy domenowe, osiągając nawet ponad 200 znaków długości. Przykład odpowiedzi umieszczonej w rekordzie CNAME znajduje się poniżej.

Oprócz losowej nazwy domeny uwagę zwraca mała wartość TTL, wynosząca tylko 60 sekund.
W praktyce tunele DNS używane są np. w hotelach, gdzie często należy płacić za dostęp do Internetu. Ruch DNS w takich sieciach często nie jest blokowany, dzięki czemu można za darmo używać udostępnionej infrastruktury, choć możliwe, że niezgodnie z polityką bezpieczeństwa danej sieci i z prawem.
Istnieją botnety używające DNS to tworzenia kanałów C&C, np. Feederbot i Morto. Mimo że nie są to klasyczne tunele, to z punktu widzenia domen generowanych w czasie działania są do tuneli podobne.

Tor proxy

W Internecie można znaleźć serwisy zapewniające dostęp do sieci Tor przez zwykłą przeglądarkę, np. tor2web. By połączyć się z odpowiednim serwisem Tor (zwanym też Hidden Service) dokleja się jego adres w pseudodomenie .onion do nazwy domenowej danego usługodawcy proxy jako domenę trzeciego poziomu. Zatem np. adres 3g2upl4pq6kufc4m.onion zamieniany jest na 3g2upl4pq6kufc4m.tor2web.org. Serwer proxy, na który wskazuje zwracany wpis DNS, pośredniczy w wymianie danych między siecią Tor a siecią zwykłą. Niestety, usługi te są używane także przez przestępców dla zapewnienia komunikacji z ich serwerami w sieci Tor. Przykładami są Chanitor/Vawtrak czy Ransomcrypt. Właśnie z tego powodu wykorzystanie tych serwisów zostało umieszczone na naszej liście jako możliwe zagrożenie.

Złośliwe wykorzystanie IDN-ów

Domeny IDN (ang. Internationalized Domain Name), to domeny umożliwiające użycie znaków z alfabetów innych niż podstawowy łaciński. Ich postać zakodowana w Unicode jest zamieniana na postać ASCII przy użyciu Punycode (więcej można przeczytać np. tutaj) i tak przetwarzana przez DNS. Postać w ASCII jest często bardzo losowa. O IDN-ach pisaliśmy już w poprzedniej części, tym razem opiszemy jak ich losowy wygląd jest wykorzystywany do złych celów. Translacja domen kodowanych w Unicode na zakres znaków ASCII może być źródłem pewnych niejasności, a przez to prowadzić do nadużyć. Raport Bluecoat opisuje wiele z nich. Można tam znaleźć wiele przykładów na podszywanie się pod domeny kodowane w Unicode, np. przez mieszanie różnych zestawów znaków. Rozpatrzmy dwie różne domeny łudząco do siebie podobne. Poniższy rysunek pokazuje ich nazwy w Unicode oraz po translacji na zakres ASCII.

Różnica między nimi polega na użytych zestawach znaków. Druga nazwa zawiera znaki z cyrylicy: „с” oraz „е” zamiast znaków łacińskich „c” oraz „e”. Postaci w ASCII są odróżnialne od razu, w Unicode nie jest to już łatwe. Podszywanie się może być dokonywane także inaczej. Nazwy zakodowane przy użyciu Punycode’u mogą się podszywać pod zwykłe domeny zapisane w ASCII, np.:

Użytkownik używający alfabetu łacińskiego może nie zwrócić uwagi na prefiks xn-- i nie wiedzieć, że jest to zakodowana domena IDN.
Jednak ze względu na temat tego wpisu ważniejsze wydaje się wykorzystanie IDN-ów jako możliwej płaszczyzny dla złośliwego użycia algorytmów DGA. Jak podaje Bluecoat, do takiego wykorzystania już dochodzi. Odkryty przez nich algorytm DGA miesza ze sobą znaki z różnych alfabetów tworząc zbitki znakowe jak podany przez nich przykład:

Znajdują się w nim znaki łacińskie, gudżarati, koptyjskie, greckie i czirokeskie. Ze względu na mały ruch jaki generują te domeny nie wiadomo do końca do jakiego celu są tworzone, możliwe że należą do jakiegoś ataku ukierunkowanego.
Przedstawiony powyżej algorytm miesza ze sobą dozwolone znaki Unicode, jednak możliwe jest użycie algorytmów generujących domeny w przestrzeni znaków ASCII i dodawanie prefiksu xn-- dla podszycia się pod domenę IDN zakodowaną przy użyciu Punycode. Prezentuje to poniższy rysunek:

Wykorzystanie prefiksu xn-- może maskować użycie DGA, choć cały mechanizm jest trudniejszy do wykonania ze względu na pewne ograniczenia wynikające z zasad kodowania Punycode. Inną kwestią jest czy istnienie zapytań o domeny IDN w danej sieci nie jest samo w sobie pewną anomalią.

Domain shadowing

W tym przypadku algorytmy DGA są używane do tworzenia losowych poddomen w najczęściej niezłośliwych domenach. Ich legalni właściciele padają ofiarą np. phishingu, dzięki czemu atakujący otrzymują dostęp do kont zarządzania daną domeną i mogą tworzyć dużą liczbę różnych jej poddomen. Te z kolei wykorzystywane są do działania przez exploit kity. Praktyka ta na przykładzie Anglera została opisana przez zespół bezpieczeństwa Talos i nazwana domain shadowing. Na podstawie opublikowanej przez nich listy domen można zauważyć, że poddomeny tworzone są na trzecim, ale też i na czwartym poziomie. Oprócz zbitek losowych znaków wykorzystywane są także słowa z języków naturalnych. Można odnaleźć poddomeny zawierające słowa m.in. angielskie, niemieckie, polskie czy szwedzkie. Co ciekawe, języki są ze sobą mieszane, np. domena popularyzujacauncalculableness.[example.com], zawiera dwa słowa: polskie popularyzująca oraz angielskie uncalculableness. Kilka przykładów z listy Talosa znajduje się poniżej. Pozostawiliśmy w nich tylko domeny trzeciego i czwartego rzędu.

Inne źródła losowych domen

Powyższa lista wymienia najważniejsze źródła losowych domen, które można uznać za zagrożenie, jednak na pewno nie jest definitywna. Wśród innych źródeł, może mniej częstych, można wskazać na przykład mapowanie poddomen, czyli subdomain bruteforcing. Polega ono na wysyłaniu dużej liczby zapytań DNS o różne poddomeny w celu odkrycia, które rzeczywiście istnieją w danej strefie. Może to być fazą rekonesansu przed właściwym atakiem na naszą sieć. Istnieją dedykowane aplikacje, które dokonują mapowania w sposób automatyczny, np. dnsmap lub dnsenum. Listę poddomen do sprawdzenia można zdefiniować przez siebie lub skorzystać z wbudowanej. I właśnie listy wbudowane zawierają dużo domen wygenerowanych losowo.

Podsumowanie

Jak pokazaliśmy w naszych dwóch wpisach pomyślne wykrycie botnetowych domen DGA może być utrudnione ze względu na dużą liczbę podobnych do nich losowych domen. Głównie używane są one do niezłośliwych celów, jak np. w sieciach CDN, ale mogą też świadczyć o istnieniu innego zagrożenia niż botnety DGA. Znajomość źródeł losowych domen umożliwia zmniejszenie liczby fałszywych alarmów systemów detekcji, a także wskazać miejsca w sieci, których poziom zabezpieczenia należy zbadać.