Katalog podatności CVE

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.

Nieprawidłowe obsługiwanie niewystarczających uprawnień w Secomea GateManager umożliwia eskalację uprawnień. Problem dotyczy wersji 11.5;0 i 11.4.625515072:0. Poprawka jest dostępna w wersji 11.6 lub 11.4.626194074 i nowszych.

W module serwera WWW Secomea GateManager występuje podatność typu Session Fixation, która pozwala na przejęcie sesji użytkownika. Problem dotyczy wersji 11.5;0 oraz 11.4.625515072:0. Został naprawiony w wersji 11.6 lub 11.4.626194074 i nowszych.

Wersje MISP do 2.5.45 mogą rejestrować nieprawidłowe dane dziennika dostępu dla żądań kończących się wyjątkiem. Ze względu na to, że CakeErrorController rozszerza AppController, renderowanie wyjątku uruchamia ścieżkę startową aplikacji po raz drugi, co powoduje podwójne wywołanie AccessLog::logRequest() dla jednego żądania HTTP. Drugi zapis może nadpisać wiersz utworzony przez pierwszy, uszkadzając czas trwania żądania, liczbę zapytań SQL, użycie pamięci i potencjalnie dziennik zapytań.

Wersje MISP do 2.5.45 udostępniają kilka akcji kontrolerów zmieniających stan bez ograniczenia do metody POST. Dotyczy to akcji purgeUnusedPictures(), enableNoticelist(), removeOrphanedCorrelations() i rebuildRedis(). Atakujący może wywołać te akcje przez zwykłe żądania GET, wykorzystując sesję uwierzytelnionego użytkownika, co może prowadzić do nieautoryzowanych zmian.

W OpenAM w wersjach przed 16.1.2 endpoint pre-autoryzacji /authservice PLL przyjmuje element XML CustomCallback, którego wartość className pozwala na załadowanie i utworzenie dowolnej klasy Java bez weryfikacji, czy implementuje DSAMECallbackInterface. Domyślna konfiguracja udostępnia ten endpoint bez uwierzytelnienia, co umożliwia atakującemu wykonanie kodu w procesie serwera poprzez niebezpieczną deserializację. Włączenie opcji sunRemoteAuthSecurityEnabled nie zapobiega temu, ponieważ sprawdzenie następuje zbyt późno.

OpenAM od wersji 13.0.0 do 16.1.2 ma podatność na odbity XSS w endpointzie OAuth2 authorize z parametrem display=wap. Strona zgody odzwierciedla wartości pochodzące z żądania bez kodowania HTML, co pozwala atakującemu na wykonanie JavaScriptu w kontekście OpenAM, kradzież sesji lub ciasteczek, ujawnienie tokenów CSRF i działania z uprawnieniami ofiary. Wymagany jest co najmniej jeden zarejestrowany klient OAuth2, ale atakujący nie musi go kontrolować.

W OpenAM w wersjach przed 16.1.2 metoda WebAuthnAuthentication.deserialize stosuje ObjectInputFilter, który zezwala na każdy serializowany obiekt na głębokości większej niż 1, ograniczając jedynie obiekt główny AuthenticatorImpl. Atakujący przed uwierzytelnieniem może dostarczyć userHandle, którego graf serializacji zawiera prawidłowy obiekt główny AuthenticatorImpl oraz zagnieżdżoną klasę gadget, powodując wykonanie readObject lub readResolve przed weryfikacją. Omija to niekompletną naprawę wcześniejszej podatności deserializacji WebAuthn.

W kontrolerze Sealed Secrets istnieje podatność w nieuwierzytelnionych endpointach POST /v1/verify i /v1/rotate. Atakujący z dostępem do wewnętrznej sieci może wstrzyknąć własną logikę szablonów Go w polu spec.template.data, a następnie wykorzystać różnice w kodach odpowiedzi HTTP (200 vs 409) jako wyrocznię deszyfrującą do odzyskania pełnego tekstu jawnego sealed secret. Problem potęguje brak powiązania pola spec.template.data z etykietą AEAD, co pozwala na dowolną modyfikację tego pola przy zachowaniu ważnego szyfrogramu.

W OpenAM domyślna konfiguracja inicjalizuje ciasteczko SSO iPlanetDirectoryPro z wyłączonym HttpOnly i bez ochronnego domyślnego SameSite, a przepływy zgody OAuth i OpenID Connect używają tego ciasteczka przez CsrfProtection jako tokenu CSRF. W połączeniu z XSS w tej samej domenie i kliknięciem przez użytkownika linku kontrolowanego przez atakującego ciasteczko może zostać odczytane i użyte do kradzieży sesji SSO oraz realizacji zgód zainicjowanych przez atakującego. Problem naprawiono w wersji 16.1.1.

W OpenAM w wersjach przed 16.1.1 AuthorizationCodeGrantTypeHandler wymaga code_verifier tylko wtedy, gdy włączone jest ustawienie codeVerifierEnforced dla całego realm. Ponieważ ustawienie jest domyślnie wyłączone, atakujący, który przechwyci kod autoryzacyjny chroniony przez PKCE, może pominąć code_verifier i wymienić kod na token. Klienci publiczni są bezpośrednio narażeni, a wykorzystanie dla klientów poufnych wymaga dodatkowo materiału uwierzytelniającego klienta.

W OpenAM ścieżka uwierzytelniania klienta private_key_jwt używa ClientJwksResolverCache bez niezawodnego powiązania buforowanego resolvera jwks_uri i zweryfikowanego asercji z oczekiwanym clientID w ClientCredentialsReader. Atakujący kontrolujący dowolnego zarejestrowanego klienta z opublikowanymi kluczami, w tym uzyskanego przez otwartą rejestrację dynamiczną, może uwierzytelnić się jako inny klient, którego klucze są udostępnione przez jwks_uri, i wystawiać tokeny w jego imieniu w różnych realmach w tym samym procesie OpenAM. Problem naprawiono w wersji 16.1.1.

W OpenAM GroovySandboxValueFilter pozwala uwierzytelnionemu autorowi skryptów po stronie serwera na ucieczkę z sandboxa pomimo domyślnych list dozwolonych i zabronionych klas. Użytkownik taki jak RealmAdmin podrealm, który może tworzyć lub edytować skrypty w kontekście wykonywanym, może wywoływać polecenia systemu operacyjnego jako konto serwera aplikacji OpenAM, przekraczając granicę administracji realmem i kompromitując JVM oraz wszystkie obsługiwane realmy. Problem naprawiono w wersji 16.1.1.

W OpenAM moduł uwierzytelniania OAuth2 aktualizuje istniejące konto lokalne atrybutami profilu, które mogą zawierać userPassword i inetUserStatus, przepisując hasło na nazwę użytkownika i reaktywując wyłączone konta. Brak filtrowania OAuth.removeRestrictedAccountUpdateAttributes pozwala tym polom poświadczeń i statusu dotrzeć do aktualizacji konta. Przy włączonym tworzeniu kont powtarzane logowanie OAuth powoduje, że domyślny łańcuch ldapService akceptuje nazwę użytkownika jako identyfikator i hasło, co pozwala nieuwierzytelnionemu atakującemu przejąć konto lokalne bez interakcji z dostawcą tożsamości. Problem naprawiono w wersji 16.1.1.

W OpenAM w wersjach przed 16.1.1 moduł uwierzytelniania MSISDN w MSISDNValidation konkatenuje wartość MSISDN z żądania do filtra wyszukiwania LDAP bez escapowania, a domyślna pusta lista zaufanych bram pozwala na cały ruch. W realmie, w którym moduł MSISDN jest włączony w osiągalnym łańcuchu uwierzytelniania, nieuwierzytelniony zdalny atakujący może wstrzyknąć metaznaki filtra LDAP, wybrać dowolnego pasującego użytkownika i uzyskać sesję OpenAM bez hasła.

W OpenAM OAuthTokenStore odczytuje identyfikatory tokenów dostarczone przez wywołującego ze wspólnego Core Token Store (CTS) bez przestrzeni nazw przeznaczonej tylko dla OAuth, a OAuthAdapter akceptuje wiersz, którego BLOB rzekomo zawiera token OAuth, bez powiązania zaufanego typu CTS i weryfikacji integralności. Atakujący, który może umieścić kontrolowany JSON w CTS pod znanym identyfikatorem tokenu, na przykład przez Push Registration, a następnie anonimowe wywołanie zwrotne SNS w włączonym realmie, może wygenerować tokeny bearer OAuth i tokeny ID OpenID Connect z wybranym podmiotem, klientem, realmem i zakresem. Problem naprawiono w wersji 16.1.1.

W OpenAM anonimowe wywołanie zwrotne SNS Push Notification obsługiwane przez SnsMessageResource po wygaśnięciu messageId z dyspozytora w pamięci sięga do predykatu blob CTS, traktuje klucze najwyższego poziomu blob jako nazwy klas Java dla Class.forName i deserializuje kontrolowany przez atakującego JSON przez Jackson. Użytkownik o niskich uprawnieniach, który rozpocznie Push Registration i uzyska messageId, wspólny sekret i wyzwanie, może poczekać na wygaśnięcie, zastąpić trwały blob przez anonimowe wywołania zwrotne i wywołać ładowanie i konstrukcję klas w JVM OpenAM. Problem naprawiono w wersji 16.1.1.

W OpenAM w wersjach przed 16.1.1 odbiornik SOAP Liberty Web Services pozwala nieuwierzytelnionym zdalnym żądaniom zapisywać trwałe wpisy przez SOAPReceiver i DiscoveryService do magazynu Liberty Discovery użytkownika oraz współdzielonej gałęzi Discovery root-realm. Handlery po stronie serwera omijają ACL LDAP i tożsamości, a ścieżka globalna używa wewnętrznego tokenu administracyjnego. Wdrożenia korzystające z danych Liberty discovery mogą następnie używać zmanipulowanych rekordów routingu usług lub mechanizmów bezpieczeństwa.

W OpenAM w wersjach przed 16.1.1 WebAuthnAuthentication ładuje serializowany graf obiektów AuthenticatorImpl z skonfigurowanego userAttribute przez loadAuthenticators bez ObjectInputFilter. Wykorzystanie wymaga osiągalności przepływu WebAuthn oraz wcześniejszego zapisania kontrolowanych danych do tego atrybutu przez delegowaną administrację, provisioning, dostęp do katalogu, starszą samo-rejestrację REST lub niebezpieczną konfigurację. Gdy te warunki są spełnione, dane są deserializowane przed weryfikacją asercji i mogą wykonać gadget z classpath w procesie serwera aplikacji.