CVE-2019-25317

Kimai przed wersją 2.65.0 zawiera podatność obejścia autoryzacji w punkcie końcowym REST API do pobierania timesheetów, która nie egzekwuje kontroli dostępu do zespołów aktywności. Użytkownicy z uprawnieniem view_other_timesheet mogą wyświetlać timesheety używające aktywności ograniczonych do zespołów, do których nie należą, omijając zamierzoną izolację danych.

Kimai do wersji 2.65.0 zawiera podatność logiki biznesowej / nieprawidłowej autoryzacji w domyślnych punktach końcowych tworzenia zespołów. Uwierzytelniony użytkownik z uprawnieniami do zarządzania uprawnieniami projektu może utworzyć lub użyć klienta, projektu lub aktywności, których nazwa pasuje do istniejącego zespołu; ponieważ punkty końcowe POST /api/customers/{id}/team, POST /api/projects/{id}/team i POST /api/activities/{id}/team ponownie używają istniejącego zespołu o tej samej nazwie i dodają bieżącego użytkownika jako lidera zespołu bez weryfikacji, czy użytkownik jest uprawniony do zarządzania tym zespołem, atakujący uzyskuje nieautoryzowane prawa lidera (administracji) nad istniejącym zespołem. Poprawiono w wersji 2.65.0.

Kimai przed wersją 2.63.0 zawiera podatność nieprawidłowej autoryzacji w punktach końcowych dostępu do zespołów, która pozwala uwierzytelnionym użytkownikom z uprawnieniami do edycji zespołów i dostępem tylko do odczytu na przyznanie dostępu zespołom do klientów, projektów lub aktywności. Atakujący mogą wykorzystać niewystarczające sprawdzanie uprawnień, wysyłając żądania POST do punktów końcowych dostępu do zespołów, aby modyfikować listy kontroli dostępu dla encji, których nie powinni móc modyfikować.

Kimai w wersjach od 2.61.0 do przed 2.63.0 nie wyłącza preferencji umowy o pracę dostępnych tylko dla administratorów dla użytkowników z niskimi uprawnieniami w punkcie końcowym PATCH /api/users/{id}/preferences. Chociaż interfejs webowy blokuje te pola umowy o pracę za uprawnieniem admina contract_other_profile, subskrybent WorkContractPreferenceSubscriber (wprowadzony w 2.61.0) rejestruje preferencje jako włączone bez sprawdzania uprawnień, więc uwierzytelniony zwykły użytkownik może użyć API do modyfikacji własnych danych umowy o pracę dostępnych tylko dla administratorów. Problem naprawiono w wersji 2.63.0 poprzez zastosowanie tego samego sprawdzenia uprawnień do punktu końcowego API.

W Kimai przed wersją 2.58.0 oficjalny obraz Docker ustawia APP_SECRET na publiczną wartość change_this_to_something_unique w Dockerfile, a .docker/entrypoint.sh nie zastępuje ani nie odrzuca tej wartości, zanim Symfony użyje jej jako kernel.secret. Nieuwierzytelniony atakujący, który dotrze do wdrożenia bez nadpisania APP_SECRET, zna nazwę użytkownika, poprawnie odgadnie identyfikator konta powiązany z tą nazwą i wybierze konto bez aktywnego uwierzytelniania dwuskładnikowego, może sfałszować artefakty uwierzytelniania chronione HMAC, w tym ciasteczka KIMAI_REMEMBER i linki logowania, aby uzyskać dostęp do konta bez hasła. Zaktualizowany entrypoint generuje i utrwala losowy sekret, gdy nie istnieje bezpieczna wartość dostarczona przez operatora.

Kimai to aplikacja open source do śledzenia czasu pracy. W wersjach przed 2.58.0 metody ExportController::createExportTemplate() i ExportController::editExportTemplate() dziedziczą jedynie uprawnienie create_export na poziomie klasy, które ROLE_TEAMLEAD otrzymuje domyślnie, i pomijają uprawnienie create_export_template wymagane przez trasy API i interfejs użytkownika. Lider zespołu może bezpośrednio uzyskać dostęp do webowych tras tworzenia i edycji szablonów eksportu, aby tworzyć lub modyfikować globalne rekordy ExportTemplate oznaczone jako dostępne dla wszystkich użytkowników, zmieniając kolumny eksportu, renderer, format i dane wyjściowe używane przez innych użytkowników i administratorów.

W aplikacji Kimai ciasteczko KIMAI_SESSION wydawane po weryfikacji hasła, ale przed ukończeniem TOTP, jest akceptowane przez każdą trasę /api, ponieważ konfiguracja security.yaml chroni API regułą IS_AUTHENTICATED, a ApiRequestMatcher kieruje istniejącą sesję przez główny firewall. Token Scheb TwoFactorToken spełnia tę regułę dostępu, a ApiVoter przyznaje dostęp API jego użytkownikowi, co pozwala atakującemu z prawidłowym hasłem konta korzystać z uwierzytelnionych operacji REST API bez podania drugiego czynnika. Problem naprawiono w wersji 2.59.0.

Kimai to aplikacja open source do śledzenia czasu pracy. W wersjach przed 2.57.0 żądania GET lub POST do /en/admin/project/{id}/rate/{rate}, /en/admin/customer/{id}/rate/{rate} oraz /en/admin/activity/{id}/rate/{rate} niezależnie rozwiązują autoryzowany identyfikator obiektu nadrzędnego i wybrany przez atakującego identyfikator stawki podrzędnej, nie potwierdzając, że ProjectRate, CustomerRate lub ActivityRate należy do tego obiektu nadrzędnego. Uwierzytelniony użytkownik mogący edytować jeden obiekt nadrzędny może połączyć go z rekordem stawki z nieautoryzowanego projektu, klienta lub czynności i utrwalić zmiany w konfiguracji rozliczeń w tabelach kimai2_projects_rates, kimai2_customers_rates lub kimai2_activities_rates.

Kimai to aplikacja open source do śledzenia czasu pracy. W wersjach przed 2.58.0 żądania POST /api/teams/{id}/members/{userId} i POST /api/teams/{id}/activities/{activityId} weryfikują, że lider zespołu może edytować zespół, ale nie weryfikują access_user dla wskazanego użytkownika ani dostępu view dla wskazanej czynności. Lider zespołu może dodać użytkowników lub czynności spoza swojego zakresu zarządzania do edytowalnego zespołu, omijając węższe wybory wymuszane przez TeamEditForm i UserRepository::getQueryBuilderForFormType(). Powstałe relacje mogą być zaufane przez RolePermissionManager::checkTeamAccessActivity() i inną logikę autoryzacji, widoczności, raportowania i przepływu pracy opartą na zespołach.

Kimai to aplikacja open source do śledzenia czasu pracy. W wersjach przed 2.58.0 TimesheetController udostępnia trasy GET /api/timesheets/{id}/stop i GET /api/timesheets/{id}/restart, które wykorzystują uwierzytelnioną sesję przeglądarki i wykonują operacje zmieniające stan przez żądania GET bez zabezpieczenia przed fałszowaniem żądań. Zdalny atakujący może spowodować, że zalogowany użytkownik wywoła jedną z tych tras z treści kontrolowanej przez atakującego, zatrzymując działający wpis czasu pracy lub wznawiając historyczny wpis w celu utworzenia i uruchomienia nowego wpisu bez zgody użytkownika. Nieautoryzowane zmiany mogą uszkodzić rekordy czasu, rozliczenia, raporty, zatwierdzenia i audyty.