M

ulticast DNS (mDNS, DNS w trybie rozsyłania grupowego) został stworzony w celu wykonywania operacji DNS w sieciach lokalnych pozbawionych konwencjonalnego serwera DNS działającego w trybie transmisji jednostkowej – unicast. Jako usługa typu zero-config wymaga niewielkiej lub nie wymaga żadnej konfiguracji, aby korzystać z połączenia pomiędzy uczestnikami w sieci. Protokół ten działa, nawet gdy nie ma żadnej infrastruktury lub jest ona w stanie awarii – wymaga jedynie współpracy pomiędzy innymi użytkownikami w sieci.

Systemy spod znaku nadgryzionego jabłka wspierają mDNS przez usługę Bonjour, która jest Applowską implementacją zeroconf – grupą technologi, w której skład wchodzi odkrywanie usług, czy rozwiązywanie hostów. Bonjour potrafi lokalizować w sieci lokalnej takie urządzenia jak: drukarki inne komputery oraz usługi, jakie te maszyny świadczą używając rekordów usług mDNS. W przypadku systemu Linux, obsługę tego protokołu zapewnia wolna implementacja zeroconf – Avahi. Jeśli chodzi o bezpieczeństwo tego rozwiązania warto przytoczyć fragment dokumentu firmy Apple:

W nieprzyjaznym środowisku muszą być stosowane inne mechanizmy w celu zapewnienia współpracy uczestników lub w celu odróżnienia niezaufanych wiadomości Multicast DNS. W środowiskach bezprzewodowych musi być stosowane szyfrowanie WPA2-PSK lub lepsze w celu zapewnienia, że aktywne w sieci są tylko zaufane strony. W środowiskach otwartych sieci (np. hotspotach Wi-Fi) administratorzy muszą wdrożyć odpowiednie ograniczenia.

DDoS i wyciek danych przez WAN:

Bardzo wiele daemonów na różnych systemach w internecie posiada błędną konfigurację i odpowiada na zapytania skierowane na ich adresy unicastowe, w tym żądania pochodzące z interfejsu WAN. Instalacje te mogą zostać wykorzystane przez napastników do ujawniania poufnych informacji odnośnie używanego sprzętu i usług oraz zostać wykorzystane w kampaniach DDoS opartych o atak wzmocnionego odbicia. Atak ten polega na wysłaniu tysięcy zapytań DNS z fałszowanym źródłowym adresem IP (docelowo będącym adresem IP ofiary). Wszystkie odpowiedzi z odpytanych serwerów zalewają adres IP ofiary, a nie atakującego, który ukrył swoją tożsamość za sfałszowanym adresem IP. Dlaczego wzmocnionego? Ponieważ informacje zwracane w odpowiedzi posiadają większy rozmiar niż samo zapytanie, czyli siła użyta do wygenerowania ataku jest znacznie mniejsza niż jego siła rażenia.

Podatność ta otrzymała od zespołu CERT w 2015 roku nr 550620, w której możemy odnaleźć listę podatnych produktów. Na stronie Open mDNS Scanning Project możemy znaleźć aktualne informacje odnośnie ilości eksponowanych hostów z podziałem na kraje oraz prefiksy IP. Na dzień: 2017-08-09 07:39:07 GMT na zapytanie mDNS odpowiedziało 1,009,381 różnych adresów IP. Poniżej znajduje się przykład odpytania podatnego adresu IP:

dig +short @13.14.15.16 -p 5353 -t any _services._dns-sd._udp.local

_workstation._tcp.local.
_printer._tcp.local.
_pdl-datastream._tcp.local.
_http._tcp.local.

dig +short @13.14.15.16 -p 5353 -t ptr _printer._tcp.local.

hp\032LaserJet\0324250\032[E71A3F]._printer._tcp.local.

dig +short @13.14.15.16 -p 5353 -t ptr _workstation._tcp.local.

nabbex\032[84:2b:2b:62:6d:bf]._workstation._tcp.local.
""
0 0 9 nabbex.local.
fe81::852b:2bgf:fe62:6bbf
13.14.15.16

Wiemy już do jakiej drukarki jest podłączony dany adres IP (HP LaserJet 4250) oraz, że prawdopodobnie Dell (84:2b:2b:62:6d:bf) jest producentem urządzenia lub tylko karty sieciowej kryjącej się za tym adresem. Analogicznie dla sieci WAN/LAN możemy użyć skryptu mDNS Recon, a dla systemu Linux wystarczy zainstalować pakiet: avahi-utils i wykorzystać polecenie avahi-browse. Oczywiście będzie ono wysyłać standardowo zapytania na adres multicast sieci lokalnej – 224.0.0.251. Ale jeśli w jednej konsoli przekierujemy ruch sieciowy na podatny adres IP:

iptables -t nat -A OUTPUT -d 224.0.0.251 -p udp -m udp --dport 5353 -j DNAT \
--to-destination 13.14.15.16:5353

A w drugiej konsoli ustawimy tcpdump na nasłuch na porcie 5353 (sudo tcpdump -i any udp dst port 5353 -vvv -l) będziemy mogli z poziomu klienta wydawać zapytania do podatnego adresu IP, widząc jego odpowiedzi:

avahi-browse -v -d local -all

Odpowiedź:

nabbex.vuln.host.mdns > 10.0.2.15.mdns: [udp sum ok] 0*- q: PTR (QM)? 
_services._dns-sd._udp.local. 2/0/0 _services._dns-sd._udp.local. [10s]
PTR _workstation._tcp.local., _services._dns-sd._udp.local. [10s] PTR
_udisks-ssh._tcp.local. (104)

Pytanie o szczegóły usługi _workstation:

avahi-browse -v -d local _workstation._tcp

Odpowiedź:

nabbex.vuln.host.mdns > 10.0.2.15.mdns: [udp sum ok] 0*- q: PTR (QM)?
_workstation._tcp.local. 5/0/0 _workstation._tcp.local. [10s] PTR nabbex
[84:2b:2b:62:6d:bf]._workstation._tcp.local., nabbex [84:2b:2b:62:6d:bf].
_workstation._tcp.local. [10s] TXT "", nabbex [84:2b:2b:62:6d:bf]._workstation.
_tcp.local. [10s] SRV nabbex.local.:9 0 0, nabbex.local. [10s] AAAA 
fe81::852b:2bgf:fe62:6bbf, nabbex.local. [10s] A 13.14.15.16 (164)

Rekonesans i wyciek danych przez LAN:

Łatwość obsługi różnych urządzeń stała się popularna w przypadku wielu firm. Ponieważ wiele startapów i hackathonów wyznaje ideologię BYOD (ang. Bring Your Own Device) – “przynieś własne urządzenie” – to bardzo często w sieciach takich firm można znaleźć urządzenia użytku biurowego wyposażone w funkcje mDNS. Raz “sparowane” przez komputer użytkownika, który przechodzi z wewnętrznej sieci firmowej do bezprzewodowego świata (np. na lotnisku, kawiarni, innym miejscu z hotspotem) są nadal przekazywane, jako informacje możliwe do zidentyfikowania. W dodatku przenikając do danej sieci LAN nie musimy używać żadnego skanera – pasywnie nasłuchując na w/w porcie urządzenia same zaczynają się do nas zgłaszać (zdradzając także porty zdalnych usług np. _http). Po 6 sekundach od odpalenia sniffera w jednej z publicznych sieci pojawiły się dwa wpisy:

macosx.mdns > 224.0.0.251.mdns: [bad udp cksum 0xa2ef -> 0x68f5!] 0 PTR (QU)?
_googlecast._tcp.local. (40)
galaxys5.mdns > 224.0.0.251.mdns: [udp sum ok] 0 PTR (QM)? _fb._tcp.local. (32)

Tutaj jako nazwy hostów posłużyły rodzaje sprzętu i systemów. Wyobraźmy teraz sobie, że jedna z firm używa imion i nazwisk użytkowników jako nazwy komputerów – ułatwia to znajdowanie informacji na ich temat poprzez przeprowadzanie podstawowych wyszukań na stronach typu LinkedIn, Twitter, czy Facebook. Tego nie da się pominąć jako cenne źródło informacji podczas testów penetracyjnych, zwłaszcza w dziedzinie inżynierii społecznej.

To nie jest jeszcze koniec problemów z mDNS. Skoro jest on podatny na spoofing istnieje możliwość na zatrucie danej usługi wewnątrz sieci lokalnej. Klient obsługujący protokół mDNS wysyła zapytanie na adres multicast. Wszyscy uczestnicy w sieci, którzy nasłuchują takich zapytań odpowiedzą swoimi nazwami. Jeśli teraz doprowadzimy do sytuacji, że w sieci będzie dwóch klientów z tą samą nazwą – kto odpowie pierwszy wygra wyścig. Na przykład: nasz edytor tekstu chce wydrukować dokument i zaczyna szukać maszyny pod nazwą printer.local – atakujący może w prosty sposób wysłać odpowiedź na to zapytanie DNS, które poleca edytorowi na wyszukanie drukarki na innym adresie IP. W ten sposób agresor z powodzeniem porywa sesję wydruku oraz zatruwa rekord domeny .local na pewien czas.

Podsumowanie:

Jeśli funkcje protokołu mDNS nie są wykorzystywane w naszej sieci / organizacji najlepiej rozważyć zablokowanie portu UDP 5353 na wejściu i wyjściu sieci lokalnej. Analogicznie musimy postąpić z urządzeniami, które “rozgłaszają” w ten sposób swoją obecność w sieci.

Więcej informacji: Name (mDNS) poisoning attacks inside the LAN, mDNS – Telling the world about you (and your device), HELIOS Base UB2 – mDNS