Kategoria: Security

Opublikowane w

Przyspieszyć hashcata

Na blogu nfsec.pl pojawił się wczoraj wpis dotyczący crackowania hashy md5crypt[1] przy pomocy hashcat. Spojrzałem na sprzęt i moją uwagę przykuła wydajność karty Intela Intel(R) Iris(TM) Graphics 650:

Hashmode: 500 - md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5) (Iterations: 1000)
Speed.#2.........:   423.2 kH/s (53.30ms) @ Accel:256 Loops:250 Thr:8 Vec:1

Mam Intel Corporation Skylake GT2 [HD Graphics 520] widzianą jako Intel(R) Gen9 HD Graphics NEO i hashcata w wersji v5.1.0 (binarka, stable), na potrzeby zabaw z platformami CTF, o których wspominałem niedawno. Część zadań wymaga użycia brute force. Chociaż nie było do tej pory okazji wyjść poza coś typu gotowy słownik, to pewnie jeszcze się przyda. Rzecz w tym, że moja karta jest znacznie wolniejsza:

Hashmode: 500 - md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5) (Iterations: 1000)
Speed.#1………:   156.1 kH/s (76.04ms) @ Accel:256 Loops:250 Thr:8 Vec:4

Rozumiem, że to inny sprzęt i inny system (u mnie Debian w wersji unstable), ale postanowiłem podrążyć temat.

Po pierwsze, zauważyłem, że mam starsze pakiety OpenCL dla Intela. Aktualizacja nie przyniosła co prawda poprawy wydajności, ale na innym sprzęcie (Ubuntu) była w ogóle niezbędna do poprawnego działania hashcata. Bez najnowszej wersji md5crypt w ogóle nie dawał się tam łamać.

Po drugie, hashcat, którego użyłem w wersji z GitHub (wersja development) to v5.1.0-951-g6caa7869 (również niezbędny na Ubuntu do poprawnego łamania md5crypt). Efekt okazał się całkiem przyjemny:

Hashmode: 500 - md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5) (Iterations: 1000)
Speed.#1………:   232.7 kH/s (51.57ms) @ Accel:256 Loops:250 Thr:8 Vec:4

Niemal połowę szybciej. Warto aktualizować soft i sterowniki, nawet, jeśli wersja wygląda na tylko nieznacznie nowszą. Co ciekawe, przyrost wydajności jest tak duży tylko dla niektórych algorytmów, w tym md5crypt. Inne, jak zwykłe md5 różnice mają jedynie symboliczne:

Hashmode: 0 - MD5
Speed.#1………:   476.6 MH/s (51.75ms) @ Accel:128 Loops:32 Thr:256 Vec:4

Hashmode: 0 - MD5
Speed.#1………:   493.4 MH/s (50.09ms) @ Accel:512 Loops:128 Thr:16 Vec:4

Tyle tym razem – trochę o instalacji i uruchomieniu hashcata, trochę o przyspieszeniu na poziomie softu. Mam świadomość, że to trochę takie wyścigi ślimaków, ale… jak się nie ma co się lubi, to się lubi co się ma. Może kiedy indziej będzie o doborze parametrów i budowie skutecznych słowników do crackowania hashy przy pomocy hashcata.

[1] Ładnie po polsku, owinięte w bawełnę, nazywa się to audyt haseł. Ewentualnie, mniej owijając w bawełnę, łamanie funkcji skrótu haseł. Zostanę jednak przy brzydkiej, potocznej wersji angielskiej.

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