Katalog podatności CVE

QloApps do wersji 1.7.0 zawiera podatność typu reflected XSS w wyszukiwarce Book Now systemu rezerwacji hotelowych w panelu back-office, gdzie parametry date_to i id_room_type są kopiowane do zmiennych szablonu bez walidacji. Atakujący może przygotować złośliwy link z ładunkiem JavaScript w tych parametrach, który wykona się w sesji zalogowanego administratora po kliknięciu linku.

Firmware AJA HELO Plus przed wersją 2.1.7 zawiera podatność typu stored XSS, która pozwala nieuwierzytelnionemu atakującemu z dostępem sieciowym wstrzyknąć złośliwy JavaScript poprzez ustawienie nieoczyszczonej wartości eParamID_SystemName przez API /config?action=set. Gdy uwierzytelnianie urządzenia jest wyłączone, skrypt wykonuje się trwale w przeglądarce administratora otwierającego interfejs zarządzania, umożliwiając kradzież sekretów (dane logowania do UI, klucze strumieni RTMP, adresy publikacji, dane logowania do udziałów NFS/SMB) oraz przejęcie sesji.

PyJWT to implementacja standardów JSON Web Token w Pythonie. Od wersji 2.11.0 do 2.13.0 metoda PyJWT._merge_options() może modyfikować przekazane przez wywołującego mutowalne mapowanie opcji, gdy verify_signature ma wartość false. Jeśli aplikacja ponownie użyje tego samego mapowania w późniejszym wywołaniu decode() lub decode_complete() i zmieni verify_signature na true, mapowanie może zachować wartości false dla sprawdzeń expiration, not-before, issued-at, audience, issuer, subject i JWT ID, co pozwala zaakceptować podpisany token z nieprawidłowymi zastrzeżonymi oświadczeniami bez wyłączania weryfikacji podpisu. Aplikacje tworzące świeże mapowanie opcji dla każdego wywołania nie są podatne.

Uwierzytelniony administrator Email Protection Gateway posiadający jedynie ograniczone, delegowane uprawnienia mógł zapisywać pliki o treści kontrolowanej przez atakującego w dowolnych lokalizacjach dostępnych dla konta usługi Email Protection Gateway. Wykracza to poza zamierzone uprawnienia administratora i może posłużyć do modyfikacji plików aplikacji i konfiguracji lub zakłócenia dostępności usługi.

Uwierzytelniony administrator mógł spowodować, że serwer wysyłał żądania do wewnętrznych usług sieciowych i wchodził z nimi w interakcję, które nie powinny być osiągalne przez ten interfejs. Sama w sobie podatność nie prowadziła do wykonania kodu.

Podatność na wyczerpanie zasobów w Kiteworks Email Protection Gateway pozwalała nieuwierzytelnionemu zdalnemu atakującemu wielokrotnie wywoływać stosunkowo kosztowną operację po stronie serwera, powodując częściową odmowę usługi.

Dwie operacje zarządzania klastrem w Kiteworks Core nie walidowały dostarczonych ścieżek plików, więc atakujący posiadający uprawnienia root na jednym węźle klastra mógł zapisywać pliki jako root na innym węźle i powodować ich wykonanie. Wykorzystanie wymaga dostępu root do backendu na węźle klastra oraz oczekującej poprawki oprogramowania obecnej na węźle docelowym.

Uwierzytelniony administrator mógł zainicjować import administracyjny przy użyciu pliku, którego zawartość nie została w pełni zweryfikowana, ponieważ import sprawdzał tylko nagłówek pliku, a nie cały plik. Mogło to pozwolić na zaakceptowanie i przetworzenie niezweryfikowanej lub sfałszowanej zawartości, wpływając na integralność importowanych danych.

Sprawdzenie autoryzacji w funkcji wymiany dużych plików Kiteworks Email Protection Gateway nieprawidłowo ustalało, czy żądający użytkownik jest stroną żądanego pakietu. Uwierzytelniony użytkownik tej opcjonalnej funkcji mógł odczytać temat, treść wiadomości i załączniki pakietów, których nie wysłał ani nie otrzymał.

Uwierzytelniony administrator może obejść walidację treści stosowaną przy przesyłaniu plików administracyjnych i zapisać na urządzeniu plik zawierający niebezpieczną treść. Sama ta podatność nie prowadzi do wykonania kodu — do uruchomienia zapisanego pliku potrzebna jest osobna luka.

W środowiskach wielowęzłowych atakujący, który uzyskał już wykonanie kodu na jednym węźle urządzenia, może przesłać przez wewnętrzny interfejs klastra wartość zapisywaną do konfiguracji monitoringu na innym węźle bez wystarczającej walidacji, co potencjalnie pozwala na wykonanie poleceń systemowych na tym węźle. Wykonanie ograniczone jest do nieuprzywilejowanego konta usługi na tym węźle.

W klastrze Kiteworks Email Protection Gateway z włączoną replikacją bazy danych strona zaufana przez klaster może przesłać spreparowany obiekt serializowany, który jest deserializowany bez wystarczającej walidacji, co potencjalnie pozwala na wykonanie kodu jako konto usługi bramy. Replikacja jest domyślnie wyłączona, a wykorzystanie wymaga kontroli zaufanego węzła klastra lub dostępu administracyjnego do urządzenia.

Kiteworks Core nie stosował mechanizmów bezpieczeństwa API na poziomie bramy do każdego żądania uwierzytelnionego przez centralną usługę uwierzytelniania platformy. Uwierzytelniony użytkownik mógł uzyskać dostęp do funkcji REST API ścieżką żądania, na której te mechanizmy — w tym egzekwowanie wylogowanych i unieważnionych sesji — nie były stosowane.

Opcjonalna, licencjonowana osobno funkcja łącznika repozytorium w Kiteworks Core nie neutralizowała znaków specjalnych w ścieżce podanej przez użytkownika przed przekazaniem jej do zewnętrznego polecenia. Uwierzytelniony administrator systemu mógł wstrzyknąć dodatkowe polecenia i zapisać dowolną treść w plikach należących do konta usługi uruchamiającego łącznik, co umożliwia wykonanie kodu w kontekście tego konta; wykorzystanie wymaga dodatkowo wyjścia sieciowego z urządzenia do systemu kontrolowanego przez atakującego.

Interfejs konfiguracji urządzenia Kiteworks nie wymuszał uwierzytelniania po zakończeniu wstępnej konfiguracji urządzenia. Nieuwierzytelniony atakujący z dostępem sieciowym do urządzenia mógł odczytać i zmodyfikować ograniczony zestaw rekordów konfiguracyjnych, w tym nazwę kontaktu i adres e-mail zapisane podczas wstępnej konfiguracji.

Kiteworks nie egzekwował poprawnie, jakie role menedżer folderu współdzielonego może przypisywać. W domyślnej konfiguracji uwierzytelniony użytkownik z rolą Menedżera folderu mógł nadać rolę Właściciela sobie lub innym członkom tego folderu.

Kiteworks nie egzekwował maksymalnej dozwolonej wartości dla konfigurowalnego ustawienia zasad bezpieczeństwa. Uwierzytelniony administrator mógł ustawić tę wartość poza zamierzonym zakresem, przez co powiązana kontrola nigdy się nie aktywowała, mimo że w interfejsie administracyjnym i dzienniku audytu nadal wyglądała na włączoną, co pozwalało na ciche unieszkodliwienie mechanizmu ochronnego.

Endpoint używany podczas początkowej konfiguracji urządzenia nie wymagał uwierzytelnienia i nie egzekwował poprawnie warunku stanu, więc w oknie początkowej aktywacji nieuwierzytelniony atakujący z sieci mógł wielokrotnie wywoływać uprzywilejowany proces aktywacji. To mogło zakłócić konfigurację i pozostawić urządzenie w niekompletnie skonfigurowanym stanie. Problem jest osiągalny tylko podczas pierwszej aktywacji urządzenia, gdy nie jest jeszcze w pełni skonfigurowane.

Kiteworks Core zawiera błąd logiki biznesowej w funkcji żądania plików, który pozwalał uwierzytelnionemu użytkownikowi wysłać żądanie wyglądające na pochodzące od innego użytkownika, ponieważ serwer nie weryfikował, czy osoba żądająca jest upoważniona do działania w imieniu wskazanego konta. Można to wykorzystać do wyłudzenia plików lub informacji od odbiorcy pod zaufaną tożsamością; wykorzystanie wymaga włączenia tej funkcji w profilu atakującego i reakcji odbiorcy na żądanie.

Kiteworks Core przed wersją 9.5.1 jest podatny na wstrzykiwanie treści. Parametr URL w przeglądarce PDF był niewystarczająco walidowany, co pozwalało na załadowanie i wyświetlenie dokumentu kontrolowanego przez atakującego w zaufanej domenie aplikacji. To mogło zwiększyć wiarygodność ataków phishingowych opartych na złośliwych linkach osadzonych w wyświetlanej treści.