Niezauwierzytelniony atakujący sieciowy może uzyskać ważny token dostępu OAuth dowolnego użytkownika Rocket.Chat poprzez wysłanie pojedynczego żądania HTTP POST z operatorami zapytań MongoDB. W przypadku uzyskania tokenu administratora możliwe jest zdalne wykonanie kodu po stronie serwera.
▸ Pokaż oryginał (EN)
Rocket.Chat is an open-source, secure, fully customizable communications platform. Prior to 8.5.0, 8.4.1, 8.3.3, 8.2.3, 8.1.4, 8.0.5, 7.13.7, and 7.10.11, an unauthenticated network attacker obtains a valid Rocket.Chat OAuth access token for an arbitrary user by sending a single HTTP POST with MongoDB query operators to /oauth/token. The Rocket.Chat OAuth2 server does not validate that grant parameters are strings before forwarding them to findOne({...}) against the oauth_apps and oauth_access_tokens collections, so an attacker substitutes {"$ne": null} for client_id, client_secret, and refresh_token and receives a freshly minted {access_token, refresh_token} pair bound to whichever user's refresh token Mongo returned first. The resulting access token is a first-class bearer credential against the full /api/v1/* surface as that user. By iterating with $nin / $regex operators the attacker walks the entire oauth_access_tokens collection, collecting one fresh access token per user per request. If any matched token belongs to an admin, the stolen bearer gives full admin API access (including Apps-Engine app installation, i.e. server-side code execution). No account, credentials, userId, or prior interaction with the instance are required. This vulnerability is fixed in 8.5.0, 8.4.1, 8.3.3, 8.2.3, 8.1.4, 8.0.5, 7.13.7, and 7.10.11.
Serwer OAuth2 w Rocket.Chat nie waliduje, czy parametry żądania (client_id, client_secret, refresh_token) są ciągami znaków przed przekazaniem ich do funkcji findOne({...}) na kolekcjach oauth_apps i oauth_access_tokens. Atakujący podstawia operatory MongoDB, takie jak {"$ne": null}, w miejsce tych parametrów, co skutkuje zwróceniem pierwszego pasującego tokenu z bazy danych i wygenerowaniem nowej pary {access_token, refresh_token} powiązanej z kontem danego użytkownika. Przez iterowanie z operatorami $nin i $regex atakujący może przejść całą kolekcję oauth_access_tokens i zebrać świeże tokeny dostępu dla wszystkich użytkowników. Uzyskany token jest pełnoprawnym credential Bearer-type wobec całej powierzchni API /api/v1/* i nie wymaga żadnych wcześniejszych danych uwierzytelniających ani interakcji z instancją.
Atakujący może przejąć konta dowolnych użytkowników, a w przypadku uzyskania tokenu administratora — uzyskać pełny dostęp do API administracyjnego, w tym zainstalować aplikacje przez Apps-Engine, co prowadzi do zdalnego wykonania kodu po stronie serwera (RCE).
Należy zaktualizować Rocket.Chat do wersji 8.5.0, 8.4.1, 8.3.3, 8.2.3, 8.1.4, 8.0.5, 7.13.7 lub 7.10.11 (w zależności od używanej gałęzi). Szczegóły dostępne w oficjalnym security advisory producenta pod adresem https://github.com/RocketChat/Rocket.Chat/security/advisories/GHSA-8p25-fm45-pjrw
Rocket.Chat w wersjach wcześniejszych niż 8.5.0, 8.4.1, 8.3.3, 8.2.3, 8.1.4, 8.0.5, 7.13.7 oraz 7.10.11
Podatność nie wymaga żadnych danych uwierzytelniających, konta ani wcześniejszej interakcji z instancją — wektor ataku jest w pełni zdalny i nieuwierzytelniony. Klasyfikacja CWE-943 dotyczy niewłaściwej neutralizacji specjalnych elementów w zapytaniach do baz danych NoSQL (NoSQL Injection).
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N