W większości aplikacji klienckich dla platformy zdecentralizowanej komunikacji Matrix zidentyfikowano podatności (CVE-2021-40823, CVE-2021-40824), które umożliwiają uzyskanie informacji o kluczach używanych do przesyłania wiadomości w czatach z szyfrowaniem end-to-end (E2EE). Atakujący, kompromitując jednego z użytkowników czatu, może odszyfrować wiadomości, które wcześniej zostały wysłane do tego użytkownika z podatnych aplikacji klienckich.
Aby skutecznie wykorzystać te podatności, konieczny jest dostęp do konta odbiorcy wiadomości. Dostęp może być uzyskany zarówno przez ujawnienie parametrów konta, jak i przez hakowanie serwera Matrix, do którego podłączony jest użytkownik. Największe zagrożenie związane z podatnościami dotyczy użytkowników zaszyfrowanych pokojów czatowych, które są podłączone do serwerów Matrix kontrolowanych przez złośliwych aktorów. Administratorzy takich... serwerów mogą próbować podszywać się pod użytkowników serwera, aby przechwytywać wiadomości wysyłane w czacie z podatnych aplikacji klienckich.
Podatności są spowodowane błędami logicznymi w realizacji mechanizmu zapewnienia ponownego dostępu do kluczy, zaproponowanych w matrix-js-sdk < 12.4.1 (CVE-2021-40823), matrix-android-sdk2 < 1.2.2 (CVE-2021-40824), matrix-rust-sdk < 0.4.0, FamedlySDK < 0.5.0 oraz Nheko ≤ 0.8.2. Implementacje oparte na bibliotekach matrix-ios-sdk, matrix-nio i libolm nie są podatne na te ataki.
Odpowiednio, podatności manifestują się we wszystkich aplikacjach, które zaadaptowały problematyczny kod, i nie dotyczą bezpośrednio protokołów Matrix oraz Olm/Megolm. W szczególności problem dotyczy głównego klienta Matrix Element (dawniej Riot) dla Web, systemów desktopowych i Androida, a także zewnętrznych aplikacji klienckich i bibliotek, w tym FluffyChat, Nheko, Cinny i SchildiChat. Problem nie występuje w oficjalnym kliencie dla platformy iOS ani w aplikacjach Chatty, Hydrogen, mautrix, purple-matrix i Syphon.
Podatności zostały wykryte podczas audytu bezpieczeństwa klienta Element. Łatki zostały już wydane dla wszystkich problematycznych klientów. Użytkownikom zaleca się natychmiastowe zainstalowanie aktualizacji, a przed instalacją zaleca się przełączenie klientów w tryb offline. Dowody na wykorzystanie podatności przed publikacją poprawek są nieobecne. Na podstawie standardowych logów klienta i serwera Określenie faktu ataku jest niemożliwe, ale ponieważ atak wymaga kompromitacji konta, administratorzy mogą przeanalizować logi uwierzytelniania na swoich serwerach, aby sprawdzić obecność podejrzanych logowań, a użytkownicy mogą ocenić listę urządzeń powiązanych z ich kontem pod kątem niedawnych ponownych połączeń i zmiany statusu zaufania.
Mechanizm ponownego dostępu do kluczy (key sharing), w którym wykryto podatności, pozwala klientowi, który nie ma kluczy do odszyfrowania wiadomości, zażądać kluczy od urządzenia nadawcy lub innych własnych urządzeń. Na przykład taka możliwość jest niezbędna do zapewnienia odszyfrowania starych wiadomości na nowym urządzeniu użytkownika lub w przypadku utraty przez niego posiadanych kluczy. Specyfikacja protokołu nakazuje domyślnie nie odpowiadać na prośby o klucze i wysyłać je automatycznie tylko zweryfikowanym urządzeniom tego samego użytkownika. Niestety, w praktycznych realizacjach to wymaganie nie zostało spełnione, a prośby o wysłanie kluczy były przetwarzane bez odpowiedniej identyfikacji urządzenia.
Źródło: opennet.ru
