Ventura

Trochę późno, bo dopiero wczoraj zaktualizowałem system do wersji Ventura. Biorąc pod uwagę mój stosunek do aktualizacji macOS, ta była wyjątkowo sprawna. Szczególnie biorąc pod uwagę rozmiar. Jednak w sumie nie widzę zmian godnych uwagi – trochę inne kolory, ot co.

Skoro jednak jest już pretekst, do wpisu, to przetestowałem nową wersję hashcata (v6.2.6-320-g9acfc26d8) na nowej wersji systemu. W stosunku do poprzedniej wersji, jest szybciej. Istotnie szybciej, nawet o 50% w niektórych przypadkach:

METAL API (Metal 306.3.5)
=========================
* Device #1: Apple M1 Pro, skipped

OpenCL API (OpenCL 1.2 (Dec 16 2022 20:37:40)) - Platform #1 [Apple]
====================================================================
* Device #2: Apple M1 Pro, GPU, 960/21845 MB (2048 MB allocatable), 16MCU

Benchmark relevant options:
===========================
* --optimized-kernel-enable

-------------------
* Hash-Mode 0 (MD5)
-------------------

Speed.#2.........:  6542.3 MH/s (0.97ms) @ Accel:64 Loops:1024 Thr:256 Vec:1

----------------------
* Hash-Mode 100 (SHA1)
----------------------

Speed.#2.........:  2718.3 MH/s (2.35ms) @ Accel:128 Loops:1024 Thr:128 Vec:1

---------------------------
* Hash-Mode 1400 (SHA2-256)
---------------------------

Speed.#2.........:   983.4 MH/s (6.52ms) @ Accel:64 Loops:1024 Thr:256 Vec:1

No i jeszcze md5crypt:

------------------------------------------------------------------------------
* Hash-Mode 500 (md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5)) [Iterations: 1000]
------------------------------------------------------------------------------

Speed.#2.........:  2516.6 kH/s (1.13ms) @ Accel:128 Loops:1000 Thr:64 Vec:1

Twitter wyłącza 2FA

Przepraszam za clickbaitowy tytuł, ale tak podobno zostały odebrane ostatnie działania i wiadomości wysyłane przez ten serwis. Zatem, gwoli ścisłości nie 2FA, tylko jedną z metod 2FA (SMS) i nie wyłącza, a udostępnia jedynie w płatnej wersji usługi. Nadal można mieć na Twitterze 2FA, za darmo, w dodatku w teoretycznie bezpieczniejszej wersji.

Wiadomość od Twittera w sprawie SMS Źródło: https://twitter.com/jsrailton/status/1626791204238008320

Motywacja jest oczywista. Chodzi o pieniądze. Wszyscy się przyzwyczailiśmy, że SMSy są darmowe, w pakiecie lub abonamencie. Bo taka jest rzeczywistość, przynajmniej w Polsce i dla SMSów wysyłanych w kraju. Tyle, że sytuacja z puntku widzenia serwisu internetowego wygląda nieco inaczej – korzystają z zewnętrznych dostawców, wysyłają do różnych krajów. To jest usługa, która kosztuje i to zapewne niemało. Czyli SMSy to taki rodzaj 2FA, gdzie całość kosztu ponosi serwis. No chyba, że przerzuci ten koszt na użytkownika, co Twitter właśnie zrobił.

Przy okazji, SMSy to jeden z najsłabszych rodzajów 2FA. Dla przeciętnego użytkownika Twittera być może nie ma to praktycznego znaczenia[1], ale istnieją ataki pozwalające na obejście tej metody komunikacji. Jak widać były w praktyce stosowane, także do przejmowania kont na Twitterze. Co gorsza, ofiara, czyli właściciel konta z takim 2FA praktycznie nie ma wpływu na skuteczność tych ataków. Atak odbywa się bowiem na dostawcę sieci komórkowej, a w zasadzie na jego pracowników obsługi klienta.

Dygresja: jeśli korzystamy z serwisu na telefonie i odbieramy SMS służące do 2FA na tym samym telefonie, to czy to jest jeszcze drugi składnik zaczyna być mocno dyskusyjne. Zależy od zagrożenia, przed którym chcemy się bronić. Dla kradzieży hasła czy sesji np. przez XSS wystarczy, dla malware na telefonie czy kradzieży telefonu – niekoniecznie. Dotyczy to także innych metod 2FA, jak email czy TOTP w Google Authenicator[2] czy aplikacji.

Niezależnie od motywacji, zapewne przypadkiem, Twitter został pionierem rewolucji w security na miarę walki Orange ze spamem przez zablokowanie wysyłki maili na porcie 25. Jest to pierwszy duży serwis, który odsyła przestarzałe 2FA via SMS tam, gdzie jego miejsce. Tj. do fanaberii typu papierowa faktura w usługach masowych. Tu od dawna mamy mniej lub bardziej zawoalowane opłaty za wystawianie papierowych faktur. Zwykle w formie „będzie 5 zł taniej, warunkiem skorzystania z promocji jest wyrażenie zgody na faktury elektroniczne”. I jakoś nikt z tym nie ma problemu. Chociaż faktury elektroniczne są także tańsze dla firm. Ale lepsze, bo nie marnujemy papieru i środków na jego transport.

Jeśli ktoś chce nadal korzystać za darmo z 2FA dla konta na Twitterze, to nadal ma dostępne takie opcje:

Opcje 2FA na Twitterze. Źródło: https://twitter.com/mkusiciel/status/1626851994097922048

Według mnie marginalizacja 2FA via SMS to dobra zmiana i będę kibicował innym serwisom, które się zdecydują na jej wprowadzenie. O wadach i zaletach poszczególnych metod 2FA może napiszę innym razem.

[1] Przykro mi, nikomu nie zależy na przejęciu naszych kont. A przynajmniej nie jest to warte ryzyka i/lub kilkuset złotych.
[2] Upraszczam, nie tylko Google Authenticator to oferuje. Tak naprawdę to trywialny algorytm, ale ta implementacja jest najbardziej znana i chyba najpopularniejsza.

Publiczne Wi-Fi a bezpieczeństwo

Wczoraj ukazał się artykuł o tym, czy korzystanie z publicznego Wi-Fi jest bezpieczne. Uważam, że prezentowane tam podejście jest dość optymistyczne. Nie uważam obcych sieci za tak bezpiecznie, jak pisze autor. Wszystko zależy od tego, czego się obawiamy. I naszego poziomu paranoi.

Na pewno podłączanie do sieci Wi-Fi, jeśli zakładamy złe zamiary jej właściciela lub innych użytkowników jest bezpieczniejsze, niż podłączanie kablem ethernetowym. Ot, nikt nie poda wysokiego napięcia na kablu i nie spali nam urządzenia. No ale żarty na bok.

Publiczne Wi-Fi – zagrożenia

Podłączając się do cudzej lub publicznej sieci ujawniamy informacje o swoim urządzeniu i systemie. Np. syngatury urządzenia typu adres MAC czy hostname. W pewnych przypadkach dane te mogą zostać wykorzystane do… powiedzmy przypisania nam pewnych działań. Ale to bardziej naruszenie prywatności niż realny atak. Pójdźmy dalej.

Podłączając się do sieci eksponujemy nasze urządzenie na bezpośrednie połączenia. OK, jeśli ktoś ma firewall lub nie udostępnia żadnych usług innym komputerom w sieci lokalnej, to problemu nie ma. Ale już udostępnienie zasobu chronionego prostym hasłem z laptopa w sieci domowej, gdzie bezpośredni dostęp miały tylko nasze urządzenia może okazać się zgubne. W naszej sieci przed atakami z internetu mógł chronić router (NAT).

Nie taki HTTPS wspaniały

Wspomniany w artykule HSTS ma dwie wady. Po pierwsze, adopcja. Zwyczajnie nie wszystkie strony z niego korzystają. Żeby daleko nie szukać, tamten artykuł zamieszczony jest na stronie bez HSTS. I pewnie ktoś przytomnie zauważy, że przecież to tylko blog, a nie bank. To polecam samodzielne sprawdzenie, czy, ew. które polskie banki korzystają z HSTS na stronach. O HSTS z preload litościwie nie wspominam.

Po drugie, jest to mechanizm TOFU. Tzn. nie zapewnia bezpieczeństwa przy pierwszym połączeniu. Owszem, przeglądarka w kolejnych połączeniach do strony, przez zwykle długi okres ważności, będzie już korzystać z HTTPS. Ale jeśli jest to nowa strona lub otwierana w nowej przeglądarce to HSTS nic nie daje.

Dodatkowo autor wspomina o powszechnych przekierowaniach HTTP -> HTTPS. Tylko niestety taki mechanizm nie zapewnia bezpieczeństwa. OK, może je podnosić w szczególnym przypadku, jeśli jest stosowany łącznie z HSTS. Bez tego raczej zapewnia złudzenie bezpieczeństwa. Bowiem jeśli pierwszy request jest wykonywany po HTTP, to nadal DNS spoofing jest groźny. Atakujący może dowolnie rozwiązać nazwę domeny do której próbujemy się połączyć. Np. na swój serwer. I tam wykonać przekierowanie HTTP. Redirect (301) może być na cokolwiek. Także na domenę z poprawnym HTTPS. Tyle, że niekoniecznie tę, na którą chcieliśmy się połączyć. Tylko np. na domenę homograficzną, albo domenę o zbliżonej nazwie. Ot, choćby wchodząc na http://mojbank.pl możemy skończyć na https://mojbark.pl, o wyglądzie identycznym jak https://mojbank.pl. I z poprawnym certyfikatem HTTPS i „kłódeczką”.

No i ostatecznie nawet połączenie HTTPS z poprawnym hostem nie gwarantuje jeszcze, że jest w pełni bezpiecznie. W niektórych przypadkach, na które użytkownik nie ma wpływu, nadal możliwe mogą ataki na HTTPS. OK, w przeciwieństwie do DNS spoofingu są trudniejsze do wykonania.

Jak korzystać bezpieczniej z publicznych Wi-Fi?

Czy to znaczy, że zupełnie nie zgadzam się z autorem? Niekoniecznie. Zgadzam się, że jest o wiele bezpieczniej, niż kiedyś. Generalnie jeśli ktoś naprawdę musi skorzystać z Wi-Fi i miałbym dać tylko jedną radę to byłoby to: włącz DoH w przeglądarce i wpisuj adresy w pasku adresu przeglądarki „z palca”, korzystając z podpowiedzi. No wiem, to w zasadzie dwie rady. Ale przyjmijmy, że jedna, tylko złożona.

Czemu tak? DoH zapewni nam odporność na DNS spoofing, a dodatkowo da bonus w postaci podwyższenia prywatności. Potencjalny podsłuchujący nie dostanie adresów odwiedzanych stron „na tacy” w postaci nieszyfrowanych zapytań DNS. W części przypadków w ogóle nie będzie w stanie ustalić z jakim serwisem się łączymy.

Wpisywanie domen w pasku adresu, z wykorzystaniem podpowiedzi uchroni przed kliknięciem w podobną domenę i zwiększy szansę na wykorzystanie protokołu HTTPS już od pierwszego requestu.