K

iedy wpisujemy URL w pasku adresu nasz komputer wysyła zapytanie DNS do właściwego serwera DNS i otrzymuje odpowiedni adres IP, który służy do osiągnięcia łączności z docelowym systemem. Protokoły takie, jak SSL/TLS, HTTPS zapewniają szyfrowanie komunikacji pomiędzy serwerem, a klientem po fakcie rozwiązania nazwy domeny. A, co jeśli atakujący przejmie komunikację pomiędzy serwerem DNS i jego klientem podczas procesu rozwiązywania domeny? Przekieruje ruch do spreparowanego serwera w celu kradzieży danych lub przeprowadzenia ataku DoS? W tym celu został opracowany mechanizm bezpieczeństwa pod postacią ciasteczka DNS.
[ czytaj całość… ]

Poniżej znajduje się aktualizacja wcześniejszej listy:

1. CloudFlare:
– 1.1.1.1
2. Quad9:
– 9.9.9.9
3. Google:
– 8.8.8.8, 8.8.4.4
4. CleanBrowsing:
– 185.228.168.168, 185.228.168.169
5. OpenDNS:
– 208.67.220.220, 208.67.222.222
6. Norton ConnectSafe:
– 199.85.126.10, 199.85.127.10
7. Comodo Secure DNS:
– 8.26.56.26, 8.20.247.20
8. DNS.Watch:
– 84.200.69.80, 84.200.70.40
9. VeriSign Public DNS:
– 64.4.64.6, 64.6.65.6
10. Yandex DNS:
– 77.88.8.88, 77.88.8.2

Więcej informacji: DNS Resolvers Performance compared, Jak znaleźć najszybszy publiczny serwer DNS w Polsce?

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.
[ czytaj całość… ]

K

rytyczna podatność została odkryta w ulubionym monolicie inita świata linuksowego – systemd. Pozwala ona na potencjalne wywołanie przepełnienia bufora oraz uruchomienie szkodliwego kodu na atakowanej maszynie, a to wszystko za pomocą odpowiedzi DNS. CVE-2017-9445 aktualnie rezyduje w funkcji dns_packet_new komponentu systemd-resolved służącego do obsługi odpowiedzi DNS, który zapewnia rozwiązywanie nazw DNS dla innych daemonów i aplikacji sieciowych. Według oficjalnego ostrzeżenia opublikowanego we wtorek specjalnie spreparowana odpowiedź od wrogiego serwera DNS może spowodować awarię programu ‘systemd-resolved’. Wysłanie bardzo dużej odpowiedzi DNS może doprowadzić do przepełnienia buforu umożliwiając atakującemu nadpisanie pamięci prowadząc do zdalnego wykonania kodu. Oznacza to, że napastnicy mogą zdalnie uruchomić złośliwe oprogramowanie na docelowym serwerze za pośrednictwem wrogiej usługi DNS. Luka ta występuje od wersji 223, która pojawiła się w czerwcu 2015 roku i jest obecna we wszystkich wersjach do 233 wydanej w marcu tego roku. Oczywiście systemd-resolve musi być uruchomiony w systemie, aby stanowił dla niego zagrożenie. Błąd dotyka takie dystrybucje jak: Ubuntu 16.10 oraz 17.04; Debian Stretch (9), Buster (10) i Sid (wersja niestabilna) oraz inne używające systemd.

Zobacz również: systemd v228, screen root exploit i globalne problemy z setuid

curl -s http://public-dns.info/nameserver/pl.csv > list; cat list | cut -d "," -f1 | \
xargs -i timeout 1 ping -c1 -w 1 {} | grep time | \
sed -u "s/.* from \([^:]*\).*time=\([^ ]*\).*/\2\t\1/g" | grep -v "1 packets" | sort -n

Więcej informacji: DNS servers in Poland

N

ie ważne, jak bardzo skręcimy dostęp sieciowy do i z naszych serwerów – to zawsze zezwolimy na ruch DNS, aby móc rozwiązywać nazwy domenowe na adresy IP i na odwrót. Osoba, która dokonała skutecznego ataku na nasze maszyny może wykorzystać tą “lukę” w zaporze ogniowej i potajemnie wyprowadzić dane za pomocą połączeń do C&C, które trudno zablokować. Aby bliżej zrozumieć tunelowanie poleceń i danych za pomocą DNS do serwerów Command and Control spójrzmy na narzędzie autorstwa Rona Bowsesa o nazwie dnscat2.
[ czytaj całość… ]

R

ekonesans DNS jest główną częścią etapu zbierania informacji w testach penetracyjnych. Można to porównać do wykonywania mapy infrastruktury danego serwisu. Większość organizacji nie monitoruje ruchu DNS, szczególnie nieudanych zapytań i prób pobrania całej strefy – dlatego wyciśnięcie jak największej ilości informacji z tego źródła często nie wpływa na alarmy w systemach bezpieczeństwa i nie wzbudza podejrzeń. W Internecie istnieje wiele dostępnych narzędzi, które mogą skutecznie wykonywać tego typu operacje, ale my skupimy się tylko na kilku i w dodatku tylko na tych napisanych w języku Python, ponieważ bardzo łatwo jest stworzyć dla nich wirtualne środowisko i zainstalować zależności, aby zadziałały od kopnięcia.
[ czytaj całość… ]

P

o napisaniu podstaw bezpieczeństwa DNS zastanawiałem się, jaka jest skala problemu źle skonfigurowanych serwerów, które pozwalają na ściągnięcie całej strefy lub wykonywanie zapytań dowolnemu klientowi. Duch patryjotyzmu namawiał mnie na sprawdzenie TLD .pl, zarządzaną przez NASK. Niestety, jak zawsze polski dwór zakończył nadzieję na czwartej wymianie zdania. Dialog wyglądał tak:

– Czy istnieje możliwość otrzymania od Państwa listy wszystkich dotychczas zarejestrowanych domen .pl?
– NASK nie udostępnia tego typu informacji.
– A orientują się Państwo do jakiego organu można zwrócić się w tej sprawie?
– Te dane posiada tylko NASK.

Nie chciało mi się już próbować, czy aby jednak istnieje taka możliwość poprzez CZDS. Rozważałem już przerzucić się na zagraniczne banany, ale z pomocą przyszedł portal, który stanowi swoiste źródło wiedzy o ruchu w Internecie. Okazuje się, że Alexa bez żadnych zbędnych formalności udostępnia milion najczęściej odwiedzanych stron. To stanowi już jakąś próbkę, którą można poddać testom.
[ czytaj całość… ]

1. Google:
– 8.8.8.8, 8.8.4.4
2. OpenDNS:
– 208.67.220.220, 208.67.222.222
3. Norton ConnectSafe:
– 199.85.126.10, 199.85.127.10
4. Comodo Secure DNS:
– 8.26.56.26, 8.20.247.20
5. DNS.Watch:
– 84.200.69.80, 84.200.70.40
6. VeriSign Public DNS:
– 64.4.64.6, 64.6.65.6

Z

ałóżmy, że do naszego serwera DNS, który jest otwarty tylko dla sieci wewnętrznej zaczyna przychodzić niechciany ruch (od setek do tysięcy zapytań na sekundę) pochodzący od szkodliwego oprogramowania / złej konfiguracji serwerów. W zależności od oprogramowania jakiego używamy do obsługi zapytań DNS – zablokowanie konkretnego rodzaju zapytań może stać się dość trudne. Pierwszym rozwiązaniem tego problemu wydaje się zablokowanie wszystkich żądań DNS, które posiadają konkretne wyrażenie w zawartości pakietu.
[ czytaj całość… ]