Podatności Rocket.Chat

Rocket.Chat to platforma komunikacyjna typu open source, bezpieczna i w pełni konfigurowalna. W wersjach Rocket.Chat do 6.12.0, punkt końcowy API GET /api/v1/oauth-apps.get jest dostępny dla każdego uwierzytelnionego użytkownika, niezależnie od jego roli lub uprawnień. Ten punkt końcowy zwraca aplikację OAuth, o ile użytkownik zna jej ID, w tym potencjalnie wrażliwe pola, takie jak client_id i client_secret. Luka została naprawiona w wersji 6.12.0.

W Rocket.Chat przed wersjami 8.7.0, 8.6.1, 8.5.2, 8.4.5, 8.3.7, 8.2.7, 8.1.7, 8.0.8 i 7.10.14, SAML SSO weryfikował podpisy XML, ale nie wiązał zweryfikowanego podpisu z samlp:Response / saml:Assertion. Atakujący mógł przesłać zawinięty dokument z fałszywymi atrybutami tożsamości wraz z dowolnym prawidłowym podpisem z zaufanego certyfikatu IdP i zalogować się jako dowolny użytkownik.

W Rocket.Chat przed wersjami 8.5.1, 8.4.4, 8.3.6, 8.2.6, 8.1.6, 8.0.7 i 7.10.13, w pliku loginHandler.ts, funkcja handleIdentityToken parsuje JWT od Apple podczas OAuth. Jeśli JWT nie zawiera adresu email, aplikacja akceptuje dowolną wartość email podaną w żądaniu, co pozwala atakującemu na przejęcie konta.

Wersje Rocket.Chat poniżej 8.5.1, 8.4.4, 8.3.6, 8.2.6, 8.1.6, 8.0.7, 7.13.9, 7.10.13 mają podatność w zakresie kontroli dostępu do plików Livechat. Proces autoryzacji pobierania chronionych plików nie weryfikuje, czy rc_rid odpowiada żądanemu plikowi, co umożliwia nieautoryzowane odkrywanie wszystkich przesłanych plików.

W Rocket.Chat w wersjach poniżej 8.3.0, 8.2.1, 8.1.2, 8.0.3, 7.13.5, 7.12.6, 7.11.6 i 7.10.9 występuje podatność na wstrzyknięcie NoSQL, która może prowadzić do przejęcia konta pierwszego użytkownika z wygenerowanym tokenem, gdy aplikacja OAuth jest skonfigurowana.

Rocket.Chat udostępnia metodę Meteor sendForgotPasswordEmail bez limitu szybkości DDP, co pozwala nieuwierzytelnionemu atakującemu na wielokrotne wywoływanie jej. Metoda jest dostępna przez DDP oraz przez HTTP POST /api/v1/method.callAnon/sendForgotPasswordEmail i wyzwala wysyłkę wiadomości resetujących hasło dla dowolnego adresu powiązanego z kontem. Brak reguły DDPRateLimiter umożliwia masowe wysyłanie e-maili oraz sondowanie adresów.

W Rocket.Chat przed wersjami 8.8.0, 8.7.1, 8.6.2, 8.5.3, 8.4.6, 8.3.8, 8.2.8, 8.1.8 i 7.10.15 metody DDP getThreadsList i getThreadMessages nie walidują typów parametrów rid i tmid. Można podstawić obiekt MongoDB (np. {"$gt": "4"}) zamiast identyfikatora pokoju lub wiadomości, co prowadzi do ujawnienia prywatnych wątków i ich odpowiedzi każdemu uwierzytelnionemu użytkownikowi o niskich uprawnieniach.

W Rocket.Chat przed wersjami 8.8.0, 8.7.1, 8.6.2, 8.5.3, 8.4.6, 8.3.8, 8.2.8, 8.1.8 i 7.10.15 endpoint REST POST /api/v1/livechat/visitor przyjmuje nieuwierzytelnione i niezdezynfekowane pole name dla odwiedzających Livechat. Ta nazwa jest przechowywana i renderowana przez dangerouslySetInnerHTML w panelu Omnichannel Queue, co umożliwia wstrzyknięcie klikalnego linku HTML do DOM agenta.

W Rocket.Chat przed wersjami 7.10.14, 8.0.8, 8.1.7, 8.2.7, 8.3.7, 8.4.5, 8.5.2 i 8.6.1, endpoint REST channels.convertToTeam umożliwia uwierzytelnionemu użytkownikowi z uprawnieniem create-team konwersję niepowiązanego kanału publicznego poprzez podanie channelName zamiast channelId, ponieważ uprawnienie edit-room jest sprawdzane tylko dla channelId.

W Rocket.Chat przed wersjami 7.10.14, 8.0.8, 8.1.7, 8.2.7, 8.3.7, 8.4.5, 8.5.2 i 8.6.1, strumień stream-notify-user w protokole WebSocket umożliwia uwierzytelnionemu użytkownikowi zapis dowolnych treści powiadomień, ponieważ nadawca nie jest sprawdzany, a interfejs klienta może utworzyć efemeryczną fałszywą wiadomość w otwartym czacie innego użytkownika.

W Rocket.Chat przed wersjami 8.5.1, 8.4.4, 8.3.6, 8.2.6, 8.1.6, 8.0.7 i 7.10.13, punkt końcowy POST /api/v1/fingerprint wymagał uwierzytelnienia, ale nie przeprowadzał kontroli autoryzacji. Każdy uwierzytelniony użytkownik mógł usunąć workspace z Rocket.Chat Cloud, co prowadziło do utraty wszystkich danych i wymagało ręcznej rejestracji.

Podatność w Rocket.Chat umożliwia dezaktywowanym użytkownikom (przez funkcję users.deactivateIdle) dalsze korzystanie z już wydanych tokenów logowania. Oznacza to, że użytkownik oznaczony przez administratora jako nieaktywny z powodu bezczynności może nadal uzyskiwać dostęp do uwierzytelnionych punktów końcowych REST przy użyciu starego tokena.

Rocket.Chat przed wersją 8.5.0 nie weryfikuje podpisu w wiadomościach LogoutRequest w integracji SAML. Nieautoryzowany atakujący może stworzyć fałszywe żądanie wylogowania, co prowadzi do natychmiastowego zakończenia sesji ofiary.

Rocket.Chat w wersjach <8.5.1, <8.4.4, <8.3.6, <8.2.6, <8.1.6, <8.0.7, <7.13.9 i <7.10.13 jest podatny na nieautoryzowane usuwanie plików. Metoda deleteFileMessage pozwala na trwałe usunięcie dowolnego przesłanego pliku po ID bez wymogu uwierzytelnienia.

Endpoint /api/v1/autotranslate.translateMessage w Rocket.Chat (wersje przed 8.5.0, 8.4.2, 8.3.4, 8.2.4, 8.1.5, 8.0.6, 7.13.8, 7.10.12) umożliwia każdemu uwierzytelnionemu użytkownikowi pobranie pełnej treści dowolnej wiadomości z dowolnego pokoju bez sprawdzania dostępu.

W Rocket.Chat występuje błąd nieprawidłowej autoryzacji w usłudze webowej (domyślnie port TCP 3000), który pozwala nieuwierzytelnionemu atakującemu zdalnemu ujawnić informacje w kontekście aplikacji.

W Rocket.Chat < 6.0 występuje podatność nieprawidłowej autoryzacji, która może pozwolić hakerowi na manipulowanie parametrem rid i zmianę metody updateMessage, która sprawdza jedynie, czy użytkownik ma prawo edytować wiadomość w docelowym pokoju.

W serwerze Rocket.Chat <5.2.0 występuje podatność prototype pollution, która może pozwolić atakującemu na zdalne wykonanie kodu (RCE) w kontekście konta administratora. Każdy użytkownik może utworzyć własny serwer w chmurze i zostać administratorem, co może wpłynąć na infrastrukturę chmurową. Wektor ataku może również zwiększyć wpływ XSS do RCE, co jest niebezpieczne również dla użytkowników self-hosted.