Podatności Kimai

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.