Tag: email

Opublikowane w

Prywatność przeciw bezpieczeństwu

Zaczęło się od historii związanej z cyberbezpieczeństwem. Użytkownik zauważył włamanie na swoje konto LinkedIn. Zapytał w social media, co się mogło wydarzyć, czy możliwe przejęcie dostępu do skrzynki pocztowej bo tam przyszedł mail z kodem potwierdzającym logowanie[1]. I czy dobrym pomysłem jest zapytanie dostawcy poczty o logi z ostatnich logowań. Informacje – jak zwykle w takich przypadkach – niepełne. Bo i nie wiadomo, co dokładnie jest potrzebne, istotne, i nikt nie napisze wszystkiego publicznie w social media. Akurat miałem chwilę, więc zaproponowałem telefon. Użytkownik nie chciał podać numeru, gdyż prywatność. Trochę rozumiem. Trochę nie. No nic, spróbujemy poczatować.

Skrzynka email była u dostawcy poczty z „no log policy”, więc nie wróżyłem sukcesów. Zasugerowałem w pierwszej kolejności zmianę hasła do poczty, ustawienie tam 2FA (nie było). Konto LinkedIn zostało zablokowane, chcą weryfikacji dokumentem. Użytkownik ma opory przed przesłaniem go do firmy trzeciej. Trochę rozumiem, trochę nie.

Nie znam charakterystyki wykorzystania komputera, ani nawyków. Te sama hasła w różnych miejscach? Raczej wyciek czy raczej stealer? Użytkownik zrobił jakieś skany antywirusem (nic wyraźnego nie znalazło), zmienił hasła w innych usługach[2] i ustawiał 2FA (dobry pomysł).

Timeline ataku:

  • 12:58 – pierwszy mail z kodem,
  • 13:00 – zmiana hasła do konta LinkedIn,
  • 13:02 – drugi mail z kodem (zapewne atakujący loguje się nowymi danymi),
  • 13:05, 13:08, 13:10 – dodane własne maile przez atakującego (czemu aż 3?).

LinkedIn wysyła sześcioznakowy kod na maila w celu potwierdzenia logowania. Nie wygląda na łatwe do brute force, kod był generowany tylko jeden za każdym razem. Czyli wszystko wskazuje na to, że atakujący miał dostęp do skrzynki. Ba, może nawet w ogóle najpierw uzyskał dostęp do skrzynki, zobaczył, że powiązana z kontem LinkedIn i je zaatakował? Dość długie odstępy pomiędzy kolejnymi krokami. Czyżby ręczne działanie?

W każdym razie pożar ugaszony. Pozostało obserwować, czy coś dziwnego się nie dzieje i ewentualnie odzyskać konto LinkedIn.

Jednak użytkownik jest niezadowolony. Narzeka, że LinkedIn nie rozpoznał ataku, a przecież IP było nietypowe, z innego kraju. Działania nietypowe. Narzeka, że chcą dokumentów. Trochę rozumiem, trochę nie.

Bo przecież z punktu widzenia użytkownika wszystko było w oczywisty sposób nietypowe. A z punktu widzenia LinkedIn? I ich skali?

Z perspektywy LinkedIn było to prawdopodobnie „czyste” logowanie. Prawidłowe hasło podane za pierwszym razem. Kod został wysłany na maila i potwierdzony. Zapewne także od razu. IP z innego kraju? To od lat bardzo słaba wskazówka. Masa ludzi korzysta teraz z VPNów, wielu urządzeń, wielu ludzi po prostu podróżuje.

Wyobraźmy sobie, że jesteśmy na urlopie w dalekim kraju, dostajemy sygnał od znajomych, że dziwne rzeczy dzieją się z naszym kontem w jakimś serwisie. Logujemy się, potwierdzamy kod z maila, chcemy zmienić hasło do serwisu. A skoro atakujący potwierdzali kod, to może problem jest ze skrzynką email? Chcemy zmienić inną, zaufaną, tam, gdzie mamy 2FA i wiemy, że wszystko jest OK. No i co, serwis miałby nie pozwolić? Kazać weryfikować się dokumentem? Nie wyobrażam sobie tego – ludzie by ich zjedli.

Blokada konta do czasu weryfikacji dokumentu jest jakby standardem. Nie jest idealna, ale działa dla wszystkich[3], niezależnie czy ktoś płacił, czy zmieniał telefon, adres itp. Prosta procedura, bez wyjątków i warunków, to dobra procedura. Atakujący nie przekona pracownika, żeby sprawdził akurat coś, nad czym akurat ma kontrolę.

Uważam, że część winy ponosi tu ślepe zachwalanie prywatności. Obrońcy prywatności krzyczą, że fingerprinting urządzeń zły[4], że trzeba się bronić. AI złe bo przetwarza dane nie wiadomo jak, trzeba się nie zgodzić. No log policy ma świadczyć o poszanowaniu prywatności, a VPN „zwiększa prywatność i bezpieczeństwo”. Ludzie może nie do końca rozumieją o czym mowa i dlaczego, ale wierzą. Wierzą reklamom, wierzą autorytetom. O tym, że nie wszystko jest dobre dla każdego, łatwo zapomnieć i mało kto to podkreśla. Wierzę, że agitatorzy prywatności nie mają złych intencji. Ale zapominają o poziomie wiedzy odbiorców i zakładają, że użytkownik jest w stanie sam skutecznie zadbać o bezpieczeństwo. Tymczasem niekoniecznie.

Czy gdyby fingerprinting był możliwy i powszechny, ludzie nie korzystaliby z VPNów tylko z „normalnych” IP, to serwisy lepiej chroniłyby użytkowników, lepiej rozpoznawały anomalie i byłoby bezpieczniej? Niekoniecznie. I raczej się tego nie dowiemy. Bo zabezpieczenia to koszt, czym innym jest profilowanie użytkownika dla większego zysku z reklam, a czym innym dla poprawy bezpieczeństwa. Za to wiemy, że teraz po prostu nie mają możliwości tego robić. Nie sensownie[5], nie w dużej skali.

[1] Dlatego maile czy SMSy nie są dobrym 2FA. Oczywiście lepszy rydz, niż nic, ale 2FA powinno być na innym urządzeniu i niemożliwe przechwycenia.
[2] Niekoniecznie dobry pomysł, bo jeśli to stealer, to skrajnie może doprowadzić do pogorszenia sytuacji poprzez wycieku danych logowania do większej ilości serwisów.
[3] Żeby zrozumieć pewne rzeczy, potrzeba czasu, bo przecież sam narzekałem kiedyś na procedurę w Allegro. No, ale tam chodziło jednak trochę o coś innego, nie o sam fakt żądania dokumentu.
[4] Wystarczy przypomnieć ostatnią aferę, choć tam nie do końca o fingerprinting szło, a sprawy poszły za daleko.
[5] Dla jasności, systemy wykrywające anomalie nadal istnieją i działają. Skuteczność jest… różna. I jednak czym innym jest oznaczenie zdarzenia jako podejrzanego, a czym innym automatyczna blokada.

Opublikowane w

Sfederowany problem

Mamy trzy główne topologie czy też modele działania usług w sieci: scentralizowany, sfederowany[1] i rozproszony. Każdy z nich ma swoje wady, zalety i… problemy. W tym wpisie będzie o tym, czemu federacja nie zawsze jest dobrym pomysłem, jaki problem wprowadził z powodu wyboru sfederowanego modelu Mastodon. I co można z tym zrobić.

Wstęp

Na początek dla przypomnienia – albo dla kontekstu – Mastodon to serwer social media, w założeniu mający być – mniej więcej – alternatywą dla Twittera. Działaja w oparciu o protokół ActivityPub. Zamiast jednego, centralnego serwera, działającego pod jedną domeną[2] istnieje wiele serwerów. Każdy z nich ma swoją odrębną domenę, swojego administratora, swoją moderację i swoich użytkowników. A pod spodem – swoją własną bazę danych. Jednak przy tych wszystkich odrębnościach, w przeciwieństwie do sieci scentralizwoanych, serwery wymieniają się między sobą danymi, jeśli zachodzi taka potrzeba. Czyli na Bluesky nie polubimy tweeta, natomiast w przypadku wpisu na Mastodonie (toot) nie ma przeszkód by użytkownik jednego serwera polubił wpis z innego[3].

Typowo za przykład sieci zdecentralizowanej podawane są serwery popularnej usługi, jaką jest poczta elektroniczna (email). Niezależnie, czy „skrzynkę”[4] mamy na Gmail, Outlook, Onecie, Protonie czy własnym serwerze, możemy wysłać mail i za – pośrednictwem protokołu SMTP – dotrze on na serwer odbiorcy.

Osobiście uważam, że lepszym, bliższym przykładem usługi sfederowanej, do której można porównać Mastodona, są grupy dyskusyjne, działające w oparciu o protokół NNTP. Niestety, usługa nie jest już powszechnie używana czy znana, więc jako przykład przybliżający ideę słabo się nadaje. Jednak wydaje mi się lepsza, bo zachodziła interakcja między wieloma użytkownikami, którzy mogli swobodnie wchodzić w interakcję z treściami zamieszczonymi przez innych użytkowników. Nie było określonego przez nadawcę odbiorcy.

Technicznie działało to tak, że administrator uruchamiał serwer NNTP, ustalał z jakimi serwerami wymienia się treściami, jakie grupy, czyli treści będzie utrzymywał na swoim serwerze. I jacy użytkownicy mogą z jego serwera korzystać, czyli pobierać i zamieszczać treści. Z punktu widzenia użytkownika wyglądało to tak, że łączy się do jednego serwera, odbiera wiadomości z wybranych grup dyskusyjnych napisane przez różnych użytkowników. A jeśli coś napisze, to trafia to na wszystkie serwery, na których obsługiwana jest dana grupa.

Problem

Tyle tytułem wstępu, pora przejść do problemu. Serwer Mastodona może postawić każdy. Obecnie działa blisko 10 tys. serwerów Mastodon[5]. Gdy któryś z użytkowników zamieści toot z linkiem do strony WWW, to wszystkie serwery, na których na których znajdują się jego followers (obserwujący), generują podgląd strony. W tym celu każdy z serwerów wysyła żądanie do docelowego serwera WWW w celu pobrania strony? Gdzie problem? Ano w tym, że w przypadku kont z większą liczbą obserwujących, tych serwerów potrafi być wiele. I wysyłają te żądania w zbliżonym czasie. Z punktu widzenia ofiary, czyli serwera WWW do którego link zamieszczono to coś w rodzaju DDoS.

Temat nie jest nowy, był dokładnie opisany w 2022, z wykresami, schematem działania i ilością żądań. Gorąco polecam lekturę, szczególnie jeśli w moim opisie jest coś niejasnego. Jest tam też trochę o zasadności nazywania tego działania DDoSem. Oryginalne zgłoszenie na GitHub jest jeszcze starsze i pochodzi z roku 2017. Sam schemat „ataku” w pewnym sensie przypomina botnet, przy czym kontrolującym byłaby tu dowolna osoba zamieszczająca link w treści toota, a boty wykonują tylko jedno żądanie.

Tyle, że to wystarcza do zakłócenia działania zewnętrznych usług. O tym, że problem nie jest jedynie teoretyczny, świadczą niedawne przykłady z kraju:

Czy linki dodawane na fedi obciążają serwery www? Obciążają, bo po dodaniu linku, każdy sfederowany serwer zaciąga sobie jego podgląd.
[…]
Spotkałem się już z głosami, że to coraz poważniejszy problem, porównywalny z małym atakiem DDOS. Nie wiem na ile wpływa to na obciążenie mojej strony, ale na pewno jest zauważalne. Dlatego będę pamiętał, aby dodawać link nieco wcześniej lub później niż w innych mediach.
Źródło: https://101010.pl/@rdrozd/113668863306405283

To jest problem, który mnie dotknął (blog na WP z wtyczką ActivityPub), po przeprowadzce na mniejszy serwer.
Mimo tego, że śledzących na fedi mam raptem niecałe cztery dychy, to pierwsza publikacja nowego wpisu zamuliła mi stronę na jakieś pół godziny, może dłużej, a logi były pełne błędów 500 i 503 (w tysiącach).
Dzięki pomocy @m0bi ustaliłem co bardziej obciążające wtyczki, wywaliłem je i trochę innych, zostawiając pewnie z połowę. Do tego czyszczenie instalacji i takie tam, a i tak pomogło dopiero zwiększenie limitów serwera. Dzięki temu przydycha po publikacji „tylko” na 5-10 minut :/
Myślałem o rezygnacji z wtyczki AP, ale widzę, że musiałbym też odpuścić wrzucanie odnośników do wpisów na fedi.

To właściwie uniemożliwia funkcjonowanie w fediświecie malutkim amatorskim blogom bez wsparcia dużych platform.
Źródło: https://pol.social/@LukaszHorodecki/113685265406284436

Jeśli chodzi o mnie i ten blog, to z zupełnie innej okazji mam nieco stuningowaną konfigurację, relatywnie mało obserwujących, a serwer uruchomiony na dedykowanym VPSie. Więc jedyne co zauważam – poza wpisami w logach – to kilkusekundowa mniejsza responsywność serwera[6].

Dlaczego problem dotyczy Mastodona, a nie innych wspomnianych wcześniej sfederowanych usług? Powody są dwa. Po pierwsze, poczta elektroniczne czy grupy dyskusyjne działają wyłącznie same ze sobą, nie wchodząc w automatyczne, masowe interakcje z zewnętrznymi usługami. Po drugie, zjawisko popularny serwis linkuje do mniejszego i ten nie daje rady obsłużyć ruchu jest znane od dawna pod nazwą Slashdot effect. Tyle, że w tamtym przypadku ruch inicjowany był przez ludzi, a nie automatycznie. Czyli problem wynika z architektury rozwiązania i implementacji.

Rozwiązanie

Możliwych rozwiązań jest kilka. Pierwsze, najprostsze, to usunięcie interakcji z zewnętrznymi usługami w ogólności, a funkcjonalności generowania podglądu w szczególności. Tyle, że to obecnie trochę standard w social media i Mastodon wyglądałby ubogo.

Kolejne rozwiązanie to wprowadzenie jakiegoś rozwiązania typu cache, działającego w obrębie całej sieci. Czy to w stylu: serwer, którego użytkownik zamieszcza link, jego serwer generuje podgląd i rozsyła go razem z tootem. Czy też w postaci zewnętrznego, wspólnego dla wielu instancji Mastodon, serwisu służącego do generowania podglądu. Wreszcie można wyznaczyć główne serwery, które będą generować podgląd, a pozostałe będą polegać na ich danych. Tyle, że wszystkie te rozwiązania – może pierwsze najmniej – podważają niezależność działania poszczególnych serwerów.

Innym rozwiązaniem jest zmniejszenie ilości serwerów, czyli większa koncentracja użytkowników. Jednak nie zanosi się na to i trudno w praktyce na to liczyć.

Konsekwencje

Z jednej strony trudno posądzać autorów rozwiązania o celowe stworzenie takiej architektury, by powodowała problemy zewnętrznych serwisów, Z drugiej strony jeśli coś wygląda jak kaczka, chodzi jak kaczka i kwacze jak kaczka... Problem jest znany twórcom Mastodona od blisko dekady i… jest uparcie ignorowany.

Piszę o tym, bo co jakiś czas wraca temat wykorzystywania scentralizowanych platform social media (Facebook, X/Twitter) przez instytucje publicznie. I pojawia się pomysł/propozycja wykorzystania Mastodona jako alternatywy. Według mnie, przy obecnym stanie rzeczy, jest to pomysł niepoważny. Trudno oczekiwać, by instytucje państwowe czy samorządowe wykorzystywały narzędzia, o których wiadomo, że mogą być szkodliwe dla innych usług w sieci.

Mnie osobiście ten stan rzeczy zniechęca do korzystania z platformy. Nie czuję się komfortowo z tym, że mój błahy wpis może powodować problem u jakiejś strony trzeciej. Może nie na tyle, by przestać zupełnie z niej korzystać, ale na tyle, by ograniczyć aktywność. Staram się linkować tylko do swoich stron i nie podbijać (boost) wpisów z linkami.

UPDATE. Jeszcze – zanim nastąpi rotacja logów – ilość żądań GET do wpisu. Pierwsze odwołanie 16:44:36, następnie, per minuta:
16:44 – 67
16:45 – 201
16:46 – 3
16:47 – 42
16:48 – 22
16:49 – 5
Praktycznie wszystkie pochodzą od botów (zawierają słowo Bot).
Łączna ilość GET w dniu 06.03.2026 – 516, z czego 431 zawierało słowo Bot.

[1] Znany też jako zdecentralizowany.
[2] Uproszczenie, w praktyce scentralizowane serwisy mają wiele serwerów, ale dla łączącego z zewnątrz użytkownika jest to niezauważalne.
[3] Uproszczenie, serwery muszą dopuszczać federację między sobą, użytkownicy nie mogą się blokować. Jednak stan domyślny i wyjściowy jest taki, że mogą.
[4] Czyli adres email.
[5] Źródło, Marzec 2026, tylko serwery działające w oparciu o oprogramowanie Mastodon. W praktyce jest więcej kompatybilnego oprogramowania o podobnym schemacie działania.
[6] Dla pamięci: load average 9,95, 3,51, 1,25 w po kilkudziesięciu sekundach od zamieszczenia tego wpisu. Możliwe, że zasługa popularnych tagów, nie ilości obserwujących. Typowo jest load average: 0,17, 0,36, 0,18.

Opublikowane w

Hasło Alert

CERT Orange uruchomił nową usługę o nazwie Hasło Alert. W zasadzie idea jest podobna jak Have I Been Pwned, ale stwierdziłem, że przetestuję. Zawsze jest szansa, że będą mieli dostęp do lokalnych wycieków, które na HIBP nie trafiły. Czy tak jest w istocie? Nie wiem, jest wyłącznie informacja o autorskim rozwiązaniu. Nie ma żadnych informacji o źródłach ani ewentualnej współpracy z innymi podmiotami.

Pierwsza rzecz, która rzuca się w oczy to podtytuł Sprawdź czy Twój mail nie wyciekł. W tytule strony hasło, w podtytule email, przypuszczam, że osoby mniej zorientowane mogą się pogubić. Tym bardziej, że nie widzę by było to wytłumaczone gdzieś dokładniej. Oczywiście chodzi o pary email i hasło w wyciekach. Ani sam email, ani samo hasło nie zostaną zgłoszone. Wynika to z zasady działania serwisu, o czym za chwilę. Czyli podajemy adres email, a dostajemy hasła, które wyciekły z serwisów dla konta z podanym tym adresem email.

To co mi się podoba, to fakt, że sprawdzenie, czy dany adres email pojawił się w wycieku wymaga dostępu do konta email sprawdzanego adresu. Aby przeszukać wycieki, trzeba kliknąć linka z potwierdzeniem zlecenia wyszukania. Same wyniki również są odsyłane mailem. Zapobiega to możliwości sprawdzania wycieków dla kont, które nie należą do nas. Zdecydowany plus, jeśli chodzi o prywatność.

Z samymi wynikami jest już znacznie gorzej. Porównując z HIBP, wyników jest mało. I nie chodzi tu wyłącznie o różnego rodzaju kompilacje wycieków. Z czego to wynika? Nie wiem. Może chodzić o zawężenie czasowe[1], może chodzić o dostęp do źródeł.

Jeśli chodzi o wyniki, to otrzymujemy zamaskowane hasło i datę. W haśle widoczna jest pierwszy i ostatni znak, oraz ilość liter, przy założeniu, że każda gwiazdka odpowiada jednej literze. Jest też jakaś data. Niestety nie jest wyjaśnione czy jest to data pobrania danych do wycieku, data publikacji wycieku, data pozyskania zbioru czy jeszcze jakaś inna. Zdecydowanie przydałoby się tu wyjaśnienie. Tym bardziej, że wyciek z LinkedIn z roku 2012, który został opublikowany w 2016, podawany jest jako… styczeń 2023.

Przede wszystkim brakuje jednak źródła wycieku, co czyni usługę w zasadzie bezwartościową. Zalecenia są słuszne, ale skoro nie wiadomo, do którego serwisu hasło zmienić, to mało przydatne w praktyce. A zmiana wszystkich haseł, bo gdzieś jakieś podobno wyciekło to chyba overkill. No chyba, że ktoś używa tego samego hasła w wielu miejscach, ale wtedy ma większy problem. I nie potrzebuje sprawdzać, czy wyciekło, tylko od razu może zmienić hasła ustawiając różne dla różnych serwisów.

Ponieważ korzystam z managera haseł, postanowiłem – mimo braku podanego źródła – sprawdzić, które moje hasła wyciekły. I tu zaskoczenie, bo w większości przypadków nie udało mi się znaleźć pasujących kandydatów. Nawet biorąc pod uwagę tylko pierwszy i ostatni znak, bez ilości liter. Dziwne, bo i niektóre wycieki świeże, i manager haseł przechowuje nie tylko bieżące hasło, ale także poprzednie. Czyli nawet gdybym zmienił hasło po informacji o wycieku, to powinienem mieć je zapisane w managerze.

Niestety nie wiem, czy jest to błąd po stronie systemu, błąd w wycieku, czy jednak zmieniłem hasło więcej niż raz. I bez źródła danych nie jestem w stanie tego określić.

Podsumowując – Hasło Alert to ciekawa inicjatywa, ale w tej chwili wg mnie mało użyteczna. Przede wszystkim brakuje źródła wycieku, ale przydało by się też nieco więcej objaśnień. Liczę, że wkrótce pojawią się zmiany w tym zakresie.

[1] Najstarsza data, którą widziałem to 2019.