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„.

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 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.

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…

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.

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.

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. 😉

MauiBot – analiza zachowania bota

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

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) i nawet 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.

Jak zabezpieczyć domową sieć Wi-Fi?

Ciągle słychać o błędach w urządzeniach Wi-Fi, ale zwykły użytkownik nie ma wielkiego pola manewru – z routera Wi-Fi korzystać będzie, może co najwyżej liczyć na aktualizację oprogramowania przez producenta. Postanowiłem popełnić krótki praktyczny poradnik o tym, jak łatwo zabezpieczyć sieć Wi-Fi w domu czy SOHO. Zakładam, że konfigurowany będzie dowolny router Wi-Fi, nie określonego producenta. Nie będę podawał konkretnych zakładek/nazw, bo na różnych routerach różnie się opcje nazywają. Efektem jest przyzwoicie zabezpieczony sprzęt w domu, zmniejszający także szansę na wykorzystanie luk w oprogramowaniu – w większości przypadków konieczny jest dostęp do urządzania przez atakującego.

Podstawy

Wymienione poniżej czynności są absolutną podstawą, a efektem jest przyzwoicie zabezpieczona sieć.

  1. Zmiana hasła administracyjnego do urządzenia – warunek absolutnie konieczny. Bez tego możliwe są ataki na urządzenie przy pomocy dowolnej strony odwiedzanej z przeglądarki w sieci domowej.
  2. Wyłączenie zarządzania na porcie WAN – po co ułatwiać włamania z zewnątrz?
  3. Włączenie szyfrowania WPA2 lub WPA + AES – brak szyfrowania czy WEP nie są żadnym zabezpieczeniem, któryś z tych dwóch powinien być obecny nawet w starych sprzętach.
  4. Wyłączenie WPS – dodawanie urządzeń przy pomocy PINu może być kuszącym ułatwieniem, ale drastycznie ułatwia włamanie do sieci.
  5. Aktualizacja firmware do urządzenia do najnowszej wersji – to, że urządzenie jest nowe i prosto ze sklepu nie oznacza, że ma wgrane nowe oprogramowanie. Warto sprawdzić, czy producent nie wydał nowszej wersji oprogramowania, często poprawiane są różne błędy dotyczące stabilności i bezpieczeństwa.
  6. Ustawienie silnego hasła do Wi-Fi – patrz rozdział o hasłach.
  7. Okresowe przeglądy – patrz rozdział o przeglądach.

Dodatki

Poniższe czynności są opcjonalne, ich skuteczność jest niewielka, dyskusyjna, albo niekoniecznie są proste czy w ogóle możliwe do wykonania.

  1. Wyłączenie zarządzania routerem przez Wi-Fi – jeśli komputer jest podłączony po kablu, nie jest to żadne utrudnienie, w innym przypadku średnio wygodne, ale podnosi nieco bezpieczeństwo, zwłaszcza jeśli wpuszczamy do swojej sieci różne obce urządzenia po Wi-Fi. Zabezpiecza przed ominięciem uwierzytelniania w przypadku błędów oprogramowania.
  2. Zmniejszenie mocy Wi-Fi – brak zasięgu oznacza brak możliwości zaatakowania sieci bezprzewodowej. Ale napastnik może mieć porządną antenę kierunkową… Tak czy inaczej, nie ma sensu zakłócać urządzeń sąsiadom – jeśli mamy przyzwoity sygnał to zwiększanie mocy nie poprawi parametrów naszej sieci.
  3. Wydzielenie osobnej sieci dla gości – czy to poprzez wirtualny access point, obecny w niektórych sprzętach, czy poprzez osobne urządzenie.
  4. Ukrycie widoczności sieci – moim zdaniem złudne zabezpieczenie. Atakujący i tak jest w stanie taką sieć wykryć, a może to utrudniać dołączanie urządzeń czy wybór najlepszego kanału.
  5. Ograniczenie dostępu na podstawie MAC adresu – kolejne złudne zabezpieczenie, bo MAC adresy można zmieniać. Niemniej trochę pomaga, bo nie każdy umie zmienić i nie każdy sprzęt/sterownik pozwala w prosty sposób na zmianę MAC. Wiąże się z koniecznością każdorazowego logowania na router i dopisywania MAC przy wpuszczaniu nowego urządzenia do sieci, więc niezbyt wygodne.

Hasła

Hasła powinny być możliwie długie (myślę, że w dzisiejszych czasach 14-16 znaków to rozsądne minimum), zawierać cyfry, wielkie i małe litery. Z uwagi na wpisywanie hasła do Wi-Fi na urządzeniach mobilnych, warto wziąć pod uwagę wygodę wpisywania, zwłaszcza, jeśli wpisujemy je często, na różnych urządzeniach. Znaki specjalne zwiększają bezpieczeństwo haseł, ale uważam, że lepiej (wygodniej i porównywalnie pod względem bezpieczeństwa) mieć hasło o kilka znaków dłuższe, niż ze znakami specjalnymi.

Przeglądy okresowe

Raz na jakiś czas – czy to kwartał, czy co pół roku – warto sprawdzić czy jest dostępne nowsze oprogramowanie dla routera, zmienić hasło do Wi-Fi. Jeśli korzystamy z kontroli dostępu na poziomie MAC adresu – warto od razu zweryfikować listę i usunąć zbędne urządzenia.

Rozważania o blokowaniu ekranu

Przy okazji trwającej dramy dotyczącej xscreensavera w Debianie[1] przypomniał mi się pokrewny temat, o którym miałem robić wpis jakiś czas temu. Chodzi o blokadę dostępu do komputera, niezależnie od używanego systemu (Windows, Linux, OS X). Tradycyjnie jest to jakiegoś rodzaju wygaszacz ekranu, który po pierwsze blokuje możliwość odczytu danych z ekranu, po drugie, blokuje możliwość wprowadzania danych do uruchomionych programów. Do odblokowania zwykle konieczne jest podanie przez użytkownika hasła do systemu.

Rozwiązanie znane jest od dawna i wydawać by się mogło, że to wystarczy, ale czy tak jest faktycznie? Coraz więcej danych jest wprowadzanych i odbieranych z komputera nie tylko przy pomocy klawiatury i ekranu, ale także przy pomocy innych urządzeń. Programy do komunikacji VoIP, czy to Skype, czy aplikacja dostępna przez przeglądarkę typu appear.in czy hubl.in, po zablokowaniu ekranu nadal działają. Umożliwiają i odsłuchiwanie połączonych osób, i przekazują dane z otoczenia do nich. Zarówno za pośrednictwem audio, jak i video. Blokada ekranu co prawda wyłączy możliwość podglądu naszego rozmówcy, ale już nie wyłączy naszego webcama…

Jak na razie nie wiem nic o alternatywach dla wygaszaczy ekranu, które w momencie aktywacji blokowałyby nie tylko klawiaturę i ekran, ale dodatkowo wyłączały webcam(y) oraz wyciszały (mute) audio[2]. Pobieżne testy urządzeń z Androidem pokazują, że także na nich problem jest aktualny, przynajmniej w zakresie dźwięku. Warto po prostu pamiętać, że zablokowany komputer czy telefon w naszym otoczeniu wcale nie musi być tak do końca zablokowany…

[1] Skomentowałem u developera na blogu i wystarczy, wpisu nie będzie, sytuacja jest IMHO żenująca, więc szkoda klawiatury – jeśli ktoś ma cierpliwość, to wystarczy śledzić podlinkowane źródła.

[2] Jeśli istnieją systemy z takimi rozwiązaniami, albo samodzielne aplikacje, to chętnie poznam – u nikogo z nowszym Windowsem nie widziałem takiego rozwiązania.