Podatności Kimai

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.

Kimai to aplikacja open source do śledzenia czasu pracy. W wersjach przed 2.58.0 PATCH /api/timesheets/{id}/restart, PATCH /api/timesheets/{id}/duplicate oraz webowy przepływ duplikowania mogą utworzyć nowy rekord na podstawie posiadanego historycznego wpisu czasu pracy po odebraniu użytkownikowi dostępu do jego projektu lub czynności. TimesheetVoter ocenia uprawnienie own-timesheet przed bieżącym dostępem zespołowym, a jego logika canStart() waliduje widoczność obiektu, ale nie weryfikuje bieżącego dostępu zespołowego użytkownika do wskazanego projektu i czynności. Stary wpis działa więc jako trwała zdolność do tworzenia nowych rekordów czasu w nieautoryzowanym projekcie i czynności, uszkadzając budżety, statystyki, raporty i faktury po administracyjnym odebraniu uprawnień.

Przed wersją 2.57.0 aplikacji Kimai, żądania GET lub POST do /en/admin/activity/create/{project} i /en/admin/project/create/{customer} wymagały tylko ogólnych uprawnień create_activity lub create_project, bez weryfikacji dostępu do edycji obiektu Project lub Customer. Użytkownik znający identyfikator projektu lub klienta mógł utworzyć nowy obiekt biznesowy pod nieautoryzowanym rodzicem, zanieczyszczając konfigurację projektu lub klienta i wpływając na późniejsze wpisy czasu, stawki, raporty i rozliczenia.

Przed wersją 2.57.0 aplikacji Kimai, endpointy PATCH /api/timesheets/{id} i POST /api/timesheets akceptowały identyfikator projektu kontrolowany przez użytkownika, który omijał kryteria dostępu do zespołu. Każdy uwierzytelniony użytkownik z uprawnieniem edit_own_timesheet mógł przypisać własny wpis czasu do projektu spoza swoich zespołów, utrwalić nieautoryzowane przypisanie projektu i pobrać metadane projektu i klienta przez GET /api/timesheets/{id}?full=true.

Przed wersją 2.57.0 aplikacji Kimai, endpoint GET /api/timesheets akceptował identyfikatory użytkowników od osoby z uprawnieniem view_other_timesheet, ale nie sprawdzał, czy osoba z rolą ROLE_TEAMLEAD prowadzi zespół zawierający każdego docelowego użytkownika. Umożliwiało to liderowi zespołu pobranie opisów, danych czasowych, tagów, stawek i wewnętrznych stawek innego użytkownika, nawet jeśli GET /api/timesheets/{id} odmówiłby dostępu.

Kimai w wersjach przed 2.58.0 zawiera uwierzytelnione problemy z cross-site request forgery w domyślnych skrótach tworzenia zespołów dla projektów, klientów i działań. Punkty końcowe są dostępne przez trasy GET i bezpośrednio tworzą lub ponownie wykorzystują zespół, dodają bieżącego użytkownika jako lidera zespołu i wiążą obiekt docelowy z tym zespołem.

Kimai w wersjach przed 2.58.0 zawiera podatność typu server-side request forgery (SSRF) w procesie podglądu i generowania faktur PDF. Jeśli atakujący kontroluje treść Markdown renderowaną do faktury PDF, np. Customer.invoiceText, serwerowy renderer PDF pobiera zdalne adresy URL obrazów osadzonych w składni Markdown, co pozwala na wysyłanie żądań do celów kontrolowanych przez atakującego lub wewnętrznych.

Kimai przed wersją 2.65.0 nieprawidłowo weryfikuje uprawnienia podczas usuwania dostępu zespołu do działań, projektów i klientów przez API. Uwierzytelnieni użytkownicy z uprawnieniem edit_team mogą cofnąć dostęp zespołu bez wymaganego sprawdzenia permissions_activity, omijając kontrolę autoryzacji.

Kimai przed wersją 2.56.0 nie egzekwuje sprawdzania przynależności do zespołu w TimesheetVoter::voteOnAttribute(), co pozwala każdemu uwierzytelnionemu użytkownikowi z rolą ROLE_TEAMLEAD (lub posiadającemu uprawnienia edit_other_timesheet/delete_other_timesheet) na odczyt, modyfikację i trwałe usuwanie timesheetów dowolnego użytkownika w systemie przez API, niezależnie od przynależności do zespołu.

Kimai przed wersją 2.53.0 nie blokuje wrażliwych metod User w sandboxie szablonów Twig, co pozwala administratorom wywoływać metody getApiToken() i getPlainApiToken(). Atakujący z uprawnieniami do tworzenia szablonów mogą osadzić te wywołania w szablonach faktur, aby wyciekać zahaszowane tokeny API w wygenerowanym wyniku faktury.

Kimai przed wersją 2.53.0 zawiera podatność na otwarte przekierowanie w obsłudze sukcesu uwierzytelniania SAML, która akceptuje niezweryfikowane parametry POST RelayState jako cele przekierowania. Atakujący z dostępem do IdP mogą dostarczyć złośliwe wartości RelayState, aby przekierować uwierzytelnionych użytkowników na adresy URL kontrolowane przez atakującego w celu kradzieży poświadczeń lub ataków phishingowych.

Kimai przed wersją 2.54.0 zawiera podatność timing oracle w TokenAuthenticator, która umożliwia nieuwierzytelnionym atakującym enumerację prawidłowych nazw użytkowników poprzez nagłówek X-AUTH-USER. Różnice w czasie odpowiedzi ujawniają istnienie kont.

Kimai przed wersją 2.56.0 nie ogranicza funkcji Twig config() w szablonach faktur i eksportu w trybie piaskownicy, co pozwala administratorom na dostęp do dowolnych kluczy konfiguracyjnych. Atakujący z uprawnieniami administratora mogą przesłać złośliwe szablony, aby wyeksfiltrować sekrety serwera, takie jak hasła LDAP i klucze prywatne SAML, do dokumentów dostępnych dla użytkowników z niższymi uprawnieniami.

Kimai przed wersją 2.57.0 zawiera podatność nieprawidłowej autoryzacji w punktach końcowych dodawania i usuwania ulubionych kart czasu, która pozwala uwierzytelnionym użytkownikom manipulować zakładkami innych użytkowników. Atakujący mogą dodawać lub usuwać wpisy kart czasu z listy ulubionych innego użytkownika, odwołując się do ich identyfikatora karty czasu, co umożliwia naruszenie stanu biznesowego między użytkownikami bez uprawnień administracyjnych.

Kimai przed wersją 2.58.0 zawiera podatność na obejście uwierzytelniania, gdzie linki do resetowania hasła pozostają ważne po zmianie hasła, ponieważ podpis LoginLink obejmuje tylko identyfikator użytkownika, a nie hash hasła. Atakujący, którzy przechwycą lub zbuforują link do resetowania hasła, mogą go użyć do 2 dodatkowych razy w ciągu 1 godziny, aby zalogować się jako użytkownik nawet po zmianie hasła przez uprawnionego użytkownika.

Podatność w Kimai przed wersją 2.63.0 w punkcie końcowym API aktualizacji zespołu (PATCH /api/teams/{id}) powoduje usunięcie wszystkich istniejących członków zespołu przed walidacją przesłanej listy zastępczej. Uwierzytelniony lider zespołu (lub inny użytkownik z uprawnieniami do edycji zespołu) może przesłać nieprawidłowy ładunek członków; mimo że Kimai zwraca błąd walidacji, istniejące rekordy członkostwa zostały już usunięte. Obejmuje to ochronę dedykowanego punktu końcowego usuwania członków przed usuwaniem liderów zespołów i może pozostawić zespół bez członków lub liderów, zakłócając kontrolę dostępu opartą na zespołach.

Podatność w Kimai przed wersją 2.64.0 w trasie eksportu ProjectViewController (report_project_view_export) wynika z braku autoryzacji. Kontrole autoryzacji są przypisane do metody __invoke, a nie na poziomie klasy, więc trasa eksportu nie dziedziczy żadnych kontroli autoryzacji. Każdy uwierzytelniony użytkownik, w tym zwykły ROLE_USER bez uprawnienia project_reporting, może pobrać eksport przeglądu projektu, który zwraca ten sam zestaw danych co chroniony raport, ujawniając nazwy klientów, nazwy projektów, walutę, typ budżetu i sumy zbiorcze dla wszystkich klientów. Rzeczywiste dane finansowe pozostają chronione w szablonie eksportu.

Kimai przed wersją 2.62.0 nie sprawdza uprawnienia create_other_timesheet w kontrolerze QuickEntry podczas tworzenia nowych wpisów czasu. Uwierzytelnieni użytkownicy z uprawnieniami view_other_timesheet i edit_other_timesheet mogą tworzyć wpisy czasu dla członków zespołu, omijając kontrolę autoryzacji.