Kategoria: Security

Opublikowane w

Skutki wycieku danych z Morele.net

Jakiś czas temu ze sklepu internetowego Morele.net wyciekły dane. W sieci zaroiło się od reakcji, dość skrajnych. Od psioczenia na słabe zabezpieczenia i „jak tak można było” i „pójdę z tym do sądu” po „nie stało się nic„.

Informacje o wycieku

Z serwisu Morele.net wyciekły maile, imiona, nazwiska, numery telefonów dla 2,2 mln kont. Oraz prawdopodobnie, dodatkowo, jak twierdzi włamywacz, a czemu zaprzeczyły Morele.net, numery PESEL oraz skany dowodów osobistych dla kilkudziesięciu tysięcy kont, a włamywacz ujawniał kolejne szczegóły na Wykopie (konto już usunięte).

Moim zdaniem prawda leży, jak to często bywa, gdzieś pośrodku. Na pewno wyciek jest ważny ze względu na skalę – 2,2 mln rekordów w skali Polski to bardzo dużo[1], w dowolnym aspekcie – czy to do wysyłki spamu, czy do ataków phishingowych przy pomocy SMSów, czy wreszcie jako baza haseł, zarówno do próby bezpośredniego wykorzystania ich w innych serwisach, jak i do analizy i budowy słowników w kolejnych atakach.

W informacjach o wycieku z Morele.net poruszony był aspekt niezłego hashowania haseł. Niestety te niezłe hashe w praktyce niewiele wnoszą – być może nie uda się złamać, w sensownym czasie i sensownym kosztem, najtrudniejszych haseł, ale najsłabsze ok. 20% można złamać na CPU na pojedynczym komputerze w ciągu pojedynczych godzin.

Jeśli informacja o wycieku skanów dowodów jest prawdziwa, to jest to dla ofiar spory problem – możliwości do nadużcia spore, PESEL w zasadzie niezmienialny, a wymiana dowodu kłopotliwa. Przypuszczam, że chodzi tu tylko o kupujących na raty.

Hasła

Pozostałe 2,2 mln niespecjalnie ma powody do zmartwień, jeśli tylko nie stosuje schematycznych haseł oraz ma osobne hasła do różnych serwisów. W tym miejscu gorąco polecam programy do przechowywania haseł w stylu Keepass.

Jeśli hasła są różne w różnych serwisach to nawet ich siła nie ma specjalnego znaczenia, o ile w serwisie są tylko dane z bazy, nie można zrobić zakupu itp. OK, atakujący dostanie się do konta w sklepie internetowym. Co zobaczy, czego jeszcze nie wie? Historię zakupów? Ironizuję, ale zakładam, że nie jest w stanie robić zamówień itp. bez dodatkowego potwierdzenia. Mógł za to usunąć konto, jednym kliknięciem, bez potwierdzania. Cóż, to strata głównie dla sklepu – jeśli ktoś potrzebuje to założy nowe konto…

Maile

Jeśli chodzi o maile, to jest spora szansa, że już wcześniej trafiły do baz spamerów i marketerów. Chyba, że ktoś stosuje oddzielne aliasy do serwisów, ale wtedy zupełnie nie ma problemu – wystarczy usunąć alias. Podobnie z numerami telefonów. A jeśli ktoś chce mieć święty spokój, to przypominam, że usługi GSM tanieją i numer telefonu płatny w formie prepaid można mieć już za 5 zł rocznie i używać go w różnych mniej istotnych miejscach. Oczywiście można to zrobić w nowocześniejszy sposób.

Konta w sklepach internetowych

Tu dochodzimy do sedna: czy do zakupu w każdym sklepie internetowym faktycznie potrzebne jest zakładanie konta? Niektóre sklepy wymuszają założenie konta, ale staram się takich unikać, a z paru zakupów zdarzyło mi się zrezygnować z tego powodu. Jeśli już zakładamy konto, to dobrze by było, żeby wymagane było podawanie jak najmniejszej ilości danych. Zupełnie dobrze by było, gdyby serwisy pozwalały na ustawienie po jakim czasie nieaktywności usunąć konto lub chociaż cyklicznie przypominać mailem o takiej możliwości.

[1] Kolejny duży polski wyciek, który kojarzę to ~700 tys. z Filmweb. Oczywiście polskie konta występują też na wyciekach światowych i będą to porównywalne ilości.

UPDATE: Wpis nieco przeleżał jako szkic i został ostatecznie opublikowany w formie nieco pociętej. Mimo tematu, który pozostał z wersji oryginalnej, celowo pominąłem m. in. spekulacje nt. skutków dla Morele.net i chciałbym, aby tak pozostało, również w komentarzach.

UPDATE2: Jak donosi Zaufana Trzecia Strona, baza sklepu Morele.net została ujawniona przez włamywaczy. Jakieś pięć miesięcy po ataku.

Opublikowane w

Trzy lata, sześć miesięcy i dwa tygodnie

Rzadko coś mnie zadziwia do tego stopnia i wielowymiarowo, jak to, o czym dowiedziałem się dziś. Chodzi oczywiście o błąd w Google+. No dobrze, nie sam błąd mnie zadziwił, bo ten był raczej mizerny. Poszło o to, że jeśli użytkownik Google+ udostępnił jakiejś aplikacji dostęp do danych publicznych swojego konta Google+, to aplikacja miała też dostęp do danych prywatnych. Z bardziej krytycznych – w świetle choćby RODO – do adresu email, imienia, nazwiska.

Chodzi o 500 tys. użytkowników, dane nie są super wrażliwe, udostępnione tylko aplikacjom. Oczywiście błąd pozostaje błędem, ale ten w dodatku został wykryty samodzielnie, nie na skutek wycieku. Ogólnie niezły potencjał na opowieść, którą nawet jeśli nie można się pochwalić, to nie ma się co wstydzić.

I tu pojawiają się tytułowe trzy lata, sześć miesięcy i dwa tygodnie, które jeżą włos na głowie. No dobrze, nie wszystkie. Trzy lata, to czas, kiedy podatność była dostępna. Tak naprawdę, powinny być dwa i pół, ale lepiej pasowało do clikcbaitowego tytułu. W dodatku zupełnie nie ma znaczenia ile czasu podatność była obecna – prawdopodobieństwo wykrycia nie rośnie z każdym dniem.

Ciekawe są dwie kolejne wartości. Sześć miesięcy to czas, przez który Google zataiło informację o podatności, bojąc się reakcji opinii publicznej. Wykryto ją w marcu 2018, ogłoszono wczoraj. W dodatku twierdzą, że w sumie nie wiedzą, czy podatność została wykorzystana, bo logi API mają z tytułowych dwóch tygodni, a nie trzymają ich dłużej, bo szanują prywatność użytkowników. Poważnie tak uzasadnili, w informacji o wycieku, która jest niejako przy okazji. Bardzo ładne zagranie PR-owe, ale jedyny komentarz, który przychodzi mi do głowy to:

Źródło: https://imgflip.com/i/2jpigy

Prędzej uwierzyłbym, że nie mają tych logów, bo im się na dyskach nie mieściły. 😉

Nie wiem, czy tak właśnie wygląda the right thing w świecie security, ale po graczu wielkości Google spodziewałem się jednak większej transparentności.

Kolejne zaskoczenie to reakcja rynku. Czy też może właśnie brak tej reakcji. Akcje Alphabet symbolicznie spadły, szybko odrobiły. Nie stało się nic… Przynajmniej na razie, zobaczymy jeszcze jak zareagują urzędy regulujące różnej maści, ale póki co wszystko wskazuje na to, że ani prywatność, ani transparentność nie są dzisiaj w cenie.

UPDATE: Po dokładniejszym zbadaniu, 10 grudnia, Google oznajmiło, że chodzi o 52 mln użytkowników więcej. Tzn. tylu więcej podobno dotyczył bug. O logach ani słowa. 😉

Opublikowane w

MauiBot – analiza zachowania bota

Pewnego dnia patrząc w logi serwera WWW zauważyłem sporą aktywność bota identyfikującego się jako MauiBot. Dokładnie:

MauiBot (crawler.feedback+dc@gmail.com)

Z zapałem crawlował labirynt dla botów. W User Agent nie było zazwyczaj obecnego URLa, żeby poczytać, co to za wynalazek, więc uruchomiłem wyszukiwarkę. Szybko udało mi się ustalić, że to bad bot, działający z chmury Amazonu (AWS). A nawet , że są reguły dla nginx do blokowania ruchu od niego.

Na początek parę znalezionych linków:

Wygląda, że bot pojawił się w marcu tego roku, czyli jest dość świeży. Wygląda też, że potrafi spowodować trochę problemów, przynajmniej na shared hostingach i/lub stronach słabo zoptymalizowanych.

Dokładniejszych informacji nie ma, więc postanowiłem poobserwować zwyczaje bota na własną rękę.

Wygląda, że 25 lipca ok. 1:20 trafił na moją stronę domową i zaczął podążać za kolejnymi linkami. Korzystał z IP 54.237.208.52, nie dało się obserwować opisywanego w niektórych miejscach wykonywania requestów grupami po 4-8 co 30 sekund. Wykonywał między 100 a 250 requestów na godzinę.

Tego samego dnia ok. 20:40 zmienił IP na 54.87.252.55 i… zaczął wszystko od początku. 26 lipca około 1:20 skończyły się requesty dotyczące blogów, pozostały tylko dotyczące wypasania botów.  W tym momencie intensywność crawlowania znacząco wzrosła – między 1600 a 2100 requestów na godzinę. Daje się też zauważyć grupowanie requestów, choć wygląda ono nieco inaczej niż w opisywanych w sieci przypadkach – 3-4 requesty co 5-6 sekund. Być może każdy wątek dla danej ścieżki wykonuje 4 requesty co 30 sekund.

Zaczynam też obserwować spadek liczby zapytań na godzinę. 26 lipca o godzinie 7 było 1500 requestów. Następnie systematycznie z godziny na godzinę spada do 900 requestów o 19 i 550 o godzinie 5 następnego dnia. O godzinie 19 27 lipca jest już tylko 340 requestów, a o godzinie 9 28 lipca już tylko 250 zapytań na godzinę.

W tym momencie zaczynam eksperymentować. Po pierwsze dodaję przed linkami z parametrami i za nimi linki z inną ścieżką, ale również prowadzące do labiryntu. Bot natychmiast za nimi podąża, najwyraźniej dokładając nowe wątki/procesy, bo liczba requestów wzrasta do ponad 700/h, przy czym liczba do bazowego powoli spada do ok. 200/h.

31 lipca liczba requestów to ok. 150/h. Podstawiam linka do labiryntu ale w innej domenie, ale MauiBot ignoruje tego linka. Trochę zbyt długo zwlekałem z analizą, obecnie bot reaguje bardzo powoli, więc publikuję teraz, a kolejne obserwacje pojawią się wkrótce, jako aktualizacja tego wpisu.

UPDATE

Aby sprawdzić, czy pomija ze względu na inną domenę, czy w ogóle przestał, dołożyłem kolejnego linka, tym razem w crawlowanej dotychczas domenie. Podążył za nim, a liczba requstów wzrosła do ok. 210/h. Podobnie bot podążył za URLem w tej samej domenie po podaniu pełnej ścieżki zamiast względnej, używanej wszędzie dotychczas.

Wygląda na to, że odwiedzone URLe są zapamiętywane. Bot nie wrócił do początkowego indeksu, mimo podanie osobnego linka w odwiedzonej już ścieżce.

Aby sprawdzić, jak sobie radzi z forkowaniem i jak to wpływ na ilość requestów, wysłałem go w dziewięć kolejnych, niezależnych miejsc.

Ostatecznie przestałem go obserwować na bieżąco przez cztery tygodnie i w zasadzie czekałem tylko, kiedy skończy pobierać i czy np. nie zmieni IP. Nie zmienił, za to pobierać przestał 20 sierpnia 2018. Tempo pobierania w ostatnich godzinach to ok. 335/h, pobierał ze wszystkich stron w grupach nie po 4, a po 8 requestów.