ta biała księga Bezpieczeństwa została wcześniej opublikowana na wickr.com/security Autor: Wickr CTO
wickr Security jest zbudowany na koncepcji niezaufanego serwera. Innymi słowy, naszym celem jest zapewnienie bezpieczeństwa nawet w przypadku” najgorszego przypadku ” naruszenia serwera, w którym wszechmocny atakujący ma pełną kontrolę nad zasobami serwera, co obejmuje możliwość odczytywania i modyfikowania kodu i danych aplikacji zaplecza oraz pozostawania przez pewien czas niezauważonym.
Eksperci zewnętrzni od samego początku nieustannie sprawdzają nasze kompleksowe szyfrowanie i bezpieczeństwo. W ramach niedawno opublikowanych obietnic bezpieczeństwa klientów wiodąca niezależna firma ds. bezpieczeństwa potwierdziła, że treść wiadomości nie jest czytelna na naszych komponentach serwerów zaplecza. W niniejszym dokumencie analizuje się szerzej kwestię bezpieczeństwa i kompromisów w zakresie serwerów. Podsumowano w nim kluczowe elementy architektury bezpieczeństwa Wickr, które zapewniają odporność na włamania do serwerów back-end i omówiono Zdarzenie pod kątem rzeczywistych możliwości atakującego lub rzeczywistego wpływu.
cele atakującego
aby zrozumieć , co atakujący może zrobić z naruszeniem serwera Wickr, musimy zrozumieć rolę serwera w architekturze Wickr i wziąć pod uwagę wartość danych zawartych w komponentach zaplecza i bazach danych. Serwer Wickr odgrywa kluczową rolę w dostarczaniu wiadomości, wspierając zarówno komunikację synchroniczną, jak i asynchroniczną. Zapewnia również scentralizowane usługi katalogowe użytkowników, zestawy uprawnień oraz synchronizację profilu i ustawień.
ataki próbujące wykorzystać Serwer Wickr można ogólnie podzielić na następujące kategorie:
- ataki mające na celu Bezpieczeństwo wiadomości lub dostęp do treści wiadomości tekstowych;
- ataki mające na celu informacje i metadane lub zbieranie i uzbrajanie poufnych informacji o systemie lub jego użytkownikach;
- ataki mające na celu dostępność lub zniszczenie danych.
omawiamy każdy rodzaj ataku w poniższych sekcjach.
Bezpieczeństwo wiadomości
narażając serwer, atakujący uzyskuje dostęp do zaszyfrowanych wiadomości, a także publicznych efemerycznych pul kluczy . Jednak wiadomości są szyfrowane od końca do końca, a zarówno zaszyfrowane wiadomości, jak i klucze w pulach kluczy są uwierzytelniane od końca do końca. Oznacza to, że atakujący nie mają możliwości odczytywania lub modyfikowania zaszyfrowanych wiadomości podczas przechodzenia przez serwer i nie mogą manipulować pulami kluczy, aby wykonać ataki man in the middle.
z tymi zabezpieczeniami, napastnicy mający nadzieję uzyskać dostęp do treści wiadomości muszą starać się przejąć kontrolę nad tożsamością Wickr. Tożsamości Wickr są zakorzenione w asymetrycznych parach kluczy, które są używane do cyfrowego podpisywania i weryfikacji danych. Zaufanie jest ustalane poprzez weryfikację łańcucha podpisów z danego obiektu lub komponentu kryptograficznego do tożsamości głównej lub użytkownika (np. wiadomość do aplikacji, aplikacja do użytkownika).
aby wygenerować autentyczny klucz (lub wiadomość), atakujący musiałby wykonać jedną z następujących czynności:
1. Uzyskaj prywatny Składnik klucza tożsamości użytkownika, który może być użyty do uwierzytelnienia aplikacji Wickr zalogowanych na konto.
2. Uzyskaj prywatny Składnik klucza tożsamości aplikacji, który może być używany do tworzenia autentycznych efemerycznych kluczy wiadomości i uwierzytelniania wiadomości wysyłanych z aplikacji.
3. Nakłonić użytkownika do zaakceptowania fałszywego klucza tożsamości dla użytkownika docelowego, co miałoby taki sam efekt jak uzyskanie istniejącego klucza tożsamości użytkownika.
prywatne komponenty kluczy tożsamości aplikacji są zabezpieczone w zaszyfrowanym magazynie danych po stronie klienta i poza zasięgiem atakującego po stronie serwera. Komponenty publiczne są przechowywane na serwerze, ale są podpisane (prywatnym) kluczem tożsamości użytkownika, chroniąc je przed manipulacją. Oszukiwanie użytkowników do przyjmowania fałszywych kluczy tożsamości jest bardziej atakiem socjotechnicznym niż atakiem technicznym i ma niewiele wspólnego z przyczółkiem po stronie serwera . W związku z tym zdolność atakującego po stronie serwera do naruszenia źródła autentyczności-i tak naprawdę jedyna techniczna droga ataku mająca wpływ na bezpieczeństwo wiadomości — sprowadza się do ich zdolności do naruszenia klucza tożsamości użytkownika.
z różnych powodów związanych głównie z użytecznością systemu, klucze tożsamości użytkownika są przechowywane na serwerze Wickr i zabezpieczone silnym szyfrowaniem symetrycznym. Ochrona tych danych jest ostatecznie kluczem 256-bitowym, który jest silną kryptograficzną pochodną hasła użytkownika. Ten klucz nigdy nie jest przechowywany ani wysyłany do serwera, więc atakujący próbujący naruszyć klucz tożsamości użytkownika musiałby wykonać atak zgadywania hasła przeciwko przechowywanej wersji za pomocą algorytmu generującego pochodne hasła, który został specjalnie zaprojektowany, aby proces był jak najbardziej zasobny i czasochłonny. W przypadku nietrywialnych haseł możemy oczekiwać, że proces ten zajmie wiele lat, a nawet wiele tysięcy lub milionów lat, jeśli użytkownik po prostu wybierze wysokiej jakości hasło o długości zaledwie 8 znaków. Aby skompromitować wiele kont, atakujący musiałby wielokrotnie poświęcać ten sam wysiłek. Ten poziom ochrony oznacza, że ataki po stronie serwera przeciwko kluczom tożsamości użytkownika są niewykonalne dla wszystkich kont poza najsłabszymi. Zobacz Białą Księgę Wickr na temat ochrony hasłem.
informacje i metadane
dzięki kontroli serwera Wickr atakujący ma dostęp do wszelkich informacji, jakie serwis posiada o swoich Użytkownikach. Projektując to Zagrożenie, Wickr ogranicza ilość przechowywanych przez nas informacji o użytkownikach do tych, które są minimalnie niezbędne do zapewnienia wysokiej jakości usług. Poniżej znajduje się lista informacji o koncie użytkownika dostępnych dla usług Wickr w momencie pisania tego tekstu:
Wickr Me:
- Data utworzenia konta
- Typ urządzenia(urządzeń), na którym takie konto było używane (np. iOS, Android)
- data ostatniego użycia
- całkowita liczba wysłanych/odebranych wiadomości
- liczba zewnętrznych identyfikatorów (numerów telefonów) połączonych z kontem (Nie numer telefonu) zwykłe identyfikatory zewnętrzne)
- ograniczone rekordy ostatnich zmian w ustawieniach konta (np. dodawanie lub usuwanie urządzenia; nie zawiera treści wiadomości ani informacji o routingu i dostawie)
- Numer wersji Wickr
Wickr Pro:
- Wickr Pro ID (adres e-mail)
- przynależność do sieci
- numer telefonu, jeśli został podany przez administratora sieci jako druga forma uwierzytelniania
- Data utworzenia konta
- Typ urządzenia(urządzeń), na którym zostało użyte konto
- data ostatniego użycia
- całkowita liczba wysłanych/odebranych wiadomości
- liczba zewnętrznych identyfikatorów (numerów telefonów) podłączonych do konta (nie
- ograniczone rekordy ostatnich zmian w ustawieniach konta (np. dodawanie lub usuwanie urządzenia; nie zawiera treści wiadomości ani informacji o routingu i dostawie)
- Numer wersji Wickr
- informacje dotyczące płatności
- Ustawienia sieciowe, w tym ograniczone zapisy ostatnich zmian ustawień sieciowych (np. włączenie lub wyłączenie Federacji)
Wickr Enterprise (wdrożenie kontrolowane przez Klienta):
- Wickr Enterprise ID (uchwyt)
- przynależność do sieci
- Data utworzenia konta
- Typ urządzenia(urządzeń), na którym zostało użyte konto
- data ostatniego użycia
- całkowita liczba wysłanych/odebranych wiadomości
- ograniczone rekordy ostatnich zmian w ustawieniach konta (np. dodawanie lub usuwanie urządzenia; nie zawiera treści wiadomości ani informacji o routingu i dostawie)
- numer wersji wickr
- Ustawienia sieciowe z ograniczonymi zapisami ostatnich zmian ustawień sieciowych (np., Włączanie lub wyłączanie Federacji)
powyższe byłoby zatem zagrożone ujawnieniem w przypadku naruszenia serwera. Nasze wytyczne dotyczące procesu prawnego i Polityka Prywatności zawierają bardziej szczegółowe dyskusje na temat tego, w jaki sposób ograniczamy zbieranie i wykorzystywanie informacji o użytkownikach na naszej platformie.
kontrola serwera zapewnia również atakującemu możliwość zbierania informacji i metadanych, które usługa ignoruje. Dwa najlepsze przykłady tego w Wickr to adresy IP klientów i śledzenie wiadomości.
Wickr jako usługa jest całkowicie niezainteresowana adresem IP klientów Wickr. Nie zapisujemy ich w logach standardowych aplikacji konfiguracyjnych ani nie zapisujemy ich w rekordach użytkowników. Są one jednak dostępne dla niektórych komponentów infrastruktury zaplecza, a zakładając, że atakujący kontroluje właściwy komponent i przeprowadza właściwą analizę ruchu i korelacji, informacje te byłyby zagrożone.
Wickr nie jest również zainteresowany tym, kto komu komunikuje się w sieci. Nie zapisujemy tych informacji w dziennikach standardowych aplikacji konfiguracyjnych. Jednak zakładając, że atakujący zainwestuje w proces wystarczającą ilość czasu i wysiłku, liczba, czasy, rodzaje wiadomości wysyłanych i odbieranych oraz identyfikatory Wickr źródła i odbiorcy byłyby zagrożone. Zwykłe identyfikatory Wickr nie są dostępne w magazynach danych Wickr Me, więc tego typu analiza byłaby znacznie trudniejsza (choć nie niemożliwa) do wykonania w Wickr Me.
dostępność
chociaż może nie jest to najciekawsza forma ataku, jaką można sobie wyobrazić przeciwko bezpiecznej usłudze przesyłania wiadomości, ataki ukierunkowane na dostępność usług mają bardzo realne szanse i dość oczywiste skutki. Nie ma wiele do omówienia na ten temat w tym dokumencie, poza uznaniem ryzyka, ale atakujący posiadający kontrolę nad serwerami Wickr miałby moc wyłączania usług i usuwania danych, niezależnie od tego, czy po prostu powoduje chaos, czy odmawia usług legalnym użytkownikom.
podsumowanie
mamy nadzieję, że ten artykuł był pouczający dla klientów, którzy chcą zrozumieć rzeczywisty wpływ naruszenia serwera Wickr. Podsumowując, takie zdarzenie, jeśli zostanie wykorzystane przez zdolnego przeciwnika, potencjalnie naraziłoby na niebezpieczeństwo:
1. Bezpieczeństwo przyszłych wiadomości kont ze słabymi hasłami.
2. Poufność ograniczonych informacji o koncie i metadanych.
3. Dostępność usług.
Wybierz hasła jakościowe.
jeśli używane są hasła wysokiej jakości, kompromis serwera Wickr (znany lub nieznany) może być uznany za zdarzenie o niskim lub zerowym wpływie.
zastanów się nad okresowymi rekeingami.
okresowe tworzenie nowej pary kluczy i ponowna weryfikacja z innymi (np. co roku, co pół roku) może jeszcze bardziej zmniejszyć ryzyko pomyślnego ataku na zgadywanie haseł, aby zagrozić kluczowi tożsamości użytkownika. Jest to również skuteczna metoda rehabilitacji konta użytkownika, które Twoim zdaniem zostało już naruszone poprzez zgadywanie haseł lub kompromis po stronie klienta. Użytkownicy mogą zmienić swoje konto, wypełniając przepływ „Zapomniałem hasła” w Wickr Pro i Wickr Enterprise lub tworząc nowy identyfikator w Wickr Me.