Tag: dns

Opublikowane w

Publiczne Wi-Fi a bezpieczeństwo

Wczoraj ukazał się artykuł o tym, czy korzystanie z publicznego Wi-Fi jest bezpieczne. Uważam, że prezentowane tam podejście jest dość optymistyczne. Nie uważam obcych sieci za tak bezpiecznie, jak pisze autor. Wszystko zależy od tego, czego się obawiamy. I naszego poziomu paranoi.

Na pewno podłączanie do sieci Wi-Fi, jeśli zakładamy złe zamiary jej właściciela lub innych użytkowników jest bezpieczniejsze, niż podłączanie kablem ethernetowym. Ot, nikt nie poda wysokiego napięcia na kablu i nie spali nam urządzenia. No ale żarty na bok.

Publiczne Wi-Fi – zagrożenia

Podłączając się do cudzej lub publicznej sieci ujawniamy informacje o swoim urządzeniu i systemie. Np. syngatury urządzenia typu adres MAC czy hostname. W pewnych przypadkach dane te mogą zostać wykorzystane do… powiedzmy przypisania nam pewnych działań. Ale to bardziej naruszenie prywatności niż realny atak. Pójdźmy dalej.

Podłączając się do sieci eksponujemy nasze urządzenie na bezpośrednie połączenia. OK, jeśli ktoś ma firewall lub nie udostępnia żadnych usług innym komputerom w sieci lokalnej, to problemu nie ma. Ale już udostępnienie zasobu chronionego prostym hasłem z laptopa w sieci domowej, gdzie bezpośredni dostęp miały tylko nasze urządzenia może okazać się zgubne. W naszej sieci przed atakami z internetu mógł chronić router (NAT).

Nie taki HTTPS wspaniały

Wspomniany w artykule HSTS ma dwie wady. Po pierwsze, adopcja. Zwyczajnie nie wszystkie strony z niego korzystają. Żeby daleko nie szukać, tamten artykuł zamieszczony jest na stronie bez HSTS. I pewnie ktoś przytomnie zauważy, że przecież to tylko blog, a nie bank. To polecam samodzielne sprawdzenie, czy, ew. które polskie banki korzystają z HSTS na stronach. O HSTS z preload litościwie nie wspominam.

Po drugie, jest to mechanizm TOFU. Tzn. nie zapewnia bezpieczeństwa przy pierwszym połączeniu. Owszem, przeglądarka w kolejnych połączeniach do strony, przez zwykle długi okres ważności, będzie już korzystać z HTTPS. Ale jeśli jest to nowa strona lub otwierana w nowej przeglądarce to HSTS nic nie daje.

Dodatkowo autor wspomina o powszechnych przekierowaniach HTTP -> HTTPS. Tylko niestety taki mechanizm nie zapewnia bezpieczeństwa. OK, może je podnosić w szczególnym przypadku, jeśli jest stosowany łącznie z HSTS. Bez tego raczej zapewnia złudzenie bezpieczeństwa. Bowiem jeśli pierwszy request jest wykonywany po HTTP, to nadal DNS spoofing jest groźny. Atakujący może dowolnie rozwiązać nazwę domeny do której próbujemy się połączyć. Np. na swój serwer. I tam wykonać przekierowanie HTTP. Redirect (301) może być na cokolwiek. Także na domenę z poprawnym HTTPS. Tyle, że niekoniecznie tę, na którą chcieliśmy się połączyć. Tylko np. na domenę homograficzną, albo domenę o zbliżonej nazwie. Ot, choćby wchodząc na http://mojbank.pl możemy skończyć na https://mojbark.pl, o wyglądzie identycznym jak https://mojbank.pl. I z poprawnym certyfikatem HTTPS i „kłódeczką”.

No i ostatecznie nawet połączenie HTTPS z poprawnym hostem nie gwarantuje jeszcze, że jest w pełni bezpiecznie. W niektórych przypadkach, na które użytkownik nie ma wpływu, nadal możliwe mogą ataki na HTTPS. OK, w przeciwieństwie do DNS spoofingu są trudniejsze do wykonania.

Jak korzystać bezpieczniej z publicznych Wi-Fi?

Czy to znaczy, że zupełnie nie zgadzam się z autorem? Niekoniecznie. Zgadzam się, że jest o wiele bezpieczniej, niż kiedyś. Generalnie jeśli ktoś naprawdę musi skorzystać z Wi-Fi i miałbym dać tylko jedną radę to byłoby to: włącz DoH w przeglądarce i wpisuj adresy w pasku adresu przeglądarki „z palca”, korzystając z podpowiedzi. No wiem, to w zasadzie dwie rady. Ale przyjmijmy, że jedna, tylko złożona.

Czemu tak? DoH zapewni nam odporność na DNS spoofing, a dodatkowo da bonus w postaci podwyższenia prywatności. Potencjalny podsłuchujący nie dostanie adresów odwiedzanych stron „na tacy” w postaci nieszyfrowanych zapytań DNS. W części przypadków w ogóle nie będzie w stanie ustalić z jakim serwisem się łączymy.

Wpisywanie domen w pasku adresu, z wykorzystaniem podpowiedzi uchroni przed kliknięciem w podobną domenę i zwiększy szansę na wykorzystanie protokołu HTTPS już od pierwszego requestu.

Opublikowane w

Sprawdzanie DNS sinkhole

W poprzednim wpisie o phishingu w Polsce pisałem, że chcę zbadać jak wygląda adopcja listy hole.cert.pl wśród ISP do DNS sinkhole zapytań o domeny używane do phishingu. Odzew był mniejszy, niż się spodziewałem, ale coś udało się zrobić. Trochę się nauczyłem i może się to przydać także do względnie łatwego, samodzielnego sprawdzania np. cenzury w sieci, nie tylko w Polsce.

Wyniki

Jeśli kogoś interesują wyniki DNS sinkhole na podstawie hole.cert.pl wśród ISP, to znajdzie je w repo. Jak widać próbka jest mała, ale pewien trend daje się zauważyć. Nawet duzi ISP kablowi nie wykorzystują listy od CERT Polska. Na pewno – co oczywiste – wykorzystują ją sygnotariusze porozumienia. CERT trafnie zauważa, że lista może być wykorzystywana nie tylko na DNS operatorów, ale także na innych poziomach (Pi-hole, filtry AdBlock). Przypomnę jednak, że chodziło mi o sprawdzenie jaka jest adopcja listy na poziomie infrastruktury ISP. Czyli bez wymagania dodatkowych urządzeń czy działań po stronie użytkowników.

Pierwotny pomysł, czyli skrypty uruchamiane przez osoby trzecie w zasadzie ląduje w koszu. Wykorzystanie sond z projektu RIPE Atlas probe pozwala sprawdzić wszystko samodzielnie, bez angażowania innych ludzi. Wyniki się pokrywają, więc w repo zostawiłem zebrane ręcznie. Przy okazji widzę, że przy wynikach przydała by się data pomiaru. Do wyciągnięcia z commitów, ale lepsza byłaby podana jawnie.

RIPE Atlas probe

Dawno temu pisałem już o RIPE Atlas probe. Ogólnie są to małe pudełka dystrybuowane przez RIPE i uruchamiane przez ochotników (zarówno firmy jak i osoby fizyczne) w swoich sieciach na całym świecie. Pozwalają na wykonywanie pomiarów zlecanych przez panel RIPE. Istnieje też wersja programowa.

Użycie RIPE Atlas probe daje całkiem spore, zwłaszcza jeśli chodzi o zasięg pomiarów, możliwości ale… nie jest proste. Po pierwsze, trzeba mieć konto i kredyty. O ile założenie konta to moment, o tyle zebranie kredytów chwilę trwa – trzeba mieć uruchomioną sondę. No chyba, że dostaniemy je od kogoś, kto już je zgromadził (dziękuję!).

Po drugie, parametrów jest dużo i podobnie jak zwracane wyniki nie są do końca oczywiste. Np. w JSON szczegółowa odpowiedź jest zakodowana w base64, przez co początkowo uznałem (nie tylko ja…), że jej tam nie ma. Dekodowanie odpowiedzi DNS jest proste i opisane w dokumentacji, z przykładami w różnych językach. Niemniej, bariera wejście jest większa, niż się spodziewałem.

Sytuacji nie poprawiał fakt, że panel RIPE jest właśnie aktualizowany czy też przerabiany i nie wszystko wydaje się działać poprawnie. Np. wyszukiwania sond zwracają różne wyniki po API i przez stronę WWW.

RIPE Atlas Tools

Ostatecznie stanęło na tym, że korzystałem z API za pośrednictwem RIPE Atlas Tools. Do prototypowania i sprawdzeń ręcznych całkiem użyteczne. Nie jest to narzędzie idealne, na przykład status jest podawany numerycznie i… nie znalazłem opisu, który co oznacza. TBH szybciej było mi sprawdzić metodą porównania z wynikami z panelu. W każdym razie status connected to 1. Opis użycia w CLI:

Usage: ripe-atlas probe-search [-h] [--asn asn] [--asnv4 asnv4] [--asnv6 asnv6] [--prefix prefix] [--prefixv4 prefixv4] [--prefixv6 prefixv6]
[--location location | --center center | --country country] [--radius radius] [--tag tag] [--limit limit]
[--field {id,asn_v4,asn_v6,country,status,prefix_v4,prefix_v6,coordinates,is_public,description,address_v4,address_v6,is_anchor}]
[--aggregate-by {country,asn_v4,asn_v6,prefix_v4,prefix_v6}] [--all] [--max-per-aggregation max_per_aggregation] [--ids-only] [--status {0,1,2,3}]

Pora na parę przykładów użycia. W zasadzie wystarczają one do sprawdzenia jak z sieci danego ISP na określonym serwerze DNS jest resolvowana domena, czyli tego, co było przedmiotem projektu. Znalezienie aktywnych sond w sieci Orange (AS5617):

ripe-atlas probe-search --asn 5617 --country pl --ids-only --status 1

Sprawdzenie rozwiązywania domeny (tu: example.com) na wskazanym serwerze DNS (tu: 8.8.8.8) i sondzie (ID 1234):

ripe-atlas measure dns --query-argument example.com --from-probes 1234 --target 8.8.8.8

Powyższe zwróci w konsoli wynik w postaci już zdekodowanej. Dodatkowo będzie tam link do wyniku w panelu RIPE, który można pobrać w postaci JSON. Wtedy trzeba zdekodować odpowiedź DNS samodzielnie w sposób linkowany wyżej.

Na koniec wystarczy porównać, czy oczekiwany wynik jest taki sam, jak z serwera co do którego mamy pewność, że nie zmienia odpowiedzi i już wiemy, czy mamy do czynienia z DNS sinkhole. No prawie, bo domena może mieć np. zróżnicowane rozwiązywania nazwy na podstawie geolokalizacji. Można oczywiście sprawdzać większe ilości sond itp., ale do sprawdzania ew. cenzurowania stron lepsze mogą być zapytania HTTP – blokada bowiem może być na innym poziomie niż rozwiązywanie nazw domen.

Co dalej?

Ustalić adresy IP serwerów DNS przydzielanych klientom przez największych polskich ISP. Sądziłem, że będzie trywialne. Niestety myliłem się. Kiedyś można było bez problemu znaleźć je w sieci na stronach poszczególnych ISP. Teraz często nie chwalą się oni tą informacją. Np. nie udało mi się znaleźć tej informacji np. dla operatorów Vectra i Toya[1]. Tu liczę na pomoc czytelników w postaci podania nazwy ISP i przydzielonych przez niego adresów serwerów DNS.

Pełny automat. Powyższe przykłady są dobre do ręcznego wykorzystania. Mam wrażenie, że odpytywanie przy pomocy RIPE Atlas Tools słabo nadaje się do oskryptowania. Obsługa timeoutów, parsowanie odpowiedzi, zapisywanie wyników – wydaje mi się, że lepiej będzie napisać wszystko w Pythonie.

Badanie czasu od pojawienia się domeny na liście do czasu zablokowania u danego ISP. Bez pełnego automatu nie ma co podchodzić do tematu. I pewnie do przemyślenia jak to potem sensownie interpretować, pewnie trzeba będzie wspomóc się statystyką.

Motywacja mi nieco siadła, więc pewnie zejdzie dłuższa chwila nim coś nowego się pojawi.

[1] Dla Netii z kolei znalazłem serwery DNS, ale nie było ochotnika do zrobienia testu wersją ze skryptem. Przy pomocy sond RIPE Atlas ustaliłem, że nie korzystają z listy CERT Polska, ale z publikacją tego poczekam na zmianę flow zamieszczania danych.

Opublikowane w

Phishing w Polsce

Phishing w Polsce ma się dobrze. Niedawno na z3s.pl pojawił się opis kolejnej kampanii phishingowej. Tak się złożyło, że równolegle widziałem opis jednej z ofiar. No i zbiegło się to w czasie z wpisem na nfsec.pl o tworzeniu RPZ dla unbound. Przypomniałem sobie o inicjatywie CERT Polska, która w założeniu może pomóc zmniejszyć liczbę ofiar tego typu ataków. Powróciło pytanie, które chodziło mi od początku po głowie, odkąd usłyszałem o projekcie hole.cert.pl[1]. Kto z tego będzie korzystał?

Phishing a hole.cert.pl

Pomysł jest prosty. Ludzie zgłaszają domeny phishingowe, CERT Polska je weryfikuje i udostępnia publicznie do wykorzystania wszystkim zainteresowanym. Zainteresowani, czyli polscy ISP, przekierowują żądania do domen wykorzystywanych przy phishingu na serwery ostrzegające użytkownika o zagrożeniu.

Pewne kontrowersje budzi analogia do rozwiązania blokującego dostęp do serwisów w ramach „ustawy antyhazardowej”. Zgadza się, w obu projektach wykorzystywany jest ten sam mechanizm. Ale są to projekty niezależne. Wszystko rozbija się tak naprawdę o „wsad”, czyli to, jakie domeny są blokowane. Jak pisałem niedawno, to samo narzędzie (tu: mechanizm) może być wykorzystane do różnych celów.

Więc tak, dla purystów wolnościowych jest to cenzura, zło i naruszenie wolności. Ale praktycznie rzecz biorąc, jest to jedyny sposób by skutecznie blokować phishingi. Szczególnie na urządzeniach mobilnych, gdzie często nie można łatwo sprawdzić domeny przed kliknięciem. Albo nie jest ona dobrze, w całości, widoczna. O ile sam raczej łatwo nie nabiorę się na phishing na desktopie, bo go zauważę[2], to w przypadku telefonu nie mam do siebie takiego zaufania. Nawet po zwróceniu uwagi i zachowaniu ostrożności.

Więc ostatecznie IMO bardzo dobra inicjatywa. Nie wymaga żadnych działań po stronie użytkowników, czyli rozwiązanie jest dostępne dla użytkowników o dowolnym poziomie wiedzy o komputerach czy bezpieczeństwie. Skutecznie blokuje dostęp do zasobu systemom korzystających z serwera DNS z wdrożonym rozwiązaniem. Jest łatwe do wdrożenia przez ISP – mają już potrzebną infrastrukturę i korzystają z niej w analogicznym projekcie. Oczywiście nie eliminuje phishingu w Polsce w zupełności, ale zmniejsza jego skuteczność.

Pomysł

Wpadłem zatem na pomysł, żeby zebrać dane, czy ISP – poza wymienionymi w porozumieniu – korzystają z tego rozwiązania. Przy okazji trochę wzrośnie świadomość, że hole.cert.pl w ogóle istnieje. Szczególnie, jeśli portale piszące o bezpieczeństwie pokuszą się o interpretację danych.

Jednak przede wszystkim ludzie dostaną argument w rozmowach ze swoimi ISP, czemu ochrona nie jest włączona. Tym bardziej, że po stronie koszt ISP praktycznie żaden. I tak już utrzymują mechanizm w związku z ustawą antyhazardową, wystarczy dodać obsługę kolejnego źródła danych.

Po krótkim namyśle stwierdziłem, że dane powinny być zbierane publicznie. Tak, aby każdy mógł sprawdzić, skąd się wzięły i ew. samodzielnie zweryfikować ich poprawność. Zresztą nie mam ani dostępu do wszystkich ISP, ani czasu na ich samodzielne testowanie.

Szybko zrobiłem repo projektu badającego adopcję hole.cert.pl na GitHubie, w którym zapisuję dane. Plus prosty skrypt w bashu, który ma ułatwić zbieranie danych.

Trudności

Niestety, nawet znając adresy IP serwerów DNS polskich ISP nie da się samodzielnie sprawdzić jak resolvują daną domenę. Ze względu na ataki DDoS wykorzystujące open resolvery DNS do amplifikacji, większość serwerów limituje dostęp do usługi. Zresztą ISP nie mają obowiązku świadczenia usługi nie swoim abonentom, więc rozumiem. To akurat wziąłem pod uwagę od początku, stąd m.in. użycie GitHub i nadzieja na pomoc innych osób.

Kolejna sprawa: nawet jeśli ktoś korzysta z danego providera, to niekoniecznie korzysta z jego serwerów DNS. I niekoniecznie ma je podane bezpośrednio w konfiguracji komputera. Dlatego trzeba podawać je jawnie. A wcześniej ustalić. Nic trudnego, ale jest to ręczna robota – albo poszukanie na stronie ISP, albo wyciągnięcie z konfiguracji.

To co mnie zaskoczyło najbardziej: Android nie daje łatwej możliwości sprawdzenia aktualnie wykorzystywanych serwerów DNS. Szczególnie przy wykorzystaniu połączenia GSM nie znalazłem tej możliwości w ogóle. Dla WiFi są programy, które to podają[3].

W zasadzie należałoby nie tylko sprawdzać, czy ISP korzysta z tych danych, ale jak często je aktualizuje. Kampanie phishingowe są coraz bardziej dynamiczne, domeny żyją nawet tylko po kilka(naście) godzin. Czas reakcji jest więc kluczowy dla rozwiązania. Synchronizacja raz dziennie byłaby słaba… Niemniej, CERT również opiera się na ręcznie dostarczanych danych i podlegają one ręcznej weryfikacji, a to potrafi chwilę trwać[4]. Wymaga to trochę innego podejścia, w tym cyklicznego uruchamiania skryptu, więc na początek odpuszczam.

Co dalej?

Planuję zebrać dane samodzielnie i z pomocą znajomych dla największych polskich ISP, którzy z nich blokują phishing. Dopracować skrypty i metody zbierania danych, szczególnie dla urządzeń mobilnych. Ustalić docelowy format plików.

Jeśli pomysł „chwyci”, postaram się dorobić badanie opóźnienia między pojawieniem się domeny na hole.cert.pl, a propagacją danych do systemów DNS danego ISP. Jeśli ktoś jest zainteresowany, zachęcam do pomocy. Raczej na GitHub, niż w komentarzach, ale nie będę wybrzydzał.

UPDATE Dobrzy ludzie przypomnieli, że istnieje coś takiego jak RIPE Atlas probe i doładowali kredyty, używane przy requestach API. Wygląda, że nada się idealnie, więc nieco zmodyfikuję podejście. Tym bardziej, że będzie łatwa możliwość zrobienia samodzielnych, cyklicznych zapytań i mierzenia czasu propagacji.

UPDATE 2 Wygląda, że RIPE Atlas probe nie potrafi zwrócić pełnego wyniku resolvowania domeny (tu: rekordów A) z danej sondy, wykonanego z danej sondy na konkretnym serwerze DNS. Będę jeszcze badał temat czy nie można jakoś tego obejść, ale w API nie znalazłem. Dobrzy ludzie też nie, więc to nie moja ślepota.

UPDATE 3 Jednak zwraca, choć w mniej oczywisty sposób. Wyjaśnienie w kolejnym wpisie.

[1] Akurat ta domena nie była jeszcze blokowana na hole.cert.pl, została zgłoszona jako phishing i… nadal jej nie widzę w blokowanych. Zdarza się.

[2] Tak pewnie myśli każdy z niezerowym pojęciem o komputerach i bezpieczeństwie IT, prawda?

[3] Tylko co mi po nich, jeśli wtedy jest to IP routera, ew. ISP stacjonarnego?

[4] Nawet robiłem jakiś benchmark, ale próbka zdecydowanie za mała, żeby wyciągać wiążące wnioski. Nie było źle.