Kategoria: Security

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.

Opublikowane w

Dlaczego k-anonimowość nie jest dobra przy hasłach?

Na z3s.pl pojawił się artykuł o tym, czym jest k-anonimowość. Jest to dobry artykuł i warto go przeczytać przed lekturą tego wpisu. Nie zgadzam się jedynie z tezą, że w przypadku haseł jest to bezpieczna metoda sprawdzania. Napisałem komentarz, ale pewnie nie wszyscy czytelnicy bloga tam trafią. Ponieważ bawię się z bazą hashy z HIBP i planuję wkrótce wpis na ten temat, uznałem, że jest dobra okazja do wstępu.

Moja teza jest taka, że w przypadku haseł k-anonimowość wcale nie jest taka bezpieczna, jak jest to przedstawiane. Zgodnie z artykułem obecnie dla hashy z bazy HIBP pierwsze 5 znaków występuje od 381 do 584. Czyli podczas sprawdzenia strona trzecia nie poznaje ani hasła, ani jego pełnego hasha. Przekazywane jest jedynie pierwszych 5 znaków hasha, czyli – tu moja interpretacja – ma jedynie 1/381 do 1/584 prawdopodobieństwo, że zna właściwy hash.

Gdyby przyjąć, że strona trzecia jest złośliwa, warto też przyjąć, że jest inteligentna. Czyli zamiast prawdopodobieństwa zwykłego użyje prawdopodobieństwa ważonego, uwzględniając ilość wystąpień danego hasha. Dla przykładu z artykułu na z3s.pl i hasła P@ssw0rd mamy zwracanych 543 różnych hashy:

curl -s https://api.pwnedpasswords.com/range/21BD1 | wc -l

Natomiast suma wystąpień wszystkich hashy w momencie pisania tego wpisu wynosi 60808.

curl -s https://api.pwnedpasswords.com/range/21BD1 | awk -F ":" '{sum += $2} END {print sum}'

Nasz hash wystąpił 52579 razy. Znając zwyczaje ludzi dotyczące haseł i stosując prawdopodobieństwo ważone uzyskujemy 86% szansę na to, że chodzi o hash należący do hasła P@ssw0rd. Pewności nie ma, ale z 1/543 czyli z ~0,18% robi się 86%, czyli jakieś 467 razy więcej. Ups!

Oczywiście nie znamy tu samego hasła. Znamy jedynie – a i to jedynie ze sporym prawdopodobieństwem – jego hash. O tym, że to niekoniecznie jest problem, może będzie w którymś kolejnym wpisie.

W każdym razie gdybym był serwisem, to bałbym się odpytywać serwis trzeci o hashe haseł moich użytkowników. Użytkowników podejrzewam o proste, słownikowe hasła, jakiś serwis trzeci. Zwłaszcza jeśli ten serwis ma/może mieć także inne informacje, które pozwalają mu ustalić kto pyta o hasło. Tak właśnie może być w przypadku Cloudflare, który może dostawać część ruchu od użytkownika w ramach CDN, DNS lub DoH. Prosta korelacja czasowa może w tym przypadku prowadzić do powiązania hasha hasła z IP użytkownika. Jeśli chcemy sprawdzać hasła, to lepszym rozwiązaniem jest stworzenie lokalnej kopii bazy którą pobierzemy z HIBP.

Co nie znaczy oczywiście, że k-anonimowość ogólnie nie spełnia swojego zadania. Po prostu mam wrażenie, że akurat w przypadku hashy hasła i tej konkretnej implementacji nie jest tak bezpieczna, jak jest to przedstawiane.

Warto też zauważyć, że hasło z którym mamy tu do czynienia jest proste/populare. Dla innych pięcioznakowych początków hashy wystąpienia mogą rozkładać się inaczej, bez tak silnego wskazania na konkretny hash.

UPDATE Tak naprawdę nie ma potrzeby używania całej bazy hashy i ilości ich wystąpień z HIBP (>20GB). Najczęściej występujące 100 tys. hashy to raptem 3,2 MB. Najczęstszy milion – 32 MB.

Opublikowane w

Oddzwanianie

Zauważyłem nieodebrane połączenie na jednym z numerów telefonów. Zwykle nie oddzwaniam na nieznane numery, bo albo pomyłka, albo telemarketer. Tym razem miałem jednak powód by przypuszczać, że kontakt był zasadny.

Rzut oka na numer – polska komórka, żadna zagranica. Szybkie sprawdzenie w sieci na portalach zajmujących się zbieraniem informacji o numerach – nienotowany, czyli prawdopodobnie nie telemarketer.

Dzwonię. Odebrał automat i poinformował, że rozmowa jest nagrywana i że dane są przetwarzane zgodnie z zasadami opisanymi na stronie – tu adres podał adres w domenie jednego z banków, zawierający słowo RODO. Czyli wszystko w porządku! Albo… właśnie nie w porządku. Czy podane dane zwiększają bezpieczeństwo? Nie ma informacji, kto jest administratorem danych osobowych, nie ma informacji przez kogo jest przetwarzane. Nie ma nawet jednoznacznej informacji do kogo się dodzwoniłem. Zresztą, w przypadku oszustwa informacja o nagrywaniu rozmowy, dane dotyczące zawartości strony itp. będą zgodne z prawdą i służyć będą tylko wzbudzeniu zaufania.

Owszem, korzystam z usług tego banku. I mają w nim podany ten numer telefonu. Ale to jeszcze o niczym nie świadczy… Tego typu dane oszust może zdobyć z różnych miejsc w sieci albo… po prostu zgadywać numery i podawać się za któryś z popularnych banków. Jeśli bank ma powiedzmy 5% udziału w rynku, to mniej więcej dla takiego odsetka numerów będzie to wyglądało OK. Zapewne przytłaczająca większość błędnych adresatów po prostu zignoruje próbę kontaktu, uzna za pomyłkę, albo nie będzie wiedziała komu zgłosić taką „dziwną sytuację”[1].

Rozłączam, się. Wiem już, o który bank chodzi, znam numer telefonu. Szukam numeru na stronie banku i w wyszukiwarkach. Nie występuje. Nie wygląda to dobrze, więc zakładam roboczo próbę oszustwa i z takim nastawieniem dzwonię ponownie.

Odbiera osoba, która przedstawia się jako pracownik banku. Ja się nie przedstawiam, informuję tylko, że dzwonię, bo miałem nieodebrane połączenie. Moje pierwsze pytanie: jak mogę potwierdzić, że faktycznie jest pracownikiem banku i że to numer należący do banku. Jest nieco zaskoczona, ale podaje informacje, gdzie po zalogowaniu do banku znajdę jej dane i numer.

Proszę o chwilę cierpliwości. Loguję się do banku i sprawdzam w podanym miejscu. Faktycznie, dane się zgadzają. Dziękuję, przedstawiam się i kontynuujemy rozmowę.

Oczywiście dałem znać, czemu uznałem telefon/proces za podejrzany, ale nie bardzo wierzę w jego zmianę. Warto pamiętać, że jeśli sami nie nawiązujemy połączenia pod wybrany przez nas numer, np. wpisany ze strony internetowej instytucji, to nie mamy żadnej gwarancji, z kim rozmawiamy. Uważajmy więc w takiej sytuacji z podawaniem danych – bezpieczeństwo zależy w znacznej mierze od nas samych.

[1] Szczerze mówiąc, sam miałbym z tym problem – można próbować na infolinii instytucji, pod którą ktoś próbuje się podszyć, ale… różnie bywa ze zrozumieniem w czym problem.