Kategoria: Security

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

gocryptfs

Dawno, dawno temu przestałem używać EncFS. Przestałem z kilku powodów. Po pierwsze, pojawiło się ostrzeżenie o tym, że nie jest to rozwiązanie do końca bezpieczne. Niby nic i w moich zastosowaniach nie przeszkadzało[1], ale jakaś tam zadra w pamięci i niechęć zostały. Po drugie, zwykłe dyski zacząłem szyfrować „normalnie” przy pomocy LUKS. A backupy itp. przy pomocy GPG. Dziś odkryłem godnego następcę: gocryptfs.

Mimo zmian w używanym szyfrowaniu, po EncFS została jedna dziura: dyski zdalne typu Dropbox czy Google drive. Miło by było móc z nich korzystać „normalnie”, ale tak, żeby dane na tych dyskach były zaszyfrowane. LUKS tu nie pomoże, bo działa dla dysków lokalnych. Szyfrowanie przez GPG dla pojedynczych plików jest niewygodne, a pakowanie w jakieś archiwa jest dobre do backupów, nie do normalnego korzystania. EncFS jako overlay dostępny poprzez FUSE ze swoim szyfrowaniem per katalog był idealny. Nie trzeba z góry określać rozmiaru szyfrowanych danych, dostęp online do pojedynczych plików, z zachowaniem ich struktury.

Okazuje się, że jest godny następca dla EncFS i nazywa się gocryptfs. Nie wiem czemu nie znalazłem go wcześniej. Może odrzuciłem, bo był świeży i w golang? Może przeważył brak realnej potrzeby?

W każdym razie: jest i wygląda bardzo dobrze. Przeczytałem opis projektu i zasadę działania. Posiada sensowne założenia, był audytowany, brak przypadłości EncFS. Do tego jest bardzo szybki. Instalacja w Debianie z pakietu – żadnych kompilacji. Do tego świetna dokumentacja, proste użycie i… dopracowanie. Oczywiście open source. Działa na Linuksie, macOS, istnieją nieoficjalne porty dla Windows i Androida.

Żeby przybliżyć o czym mowa. Weźmy takie utworzenie szyfrowanego katalogu. Jedno proste polecenie, podajemy hasło, powtarzamy je i… dostajemy master key, wraz z przeznaczeniem i jak się z nim obchodzić. Aż pokażę[2], bo na stronie tego nie ma:

$ gocryptfs -init cipher/
Choose a password for protecting your files.
Password:
Repeat:

Your master key is:

d28966ae-f39ff48a-695993f9-a5e354eb-
3d31e7a1-29c834c5-31b2cb3b-b38b6cec

If the gocryptfs.conf file becomes corrupted or you ever forget your password, there is only one hope for recovery: The master key. Print it to a piece of paper and store it in a drawer. This message is only printed once.
The gocryptfs filesystem has been created successfully.
You can now mount it using: gocryptfs cipher MOUNTPOINT

Prawda, że piękne? Bardzo możliwe, że przyda się i wkrótce wrócę do tematu zdalnych dysków.

[1] Moje zastosowania: nie będą mi dyski sieciowe w stylu Dropbox grzebać po plikach, nawet jeśli nic tajnego tam nie ma.
[2] Jakby ktoś zaczynał panikować, że „ojej, master key podał” to spieszę donieść, że to z testowego katalogu utworzonego na potrzeby tego wpisu, żadnych danych tam nie ma i nie będzie.

Opublikowane w

Potwierdź mój wiek, anonimowo

Pojawiło się zagadnienie weryfikacji wieku przyjaznego dla prywatności czyli anonimowej weryfikacji wieku. Czyli mamy serwis X, który chce potwierdzić, że użytkownik ma 18 lat, ale jednocześnie ma otrzymać możliwie mało danych na temat tego użytkownika. Idealnie: tylko wiek.

Rysiek zaproponował rozwiązanie, które zaintrygowało mnie na tyle, że postanowiłem przeanalizować, czy to ma szansę działać. Wyszło mi, że nie. W tym wpisie skupiam się wyłącznie na proponowanym opisie algorytmu, czyli punktach i akapicie w którym jest zawarty.

Podsumowując założenia, ma tam być tak, że jest serwis X, użytkownik U, oraz serwis potwierdzania identyfikacji EID. X ma nie wiedzieć, kim jest U (dane osobowe). EID jak najbardziej zna dane osobowe użytkownika U, ma potwierdzić wiek, ale ma nie wiedzieć, że potwierdzenie jest na potrzeby serwisu X.

Problemy, które tu widzę, są dwa. Pierwszy jest taki, że użytkownik U w pełni kontroluje komunikację pomiędzy X a EID. Najpierw wysyła dane (które może dowolnie ustalić przed wysłaniem), potem otrzymuje odpowiedź, którą przekazuje. Czyli mamy do czynienia z man in the middle. Nie byłoby tu wielkiego problemu, gdyby EID wiedziało, że rozmawia z X – wystarczyłoby wtedy użyć odpowiednich kluczy prywatnych i publicznych. Ale jest to sprzeczne z założeniami.

Drugi problem jest poważniejszy. Serwis X nie wie, jakiego użytkownika weryfikuje. W tej sytuacji dowolny „dowód osobisty” może posłużyć do weryfikacji użytkownika.

Przekładając to na bardziej tradycyjne okoliczności: osoba w kominiarce przychodzi kupić alkohol i w ramach weryfikacji wieku pokazuje na ekranie telefonu zdjęcie dowodu osobistego. Czy sprzedawca jest w stanie zweryfikować wiek osoby na tej podstawie? Wg mnie – nie bardzo. Zdjęcie na ekranie to tutaj odpowiednik MITM (nie wiemy nawet, czy dowód jest autentyczny). Natomiast kominiarka (ukrycie tożsamości, anonimowość) uniemożliwia sprawdzenie, czy dowód należy do danej osoby.

Czyli dokładanie kolejnych warstw, algorytmów, systemów, stron w komunikacji nie zwiększa nam tu pewności anonimowej weryfikacji wieku. Nie w stosunku do wybrania przez użytkownika na stronie opcji „potwierdzam, że mam 18 lat”.

Być może po prostu mamy problem z akceptacją faktu, że weryfikacja wieku nigdy nie była anonimowa? Bo sprzedawca w sklepie z alkoholem nie tylko sprawdza[1], czy osoba posiada dowód osobisty. Sprawdza też, czy jest on autentyczny. I czy należy do tej osoby. OK, do tego ostatniego nie potrzebuje tu kompletu danych z dowodu, wystarczy zdjęcie. Ale do pozostałych danych ma dostęp w trakcie sprawdzania autentyczności.

Na Mastodonie trwa dyskusja, pewnie warto zapoznać się z całością, a komentować czy sugerować działające rozwiązania można równie dobrze tam.

[1] A przynajmniej powinien to robić.