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.

Delegalizacja noży

Czy noże są legalne? Odpowiedź jest nieoczywista, w przypadku noży fizycznych i różni się mocno między państwami. Wygląda na to, że delegalizacja noży to etap do którego dotarła nasza cywilizacja. Przynajmniej w przypadku oprogramowania. Noże są metaforą, chodzi o narzędzia w postaci oprogramowania.

Tym razem wirtualnym nożem został program youtube-dl. W całej sprawie chodzi o zamknięcie jego repozytorium na GitHubie po otrzymaniu niedawnego żądania usunięcia na podstawie DMCA. Polecam lekturę, mi uzasadnienie wydaje się ciekawe – oprogramowanie służy do omijania zabezpieczeń i robienia nieautoryzowanych kopii. I rzekomo posłużyło do zrobienia nieautoryzowanych kopii artystów zrzeszonych w RIAA. W to ostatnie akurat jestem skłonny uwierzyć.

Zastanawiam się jednak nad pierwszą częścią. Pobranie z YouTube jest możliwe przy pomocy wielu narzędzi. Potrafi to każda przeglądarka internetowa. Kopię można zrobić smartfonem. O masie oprogramowania dedykowanego do odtwarzania multimediów, w tym z YouTube nie wspominam. Poza tym, w grę wchodzi dowolne oprogramowanie do rejestracji obrazu, nagrywania dźwięku czy nagrywania pulpitu. Tak wiele noży do zdelegalizowania…

Zresztą, celem umieszczania materiałów na YouTube jest udostępnianie ich publicznie. Szczególnie jeśli nie są ustawione ograniczenia widoczności, czyli materiał jest publiczny. A może znowu chodzi o reklamy i ich omijanie? Bo przecież narzędzie, czyli nóż może służyć do różnych celów. Na przykład do krojenia chleba. W przypadku youtube-dl mogę zrobić kopię własnych materiałów, które umieściłem na YouTube. Albo pobrać na dysk – legalnie w świetle polskiego prawa – materiały do ich odtwarzania bez zużywania transferu przez komórkę.

Sprawa jest głośna i zastanawiam się, jak się skończy ta próba delegalizacji noży. Czy usunięcie miało charakter automatyczny i zostanie wkrótce przywrócone? Całość jest ciekawa tym bardziej, że w grę chodzi GitHub jako miejsce do rozwijania oprogramowania. Jeśli usunięcie repozytorium zostanie utrzymane, to mogą być tu spore ruchy – ludzie mogą zacząć migrować na inne platformy. Smaczku sprawie dodaje fakt, że właścicielem GitHuba jest Microsoft, a YouTube Google.

UPDATE Program nadal można pobrać ze strony projektu, jest też dostępny w repozytoriach dystrybucji Linuksa.

UPDATE 2: O sprawie zdjęcia youtube-dl z GitHuba w kontekście legalnych zastosowań pisało EFF. Jest też artykuł w serwisie Torrentfreaks o odpowiedzi w postaci zamieszczania mp3. Oraz poruszona kwestia przeglądarek. Polecam.

UPDATE 3: Pojawił się ciekawy wpis na blogu pierwotnego autora youtube-dl w którym pisze o genezie projektu i realiach. Zachęcam do lektury.

UPDATE 4: Trwało to dłuższą chwilę, ale wygląda, że repo youtube-dl powróciło. Decyzja do przeczytania tutaj. Dłuższe uzasadnienie stanowiska GitHub. I zamierzają zmienić proces obsługi DMCA na bardziej przyjazny developerom.

Alert RCB przed wyborami

Alert

W sobotę, dzień przed drugą turą wyborów prezydenckich w 2020 dostałem, podobnie jak miliony Polaków, takiego oto SMSa zawierającego alert RCB:

SMS alert RCB
Screenshot SMSa od ALERT RCB

Zdziwiłem się. Jakiż to alert i czemu jest wysyłany w trakcie trwania ciszy wyborczej? Dziwna sprawa. A może w ogóle jakiś fake i dezinformacja? W końcu pojawiały się już nieprawdziwe informacje, że jeśli ktoś głosował w pierwszej turze na danego kandydata, to w drugiej nie musi, jeśli chce głosować na tego samego. Sprawdziłem na stronie rcb.gov.pl i tam znalazłem taką informację:

Lipiec 11, 2020 Kategoria: KOMUNIKATY

W związku ze zmianą zasad obsługi wyborców przez obwodowe komisje wyborcze,  do obywateli został wysłany Alert RCB o treści:

II tura wyborów prezydenckich w niedzielę 12.07. Osoby 60+, kobiety w ciąży oraz osoby niepełnosprawne będą mogły głosować w komisjach wyborczych bez kolejki.

I dodatkowo obrazek:

Jest też wyjaśnienie, czemu został wysłany:

Państwowa Komisja Wyborcza zwróciła się z apelem do organów władzy i administracji publicznej o jak najszersze rozpowszechnienie informacji o nowych przepisach wśród wyborców.

Do czego służy RCB?

Ale czy w ogóle RCB służy do tego? Popatrzyłem w FAQ, a tam:

Komunikaty będą wydawane tylko w wyjątkowych sytuacjach, które realnie mogą zagrażać życiu i zdrowiu człowieka.

Wiadomości tekstowe (SMS) są wysyłane tylko w nadzwyczajnych sytuacjach, gdy zagrożone jest bezpośrednio życie i zdrowie.

Alert RCB powstaje na podstawie informacji o potencjalnych zagrożeniach otrzymywanych z ministerstw, służb np. policji, straży pożarnej, urzędów i instytucji centralnych np. IMGW oraz urzędów wojewódzkich.

Alert RCB dotyczy wszystkich zdarzeń bezpośrednio zagrażających zdrowiu i życiu. Jest rozsyłany tylko w sytuacjach nadzwyczajnych.

Nijak mi nie pasuje informacja o zmianie zasad uczestnictwa w wyborach do żadnego z powyższych. Nie ma przecież żadnego zagrożenia, sytuacja nie jest wyjątkowa – zwykłe wybory. Wygląda więc, że ktoś zrobił sobie z RCB tubę propagandową. Chyba, że FAQ jest wyjątkowo słabe.

Wtopy

Czy uważam, że sytuacja była niejednoznaczna etycznie i mogła wpłynąć na wynik wyborów? Oczywiście.

Po pierwsze, głosowanie poza kolejnością dotyczy tylko niektórych grup społecznych. W szczególności osób w wieku 60 i więcej lat, czyli grupy, w której partia rządząca ma największe poparcie. Przypadek? Nie sądzę.

Po drugie, wszystko wskazuje na to, że wykorzystano struktury państwowych niezgodnie z przeznaczeniem do wysyłania informacji. Ciekawe, ile kosztowała ta akcja?

Zmiana zasad tylko w II turze, wysłanie informacji w ostatniej chwili również nie budzą zaufania.

Informacja była niepełna, nie zawierała informacji o tym, że do głosowania poza kolejnością uprawnione są osoby z dziećmi do lat 3. W komunikacie nie było również informacji o tym, że przesyłana informacja jest częściowa i gdzie można się zapoznać z pełną wersją. Próba manipulacji czy zwykła niekompetencja? Podobno nie należy przypisywać złych intencji, jeśli zachowanie da się wytłumaczyć głupotą…

Podobno motywacją była pandemia, więc konia z rzędem temu, kto wytłumaczy mi w jaki sposób osoby z dzieckiem do lat 3, niepełnosprawni czy wymagający kształcenia specjalnego są bardziej podatni na zarażenie.

Jak się dokładniej zastanowić, to przepisy promowały wypożyczanie dzieci do lat trzech w celu uniknięcia stania w kolejce.

Niebezpieczeństwa uprzywilejowania

Ogólnie uważam, że faworyzowanie jakichkolwiek grup społecznych podczas wyborów jest niebezpieczne. W przypadku zorganizowanej akcji może powodować tworzenie np. sztucznych kolejek, które będą zniechęcały ludzi spoza uprzywilejowanych grup do głosowania.

Mechanizm nadużycia jest prosty: stoi kolejka, przychodzi kilkadziesiąt albo więcej osób w sposób oczywisty należących do uprzywilejowanej grupy, zajmują miejsca na początku kolejki. I tak ciągle. W sumie nie muszą nawet głosować – kto im zabroni stanąć i odejść, nie oddawszy głosu? Czy osoby nie będące w uprzywilejowanej grupie, czekające w kolejce mogą się zniechęcić w takiej sytuacji do oddania głosu? Ano mogą.

PS Wpis niezbyt na czasie, bo ostatnie dwa tygodnie spędziłem bez komputera praktycznie – z racji sytuacji urlop pod namiotem. Ale podobno lepiej późno, niż wcale.

Niedoszła afera z Brave

Wszystko zaczęło się od wpisu o nieco przydługim tytule The Brave web browser is hijacking links, and inserting affiliate codes, który podrzucił kumpel z pracy. Z tytułu wynika, że Brave podmienia linki tak, aby używane były jego kody afiliacyjne.

Krótko o afiliacji – serwisy internetowe płacą za ruch, albo, dokładniej, za określone akcje użytkowników. Np. rejestracja w serwisie czy zakup produktu. Zwykle wejście od określonego polecającego jest identyfikowane przez odpowiedni parametr w URL, zliczana jest liczba interakcji, a na koniec okresu rozliczeniowego podmiot kierujący użytkowników do serwisu dostaje pieniądze. Takie płatne polecanie.

Z kolei Brave to przeglądarka, która reklamuje się jako szybka, bezpieczna. Blokuje reklamy i trackery, w zamian oferując użytkownikom możliwość zarabiania za oglądanie reklam i dzielenia się z twórcami stron WWW. Brzmi nieco utopijnie i podchodziłem nieco sceptycznie, ale… sprawdziłem, faktycznie jest szybka i bardzo łatwo pozwala na blokowanie reklam, bez konieczności zabawy z rozszerzeniami typu uBlock. Nie jestem fanem, ale przyznaję, że to świetna kombinacja do niektórych zastosowań.

Jak widać w artykule kręcona jest afera, jakoby przeglądarka Brave podmieniała linki i wstawiała swoje kody. Tak naprawdę użytkownikowi końcowemu jest raczej obojętne, kto skorzysta na jego rejestracji w jakimś serwisie. Oczywiście cicha podmiana psułaby biznes afiliacyjny, ale byłby to raczej problem wydawców. I żeby doszło do podmiany, użytkownik i tak musiałby wykonywać interakcję z portalem, na którym uruchomiona jest afiliacja. Biorąc pod uwagę, że chodzi o kilka portali związanych z krytpowalutami, szansa na to jest
niewielka. Więc nawet gdyby o to chodziło, to wpływ na użytkownika końcowego jest dyskusyjny i nie widzę powodu by rezygnować z dobrej przeglądarki. Choć oczywiście takie działanie byłoby kontrowersyjne od strony etycznej i ingerowałoby w wolność użytkowników.

Trochę dziwne byłoby jednak trzymanie listy „cichych podmian” publicznie w źródłach na GitHubie, prawda? No właśnie… Używam od pewnego czasu trybu przypuszczającego, bo tak naprawdę nie o podmienianie linków tak naprawdę chodzi. Z tego co sprawdziłem, nie chodzi o cichą podmianę bez wiedzy użytkownika, tylko o… wyświetlenie w sugerowanych stron z linkiem afiliacyjnym w ramach podpowiedzi, gdy użytkownik wpisuje odpowiedni ciąg w adresie strony.

Podpowiedź w pasku adresu w przeglądarce Brave

Użytkownik musi samodzielnie, ręcznie wybrać URL będący linkiem afiliacyjnym. Co więcej, opcję podpowiadania można w ogóle wyłączyć w ustawieniach, po prostu klikając, nie trzeba używać żadnych ukrytych opcji.

Wiadomo, że Brave to projekt komercyjny, więc jakoś zarabiać musi, ale w tym przypadku w mojej ocenie nie dzieje się nic złego. Nadal spokojnie można używać Brave, jeśli komuś zależy na szybkiej przeglądarce z wbudowanym blokowaniem reklam. Z racji tego, że źródła Brave są dostępne na GitHubie, ciche nadużycia będą raczej trudne do przeprowadzenia.

UPDATE: Dodałem screenshot poglądowy jak to wygląda. Ale przyznaję, że sprawdziłem niedokładnie i trochę racji w zarzutach jest – jeśli wpiszemy cały ciąg binance.us to jako podpowiedź wskakuje pierwszy URL, więc wciśnięcie klawisza enter w tym momencie spowoduje wejście z linkiem afiliacyjnym od Brave:

Podpowiedź w pasku adres w przeglądarce Brave – pełna nazwa, podświetlony link, który będzie użyty po wciśnięciu enter.
Podpowiedź w pasku adres w przeglądarce Brave – pełna nazwa plus spacja, podświetlony link, który będzie użyty po wciśnięciu enter.

Jak widać jest to widoczne dla użytkownika, jak widać powyżej dodanie jakiegokolwiek znaku (spacja, /) po binance.us spowoduje wejście bezpośrednie, bez podpowiedzi, ale… jest.

Terroryści wszystkich krajów, łączcie się!

Parę dni temu mignęła mi wiadomość na stronach Debiana, że jeden z developerów, Dmitry Bogatov, został zatrzymany. Przez moment zastanawiałem się, cóż takiego mógł zrobić i czy przypadkiem nie chodzi o zbieg okoliczności i działalność poza projektem Debian i pozainformatyczną w ogóle, bo trochę mi się w głowie nie mieściło jak projekt Debian może powodować aresztowanie. Nawet w Rosji.

Sprawa się wyjaśniła, chodzi o terroryzm[1]. Dokładniej, o prowadzenie węzła Tor. W dodatku wyjściowego, czyli tzw. exit node. Projekt Tor uruchomił akcję, w której wzywają do uruchomienia węzła wyjściowego lub jakiegokolwiek węzła Tor w geście solidarności z aresztowanym. Uruchomione w ramach akcji węzły powinny mieć w nazwie Bogatov lub KAction.

O ryzyku prowadzenia węzła Tor pisałem jakiś czas temu, miałem też notkę o konfiguracji relay node, czyli wersji bezpiecznej, w wersji z eleganckim monitoringiem w konsoli.

[1] Gdyby ktoś miał wątpliwości: w dzisiejszych czasach każda nieprawomyślność względem rządzących może być podciągnięta pod terroryzm, niezależnie od miejsca na świecie.