Podatności Checkmate

Checkmate do wersji 3.11.0 pomija oprogramowanie pośrednie ochrony roli isAllowed na trasach dotyczących okien konserwacyjnych, powiadomień i usuwania kontroli, co pozwala użytkownikom tylko do odczytu na wykonywanie działań administracyjnych. Atakujący z sesją roli użytkownika mogą tworzyć dowolne okna konserwacyjne w celu wyciszenia alertów, modyfikować kanały powiadomień i usuwać historię kontroli monitorów, aby zatrzeć dowody incydentów.

Problem w komponencie inviteController.js w Bluewave Labs Checkmate w wersji 3.3.0 i wcześniejszych. Zdalny uwierzytelniony administrator może eskalować uprawnienia do superadmina poprzez parametr role w punkcie końcowym /api/v1/invite.

Checkmate od wersji 3.3.0 do 3.9.2, przy włączonym globalnym ustawieniu showURL, powoduje, że nieuwierzytelniony endpoint GET /api/v1/status-page/:url zwraca kompletne obiekty monitorów, w tym pole secret używane jako poświadczenie HTTP Authorization, mimo że nie jest ono wyświetlane w interfejsie.

W wersjach od 3.5.1 do 3.9.2 narzędzia Checkmate, uwierzytelniony administrator lub superadministrator może ustawić matchMethod na regex i umieścić złośliwe wyrażenie w polu expectedValue dla zaawansowanego dopasowywania monitora HTTP. Wyrażenie to jest oceniane synchronicznie na głównej pętli zdarzeń Node.js bez limitu czasu lub izolacji wątku, co pozwala na katastrofalne cofanie się (backtracking) i zamrożenie punktów API, kontroli monitorów oraz połączeń WebSocket dla wszystkich użytkowników. Problem został naprawiony w wersji 3.9.2.

Checkmate przed wersją 3.9.1 zawiera podatność na wyczerpanie pamięci w publicznym punkcie końcowym rejestracji. Niezautentykowany atakujący może wysłać wiele jednoczesnych, zbyt dużych plików, które są buforowane przed walidacją, co prowadzi do przeciążenia pamięci i awarii backendu.

Podatność na enumerację użytkowników w bluewave-labs/Checkmate do wersji 2.1.0 umożliwia nieuwierzytelnionemu zdalnemu atakującemu określenie, czy dany adres e-mail jest zarejestrowany. Endpoint POST /api/v1/auth/recovery/request zwraca HTTP 200 dla zarejestrowanych adresów e-mail i inny kod statusu dla niezarejestrowanych, co umożliwia atakującym enumerację prawidłowych kont użytkowników.