Tag: prywatność

Opublikowane w

Nowa reCAPTCHA

Pojawiło się doniesienie o wprowadzeniu przez Google nowej wersji reCAPTCHA. Nazwa jest piękna Google Cloud Fraud Defense. Od razu wiadomo, jak opakowana została zmiana, w imię której będziemy poświęcać wolność. Walka z nadużyciami, bezpieczeństwo. W artykule jest security, safety, trust i fraud. Oczywiście pojawia się też AI.

Trochę miałem do czynienia z rozwiązaniami do detekcji botów, wydaje mi się, że widzę, w czym rzecz. Nowatorstwo rozwiązania nie jest w QR-code. Nie jest w konieczności użycia drugiego urządzenia do odczytania danych z pierwszego. To wszystko można oprogramować i zasymulować i zrobić na tym samym urządzeniu, automatycznie.

Prawdziwa natura nowego rozwiązania jest wg mnie widoczna w niepozornym fragmencie: By correlating telemetry across the entire lifecycle, our unified trust model identifies complex, multi-stage fraud campaigns that disconnected point solutions miss. This holistic view has demonstrated […] Wytłuszczenia moje.

Zmierzamy do tego, że poprawne rozwiązanie CAPTCHA, tj. bycie słusznie uznanym za człowieka, będzie opierało się na tym, że przynajmniej na jednym z urządzeń – o ile nie na obu – trzeba będzie wyrazić zgodę na telemetrię. Czyli pozwolić dostawcy – tu: Google – na pobieranie masy danych z urządzenia i o urządzeniu. O położeniu (geolokalizacj), o IP, o stanie baterii, zainstalowanych kodekach, fontach, o tym, jak i kiedy się porusza (akcelerometry). Wreszcie metadane o tym, które urządzenia były powiązane z którymi. I nie, nie na chwilę, tylko holistycznie przez cały cykl życia (cokolwiek ma to znaczyć).

A jeśli nie wyrazimy zgody? No cóż, w najlepszym wypadku stracimy więcej czasu na częstsze skanowanie lub rozwiązywanie innych form CAPTCHA. W najgorszym? Zostaniemy uznani za boty i pozbawieni dostępu do usług.

Czy będzie to skuteczne? Cóż, na początku pewnie tak. Czy da się obejść? Pewnie tak, ale wątpię, by obejście zyskało masową popularność. Ale masa danych, łatwych do skorelowania i niosących wiele informacji nie wprost trafi do dostawcy (tu: Google).

Dlatego mam szczerą nadzieję, że rozwiązanie spotka się z bojkotem użytkowników. Zarówno tych, którzy mieliby rozwiązywać CAPTCHA, jak i tych, którzy wybierają rozwiązanie, które wykorzystują. Zawsze zamiast rozwiązywać CAPTCHA można zrezygnować z dostępu/zakupu i zamiast tego zgłosić problem z dostępem do danych na stronie.

UPDATE: Nie padło to w pierwotnej wersji wpisu, ale oczywiście chodzi o umacnianie monopolu Google (ew. duopolu, bo jeszcze Apple). Weryfikacja na systemie Android wymaga telefonu z Google Play.

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

Browsergate

Skoro jest strona, to sprawa jest poważna, prawda? Coraz głośniej robi się o aferze ochrzczonej Browsergate. Zaczyna się od LinkedIn Is Illegally Searching Your Computer. Czyli grubo. Ale czy słusznie?

Wydaje mi się, że autorzy trochę wyolbrzymiają. Co się dzieje technicznie? Na stronie LinkedIn jest javascript, którego zadaniem jest zebranie informacji o zainstalowanych rozszerzeniach w Chome[1]. Jest to robione przy pomocy paru technik. Najważniejsza z nich opiera się o predefiniowaną listę rozszerzeń i obecnych w nich plików. Skrypt próbował czytać kolejne pliki i – w przypadku sukcesu – zapamiętywał informację, że dane rozszerzenie jest obecne (i aktywne). Tak zebrane informacje były wysyłane do właściciela LinkedIn, czyli Microsoftu. Nie ma natomiast mowy o przeszukiwaniu komputera, co sugeruje nagłówek autorów znaleziska. Aktywność jest ograniczona do plików rozszerzeń.

Autorzy znaleziska argumentują, że za sprawą rozszerzeń w przeglądarce można określić przekonania polityczne, religijne, zdrowotne i dotyczące zatrudnienia. Jestem w stanie się zgodzić, że w specyficznych przypadkach[2] faktycznie da się określić je z wysokim prawdopodobieństwem. I – ponieważ użytkownik jest zalogowany – skorelować z konkretną osobą.

Zatem oburzenie na Microsoft jest słuszne. Czemu jednak jest ograniczone tylko do tej jednej firmy, a Google i twórcy rozszerzeń są tu pominięci? Cała technika możliwa jest tylko dlatego, że przeglądarka Google, podobnie jak wszystkie pochodne Chromium, stosują stałe lokalne identyfikatory rozszerzeń. Nie jest to żadna tajemnica. Nie jest to też norma wśród przeglądarek. Firefox na przykład stosuje losowe identyfikatory lokalne. Takie działanie uniemożliwia stronie próbę odczytu znanego pliku z rozszerzenia, więc technika nie zadziała.

Dodatkowo, twórcy rozszerzenia muszą w manifeście jawnie zezwolić stronie[3] na dostęp do plików przy pomocy dyrektywy web_accessible_resources. Ładny opis, łącznie z tym, że Chrome nie ma losowych identyfikatorów znajdziemy na stronie Mozilli.

Czemu nie ma oburzenia na twórców Chromium, którzy nie randomizują lokalnych ID rozszerzeń? Ani na samych twórców rozszerzeń pozwalających na ustalenie wrażliwych danych, że pozwalają na czytanie plików rozszerzenia stronom[4]? No i w końcu zastanawia mnie, czy to jedyna strona, która tak działa?

Sama funkcjonalność odczytu plików rozszerzeń nie jest nowa i była znana wielu osobom (tak, znałem). Zastosowanie jest… interesujące. Mi masowe skanowanie rozszerzeń nie przyszło do głowy. Może dlatego, że nie mam zastosowania dla tych danych? Czy za sprawą Browsergate będzie mała rewolucja w świecie rozszerzeń i podejściu do prywatności? Zobaczymy.

[1] Tak naprawdę w pochodnych Chromium.
[2] Wymieniają te przypadki i są to konkretne rozszerzenia, których obecność Microsoft celowo sprawdza.
[3] Lub stronom, możliwe wildcardy.
[4] No dobrze, nie zawsze może dać się uniknąć dostępu do plików, zapewne zależy od tego, co dane rozszerzenie robi.